1

I am working on an application that has a "tree" that users can navigate to select items from, and the UI element being employed is the jQM collapsible widget. When the user clicks a "parent" item, "child" nodes are added to the collapsible. One of the "parent" items in the tree expands over 1200 items below it.

This all works fine in FF and Chrome, however in IE it becomes very sluggish when the parent item with over 1200 child items is expanded. You should be able to check this for yourself with the following fiddle:

http://jsfiddle.net/1q40qytg/

Just click the "Test" button to add the nodes below "Root", then click on any of the child items to expand/collapse them. For me, at least, the difference between browsers is quite noticeable.

I'm looking for suggestions as to whether there might be a way of making IE perform better, or just a better way of handling such a large number of child items.

<ignore>Here's some bogus code to satisfy SO</ignore>
Dave Nottage
  • 3,411
  • 1
  • 20
  • 57
  • You can increase performance by using pre-rendered markup as: http://jsfiddle.net/ezanker/1q40qytg/6/ See bottom of this page: http://demos.jquerymobile.com/1.4.3/collapsible/ – ezanker Aug 08 '14 at 14:32
  • @ezanker The performance issue is not in the adding of nodes; it's in the operation once the nodes are added. In IE, clicking on them to expand/collapse is noticably slow; in FF, there's no noticeable difference. – Dave Nottage Aug 11 '14 at 00:08
  • I've ended up completely ditching the collapsible widget. I've written custom code to build the content with the same styling as the widget, and handle the events in the custom code. The result is that it now flies along way, way faster, including expanding/collapsing on IE. The only issue now is that the single (jQuery) append used to populate the collapsible content on IE is over 5 times slower on IE than on FF, however it is still within a reasonable limit. – Dave Nottage Aug 14 '14 at 05:48

1 Answers1

0

Rendering 1200 items is slow in any browser. Try Android 2.x to see how long this would take.

When you get the list to load you should ask yourself the real question = whether your users will be willing to scroll that far to see an item at the bottom? Consider instead to use a filterable widget on top of your list demos and maybe provide the items mostly used on the top of your list.

If this is not an option, consider providing pre-enhanced markup vs enhancing on the client/browser.

frequent
  • 27,643
  • 59
  • 181
  • 333
  • See my response to ezanker. Haven't tried Android 2.x, though it's doubtful any of our users will be using lower than 4.x. I'd forgotten about filterable; I'll be having a look at that, thanks! – Dave Nottage Aug 11 '14 at 00:05