Blog: Detail

Published on:
4 July 2014
Technology do we really need another Javascript framework?, the hot new kid on the Javascript framework block, has recently launched its first public release after being in development for nearly three years. Even before it was released there was a lot of buzz in the developer community about this framework that claims to make it easy to create beautiful and lightning-fast HTML5 powered apps. In this article Jeroen Janssen tries to see beyond the hype and explains what does and how it differs from the myriad of existing Javascript frameworks. major claim to fame is that it lets developers create HTML5-powered mobile apps that are just as fast and fluid as native apps. Before we dive into how tries to accomplish this it might be good to take a moment to make clear out what it is not. is not an organisational MVC framework like Backbone, Ember or Angular, neither is it a replacement for something like jQuery. As a matter of fact, doesn’t give you much to organise your code at all and it should probably be used together with an existing MVC framework for all but the simplest of projects. Mind you, this is not a bad thing, there are more than enough excellent Javascript MVC frameworks already and there are efforts underway to make integrate nicely with most of these. The team is even working on an ‘official’ integration of with Angular.

So what is then?
To put it simply, is a custom built JavaScript 3D rendering and physics engine meant as a replacement for the standard layout engine of the browser. It effectively skips the browsers rendering engine and instead uses its own more efficient rendering engine based on WebGL that replaces the DOM positioning model with CSS3 transformations. The stated reason behind this is that the DOM was made for displaying text documents, not building complex apps.

As mentioned earlier, Web technologies like HTML and CSS were originally intended to markup and style text based documents and they are not well suited for making rich media based experiences, let alone for making complicated applications. HTML5 has added a lot of possibilities for making more complex websites and apps, but fundamentally it is still a markup language. intends to solve this problem by skipping all the markup based functionality of HTML5. We can still use CSS to style elements, but the whole idea of ‘markup’ is basically gone and we are left with a page with a bunch of absolute position divs without any hierarchy or structure.

In that sense there is a fundamental difference between MVC frameworks and; the former are meant to organise code but the end-result of using these frameworks is still a HTML5 based website, however basically replaces most of HTML5 with its own technology. In that sense might be more like Flash than like most existing frameworks. There are some key differences between Flash and as well. For instance, one of Flash major shortcomings, and probably a big reason for its downfall, is its proprietary nature, is Open Source so that would be less of an issue. Another key difference is that uses built in browser technologies and doesn’t rely on plug-ins, which of course also means that it’s dependent on certain browser technologies to make it work. Which brings me to another point, and it’s kind of a big one: Unfortunately currently doesn’t currently support Internet Explorer. For mobile only development this is not really a big deal but it effectively eliminates as a serious option for web apps that also has to work on the desktop.

Is it a bad thing that replaces major parts of HTML5? To be honest, I’m not sure. As a Front-end developer I have to admit it makes me slightly uneasy to have to use a custom API instead of ‘standard’ HTML5. On the other hand, like almost everyone that makes web apps for a living, I have been terribly frustrated by some of HTML5 limitations, like slowness and browser incompatibilities. Either way, it might be a good thing to try a fundamentally different approach so I’m keeping an open mind for now. chases another holy grail, namely the ‘write once, run anywhere’ dream. Instead of having to write different code for different platforms, like iOS and Android, developers can write one application that works and looks as good on all platforms, in theory anyway. This of course saves a huge amount of time and resources. Unfortunately, this idea is not without its problems and has never really worked very well with earlier attempts like Java-applets, Flash and Silverlight. In the end native applications have so far always been faster and slicker and I’m pretty sceptical will be able to change this.

So, does live up to its stated goals? Well, yes and no. The demos that put out were really impressive but after the initial release a lot of developers were severely disappointed by some serious performance issues. Scrolling for instance is really slow and jerky, which is a major disappointment, especially considering how much emphasis is put on the speed of the rendering engine.

The consensus seems to be that has a lot of potential but that it’s not really ready for prime time yet and that a lot of kinks need to be worked out before it’s ready to be used for serious production work.

Will we start using
It’s great that is pushing the boundaries of what’s possible with HTML5. But it will probably take a while before we at Inspire will seriously consider it for production work. It’s still a bit rough around the edges and we are holding off on using it for production work until it has matured a bit more and when the browser support is a bit better but we will definitely keep playing around with it.



  • 4 July 2014 Brian

    Good info, but please check this out:

  • 4 July 2014 Wade

    "Unfortunately currently doesn’t currently support Internet Explorer. For mobile only development this is not really a big deal"

    Reading this on a mobile device where that's a big deal. Internet Explorer 11, which is the current Windows Phone version, supports WebGL. I hope they're looking at it.

  • 4 July 2014 Craig

    We had to abandon in our recent project due to it's scrollview performance.

  • 4 July 2014 Terry A. Davis

    I wrote a compiler. I do not use anybody else's code. My operating system is 130,000 lines of code written by me. I know what a fucken compiler is. I wrote one. It is not an interpretor. It compiles 64-bit holy C and asm. I'm so awesome you don't beleive. Sad.

  • 4 July 2014 Krish Dholakiya


    When listing JavaScript frameworks, you listed Amber, which is actually spelled Ember. Just thought I'd let you know :)

    - Krish

  • 4 July 2014 Jeroen Janssen

    Brian and Krish I've fixed the mistakes, thanks for pointing it out.

  • 5 July 2014 Jon Frisby does *not* use WebGL, and does *not* "replace" the rendering engine. It's a scene-graph architecture on top of CSS3 transforms (which you'll note have absolutely nothing to do with WebGL, and are a perfectly ordinary part of the rendering architecture of a the DOM positioning model).

  • 5 July 2014 Bobby Schultz

    Frameworks is too broad a term when you're comparing these things together. They are all intended to solve different subsets of the problem. HTML+CSS is head and shoulders above other structures for rendering static content at any screen size but with dynamic content it often falls flat.
    Angular and Backbone are tackling the problem of building fully dynamic app without worrying about the current browsers rendering inefficiencies. and Facebook's React are attempts to propose better rendering engines for the browsers to handle dynamic content effectively.
    A more accurate why to look at is like what Polymer does. Polymer is a titanic shift in web development at the same scope that REST has been to allow for webapps and mash-ups. They are polyfilling the browser to create proper web components, figure out the issues and evolve a better solution to fix the issue of reusable code and 3rd party libraries. JQuery did the same thing which has evolved into the document.querySelectorAll. is a polyfill to improve the browser's rendering engine. Through developers building more things and feeding back improvements to the rendering engine. Hopefully it will help drive W3C to start tackling the massive rendering problems it has with dynamic content.

  • 6 July 2014 Jon Frisby is *not* even remotely like a polyfill for for the rendering engine. It's simply an abstraction on top of the rendering engine to make it easy to utilize it in a particular way that would otherwise be awkward to use. is a *scene graph architecture* that utilizes the DOM for rendering. Nothing more, nothing less.

Add comment