Looking at Tools

Its been a month, and I've spent it playing around with different front-end web application development tools. Specifically, in previous incarnations of this blog, I've stated that I'm not fond of javascript. Really not fond at all in fact. This has been debated endlessly online, but frankly I think its language which has several specific technical faults, and which just generally doesn't serve well as an application development tool. Even for small-to-medium projects I'd rather have strong typing, ONE kind of representation of 'null' instead of several, and a more clear and established sort of OO paradigm (to be fair javascript has maybe 5 different ones, and that's the problem!). While there are some 'standards' for modularity in javascript it isn't baked into the language, the various strategies don't mix well, and basically the result is a mess. While you could argue that ES2015, aka ES6, rectifies some of the deficiencies in a mild way, it leaves many of them intact and creates a C++-like mess of backwards compatibility hacks. This means you'll always be dealing with bad practices in libraries and tools forever. ES6 is also not available in browsers, meaning you still would have to compile/translate it to ES5, just to gain access to a few of the desired advantages.

The upshot is, I don't want to web application development in javascript; I just don't! I would argue against it even if I were doing work for a client, unless it was some extremely trivial amount of code. The lack of a good module system, strong typing, and a single consistent OO model are in my mind disqualifying. Of course there's no other option except javascript as an executable format for client-side application logic. Luckily we've progressed now to the point where we can write code in a better language and compile it to some sort of javascript which will run on the client side. This comes with many advantages:

1. We avoid the badness of javascript, a good implementation language will simply give you strong typing, good OO, modules, etc.
2. We get better unit testing and integration with existing mature IDE technology.
3. We can, if we choose correctly, share code between the client-side and the server-side of our application.

There are many choices for this implementation language, probably far too many to evaluate and almost too many to even list them all. Personally I've encountered, and sometimes used, the following: TypeScript, clojure, kotlin, scala, java, groovy, Ceylon, and Dart. Of these I exclude TypeScript and Dart from consideration due to their lack of JVM-based implementations. They could be used to create client-side code, but not to share it with server-side. This might not be a fatal consideration in a larger project, particularly where these languages might already be in use, but for my purposes I might as well have a JVM language, since I am planning to use the JVM in the back end.

Beyond wanting a JVM language, I would like one that is reasonably Java-like. Java may be criticized in various circles for this and that, and it has its faults, but its a very vanilla language, easy to understand, easy to write, very familiar. I also need something with good support for compilation to javascript. All of the above listed JVM languages have reasonable javascript target compilation support, so I did significant analysis of clojure, scala, and java itself. I also looked into the state of support for kotlin, ceylon, and dart.

Clojure is a little too functional for me. It lacks any real OO model at all. Clojurejs is a very mature ecosystem that provides all the functionality required to build a front end for a web application, compile to javascript, invoke existing javascript libraries, etc. However I just don't feel that the learning curve is worth climbing, and it is a steep one. If I was a LISP guy then I'd probably just go with this, but I'm going to pass.

I did a pretty extensive examination of Scalajs, including making a PoC of a front-end. Its a rather tempting idea. There's good support for React, which is an excellent front-end, and a good bit of support. Still, I find scala to be dense, obtuse, and hard to read. While I was able to master the language to a decent extent it would require a lot more time to fully master. I also found that the Eclipse support for scala/Scalajs is middling at best. Syntax highlighting, completion, and other features work intermittently and I spent many hours fiddling with things, and still never got Scalajs to consistently build my project every time. The resulting code is obtuse looking and I'm far from certain I've really achieved a good design. It would clearly require a lot of head scratching to get to a full web application this way. While scala is closer to a standard OO language than clojure, it still has a steep learning curve.

Of the three languages I checked out thoroughly that leaves java itself. Now, many years ago Google produced GWT, a large client-server app framework which relied on target compiling java to javascript. There were two issues with this, the framework was very heavy, mandating specific ways of accessing data, a specific application model and structure, etc. Secondly, javascript and browsers were much cruder in 2006 than they are now. As a result the target compilation was fairly unreliable and insuring cross-browser functionality was problematic at best. This earned GWT, and the notion of java as a front-end language, somewhat of a bad rep. Google eventually developed AngularJS as an alternative, and turned to Dart and then TypeScript in an attempt to make a lighter weight and more reliable construct.

However, as much as the entire mass of the GWT framework has no appeal for me and doesn't fit my idea of what I want to do, the GWT compiler itself is an excellent tool! Several different groups have continued to evolve the compiler and various light weight approaches to client-side java which simply use it as a nothing but a compiler. This is a very attractive concept. Currently I'm looking at VertxUI, which uses this strategy along with some simple libraries which provide something very similar to React, but written in java instead of JSX/javascript.

As for kotlin, ceylon, and dart... There doesn't appear to be a JVM incarnation of dart, though it seems like an obvious idea and dart has targetted other VMs, oh well! Ceylon has what appears to be a pretty solid javascript target compiler, some libraries, etc. Kotlin also targets javascript and has some active development. Neither of these two languages seems currently to have quite the level of maturity on the client side that java, scala, and clojure have. Ceylon seems to have limited traction in general, although it is a decent language. Kotlin appears to be gaining momentum, is a lot easier to use than scala as a java programmer, and has a decent amount of client-side activity. Still, neither of these seems to have anything quite like scalajs or java itself.

A final consideration is integration with my tool chain. I touched on Eclipse a bit earlier with respect to scalajs. I didn't get a chance to delve into kotlinjs, but kotlin is very heavily Intellij biased. I'm sure there's Eclipse support, but it is more of an afterthought. With scalajs there is a full suite of plugins for Eclipse and Gradle (my build tool of choice) although the community seems largely focused on the sbt command-line tool. I didn't evaluate ceylon deeply enough to discover exactly how well I could use it with Eclipse/Gradle.

VertxUI/GWT compiler seem to be rather winners here. Vertx itself has very solid Gradle support, and this seems to extend to VertxUI as well. Given that the implementation language is java, the Eclipse language support is sterling. I'm really looking forward to digging in and generating a PoC with this on a par with what I did for scalajs. It looks like the code itself will be MUCH more straightforward than the equivalent scala.