GWT and big applications

[mrblue]

How GWT works with applicactions which have about 50-70 screens
(forms)? It should be created on one page? I think I'll have a lot of
JS and my GWT application will work very slow.

[~Young Devil]

well, its created on the client side.. if its too big of an
application.... then you might have a problem with the
Browser .....with GWT,
a javascript is created and its shiped on the clients browser and..
then on the clients browser and memory your application is
loaded...... so depending upon the client configuration loading time
may differ... and if the application is just toooooo big then there
can be a possibility of browser crash.

so, check with your apps.. and use stuffs carefully

[os2be]

maybe there is a way to split the project...

one screen = 1 project

[os2be]

try one screen = one gwt project

On 12 mar, 09:03, mrblue <p...@interia.pl> wrote:

[Jason Essington]

As it turns out, the size of the javascript doesn't increase linearly
with the size of the application.

As you begin to reuse widgets on additional "forms" you don't incur
additional bytecount for that reuse, so large applications tend to be
just fine in GWT.

I have yet to hear of anyone who as had the javascript payload of
their large application overrun the available memory in the client
browser.

Overall, the one module (page, project) per form idea that is
typically used for server side technologies is particularly
inefficient when it comes to GWT because you will end up not
benefiting from code reuse (talking about the compiled javascript
here), and your overall byte count will likely be quite a lot larger.

-jason

[David]

Hey,

It all depends on how the applications handles the screen switching
ofcourse. If you put all the screens in a big DeckPanel then I'm sure
the application will slow down when you really have a lot of screens.
But if you are smart enough and just keep the panels which state must
be preserved (when going back and forth through a flow) then the
number of screens do not have much impact.

The JavaScript file grows, but as Jason said its not linear... in fact
its hard to beat the compactness of the generated code, and if your
applications defines reusable widgets you will see a very small
increase when a screen is added. We have a large application running
in GWT and the generated code is about 100KB.

If I look at some old struts application we created in the past... I
noticed that someone managed to add a JS calendar widget that was
actually 200KB in size!

David

[Rob Wilson]

Also when compared to solutions that use flash, you really shouldn't
worry - I often see flash sites set up that are 1MB+ just for the
initial page (yuck!).

> > > JS and my GWT application will work very slow.- Hide quoted text -
>
> - Show quoted text -

[arthu...@gmail.com]

It's a problem only if you're loading a hundred widgets at once. If
you are lazy loading your various screens, you'll be fine. Just keep
in mind that loading 100+ widgets at once will put the browser at 100%
CPU until they're all loaded. This can of course be fixed by using
DeferredCommand and when you couple that with lazy loading, your app
should be fine. If you want to load everything in the beginning, you
can have a splash screen (like gwt-ext) and load all the widgets in
the background using DeferredCommand.

[jgr...@gmail.com]

mrblue,

No one can really answer the question for you. Think about how long a
user will stay within your application. My company makes a
heavyweight RIA which is about 1MB of HTML & Javascript in a single
web page. Compared to a "normal" web page, like Google's home page,
it takes forever to download, and it takes even longer to render. But
our users stay on that one web page for hours, and once it has
rendered it is incredibly fast and responsive.

For your application containing 50-70 forms, you should think through
how users will use your application. Are users going to fill out one
or two forms then be directed to another application or website? If
so, you better keep that initial download and rendering time to a
minimum. Or, will users live within your application for hours at a
time? In this case, you want to minimize the number of pages, render
the parts of your application lazily, and keep the interactions with
the server to asynchronous HTTP requests.

Hope that helps.

Cheers,
James

[NN]

yeah it is true how your user going to use different forms or page of
website. I mean first page must be fast for normal websites compare to
any financial application or intranet apps based on RIA.

I like Flex as well because of rendering of UI and available widgets
with charting and ready made components. GWT has third party libraries
but they won't have performance or nor guarantee when data sets are
very high. But I have not use either of them for large data sets but
initial impression is clear. After working on GWT one thing stuck & in
Flex base apps as well that if you stay in one or two screens it works
wonderfully. If you want to replace PHP or JSP base website into GWT
or Flex you are into different mod. Yeah I am not very precise in
comments but tire of repeating pros and cons since it is discuss at
length on this forum and other places as well.

[Jason Essington]

One thing to keep in mind, even if your Javascript payload (compiled
application) is quite large, your users should only incur the download
delay once if the server is properly configured to instruct the client
to cache the file. So, for say a large internal RIA, only the first
visit to the application is going to have a pause while the
application downloads, repeated visits should start instantaneously.

As for rendering complicated forms, yes it is possible that those
could take some time. But, if you design your application properly you
can avoid the appearance of a stalled application. For instance, if
you begin rendering a complicated form (hundreds of cells in a grid
for example) you can render just a few (50 - 100 or so) at a time
using an incrementalcommand, which will allow the application to
remain responsive even while the form continues to render.

For instance, I've been benchmarking the rendering of a 100 x 100 grid
with a label in each cell. If the grid is rendered synchronously, the
browser will stall for about 5 seconds while all of the DOM objects
are created and attached, however if the grid is created, then
populated using an IncrementalCommand that fills 200 cells per
iteration, the browser only stalls for about 25 milliseconds (not
detectable by the user) and continues to fill the cells while still
allowing the user to use the UI. This is a handy technique for
rendering very complicated layouts.

-jason

[Andrij Skalyuk]

I have experience in big GWT application with about 30 forms (i mean
insert data, update data, some special forms, reports etc.).
Performance is very good. I use many UI generation on the fly.

[matias_warrior]

I have an application with many forms, about 30-40.
Each form is a panel and I switch between them showing one panel and
hiding all the others. I actually remove all panels from the root
panel, and let only the one I want to see.
I creates the panels on demand, when the user first enter the form.
But once the panel is created, I keep it in memory.
So, If the user enter all the forms at least one time I will have all
them in memory.
The app becomes a little slow, especially with key events in textbox,
after the user has used many forms.

Would it be better if I create and then drop each form, every time the
user enter?