GWT

From APIDesign

Revision as of 20:21, 21 March 2013

GWT is a Java port that runs in a browser, but (unlike Bck2Brwsr project) compiles on the desktop. The GWT compiler runs in real VM (e.g. HotSpot) and translates Java code to static JavaScript. As such the GWT looses a lot of the dynamism Java could offer - late bindings of classes and libraries, generating bytecode on the fly, loading new classes, using reflection, etc. is hard/almost impossible in GWT.

Slow JavaScript Interpreters and Doing Less Work

GWT was the first attempt to bring Java to browser. At the time of its introduction, the JavaScript interpreters in browsers were slow and it made sense to do as much work as possible in advance. However since then the speed of JavaScript increased enormously and as such it becomes more and more viable to bring more of Java Bck2Brwsr.

For example the Bck2Brwsr project does not deal with Java source, but with Java ByteCode:

• one does not need to write lexer and understand Java keywords
• one does not need to write parser to for a Java AST
• one does not need to do attribution - e.g. resolve the fully qualified name of each symbol

All of this has already been done by JavaC when generating the ByteCode. Bck2Brwsr can use such information, become more effective and at the end fit into the browser.

Gmail Web Toolkit

GWT started as a framework to allow Google to write Gmail. In fact, it is almost clear it was the opposite way - the goal was to write Gmail (with permission to do it in experimental Java) - to support this goal GWT has been created. First of all only internally, then it was released as a toolkit of its own.

However the history shows - GWT is perfect for writing Gmail. Gmail and applications that look like Gmail. But be honest, do you really want to write applications like that? And when you want something just a little different, don't you feel GWT is a bit too heavyweight?

Bck2Brwsr is different. It started small with the goal to have as small Java as possible. Support just as little as possible to bootstrap Bck2Brwsr - this means less than 100 classes. The rest of the system is modular - look at the Bck2BrwsrJavadoc. It contains minimal emulation library, it contains Bck2Brwsr profile (the standard library people code against). When you want more - like access to an HTML page - you can use another library. When you want to use widgets (like Java FX ones) - add another library. If you don't need them, don't include such library and your framework is still going to be as slim as possible (currently ~200KB gzipped).