Errai: The browser as a platform

Saturday, December 17, 2011

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.

10 comments:

  1. > 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.

    That argument can be reversed by saying "just use javascript on the server". Note that running javascript on the server is a natural thing. You don't have to compile javascript to java to run it on the server.

    > 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.

    It's not about hiding the nature of the web, it's about whether you trust X -> HTML5/JS compilers to output something useful.

    If you don't care about the generated markup, then by all means use the tools. If you care about semantic accessible markup then you use HTML5 and JavaScript.

    If your platform can actually write semantic and accessible markup then I'll be greatly suprised and interested.

    ReplyDelete
  2. Hopefully Errai 2 will leverage the GWT RequestFactory stuff to allow JPA Entities to be sent back and forth complete with validation annotations etc... Or maybe this is already possible and I missed it? Complete with data-binding. Ah, I can dream...

    ReplyDelete
  3. Our plan for JPA is a little bit different than the approach taken by the GWT team with RequestFactory. You will start hearing more about that soon. And it's really, really cool.

    ReplyDelete
  4. Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
    Avatar Html5 Video Player

    ReplyDelete
  5. Wow, the game has changed with the announcement that Adobe is no longer supporting development for FLASH for mobile devices or TV…it is focusing on youtube html5 and Adobe AIR apps instead….the news got around the game development community quickly. I think the market penetration of mobile devices like the iPad, iPhone, and iTouch from Apple being a merket leader who doesn’t support FLASH made a true impression on developers whose clients pages were losing views by this audience. Comsider Apple’s leadership history introducing CD ROM’s fiirst in computers, dropping the beige look of computers, introucing the iMAc, iTunes, Quicktime, and Jobs support of Blu Ray at Disney helped set standards in many industries…

    ReplyDelete
  6. very nice thanks for sharing

    hey friend see snow on google
    Type “Let It Snow” on @Google If you click and drag you can wipe the snow away. It is great. source: http://le-titsnow.blogspot.com

    ReplyDelete
  7. I am exicited about HTML5 but Flash can do all these things youtube html5 player
    can do in a better way.Creating slideshow in HTML5! wow! what, flash did that 10 years ago! It is very easy to create a flash animation, for example a ball bouncing in flash professional in less than am minute. Javascript is a mess when compared to AS3.

    ReplyDelete
  8. I wanted to thank you for this great read!! I definitely loved every little bit of it. I have you bookmarked your site to check out the new stuff you post.
    source: www.wbupdates.com

    ReplyDelete