1. #1
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    13
    Answers
    1
    Vote Rating
    -4
    Adam Davies can only hope to improve

      0  

    Default Answered: How can any company develop something so rubbish as gxt?

    Answered: How can any company develop something so rubbish as gxt?


    List of rubbish features about gxt:
    1. Setting IDs on TextFields does not corrispond to id's on HTML <Input> fields.
    2. CellEditors and validators screwing up the MVC paradigm
    3. ModelData - piece of junk hash-table that does not implement Map. Also prevents custom objects being added to the GWT white-list
    4. ListStore not implementing the java.util.Collection interface
    5. Indirection overload (Grid -> store -> loader -> model -> model data)
    6. Huge cost of development (what will take 1 day via HTML5, CSS and Javascript, will take 3 days using gxt)
    7. Huge amounts of html generated (just take a look at Firebug to see how much html TextField creates)

  2. Quote Originally Posted by Colin Alworth View Post
    To directly address a few more points, ModelData is part of the legacy jar (in 3.0 anyway, and as this is in the 3.0 forums, I'm assuming that is what you are using), and not intended for new projects to use. If your data model is best described by a Map, then by all means, use a Map - the stores and data widgets are able to work directly with a Map, or any Object at all, provided the appropriate ValueProviders, etc can be created.
    So why did anyone ever think ModelData was a good idea? And if anyone thought it was a good idea, then why not use a Map anyway (after all that what ModelData is)? And why did you not anticipate that ModelData would fail the GWT white-list test mentioned above? Why not just use JSON?

    Quote Originally Posted by Colin Alworth View Post
    ListStore deliberately does not implement Collection or List to discourage developers from using the Java 5 for-each syntax - situations where it makes sense to iterate over all elements are typically performance critical, and the GWT compiler presently produced much more performant code from a for loop than a for-each loop. If a Collection is requires, ListStore.getAll() returns a List that represents the current set of items.
    How so, List and Collection are interfaces, and performance depends on implementation. Exactly how much more performant is ListStore compared to ArrayList uing the for-each loop. If you could give some figures that would be helpfull. How large a dataset are you talking about? And isn't most of this code run on the client so I assume the dataset would be very small. Thanks for your concern about performance, but I really thing you should let the developer decide what performance issues are relevent and which are not.

    While we're on the subject of performance, how much more performant is your version of the GWT RPC compared with a standard REST call (about 10 times slower from my measurements).

    Quote Originally Posted by Colin Alworth View Post
    While a Grid does need a Store to hold the data itself, a Store need not work with a Loader, and in 3 there is no need for the model to be distinct from the model data (again, assuming that this post is in the correct forum). A Loader can often be useful as not every Grid use case needs to pass information to the server about how to load the next batch of data, but it is sometimes useful.
    Perhaps you should put some effort into updating your shockingly poor JavaDoc and documentation then.

    Quote Originally Posted by Colin Alworth View Post
    TextField is responsible for more than just drawing a single <input> tag. It needs to allocate space for any eventual error reporting, and building consistently sized and styled elements that show these details well across all browsers sometimes requires extra pieces as well.
    I understand that TextField does more than provide a <input> tag, so why is there not a method for setting the ID to the input tag? Probably because when you developed it you didn't consider the needs of testing (such as selenium test). Which also means that you probably don't test your framework either (which is no surprise - considering you don't document it).

    Quote Originally Posted by Colin Alworth View Post
    IDs are part of this same issue - rarely should Widget internals be directly manipulated from the DOM, but the entire widget can be addressed from an ID. Typically when internals also need IDs, they are based on the external ID, if any.
    I suppose you're last comment sums it all up. You assume anyone that uses GXT will not be refering to widgets by their client side IDs. Which assumes that developers will not be using client side testing frameworks. Which, in tern, means that GXT is not ready for developing mission critical and highly available applications.

    Which was my point in the first place. It's a second rate product.

    But to be fair it does provide a set of lovely pre-built widgets, as long as you've got plenty of time on your hands.

    Anyway chaps, that's enough of this thread now, but I will update my page here with any other reasons why developers should not use GXT (work in progress).

    I also know that developers who have invested much time and money into using GXT will probably stick with it, and I congratulate you and wish you luck. I don't expect those people to agree with me, and neither to I expect anything I say will change their minds.

  3. #2
    Sencha User PhiLho's Avatar
    Join Date
    Nov 2011
    Location
    Near Paris, France
    Posts
    140
    Answers
    2
    Vote Rating
    1
    PhiLho is on a distinguished road

      0  

    Default


    6) The point of GWT is precisely to avoid JavaScript. Most of my co-workers have fits at the idea of having to learn it... Dynamic languages = evil, for them (and I admit static checking is cool for large projects). If you master JS, why do you want to use GWT / GXT?
    7) That's an issue with most frameworks generating HTML, I think. One of the problems can be to make something where you have fine grained control on the look: it is hard to make resizable buttons with complex look (gradients, etc.) without using lot of sub-cells (Sencha uses tables, IIRC). Now, sometime I grunt when I see lot of nested divs in Firebug, indeed.

    Part of the other issues are actually inherited from GWT... On 1), I think you have a setDebugId or similar. I had no issues setting real ids in HTML when using UiBuilder...
    On 2), I don't think an auto-validating component is a problem with MVC: it just helps the user, and the server code must validate the data anyway (one can easily tamper with data in the browser). And nothing force you to use validators, anyway.

    I am not sure that using insults will help in the dialog (note: I am just a user of GXT, not tied to Sencha at all). You had several releases to provide feedback, and I am sure GXT can still evolve, if making pertinent suggestions.

  4. #3
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    13
    Answers
    1
    Vote Rating
    -4
    Adam Davies can only hope to improve

      0  

    Default GXT Rubhisness part II

    GXT Rubhisness part II


    Saying something is rubbish is not insulting. Its a conclusion based on empirical observation, evidence, experience and comparative analysis.

    As far as validators and cell editors go . Try this: Create a Money class that has a currency code (taken from an enumeration), and a value (held as a BigDecimal), Then create a editable grid where the user can edit the Money value. The supporting functionality should ensure that the currency entered is valid, and the money value is valid (i.e. a number), and than format the display so that if the user entered "USD 34567.129" it would look like: "USD 34,567.13" after the user tabs away. Try this using JavaScript (about 20 minutes), then using GXT (not possible - particularly if the user enters a value such as "*NHNUYU&^^&", because GXT will still try to assign this value to a Money object, before it calls the validator).

    If developers don't know how to write client side web pages then you really shouldn't be letting them loose pretending the can write front ends because they're using GXT.

    Secondly, dynamic languages are not evil but present some challenges and some advantages. How easy is it to write a bit of html and javascript in a file and then view that file in a browser - very. That is the power of dynamic languages (just like python). It also means you have to make sure your code is structure to be composed of small testable modules (a good practice anyway).

    How long does it take to change and deploy an html file, or a css file - 5 seconds. How long does it take to change and deploy a gxt client file? 10 minutes, 30 minutes if you want to do a full optimized compilation?

    Most of the issues such as all those DIVs and IDs not being on the things intuitively set, are not to do with GWT, they are to do with the rubbish that sencha has put around GWT. GWT is fairly lightweight and bare-bones product. And google do not pretend that it should be used for large projects while sencha does.

    So I say GXT is rubbish because it makes simple things difficult (e.g. layouts), and uses technology that is unreliable (ModleData RPC calls), makes simple things complicated (grids), takes 4 times longer than normal development (JQuery, HTML, css etc), and obfuscates between client code and server code (being that all is done in Java when the HTML etc for client, and Java for the server is a much cleaner boundary).

    Oh, and one more thing. GXT apps look rubbish too. Like Windows 95 applications. And no matter how much styling you do they will still look like windows 95 applications, just with style. You couldn't do facebook in GXT.

  5. #4
    Ext GWT Premium Member
    Join Date
    Aug 2010
    Location
    Germany, Solingen
    Posts
    241
    Answers
    4
    Vote Rating
    2
    gishmo is on a distinguished road

      1  

    Default


    Well, one question, why you want to use GXT?

    If you are happy with HTML, JavaScript, jQuery, use it.

  6. #5
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    13
    Answers
    1
    Vote Rating
    -4
    Adam Davies can only hope to improve

      -1  

    Default


    I ask myself that question each and every day. Maybe it's because I want to punish myself and can not face going to an S&M club. Maybe its because I hate life and want to feel the loathing of other companies hell bent on making my life as unbearable as possible. Or maybe, in these bad economic times, I want to be able to point at one of the masters of evil, and say "I would never work there!!!".

    Or maybe is because people with less experience than I, but with more authority than I can bare, have pointed to me and said:

    "Towards thee I command, thou all-destroying but unconquering developer; to the last I grapple with thee; from hell’s heart I stab at thee; for hate’s sake I will spit all my GXT at thee. Sink all coffins and all hearses to one common framework! and since HTML, CSS nor Javascript can not be mine, let me then smite and destroy all works of greatness. Now tied to GXT dammed developer! I will never give thee up!"

    Between you and me, I pray every day to be delivered from this evil, but the Lord has forsaken me.
    Is the truth of GXT's existence final proof that there is no God or no good in this world?

  7. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Answers
    109
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      2  

    Default


    To directly address a few more points, ModelData is part of the legacy jar (in 3.0 anyway, and as this is in the 3.0 forums, I'm assuming that is what you are using), and not intended for new projects to use. If your data model is best described by a Map, then by all means, use a Map - the stores and data widgets are able to work directly with a Map, or any Object at all, provided the appropriate ValueProviders, etc can be created.

    ListStore deliberately does not implement Collection or List to discourage developers from using the Java 5 for-each syntax - situations where it makes sense to iterate over all elements are typically performance critical, and the GWT compiler presently produced much more performant code from a for loop than a for-each loop. If a Collection is requires, ListStore.getAll() returns a List that represents the current set of items.

    While a Grid does need a Store to hold the data itself, a Store need not work with a Loader, and in 3 there is no need for the model to be distinct from the model data (again, assuming that this post is in the correct forum). A Loader can often be useful as not every Grid use case needs to pass information to the server about how to load the next batch of data, but it is sometimes useful.

    TextField is responsible for more than just drawing a single <input> tag. It needs to allocate space for any eventual error reporting, and building consistently sized and styled elements that show these details well across all browsers sometimes requires extra pieces as well.

    IDs are part of this same issue - rarely should Widget internals be directly manipulated from the DOM, but the entire widget can be addressed from an ID. Typically when internals also need IDs, they are based on the external ID, if any.

  8. #7
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    13
    Answers
    1
    Vote Rating
    -4
    Adam Davies can only hope to improve

      -1  

    Default


    Quote Originally Posted by Colin Alworth View Post
    To directly address a few more points, ModelData is part of the legacy jar (in 3.0 anyway, and as this is in the 3.0 forums, I'm assuming that is what you are using), and not intended for new projects to use. If your data model is best described by a Map, then by all means, use a Map - the stores and data widgets are able to work directly with a Map, or any Object at all, provided the appropriate ValueProviders, etc can be created.
    So why did anyone ever think ModelData was a good idea? And if anyone thought it was a good idea, then why not use a Map anyway (after all that what ModelData is)? And why did you not anticipate that ModelData would fail the GWT white-list test mentioned above? Why not just use JSON?

    Quote Originally Posted by Colin Alworth View Post
    ListStore deliberately does not implement Collection or List to discourage developers from using the Java 5 for-each syntax - situations where it makes sense to iterate over all elements are typically performance critical, and the GWT compiler presently produced much more performant code from a for loop than a for-each loop. If a Collection is requires, ListStore.getAll() returns a List that represents the current set of items.
    How so, List and Collection are interfaces, and performance depends on implementation. Exactly how much more performant is ListStore compared to ArrayList uing the for-each loop. If you could give some figures that would be helpfull. How large a dataset are you talking about? And isn't most of this code run on the client so I assume the dataset would be very small. Thanks for your concern about performance, but I really thing you should let the developer decide what performance issues are relevent and which are not.

    While we're on the subject of performance, how much more performant is your version of the GWT RPC compared with a standard REST call (about 10 times slower from my measurements).

    Quote Originally Posted by Colin Alworth View Post
    While a Grid does need a Store to hold the data itself, a Store need not work with a Loader, and in 3 there is no need for the model to be distinct from the model data (again, assuming that this post is in the correct forum). A Loader can often be useful as not every Grid use case needs to pass information to the server about how to load the next batch of data, but it is sometimes useful.
    Perhaps you should put some effort into updating your shockingly poor JavaDoc and documentation then.

    Quote Originally Posted by Colin Alworth View Post
    TextField is responsible for more than just drawing a single <input> tag. It needs to allocate space for any eventual error reporting, and building consistently sized and styled elements that show these details well across all browsers sometimes requires extra pieces as well.
    I understand that TextField does more than provide a <input> tag, so why is there not a method for setting the ID to the input tag? Probably because when you developed it you didn't consider the needs of testing (such as selenium test). Which also means that you probably don't test your framework either (which is no surprise - considering you don't document it).

    Quote Originally Posted by Colin Alworth View Post
    IDs are part of this same issue - rarely should Widget internals be directly manipulated from the DOM, but the entire widget can be addressed from an ID. Typically when internals also need IDs, they are based on the external ID, if any.
    I suppose you're last comment sums it all up. You assume anyone that uses GXT will not be refering to widgets by their client side IDs. Which assumes that developers will not be using client side testing frameworks. Which, in tern, means that GXT is not ready for developing mission critical and highly available applications.

    Which was my point in the first place. It's a second rate product.

    But to be fair it does provide a set of lovely pre-built widgets, as long as you've got plenty of time on your hands.

    Anyway chaps, that's enough of this thread now, but I will update my page here with any other reasons why developers should not use GXT (work in progress).

    I also know that developers who have invested much time and money into using GXT will probably stick with it, and I congratulate you and wish you luck. I don't expect those people to agree with me, and neither to I expect anything I say will change their minds.

  9. #8
    Ext GWT Premium Member
    Join Date
    Aug 2010
    Location
    Germany, Solingen
    Posts
    241
    Answers
    4
    Vote Rating
    2
    gishmo is on a distinguished road

      0  

    Default


    @Adam:
    I spent some time reading your articels.
    Are you sure, you know, what you are talking about ....

  10. #9
    Ext GWT Premium Member
    Join Date
    Jun 2011
    Posts
    13
    Answers
    1
    Vote Rating
    -4
    Adam Davies can only hope to improve

      0  

    Default


    Which articles. This one or the ones at jeeni.co.uk?

    Either way the answer is yes. Most of them at jeeni are still in production, but are reasonably OK.

    The most up to date ones are Coffee Shops do Use Two-Phase Commit and The Economics of Testing

    If you have any comments or doubts about their content please post on the site, or you can email me at: adam@jeeni.co.uk. Your feedback would be appreciated.

    Thanks

  11. #10
    Sencha User
    Join Date
    Jan 2012
    Posts
    8
    Vote Rating
    0
    planadecu is on a distinguished road

      0  

    Default I must agree

    I must agree


    After 1,5 years developing in GXT I must agree with Adam's opinion.

    I would add up some stuff: nested layout management and integration with different size devices is a hell. In my point of view native CSS should be used intead of huge stack of inmantainable listeners that sometimes triggers and some other time don't.

    Adding a combo with some values (key, value) is a page of Java code.

    Aligning a table on a dynamic width container is impossible, comes from the facto of using 2 different HTML table underneath.

    After discovering the simplicity of some nowadays "frameworks" like bootstrap I gave up on GXT.