The last article here was "Reactive Programming Tutorial in Scala + GWT". Now is the time to become more familiar with GWT in general.
developers.google.com/web-toolkit/overview
gmarwaha.com/blog/2011/05/09/gwt-pros-and-cons/
I love JavaScript. With the advent of jQuery and Mootools, my love for JavaScript has only increased plenty-fold. Given a choice I would use either of the aforementioned frameworks for any web application I develop. But being in the service industry, time and again I have to succumb to the client’s pressure and work in their choice of technology – whether or not it is the right one (The one who pays the piper calls the tune. Isn’t it?). One such client exposed me to the world of GWT.
I have given GWT a shot couple of years back on the day it was released. I didn’t like it that much then, so I dismissed it and never returned back. But, over the past six months working on this project I have a slightly different impression on this framework. I still cannot say that GWT is the next big thing since sliced bread, but at least it is not as bad as I thought it was. I have just documented my observations, both good and bad during the course of this project and thought some fellow developer might find it useful while evaluating GWT.
Pros:
developers.google.com/web-toolkit/overview
Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript. GWT is used by many products at Google, including Google Wave and the new version of AdWords. It's open source, completely free, and used by thousands of developers around the world.The best GWT pros and cons list I could find on the web is a post by Ganeshji Marwaha, a JavaScript lover. I decided to cite it here and put my comments in the Cons section with regard to GWT + Scala.
gmarwaha.com/blog/2011/05/09/gwt-pros-and-cons/
I love JavaScript. With the advent of jQuery and Mootools, my love for JavaScript has only increased plenty-fold. Given a choice I would use either of the aforementioned frameworks for any web application I develop. But being in the service industry, time and again I have to succumb to the client’s pressure and work in their choice of technology – whether or not it is the right one (The one who pays the piper calls the tune. Isn’t it?). One such client exposed me to the world of GWT.
I have given GWT a shot couple of years back on the day it was released. I didn’t like it that much then, so I dismissed it and never returned back. But, over the past six months working on this project I have a slightly different impression on this framework. I still cannot say that GWT is the next big thing since sliced bread, but at least it is not as bad as I thought it was. I have just documented my observations, both good and bad during the course of this project and thought some fellow developer might find it useful while evaluating GWT.
Pros:
- If you are a Java veteran with experience in Swing or AWT, then choosing GWT should be a no-brainer. The learning curve is the least with this background.
- Even if you are not experienced in Java GUI development, the experience in working on server-side Java for years will come in handy while developing GWT apps
- You can create highly responsive web applications with heavy lifting on the client-side and reduced chattiness with the server-side
- Although there are numerous JavaScript libraries out in the wild and most of them are worth their salt, many conventional developers don’t understand its true power. Remember, a powerful language like JavaScript is a double-edged sword. If you don’t know how to use it, even you won’t be able to clean the mess you create
- You can migrate from a typical web application to a GWT application iteratively. It is not an all or nothing proposition. You can use a clever trick called JSNI to interact with loads of JavaScript functions you already possess. But it is always better to move them to GWT sooner rather than later
- The IDE support for GWT cannot be better. Java IDEs have matured over the past decade to be one of the best in the world and GWT can take direct advantage of it
- The integrated debugging beauty is something you can kill for. The excellent debugging support offered by the mature Java IDEs is one feature that could sway anybody’s decision in favor of GWT
- The built-in IDE support to refactor Java code can directly be put to good use to maintain a simple design at all times. Doing this in JavaScript is not for the faint at heart
- The IDE syntax highlighting, error checking, code completion shortcuts etc are overwhelming – to say the least
- GWT is being actively developed by Google. We know that the project is not going to die off anytime soon. Until now their commitment towards the project says a lot about its future in the industry.
- The community behind the project is also a big PLUS. Discussions take place daily in Stack overflow, discussion forums, wikis and personal blogs. A simple search with the right keyword could point you in the right direction
- GWT is a well thought-out API; not something that was put together in a hurry. This helps you as a developer to quickly comprehend the abstractions and makes it really intuitive to use
- You can use GWT’s built-in protocol to transfer data between the client and the server without any additional knowledge of how the data is packaged and sent. If you prefer more control, you can always use XML, JSON or another proprietary format of your choice. Even in that case, while using JSON, you don’t have to use an non-intuitive java JSON library. You can use JSNI to ‘eval’ the JSON using straight javascript. Cool huh!
- You have the advantage of being able to use standard Java static code analyzers like FindBugs, CheckStyle, Detangler, PMD etc to monitor code and design quality. This is very important when you are working in a big team with varying experience.
- You can use JUnit or Test NG for unit testing and JMock or another mock library for mocking dependencies. Following TDD is straight-forward if you already practice it. Although there are JavaScript based unit testing frameworks like jsunit and qunit, come on tell me how many people already know that or are itching to use that.
- The GWT compiler generates cross-browser JavaScript code. Today, any marketing person who says this will probably be beaten. It has now become a basic necessity, not a luxury
- The GWT compiler optimizes the generated code, removes dead code and even obfuscates the JavaScript for you all in one shot
- Although the compilation process takes hell a lot of time, you don’t have to go through that during development. There is a special hosted mode that uses a browser plug-in and direct java byte-code to produce output. That is one of the main reasons you are able to use a Java debugger to debug client side code.
- Rich third-party controls are available through quite a few projects like Smart GWT, Ext GWT etc. They are well designed, easy to use and theme-able. So, if you have a requirement where existing controls don’t just cut it, you should be looking into one of these projects. There is a really fat chance that one of those components will work out. Even if that doesn’t work out, you can always roll out your own.
- GWT emphasizes the concept of a stateful client and a stateless server. This results in extremely less load on the server where many users have to co-exist and high load on the client where only one user is working
- I18N and L10N are pretty straight-forward with GWT. In fact locale based compilation is taken care by the GWT compiler itself. The same cannot be said about regular client-only frameworks
- GWT comes built-in with browser back button support even while using AJAX. If you are an AJAX developer, I can almost feel your relief. This is priceless.
- GWT is a fast developing project. So, there are a lot of versions floating around. Many functions, interfaces and events get deprecated and keeping up with their pace is not too much fun when you have other work to do
Sasha: The pace is slowed down nowadays. - There were quite a few GWT books during the beginning. Not so much these days. For example, I haven’t found many books on the 2.0 version of GWT. This leaves us only with Google’s documentation. I agree that the documentation is good and all, but nothing can beat a well written book
Sasha: At least there are several books on the 2.0 version of GWT. - GWT is not fun to work with. After all it is Java and Java is not a fun language to work with. If you add the fact that entire layouts and custom controls should be created in java, you can easily make a grown programmer cry. With the introduction of UI binder starting version 2.0, that problem is kind of solved, but now you have a new syntax to learn.
Sasha: GWT is fun to work with once you start using Scala in place of Java. And you don't have to use UI binder to get its benefits. More on that below. - The Java to JavaScript compilation is fairly slow, which is a significant con if you choose GWT.
Sasha: But you shouldn't be doing that during development, because there is faster development mode. - I personally prefer defining structure in HTML and styling it using CSS. The concepts used in HTML are clean and straight-forward and I have years of experience doing just that. But in GWT, I am kind of forced to use proprietary methods to do the same. That combined with the fact that GWT doesn’t solve the styling and alignment incompatibilies for me compounds the problem. So, writing layout code in GWT is something I despice. But with UI Binder and HTMLLayout from version 2.0 onwards, I feel I am back in my own territory
Sasha: I think this is good that there are two ways to go about design and layout in GWT, because there are different ways to work with designers. I believe I've come to even more clean scheme of separating design/layout from Scala code, which is completely optional. Even cleaner than typical JavaScript templating libraries can do. Wait for the next articles on that. - It requires some serious commitment levels to get into GWT, coz, after that, a change in client side technology could require a complete rewrite of your app, as it is a radically different approach than other client side frameworks
Sasha: Nowadays we're starting to see pure JavaScript frameworks that are more radically different from each other and require more serious commitment levels to get into. - There is not a defined way to approach an application development using GWT. Should we use only module per app or one module per page or somewhere in between. These design patterns are slowly evolving only now. So, typically people tend to develop all in one module until the module size goes beyond being acceptable and then they refactor it into multiple modules. But if it is too late, then refactoring could not be that easy either
Sasha: Code splitting pretty much obviated the need to break into different modules for performance reasons. - Mixing presentation and code doesn’t sound right although typical desktop GUI applications does just that. But these days, even desktop application frameworks like Flex and Silverlight have taken an XML based declarative approach to separate presentation from logic. I think GWT 1.x version had this disadvantage. With the introduction of UI Binder starting from version 2.0, I think this disadvantage can be written off although it is yet another painful XML language to learn
Sasha: When using Scala instead of Java there is no need to invent new painful XML languages to learn. You can use just plain Scala code and plain HTML templates. As I said, wait for the next articles on that to see what I mean. - You would often be punching in 3X to 5X more code than you would with other client libraries – like jQuery – to get simple things done
Sasha: Scala code size is on par with dynamic languages. And using reactive programming in Scala you can create dynamic UIs with less code than using jQuery. - You should also remember that with GWT, the abstraction away from HTML isn’t complete. You’ll still need to understand the DOM structure your app is generating in order to style it, and GWT can make it harder to see this structure in the code.
Sasha: The solution is a more clean separation of Scala code from HTML templates. As I said, wait for the next articles on that. - GWT is an advantage only for Java developers. Developers with .NET or PHP background won’t gain anything here
Sasha: But with GWT + Scala even pure JavaScript developers can gain advantages that typesafety brings without much of its usual costs. - If you have tasted the power of JavaScript and know how to properly utilize it to your advantage, then you will feel crippled with an unexpressive language like Java
Sasha: If you have tasted the power of Scala and know how to properly utilize it to your advantage, then you will feel crippled with an unexpressive language like Java or with a type-unsafe language like JavaScript.
-----
The main con of using Scala+GWT right now is that you are forced to use unreleased versions of Scala and GWT. Here are the words by Grzegorz Kossakowski, the main developer behind Scala+GWT project:
groups.google.com/group/scalagwt/browse_thread/thread/35bd8fabce47b4ee
Some more GWT pros before the end:
The main con of using Scala+GWT right now is that you are forced to use unreleased versions of Scala and GWT. Here are the words by Grzegorz Kossakowski, the main developer behind Scala+GWT project:
groups.google.com/group/scalagwt/browse_thread/thread/35bd8fabce47b4ee
Well, I didn't want to go into details what's missing for 1.0 but let me give you a few examples that come to my mind:
Apart from first bullet others are fairly straightforward to address. I
- Optimized JS generation doesn't work yet due to some obscure bug I couldn't track down. This means we generate really huge JS. Remember what happened to Dart when they announced it and people found out that they generate 18k of JavaScript for hello world?
- Documentation is lacking. It's not something unique but we really need to do a bit more work on it.
- We don't ship any Maven artifacts. Therefore, even if technically it's possible to use Maven for building Scala+GWT projects then in practice it's not feasible yet.
- We still don't have continuous builds set up (meaning I don't want to have storm of pull request yet)
- Nobody apart from me knows how to build Eclipse plugin that supports Scala+GWT. Exact steps got a lot better due to work of Eclipse plugin team but still I need to document it.
don't say everything has to be perfect for 1.0 release but I'd like to get
at least a few things addressed here. Help is always welcome.
Also, I'd like to release more often from now.
Some more GWT pros before the end:
Code SplittingAnd here is some new interesting feature preview post by Ray Cromwell:
The value that whole-program compilation for JS brings to the table is no better demonstrated than it is here, by the ability of the GWT compiler to statically compute transitive callgraphs and dependencies from any callsite you desire, and split off that chunk of code for deferred loading. Ask yourself, if I handed you a hand-written large JS application like Maps, or GMail, or Y! Mail, how long would it take you to fully modularize all of the libraries used, get all of the dependencies exactly right (if you need feature F, load library F, but F needs G and H, so load libraries G and H). You can point to popular JS libraries using complex JS module loaders with dependency management, but keep in mind, that is all done by hand, on very mature libraries. GWT Code Splitting brings this functionality to mere mortals in just a few lines of code....
Speed Tracer, 'nuff said!
1. It's awesome. 2. It's actually written in GWT. 3. It enables easy collaboration and sharing of traces. 4. It has a plugin mechanism for analyzing traces and providing automated warnings and suggestions like YSlow!. 5. It's awesome. 6. It's awesome!...
Story of Your Compile, Compile Reports
Think of it as Compile-Time SpeedTracer. SOYC gives you lots of detail about what each part of your app is contributing to the output in terms of size, and what the interdependencies are. This provides valuable feedback as to where to look to reduce bloat, or split-off code better. This would be the equivalent of a JS tool that looked at your jQuery application, and told you exactly how many bytes were used by each method in each jQuery plugin you're using, and which modules and functions pulled in the others. Think about it.Better stack traces, and stack trace emulation for IE6
...
that's why GWT is so beneficial. It unifies where other approaches fragment. Sure, you could combine your own code splitting, with your own handrolled JS loader, with someone else's image sprite tool, with another guy's test framework, and someone else's minifier, and this guy's trace analyzer, and that guy's widget toolset. And if you think you could achieve the same outcome, you'd be absolutely right.
GWT isn't about doing what isn't possible elsewhere. It's about making you productive doing it.
If you're a GWT user, try to guess what is going on in this screen shot.And there are free improvements for GWT apps with every GWT release:
...
Robert is right, this is not DevMode, it is SourceMaps in action, which enables source-level debugging within Chrome DevTools, and yes, it works like with obfuscation and optimization.
+Brian Slesinsky and I are working on a "Super Draft Mode" GWT compiler spec that will eliminate the need for DevMode. Like the Dart Compiler, we will emit unoptimized separately compiled "linkable" JS. The compiler will run as a persistent server. When it notices a source file change on disk, it will load in, and re-translate that file to JS (and maybe re-run generators). It can either re-link the JS and refresh the whole patch, or just patch/eval in the new code (edit and continue)
GWT 2.5 can produce code 39% smaller than GWT 2.4.
-----
The next step in my plan is to rewrite GWT tutorial in Scala, and then rewrite it in Scala using reactive programming. Stay tuned.
The next step in my plan is to rewrite GWT tutorial in Scala, and then rewrite it in Scala using reactive programming. Stay tuned.
No comments:
Post a Comment