GWT application architecture

5 views
Skip to first unread message

Benjamin G

unread,
Jun 19, 2006, 10:36:55 AM6/19/06
to Google Web Toolkit
Hi all,

I'm trying out the GWT and considering it to write a not-so-smallish
application. It has two roles (admin & user) which both have different
tabbed menus.

I'm used to write applications in Struts and Swing. GWT seems to
emulate the Swing model, however my question is:

If I have several tabs with different panels each, will performance
degrade as a user performs functions under different tabs? Under the
"old" web development model this wouldn't matter too much since each
time a new tab is selected, the browser goes to the URL, refreshes and
(I assume) most memory structures and javascript are cleaned up.

How does this work with GWT? Does performance degrade after continuous
usage of a pure-javascript presentation layer with different views or
is this not an issue? Should I create all the views under a single
servlet, or split them among different servlets with different url
mappings (kind of like struts with its action mappings)?

Thanks in advance,
Benjamin.

Sam

unread,
Jun 19, 2006, 11:08:30 AM6/19/06
to Google Web Toolkit
With a large application you want to avoid keeping to large a DOM in
memory. The larger the DOM the slower the performance (at least in a
lot of cases and browsers).

As you navigate around you should in most cases destroy all javascript
objects/screens that are no longer visible. This forces more server
hits of course as you navigate around and rerender the screens.
However, in the grand scheme of things this is preferred in a
multi-user application anyway as the data you may have cached on a
previous screen can become stale. It is a balance you must strike.

-Sam

bruciadmin

unread,
Jun 20, 2006, 12:28:04 AM6/20/06
to Google Web Toolkit
I wonder, and feel free to jump in someone who knows more, if the
javascript objects we work with are part of the DOM tree?

If they were detached, would the browser still perform well if the DOM
tree was kept "trimmed" but the number of "in memory" Javascript
objects were relatively large. That way, when sub sections were called,
they could be re-created from the Javascript objects if they were
already in memory, or retrieved from the server if not. If this were
the case, people could focus larger applications on creating pages on
demand from javascript objects rather then retrieving them.

Dave

Reply all
Reply to author
Forward
0 new messages