Thoughts on HTML5 and Development Methodologies

Over the past few months the Errai team has been busy at work preparing the next version of the Errai Framework, Errai 2.0.

It is a significant update that leverages all the best ideas that Errai 1.x had, while retiring some ideas and approaches that didn’t quite work out the way we’d planned.

Errai has developed a philosophy about rich application development in the browser. That philosophy might be summed up as: Your Application. Everywhere. Literally.

However, there’s been some people who’ve criticized this methodology. I’d like to respond to some of this now.

We have eschewed much of the conventional wisdom about how you should architect a web application by focusing on not just rich user experience, but rich developer experience. We believe that the latter ultimately leads to a better former.

We reject the need for polyglot applications as necessary -- the idea that the best way to build an application is to arrange a constellation of disparate languages and frameworks into a coherent single application is simply the “best approach” is something we don’t agree with.

You’re building your application in Java on the server. Why do you build the other part of it in JavaScript? The common response to this is, well, “that’s just the best way to do it”. But is it?

We don’t think it is. At the end of the day, the whole HTML5 group of technologies is just a specification that tells us how to make a browser do things.

Whether we write HTML and JavaScript directly or not, whether it’s translated from CoffeeScript, Dart, or in the case of Errai -- Java -- is immaterial. And it’s wrong to even suggest that Errai, with its use of the GWT compiler, sandboxes you into a world that proscribes any of these things. It doesn’t.

With Errai, your application can contain no JavaScript, or be almost all JavaScript.

The important part is how Errai helps you share not just model between the client and the server, but functionality. Without the need to write it twice, or write marshalling code, or worry about setting up your own comet or websockets. The communication model is central to the application development model.

Being able to share functionality, using the same code, with the same functionality is a good thing. You get all the benefits of type checking, code reuse, and productivity.

The implication that some make that, this sort of thing “hides the true nature of the web” is always one that puzzled me among those who advocate for a pure JavaScript approach.

I’ve always been of the opinion that such essentialist notions of pretty much anything are probably notions you should be suspicious of. I mean, the Java compiler hides bytecode. The C++ and C that the JVM is written in hides machine code.

It goes without saying that JavaScript itself is hiding all of this.

Moreover, JavaScript isn’t a terribly good language for large applications. And it surprises me that some of the very same people who trumpet the advantages of Java over other languages, will so willingly jettison their arguments in favor Java when it comes to JavaScript. There’s no immutability, side effects are hard to control, the object model is a mess, there’s nothing resembling a threading model, etc.

To which, counterarguments often include techniques about how JavaScript prototypes can be used in ways that simulate classes and inheritance, unit testing can guard against unintended side effects in large codebase, concurrency concerns do not apply in the world of the future, etc -- as if any of this somehow redeems JavaScript in any way in the eyes of someone who buys into these notions as being intrinsically good parts of a language.

JavaScript isn’t a bad language. Don’t get me wrong. It is mature and well understood. It does what its supposed to do. But the problem is, it was never designed with large application development in mind. Its designers did not envision a world where there’d be codebases of 100,000 lines of JavaScript code.

Yet, this is the world we’re quickly moving into. And the reality is, that technologies like GWT are extremely good solutions to manage these sorts of projects.

Over the next few weeks we’re going to show you why. Watch this space.