Javascript Treeview is slow! #103

mvriel opened this Issue May 8, 2011 · 7 comments


None yet
3 participants

mvriel commented May 8, 2011

The jQuery Treeview is rather slow and does not perform well with large codebases. Such as Zend Framework.
When opening a page in (for example) Internet Explorer 8 or even Firefox 3.6 the OS warns that the application has become unresponsive because the Javascript is working thus hard.

I have written a light alternative to the current treeview in jQuery and noticed that the initial loading of jQuery, or jQuery UI might be the cause of the issue

                $('.filetree li ul').parent('li').toggleClass('expandable').prepend('<div class="hitarea closed-hitarea expandable-hitarea"></div>');
                $('.filetree li div').click(function() {
                $('.filetree li span:not(a)').click(function() {
                $('.filetree li span:not(a)').hover(function(){jQuery(this).addClass('hover');}, function(){jQuery(this).removeClass('hover');});
                $('.filetree li:last-child').addClass('last');

More effort should be put in optimizing the Javascript in the sidebar before the next full release.


mvriel commented May 24, 2011

Suggestion from Phil Sturgeon: try to implement the possibility to highlight the active file / class in the sidebar (may become a separate issue)


mvriel commented Jun 12, 2011

Will have to move this to the next version; not enough time left to implement


onigoetz commented Aug 24, 2011

Hi, I'm currently investigating on this and have some ideas and informations

I got the same problem with the slow tree on firefox 6, but could partly solve it by enabling only one tree ... because, having 2 or 3 trees (namespace, packages and files) is very resources consuming, more when we have a big framework like zend.

My first Idea was to transform all this into one big tree. this would remove a lot of processing, and remove the accordion.

The other idea was to have a lazy loading tree, that means, that doesn't parse the tree once and for all. but this would meant that we could not implement the tree "filter"

I'll try these two solutions and tell you which is the best in my opinion


onigoetz commented Sep 11, 2011


I just thought about all this these days.

My Idea is :
the slowness comes from the fact that the whole tree has to be parsed and treated to implement the onclick events and all this stuff on the page loading.

the options would be to have this as a json tree and load it on the fly when we need it ...
this would lead to a much more responsive system.
but the problem comes up if we want to have a filter system.

If someone has an other idea about this ...


rvanvelzen commented Sep 20, 2011

Another idea would be to not implement onclick-handlers on all seperate links, but on the entire tree. You could find the link which was clicked in which could also produce much better results.


mvriel commented Sep 20, 2011

I am working on a prototype which has onclick handlers on the accordion which assembles the treeview just in time; soon I have a working example


mvriel commented Oct 1, 2011

A new version of the sidebar has been implemented which waits with initializing the treeview until you actually open the specific section of the sidebar. this should solve a lot of issues.

mvriel closed this Oct 1, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment