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.
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
On Mar 12, 1:03 am, mrblue <p...@interia.pl> wrote:
> 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.
> 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.
> 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.
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.
> 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.
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!
> 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
> On Mar 12, 2008, at 2:03 AM, mrblue wrote:
> > 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.
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!).
On Mar 12, 4:11 pm, David <david.no...@gmail.com> wrote:
> 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
> On Wed, Mar 12, 2008 at 4:56 PM, 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
> > On Mar 12, 2008, at 2:03 AM, mrblue wrote:
> > > 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.- Hide quoted text -
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.
On Mar 12, 4:03 am, mrblue <p...@interia.pl> wrote:
> 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.
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.
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.
On Mar 12, 5:03 pm, "jgr...@gmail.com" <jgr...@gmail.com> wrote:
> 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.
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
On Mar 12, 2008, at 7:03 PM, jgr...@gmail.com wrote:
> 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.
