GWT

From APIDesign

Current revision

GWT is a Java port that runs in a browser, but (unlike Bck2Brwsr project) compiles to JavaScript on the desktop. The GWT compiler runs in real VM (e.g. HotSpot) and translates Java code to static JavaScript. As such 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 create a Java AST
• one does not need to do attribution - e.g. resolve fully qualified names of every symbol
• new versions of the Java language are supported (almost) immediately

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 was created. First of all only internally, then it was released as a toolkit of its own.

However the history remains - GWT is perfect for writing 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).

Language or a Framework?

In one of my essays I asked: Is Java language or a framework? GWT answers such question clearly: Java is seen as a language. The fact that there is also a VM specification is put aside. The fact that various systems/languages can talk via ByteCode to each other, is ignored.

On the other hand Bck2Brwsr tries to treat Java as a framework. The VM interface is there, ByteCode is the lingua franca which the Bck2Brwsr VM understands. Reflection is naturaly present. Sure, the Bck2Brwsr framework is not full featured Java SE - it is a subset. But a base, common subset that can grow and behave same in browsers as well as HotSpot.

Common Ground and WORA

The days when WORA was the biggest strength of Java seemed to come to their ends. If you want to target browsers now, you need to deploy JavaScript. But that does not mean you have to write JavaScript! We can (re)design the roots of Java and together find a common ground for the Java as we know it (aka HotSpot) and Java that fits into browsers.

Bck2Brwsr framework can be such common ground. If you care about Java, join us to make it better. Consider migrating from GWT - it is so easy!