GWT: The Good Bits(gwt.fr)
gwt.fr
GWT: The Good Bits
http://gwt.fr/
18 comments
GWT may have been an impressive solution for a problem that existed when supporting legacy browsers such as Internet Explorer 6 was still an issue, but its time has passed.
The general idea was that you get the mature tooling and strong typing of Java, and abstract away all the browser nastiness. Best of both worlds right?
The problem with GWT is that you are only using the Java language, and so you are missing all the libraries that make Java such a rich ecosystem when run in the JVM. The abstraction layer it forms keeps your developers locked in a world that is neither Java, nor modern HTML5/ECMAScript. So instead of learning to use new browser features, your team is stuck fighting GWT's idiosyncrasies and waiting for it to finish compiling.
If you are considering frameworks for a new web application, go for Ember or Angular. GWT is obsolete and will hold you back.
The general idea was that you get the mature tooling and strong typing of Java, and abstract away all the browser nastiness. Best of both worlds right?
The problem with GWT is that you are only using the Java language, and so you are missing all the libraries that make Java such a rich ecosystem when run in the JVM. The abstraction layer it forms keeps your developers locked in a world that is neither Java, nor modern HTML5/ECMAScript. So instead of learning to use new browser features, your team is stuck fighting GWT's idiosyncrasies and waiting for it to finish compiling.
If you are considering frameworks for a new web application, go for Ember or Angular. GWT is obsolete and will hold you back.
You've maybe missed the key point of GWT. It's definitely not to get around weird browser issues. The point of GWT is to create your complex business logic in Java (which Java is very good for), and then share that business logic across your server, web and mobile platforms. You can do the same with Javascript, but Java is (imo) better designed and suited to that task. Typescript is a closer alternative, but Java just plain has better tooling and server runtimes, and Typescript is compile-to-js in the same way Java with GWT is.
That said, polymer with GWT is really nice and works as well as most web things. Stuff like Angular has so many problems of it's own that it's just plain false to say GWT is obsolete when it actually solves some of the problems Angular still has.
That said, polymer with GWT is really nice and works as well as most web things. Stuff like Angular has so many problems of it's own that it's just plain false to say GWT is obsolete when it actually solves some of the problems Angular still has.
[deleted]
> * If you are considering frameworks for a new web application, go for Ember or Angular.*
Why not React?
Why not React?
No particular reason beyond my inexperience with React and the impression that Ember and Angular are more mature at this point.
The JavascriptObject AJAX bit doesn't really apply anymore, it's now jsinterop and is really nice.
https://drive.google.com/file/d/0BwVGJUurq6uVR1Y5anV5TC1SQkk...
https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1...
https://drive.google.com/file/d/0BwVGJUurq6uVR1Y5anV5TC1SQkk...
https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1...
I have been using GWT since 2007, so I'm rather biased. I have come from a Java/Swing Development, so developing with GWT was rather easy for me. Over the years as I've been training junior developers to develop with GWT, I found it is rather hard for them to get their heads around the framework. But, once they do - it becomes easier.
GWT is for large codebases, if you are trying to make a small project with GWT - you won't find much benefit from it. As the development is Java based, there is a lot of cross-pollination of good ideas, practices and tools. For example, you could use familiar testing frameworks, DI frameworks and debugging tools.
Finally, you can share code between Server, Web Clients and (Native) Mobile Clients. This is one feature which is hard to beat in today's code multi-platform world. Checkout https://drive.google.com/a/vaadin.com/file/d/0B3ktS-w9vr8IS2...
GWT is for large codebases, if you are trying to make a small project with GWT - you won't find much benefit from it. As the development is Java based, there is a lot of cross-pollination of good ideas, practices and tools. For example, you could use familiar testing frameworks, DI frameworks and debugging tools.
Finally, you can share code between Server, Web Clients and (Native) Mobile Clients. This is one feature which is hard to beat in today's code multi-platform world. Checkout https://drive.google.com/a/vaadin.com/file/d/0B3ktS-w9vr8IS2...
We used GWT quite a bit. I am not sure we will in the future, because:
- it's so complex and frustrating. A lot of time you find yourself just fighting GWT and spending an afternoon to get two nested DIVs right.
- it is slow to compile/run and way more verbose than just Java
- when opaque code generators break, it is a royal PITA to understand what goes on
- everything is just over-engineered. Using a CellTable requires way too many steps. Sometimes you just want to display 10 rows and that's it.
- using cells is opaque and leads to way too many little classes
- GWT templating (UiBinder) is very weak - no way for example to define the columns in a CellTable
- styling the UI is a project in itself!
- you cannot use in a shared class some "server" features, even if they are not used at all on the client. E.g., an Address class cannot reference a java.sql.Connection, even if you only use it on the server.
- Has anyone tried to use server Regexps vs client Regexps? or Calendar?
- It's a couple of years we are waiting for GWT v3, and it's always just around the corner.
It had some definite plusses, like dynamic loading, and very efficient JavaScript. And of course you can easily, and safely, refactor.
- it's so complex and frustrating. A lot of time you find yourself just fighting GWT and spending an afternoon to get two nested DIVs right.
- it is slow to compile/run and way more verbose than just Java
- when opaque code generators break, it is a royal PITA to understand what goes on
- everything is just over-engineered. Using a CellTable requires way too many steps. Sometimes you just want to display 10 rows and that's it.
- using cells is opaque and leads to way too many little classes
- GWT templating (UiBinder) is very weak - no way for example to define the columns in a CellTable
- styling the UI is a project in itself!
- you cannot use in a shared class some "server" features, even if they are not used at all on the client. E.g., an Address class cannot reference a java.sql.Connection, even if you only use it on the server.
- Has anyone tried to use server Regexps vs client Regexps? or Calendar?
- It's a couple of years we are waiting for GWT v3, and it's always just around the corner.
It had some definite plusses, like dynamic loading, and very efficient JavaScript. And of course you can easily, and safely, refactor.
Some of this has been fixed. For example there is a @GwtIncompatible annotation for putting server code in a shared class.
http://www.gwtproject.org/javadoc/latest/com/google/gwt/core...
http://www.gwtproject.org/javadoc/latest/com/google/gwt/core...
I know, but at this point it's way too many DTOs and nobody really wants to change that.
GWT widgets are no longer recommended, and they plan to stop including them in GWT 3.0. The good side of GWT is using it for evwrything else. You can use it with GWTPolymerElements and make your app more mothern. Or you can use it with Errai for some serious enterprise capabilities.
Neither the link above nor the offical docs site ( http://www.gwtproject.org/ ) explains what GWT is!
Just in case anyone else is wondering I got this from wikipedia: Google Web Toolkit (GWT /ˈɡwɪt/), or GWT Web Toolkit, is an open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java.
Just in case anyone else is wondering I got this from wikipedia: Google Web Toolkit (GWT /ˈɡwɪt/), or GWT Web Toolkit, is an open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java.
My previous company used GWT. I won't rehash the good and the bad points, as that's already been done in this thread, but I will add that if for some reason you're going to use it, I would look at Vaadin (it uses GWT):
https://vaadin.com
I think they're the primary backers of the GWT project now that Google has dropped support of it.
https://vaadin.com
I think they're the primary backers of the GWT project now that Google has dropped support of it.
There are some good changes in the works for GWT, it just needs a little more love to get them done. GWT 2.8 (currently in beta) is a good step in the right direction, and hopefully after that it'll see a bit of a reincarnation to strip out dead wood.
Does GWT still generate a 1,000 nested tables to render one component ?
I don't remember this being an issue. Maybe you are thinking of ExtGWT (now GXT)?
If I recall, the problem was more about ExtJS using overly complicated DOM structures to build its widgets than about the barebones GWT components themselves.
If I recall, the problem was more about ExtJS using overly complicated DOM structures to build its widgets than about the barebones GWT components themselves.
Only if you use some of the old-school widgets (e.g. Horizontal Panel). I think standard practice these days is to use HTML as far as possible in views.
Good bits:
- abstraction from different browsers
- ability to set breakpoints and debug code running in browser (browser based tools were not so full featured as they are now)
- refactoring
- Java code organization (packages, classes, interfaces)
- could share validation logic between front end and back end
Bad bits:
- abstraction broke sometimes. I remember one bug that drove me crazy--only showed up when I deployed the optimized code (vs the detailed code which was human readable), and was due to a namespace collision with a global js variable.
- compilation was another build step and sometimes not a quick one.
- far better for full page applications than drop in js widgets (we used it in both ways)
Overall I think it was a great solution for its time. Now a lot of the JavaScript ecosystem has caught up or surpassed it.