Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    @codedude As we have previously explained, a large community of users and many mega-corporations disagree with your opinion.

    Here again is the right kind of assessment to make on whether to use SmartGWT for a given application:

    If your users will use the application infrequently and briefly AND many of them will not have broadband AND you cannot use a CDN or similar approach AND you have no way to mask the download time (see background downloading) AND your app doesn't require anything unique to SmartGWT AND you decide that it makes sense to spend extra time in development and delay release in order to save your users a few seconds wait on the first ever access THEN yes by all means use another technology, SmartGWT doesn't solve every problem and it would be worse if it tried to.
    This excludes only ultralight applications, such as the landing page of a site that serves primarily content. For such ultralight applications GWT is unsuitable, because:
    • GWT's widget system will never match JQuery's ultralight footprint for basic interactivity
    • GWT is an awkward technology to use for sites that are mostly about content rather than interactivity (eg, mainstream CMS integration lacking)
    • perhaps worst, GWT applications grow in proportion to their most complex screens, forcing you to keep dividing the application to keep a light footprint on key landing pages, which basically throws away many of GWT's key benefits.


    Codedude, as we mentioned before, posting your .. unique .. opinion in various places only forces the SmartGWT team to waste time making sure the full story is told. This hurts SmartGWT and the SmartGWT community. This discussion has already been pursued exhaustively, let's leave it alone now.

    Leave a comment:


  • mihai007
    replied
    Usually when i do a webpage it comes with a backend for administration so the customer customizes it's content alone. For this SmartGWT is a great value.

    Leave a comment:


  • codedude
    replied
    Just use native GWT no need to use jquery

    Originally posted by yariv.snapir
    Thanks for you responses.
    Wrt firebug, it was disabled when I tested download time. I only used it to see what files are downloaded and its size - I know better then to look at download time in firebug.

    I see your point on the Boeing vs. space shuttle. Nice analogy, only please consider that a space-shuttle is the one being used twice a year (at most) where the Boeing is used thousands of time each day :).

    I think it is a pity that you are giving up on the small-time application world. Going back to the "home pages" or other even semi static sites, they too can use your client (even if its not for the handling of large data-sets) if it was possible to download only what you really need.

    Maybe to explain where I come from would help:
    I am considering a new client library for the use of MANY developers. Developing both kinds of applications. Small time as well as enterprise. I would want to be able to use one client library for both cases instead of introducing multiple new libraries.

    Again, Thanks for your very quick and elaborate answers it definitely helped me
    Just use native GWT for realworld used multiple times a day no need to use jquery google has done amazing amount of work to decrease size and increase performance of GWT ........also maintaining jquery is a mess..................as I found out ........smartgwt is only good for those corporate lan apps or complex dinosaur apps
    Last edited by codedude; 9 Apr 2009, 03:41.

    Leave a comment:


  • lo-ran
    replied
    On-Demand Javascript loading ?

    what about dynamically (lazy) loading javascript code only when it's actually required ?

    See http://ajaxpatterns.org/On-Demand_Javascript

    Leave a comment:


  • kajkurt
    replied
    I would like to take up this post again, if it's not a problem. I am also experiencing some high load times with my modules. The problem, when looking at firebug, is that the files are being loaded synchronously. Shouldn't it be possible to merge the libraries included in GWT with the gwt JS code so one big JS file is being sent instead? If this isn't possible, are there any tools available for merging these JS files so I'll get rid of the synchronous loading.

    Leave a comment:


  • Isomorphic
    replied
    Yariv, we've seen many companies try to find a single library for both the "lightweight homepage" use case and the enterprise application use case, and they all eventually come to the conclusion that the use cases are too different and two libraries are required. This is also what Forrester and other analysts will tell you.

    By recommending JQuery for the lightweight homepage case, we're giving you the actual solution, not "giving up" on this use case. Standardization is important and it's key to use a minimal number of libraries, but not at the expense of using one tool for two different jobs and doing both poorly :) The important thing is to find a single vendor that supports this mixed use, as we do.

    Importantly, component by component loading does not mean that a library can handle both use cases. The simple, technical reason for this is that any well-factored library that supports the enterprise application use case ends up with a common component framework used by all components. Using any single component pulls in this common code, and even GWT's static analysis will not substantially reduce it.

    All you need to do to convince yourself of this is build a minimal GWT or ExtGWT application: you'll find yourself 6-8x heavier than JQuery with less functionality. Consider that Google themselves do not use GWT for any of their light to medium weight pages or applications.

    Or, look at Dojo. It has a widely touted minimum size similar to JQuery, but, like SmartClient's FileLoader, it's primarily capable of loading the rest of the framework and little else :) Dijit (dojo's core widget framework) is far too large for the "lightweight homepage" use case.

    By contrast, many of the basic widgets available for JQuery and other tiny Ajax libraries are completely purpose-specific: they rely on JQuery only and have no common code with other widgets. This is very inflexible, creates great inconsistency across widgets, and is totally wrong for an enterprise application framework. But it's absolutely the right thing for a page that needs to be super light and has very minimal dynamic functionality.

    Anyway, you don't need to take our word for it. There are countless companies with a JQuery front page and a different technology in use for enterprise applications. Just look around :)

    Leave a comment:


  • yariv.snapir
    replied
    Thanks for you responses.
    Wrt firebug, it was disabled when I tested download time. I only used it to see what files are downloaded and its size - I know better then to look at download time in firebug.

    I see your point on the Boeing vs. space shuttle. Nice analogy, only please consider that a space-shuttle is the one being used twice a year (at most) where the Boeing is used thousands of time each day :).

    I think it is a pity that you are giving up on the small-time application world. Going back to the "home pages" or other even semi static sites, they too can use your client (even if its not for the handling of large data-sets) if it was possible to download only what you really need.

    Maybe to explain where I come from would help:
    I am considering a new client library for the use of MANY developers. Developing both kinds of applications. Small time as well as enterprise. I would want to be able to use one client library for both cases instead of introducing multiple new libraries.

    Again, Thanks for your very quick and elaborate answers it definitely helped me

    Leave a comment:


  • Isomorphic
    replied
    @yariv SmartGWT is not for building home pages that present static data. Neither SmartGWT nor ExtGWT is appropriate for that purpose.

    To say that ExtGWT is more nearly appropriate for a mostly static page is like saying that between a space shuttle and a Boeing airliner, a Boeing airliner is better for commuting down the freeway to work. Technically correct but you wouldn't use either vehicle to drive to work, both are wildly inappropriate :)

    To us, ExtGWT inhabits an awkward middle ground: it is not nearly as productive for building complex enterprise applications as SmartGWT and the result is not nearly as good. And, despite the focus on being lightweight, it is not nearly lightweight enough for the use cases where SmartGWT is overkill.

    For use cases like adding a flyout menu system to a homepage or adding some pizazz to an e-commerce site, JQuery or Scriptaculous make much more sense. These systems have extremely tiny widgets which are very easy to set up, are not particularly extensible but don't need to be for their target use case. They will remain tiny over time because they are not being simultaneously subjected to the requirements of an enterprise grade menu system (like, say, binding to a load on demand tree model).

    Given the ability to use JQuery and SmartClient in tandem, as several of our customers do, and given SmartClient's ability to download in the background while the user is logging in, it's hard to see a case where ExtGWT is the most effective tool. Perhaps an enterprise app that you use only twice a year, only briefly, and that you use over a very slow network, so that load time from clean cache matters..?

    Bottom line, if you are building an application where it makes sense to consider either ExtGWT or SmartGWT, the vast majority of the time you are in a use case where component-by-component trimming is going to have a negligible impact on actual perceived performance. You would be serving your users much better by analyzing the number of round trips to the server during common interactions, and how to reduce them.

    PS. on your numbers, I'm not sure what you're measuring, but it absolutely makes an impact in terms of load time and initial render time that the SmartGWT showcase has 6 times the samples and shows far more functionality. I should also mention, if you're measuring all this with Firebug, comparative numbers are bogus because Firebug is known to have a greater performance impact on larger frameworks and applications. And furthermore, Firebug slows down all applications a great deal, so you are not seeing real-world load or response times for either framework. It's easy to get worried about performance while measuring with Firebug and then realize that there isn't a problem as soon as you turn Firebug off! :)

    Leave a comment:


  • yariv.snapir
    replied
    The size of EXT-GWT explorer code (regardless of the core EXT size) is 770Kb, the size of the SmartGWT code is 736Kb.
    Since the first page only loads the javascript and builds ONLY the first introduction pane and the tree, there is no relevance to the number samples, since it is not being executed.
    Also, there is no relevance to the number of datasets or samples since it the first introduction page never loads it. And if it does, then its part of the ~700Kb which is quite the same for both demos.
    So I do think the comparison is valid from this perspective.

    I agree (and also mentioned it) that data binding and data handling design are differentiators.
    However, if we take of the 262Kb of ISC_DataBinding, the rest is still much larger.
    It may be that more of the advanced code is in part in the other files as well (I assume so) and I can understand that this is what makes SmartClient much larger overall.

    I am happy that you mentioned that you "do plan to make it easier to trim off components you aren't using at a finer granularity". That is my most impotent point.
    Let me load, only those parts I use. This way, who cares which library is larger.

    You keep mentioning real-world. I visited parts of it.
    NOT all real-world applications are fortune-500, not every application has a large data-volume. Some just want to look and act pretty. For these, loading time that look as if you handle large data volume - is not so good...
    Most home pages in the world present static data. It could be in grids, tabs etc or other fancy widgets. It almost always use forms (357Kb!).

    To summarize my one and only point. I agree SmartClient is "smarter".
    There should definitely be more finer granularity in order to improve load time - "what you see is what you load!!"
    When it will be like that, there would be less to argue about.

    Leave a comment:


  • Isomorphic
    replied
    yariv:

    First understand, when it comes to the real-world performance of enterprise applications, SmartClient has a very dominant lead over Ext-GWT and others. Real users not only load but use applications :) The key factor in performance of enterprise applications - speaking across many industries and applications - is the number of server trips that require dynamic responses, in particular the number and severity of hits on the database. In this area - again real world performance - SmartClient has a dominant lead because of it's advanced data management architecture.

    SmartClient is larger, and it is larger because an explicit tradeoff is being made to be more dynamic and do more work on the client-side. We are always tuning for size, and we do plan to make it easier to trim off components you aren't using at a finer granularity, but understand that we will never try to match Ext's current size because doing so would necessarily imply taking backward steps in functionality. Both libraries are equally compact and SmartClient simply delivers more. When SmartClient's feature set was more comparable to Ext, it was Ext's size. In a few years if Ext's feature set reaches where SmartClient was in 2008, it will be SmartClient's size from 2008.

    Also, you somewhat touched on this, but your comparisons of the showcases are quite invalid. There are almost 6 times as many samples in the SmartGWT showcase, as well as several large datasets, and much, much more sophisticated functionality is demonstrated.

    It is definitely difficult to do direct comparisons, but if you have an enterprise architect who is experienced in evaluating performance, they will quickly spot many features in SmartClient that make the result of the comparison a foregone conclusion for any complex, large data volume application.

    Also not sure why you think this:

    "In favor of SmartGWT I can say that its internal design is better with the Data-binding and Data-sources. In most cases you will not need to use it but when you do, it’s better."

    Substantially all real-world SmartClient applications use SmartClient's data binding architecture, and such applications are deployed pervasively throughout the Fortune 500. If you are trying to do a comparison and have come to the conclusion that SmartClient's databinding doesn't apply in most cases - there's no way around it - you need to pretty much start over :)

    Leave a comment:


  • yariv.snapir
    replied
    SmartGWT and EXT-GWT benchmark

    Please see some benchmark details - comparison with EXT-GWT

    The SmartGWT showcase size is 3Mb whereas the EXT showcase is 2Mb

    If you compare the sizes of the core javascript downloaded for each of the libraries (EXT/SMART) the results are as follows:

    EXT - total core javascript size is about 500KB (ext-all.js) (you can compile a smaller library using only components you choose)
    Smart - total size is larger:
    ISC_Core – 455Kb
    ISC_Foundation – 160Kb
    ISC_Containers – 70Kb
    ISC_Grids – 416Kb
    ISC_Forms – 357Kb
    ISC_DataBinding – 262Kb
    ISC_Calander – 50Kb


    Obviously you can load only those you want but still you will probably at least use grids, containers Core and Foundation which is together 1.1 Mb – this is still very large comparing to Ext.

    We all use Zip filters obviously which makes actual network size:
    Smart-All – 467Kb
    Smart (Core, Foundation, Containers, Grid) – 270Kb
    EXT-All – 136Kb

    Assuming we download once and the content is cached, there is still the JS load time (syntactic parsing of javascript) which will happen for every page load, and there is a big noticeable difference.

    Wrt CSS:
    Core CSS file size for ext is 112Kb (ext-all.css) – it can be reduced depending on components used.
    Core CSS size for a SmartClient skin is 50Kb
    CSS makes much better zipping ratio then JS and much faster syntactic parsing time. So this is a negligible difference
    Zip size for CSS is:
    EXT-ALL – 13Kb
    Smart-All – 8Kb


    Summary:
    Ext is definitely better from this perspective.

    One more benchmark:
    I installed both SmartGWT showcase and EXT-GWT explorer locally and simply opened it (as static HTML) – with no app-server…

    EXT-GWT explorer loads twice as fast (4 sec) then the SmartGWT showcase (8 sec).

    Yes, it’s not the same application but it is very similar:
    Both applications load a static tree structure on the left pane and one initial tab on the right-side tab panel.
    Everything is static, download times are minimal, most of the time is spent on parsing javascript and CSS (HTML is minimal) and creating the DOM tree.

    I also compared the initial download times of both DEMO’s from the web. It’s not the same network path so it’s not a very valid comparison,
    However, EXT-GWT explorer loaded in 15 sec whereas SmartGWT showcase in 27 seconds!

    In favor of SmartGWT I can say that its internal design is better with the Data-binding and Data-sources. In most cases you will not need to use it but when you do, it’s better.

    Question: Is there any ongoing effort to improve SmartGWT in this perspective?

    Leave a comment:


  • Isomorphic
    replied
    Hi pbackx - another quick tip - it looks like your page is definitely not using the Forms, Calendar or RichTextEditor modules, but they are being included. You might also be able to get rid of DataBinding (if you don't use a DataSource) and Containers (which is TabSets, Windows and the like).

    Leave a comment:


  • pbackx
    replied
    Thank you all for the suggestions. I have already implemented the gzip suggestion, which has helped a lot.

    I know the server isn't exactly speedy, but that's what I currently can afford :) I do think that 800kb is a bit much for such a small application, but I can understand that for larger applications, this is no longer a problem. Also, this means that, if I expand the application, the total size will remain almost constant from now on, so that's a good thing.

    I will look into the loading screen next, this way the user at least gets a sense of progress. Now you have to look at a blank screen for a while.

    Thanks again!

    Leave a comment:


  • Isomorphic
    replied
    ongwt.com covered it, I think it's the "Slashdot effect" :)

    Leave a comment:


  • nlotz
    replied
    The suggestions Mike made should help a lot. Kudos.

    I noticed the servers network connection is slow as molasses.
    It takes me (Germany) more than 23 secs to download 790 kb.
    That is about 35 kb/s !?
    Last edited by nlotz; 16 Dec 2008, 16:02.

    Leave a comment:

Working...
X