Unresponsive Javascript on complex GUI

Dear Vaadin Community:

I’m implementing some kind of very complex UI with a lot of nested layouts, validators and data source listeners; and everything is working really great at the moment. To provide you some more context, on this interface you can add more and more objects (with all its stuff such as listeners and validators) and save your changes. The only problem I have seen at the moment is that after some lenght in the HTML DOM, Firefox 6 and IE8, fail loading the component. The next message is displayed on Firefox:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://mywebpage.test.com:8080/test/VAADIN/widgetsets/com.test.widgetset.TestWidgetSet/EC23FB31D0A230E26A0958EBB3EEE690.cache.html:3041

And a simmilar one on IE8; on the other hand, Safari, Chrome and Opera work fine, (some times slowly) So my point or questions are:

“What would you recommend me to solve this issue, since the problem is on the client side?”
“How long does the HTML DOM can be, to be supported by Firefox and IE8?”
“Have you ever experiment the same problem as me creating custom components or complex views?”

Since I don’t understand very well, what’s happening there, I did some tests removing validators, listeners and layers; and it seems to be a multifactorial problem involving those three elements, making the script unresponsive once executed (I sized the whole script and its 20 KB ). I know that the client can change its Firefox configuration:
to zero; but that’s not an option.

I will appreciate any advice or sugestion about how to avoid this unresponsive javascript problem.

Regards: Samuel

As the problem is on the client-side, validators, listeners and other server-side stuff should not be relevant.

It’s hard to say what could be the problem. The script error means that the layout is extraordinarily heavy to render by the client-side engine of Vaadin. Some components are faster to render than others. Vaadin layout components make a lot of size calculations that can be slow, and complex layouts and big tables or grids with nested components can be too heavy. Using lighter layout components, such as CssLayout or FastLayout add-on, can help. Deep nesting can cause trouble.

Thank you Marko for your suggestions. For a quick test, I changed all my Layouts to CSSLayout and ran my code, the result was just the same and I got again the message of unresponsive javascript on Firefox.

I’ve counted the depth of my DOM’s tree, and I found my deepest element is at 71 levels from the tag, that number may sound excessive but my work started on the 37th level (I’m developing Liferay Portlets), and the theme, liferay and velocity are adding lots of boxes of boxes.

To provide more info about my case, I’m using DragAndDropWrapper, (two nested dragg-and-drop), Basically is a list of objects that can be dragged to reordering them, and each element of the list may contain another nested list of objects that can be dragged too.

I really appreciate any advice or suggestion about how to manage this situation (nested forms with DragAndDropWrapper), Do you think this may be making the DOM too heavy to be rendered by the client-side engine of Vaadin?

Before implementing a re-engineering of my GUI, What should I take care of, to avoid this Firefox nasty response?

Kindest regards: Samuel

I had the same problem today: there is a table on our UI containing Labels inside VerticalLayouts with ClickListeners. When the size of the table is about 8x50 and above, using the UI was only possible with chrome… firefox said the script is not responding, and IE was unusably slow. Examining the DOM revealed that each cell contains 8 divs. I developed a custom component which renders everything into one div, and containts only the neccessary logic and nothing more. It was a HUGE improvement… everything works well now. Maybe something like this can be a solution to your problem.

Thank you Ferenc for the advice, I just gave up and made another “step”; instead of showing all the complex components at the same time on the view, I only show the title and button to edit it, when the user clicks the button, a new window display the “details” for the component. Now in Firefox some times is slow (I think I have to improve the memory usage too) but it’s not displaying the unresponsive javascript message.

Well, I think the lesson here is to make simple interfaces, nothing more complex than a form with at most 20 fields I counted, more or less; I hope future versions of GWT and Vaadin may support more DOM depth and less tags per layout; I hope this advice will be useful for someone.

Yes, making UIs simple is a good approach, also for usability.

Sometimes UI performance problems are caused by real problems with some components or component combinations. For example, there has been very unexpected performance issues with ComboBoxes inside a Table, etc. In cases where the performance impact is serious, you could consider filing a bug report. Layout calculations are often a major cause of problems.