Results 1 to 8 of 8

Thread: GXT vs. GWT

  1. #1

    Default GXT vs. GWT

    Has anyone seen this site: http://gxtvsgwt.appspot.com/ ?

    When I ran all the tests GXT was significantly slower in every one.

    Any commentary by the developers of GXT? Just curious.

  2. #2
    Sencha User
    Join Date
    Sep 2007
    Posts
    31

    Default

    I am not a Sencha developer, though I think the answer lies in the generated markup. GWT components are spartan both in element structure and style sheet rules. They look dull by default but make good building blocks if you have good CSS knowledge. I would say you pay for what you get.

  3. #3
    Sencha Premium User
    Join Date
    Nov 2008
    Location
    Vienna - Austria
    Posts
    888

    Default

    But anyway, the difference is way big.
    I have good expectations for GWT 3. I hope the performance is getting improved in that version.

    Regards,
    Michel.

  4. #4
    Sencha User
    Join Date
    Sep 2007
    Posts
    31

    Default

    But anyway, the difference is way big.
    But, you can not compare apples to oranges.

    GWT ListBox vs GXT ComboBox

    GWT Grid vs GXT Grid

    By the way, the quality of the native GWT API has been declining, turning into a deprecation minefield. The latest additions (MVP, RequestFactory) bring back the nightmares of EJB 2 were you had to maintain 3-4 different artifacts for a each component. Also their new Data Presentation Widgets are a joke. I wish they would restrain themselves from trying to make complex widgets and APIs.

  5. #5
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    The latest additions (MVP, RequestFactory) bring back the nightmares of EJB 2 were you had to maintain 3-4 different artifacts for a each component
    Deprecation is only a problem if you want to use the new classes/compilers if you are content to use the old ones, then there is no need to upgrade. But if you choose to upgrade to take advantage of, say, the new layout code, or the new editor code, you must make your code actually fit those new patterns and classes, or they won't work. Try adding a DockLayoutPanel to a RootPanel instead of a RootLayoutPanel, and see how that goes.

    RF is a whole different story in addition to being experimental and so possibly incomplete it can be used totally independently of MVP, or can be ignored altogether in favor of classic RPC. If you wish to ignore these features (their "complex widgets and APIs"), stick with the last release of the 1.7 or 2.0 lines - the compilers don't change that drasticaly. But if you ever want to get out of the ugly BaseModelData subclass and build getters/setters that just dispatch to Object get(String) and Object set(String, Object), the RF or AutoBean mechanism is a good way to do it. These new features come with Generators, not raw code - if you build out an editor it can talk to anything that looks like a bean, no matter where it comes from through generated code.

    If it is just a problem of maintenance, use your dependency management tools and keep old code using old jars. But GXT itself can't continue to differentiate based on widgets alone if the library can't take advantage of generators and building both uibinders and editor drivers as the rest of the GWT world can.

  6. #6
    Sencha User
    Join Date
    Sep 2007
    Posts
    31

    Default

    If you wish to ignore these features (their "complex widgets and APIs"), stick with the last release of the 1.7 or 2.0 lines - the compilers don't change that drasticaly.
    Unfortunately GWT does not support proper object detection, so you have to recompile with the latest version if you want your code to keep up with browser updates.

    But if you ever want to get out of the ugly BaseModelData subclass and build getters/setters that just dispatch to Object get(String) and Object set(String, Object), the RF or AutoBean mechanism is a good way to do it.
    Those getters and setters take care of type safety, it doesn't really matter what they dispatch to. In fact all javascript objects are hash maps.

  7. #7
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    I think you and I are talking past each other to a degree at this point, but I want to point out that the user agent detection is just a chunk of js in a file called UserAgent.gwt.xml, and can trivially be overridden, either in general to detect browsers in a prefered way, or on a feature by feature basis as PPK suggests. The obvious downside, and the reason GWT elected to not go with this, is that generating new code for each set of feature has/has-not pair would raise the number of permutations so drastically as to almost certainly not be worth it.

    As to javascript objects being hashmaps - again, you are certainly correct, but I am referring to the time spent building/updating DTOs - AutoBeans and EntityProxies do not require you to implement those hooks into the underlying map (or fields). Additionally, using Map<String, Object> code prevents the GWT compiler, which takes advantage of the static nature of Java code to better clean up the final product, will be unable to tell when you might not need the full map (as should be the case for something like the SimpleComboValue class).

    The goal of the GWT core is to provide and demonstrate ways to solve problems in such a way that the Java language subset supported can be turned into fairly optimized javascript. Most of the built in features can be ignored by just not importing User or Core into your project. You still get the compiler, but avoid even such pieces as the User Agent detection.

  8. #8
    Ext GWT Premium Member
    Join Date
    Apr 2009
    Posts
    15

    Default

    I agree that the comparisons are not perfect apples to apples as suggested above, especially on the complex ones like Grid and ComboBox, but they're as close as you can reasonably get without a huge divergence in code. And in those cases the GXT widgets do often have more features out of the box. Still, they illustrates some fundamental flaws - even better illustrated by the really simple ones like VerticalPanel or Button - which are what really hinder GXT performance. There is far too much code (and generated code) baked into core superclasses like Component that are frankly not needed in a a majority of cases, and while it would require nearly a rewrite, could potentially be solved in GXT 3 while keeping the rich functionality. Stylistically I'll agree that GXT's CSS makes everything look way better out of the box, but CSS tweaking to make the GWT counterparts look the same is very doable and will have zero adverse impact on performance. If GXT was only slow when using a Grid with many of the advanced features enabled I'd have no problem with it, but an empty VerticalPanel being slow? This is why simple layouts built using GXT degrade very quickly on moderate hardware, IE, or mobile browsers. This is an unfortunate contrast to the other great work Sencha is doing with its pure-JS frameworks specifically targeting mobile.

Similar Threads

  1. GWT Rpc Error with GXT 2.1.3 and GWT 2.0.3
    By Shivender in forum Ext GWT: Discussion
    Replies: 1
    Last Post: 19 Sep 2010, 4:01 AM
  2. Mixing GWT, GWT-Ext and GXT?
    By WeirdAl in forum Ext GWT: Discussion
    Replies: 0
    Last Post: 6 Jan 2010, 11:45 PM
  3. [2.1] GXT.isSafri vs. GXT.isWebkit in GWT Hosted Mode for OS X
    By cravemusic in forum Ext GWT: Bugs (2.x)
    Replies: 0
    Last Post: 1 Dec 2009, 10:15 AM
  4. GXT Table Events.SelectionChange issue in GXT GWT Beta 5
    By denizstij in forum Community Discussion
    Replies: 1
    Last Post: 19 Jun 2008, 6:38 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •