During the last year, HTML5 has gained general acceptance as one of the dominant development platforms for both the classic and the mobile Web. In that time new JavaScript frameworks have evolved that directly target this platform and attempt to set a new paradigm for Web development.
InfoQ has had a virtual panel in the past with the creators and lead developers of some of the most popular JavaScript frameworks and platforms like Dojo, YUI, Prototype, script.aculo.us, MooTools and GWT, about how they see their projects evolving to facilitate HTML5 development.
With the emergence of new HTML5-specific frameworks, InfoQ had a Q&A with their creators about how their projects differ from the current toolkits and what new things they have to offer to developers.
The participants where:
InfoQ: With several established JavaScript frameworks already out there, what was the motivation for developing a new one targeted at HTML 5? What are its benefits over more traditional solutions?
Dave (Jo): The premise for Jo was "what happens when you let the browser engine do more of the work?" Turns out you end up with a very small, simple framework which doesn't have any deep compromises based on individual browser engines. It's like a fresh start, and it feels great.
The set of W3C working drafts and proposals we're calling "HTML5" give JavaScript developers more of an ability to produce world-class applications which can compete with native applications. Persistent client-side storage, low level file access, sockets, background processes, hardware-accelerated UI presentation and animation are some of the features which caught my eye.
HTML5 has gained a foothold in the desktop browser, but doesn't dominate that world yet. While we wait for the Windows user base to adopt Internet Explorer 9 (which will have many of the "cool" features in the HTML5 specs), other devices already have many of these capabilities. Apple iOS, Google Android and Chrome, webOS and recently Rim and Symbian are baking advanced features found in HTML5 into smart phones, tablets and netbooks.
So while HTML5 is a little early for broad desktop support, newer mobile devices have already converged on HTML5 as a pretty consistent platform across the market.
Faruk (Modernizr): Modernizr emerged from the idea that websites don't have to look the same in every browser—most notably, older and less capable browsers need not look pixel-perfect. I started thinking about a way to not just spread that message to more people, but also to make the development of websites in that fashion easier. Spreading good advice on web development is one thing; facilitating the process and making it easier and better is much more effective. The fact that I was getting frustrated with relying on the largely unreliable (and terribly ill-advised practice) of UserAgent sniffing to target different browsers' feature sets compounded the need for a reliable way to know what features from HTML5 and CSS3 were available to use in each browser.
When I set out to create Modernizr, it was clear that I had to keep its focus narrow. jQuery and other frameworks existed, but none of them offered the key thing that Modernizr does, so I decided to make Modernizr focus solely on that one key thing, which is feature detection. Rather than trying to be a huge swiss knife of a JavaScript library, I wanted Modernizr to be a tiny but fundamentally useful component to any web developer's arsenal. And the more cutting edge they are, the more useful Modernizr would be.
Jacob (Simpli5): My guess is probably 1/2 of the code that makes up established Javascript frameworks accounts for cross-browser compatibility or filling in features missing in subpar browsers. If I'm building HTML5 apps, why should we require the download (and slow-down) of scripts that help out older browsers? In addition, there are many Javascript features that frameworks can't use because not all browsers would be compatible (e.g. implicit getters/setters). By developing a new framework targeted for HTML5 instead of extending existing frameworks, we can make the framework smaller, faster, and slicker because we are not constrained by the same rules that current generation frameworks are.
InfoQ: Would you like to give us an architectural overview of your framework? What are its main components and how do they interact with each other?
Dave (Jo): First, the whole framework embraces JavaScript's object model. The techniques and coding patterns used to build Jo mirror those presented in "JavaScript, The Good Parts" (Crockford / O'Reilly Press) along with some idioms which perform well; especially so in Google's V8 engine.
Name-spacing is accomplished through a consistent naming standard rather than nesting objects (e.g. joButton vs. JO.UI.Button). This saves a little time versus walking the prototype chain each time you reference an object. More importantly, JavaScript engines like V8 can highly-optimize storage for object literals, but have to "downshift" to slower methods if you add or remove individual properties to the object. This means that entire frameworks which use the nested object name-spacing are making their library bigger and slower.
Aside from simple utility objects and methods, formal objects within Jo use a refined "observer pattern" OOP standard. Basically, objects fire off event notifications to any subscriber objects. This type of communication between objects is very flexible and easy to "rewire". Plus, since the interface between objects is "clean", it helps promote good unit testing practices.
UI elements have a base "class" called joView. Each UI element you create in Jo consumes one or more HTML tags, and manipulates them in most cases by changing .className properties. This means all the presentation and visual behaviors are controlled by CSS. Instead of animation code written in JavaScript, we're using CSS3 transitions to accomplish all the shiny stuff.
joControl is the basis for input boxes, buttons, checkboxes and other typical GUI controls. joContainer is the base "class" for organizing sets of UI elements. Some of the sugar in Jo can be seen with joContainer (and its children, like joCard). For example:var myui = new joCard([ new joTitle("Hello World!"), new joGroup([ new joLabel("Username"), new joInput(joPreference.bind("username")), ]), new joFooter([ new joDivider(), new joButton("Goodbye") ]) ]);And you have a simple dialog, ready to display (usually by calling the joStack.push() method).
Along with a rich set of UI objects, Jo has joDataSource and its children. Basically, these objects wrap things like XHR, SQLite, cookies and other more interesting ways to get asynchronous data. The advantage here is your app can have a pretty consistent interface over different data storage and retrieval approaches.
Faruk (Modernizr): Modernizr is very small and straightforward, really: we run a series of tests, and each test detects a specific feature in the browser. We don't ask what browser it is, we simply ask: do you support (e.g.) border-radius? Do you support HTML5 Video? Do you support Geolocation? And so forth. We then collate all the test results and add them as classes to the HTML element, as well as putting them in a Modernizr object you can interact with in JavaScript. The classes on the HTML element simply say either "borderradius" or "no-borderradius" for border-radius, depending on if the browser supports it natively or not. With all of the tests available to you as CSS classes you can fork even your CSS rules based strictly on what the browser can do. Not what its UserAgent string is or its version number, but whether it actually supports that feature.
So the only components we have, really, are the many individual tests, and a small bit of routine for processing. Some tests involve a timed fallback, like the @font-face test, because their associated feature is not always immediately available, and needs an asynchronous check.
Jacob (Simpli5): I really love how easy jQuery makes working with the DOM, but I've always wished I could call the methods on the elements when I had one instead of always needing to wrap them with jQuery. So the core of Simpli5 adds much of what jQuery provides to the HTMLElement prototype. Some Javascript developers will look down on this, but I feel that taking advantage of the Javascript language (without getting too out of hand) allows us to be more productive and have more readable scripts. A Simpli5 object, much like a jQuery object, is an array of elements and calling methods on it will forward those calls onto the elements themselves. So document.body.addClass('myclass') and $('div').addClass('myclass') both add to the class of the elements.
I've added a small class system because robust HTML5 applications need structure and good organization to maintain. It looks similar to MooTools classes which I find very readable, and it works quite well with inheritance.
Finally, I've built a component system that includes templating (inspired by ExtJS core) and data-binding and is the coolest part of the system IMO.
InfoQ: How is the interoperability between your framework and the more popular client-side JavaScript frameworks like jQuery, Dojo and Prototype? Do they play well together?
Dave (Jo): Jo plays well with other libraries. In fact, it's designed with low level libraries like PhoneGap in mind. I'm not trying to solve all the nitty-gritty problems across devices like "launch a browser URL" or "tell me when my app code can start". Jo is a relatively high-level framework.
Faruk (Modernizr): Instead of trying to be a framework, Modernizr sticks to being a toolkit that you can safely use in combination with many other libraries and frameworks. There was an incompatibility with ie-css3.js but that existed only under still-uncommon use cases (using ARIA role attributes).
Jacob (Simpli5): They should play just fine together mostly. Simpli5, like jQuery will use the $ variable if it hasn't already been taken, but can be assigned to something else. It does use Class same as Prototype and MooTools, so whichever of those is loaded last will be the class system you're using.
InfoQ: Could you give us an example case where your framework best demonstrates its capabilities and a brief description of the solution?
Dave (Jo): Jo was made specifically to solve the problem of "how can we make an app supported across a broad range of devices, each with their own display size and eccentricities?". Since Jo offloads all the real UI work to CSS3 (and, on some platforms, hardware acceleration), this means your application code across these platform will be essentially the same. The bulk of the cross-platform issues are mitigated through CSS3 and wrapping low-level libraries like PhoneGap.
Faruk (Modernizr): My own website (at time of writing) features, among other things, a series of tabs that behave differently on a mouse over ( :hover ) state, depending on what the browser can do. If the browser is fully capable, there is a nice, subtle animation with a color transition and a small width change. The fewer features other browsers have, the less interesting this hover effect becomes. Modernizr allowed me to very easily and safely target browsers based on their capabitilies and feed them different CSS rules—rules which would conflict and override each other without Modernizr.
Jacob (Simpli5): The framework is still very fresh, just a month old, but I think it has been maturing quickly. I'm striving to support what most other frameworks support with less code as well as making it easier to code by taking advantage of features that are supported by HTML5 browsers. I think it best shines in the component system as you are able to define a component in an easily readable manner that works well, and encourages component development.
InfoQ: How do you see the JavaScript frameworks evolving to accommodate HTML5?
Dave (Jo): JavaScript libraries should be getting smaller and simpler over time. More low-level UI and animations should be offloaded to CSS3, keeping the JavaScript clean of DOM-centric code. Also, things like worker processes built into HTML5 mean we code background tasks in a more natural way, without having to build ridiculously complex code to prevent blocking the UI.
Faruk (Modernizr): HTML5 and CSS3 are becoming more and more widespread, thanks in large part to the Webkit browser engine which is the de facto standard for almost all mobile browsers today, in most of the world. JavaScript frameworks are playing in on this, and are slowly adapting themselves to take advantage of native implementations where available, and using JavaScript-driven fallbacks where not.
Jacob (Simpli5): I see most of them adding HTML5 extensions, leaving the core of their frameworks bloated with cross-browser compatibility code for a few years still, until most of the internet has moved to HTML5. They have to because they fill a need for developers to have their scripts run cross-browser. Only a few who are able to choose to only support HTML5 have the benefit of ditching the old code and old browsers and moving forward. And honestly, the "bloat" isn't significant with higher bandwidths and faster JS engines.
I also see new libraries for SQL, stored data, sockets, and other cool things popping up. Those should be fun to play with.
InfoQ: How do you see the HTML 5 and browser implementations evolving in the near future? Are there things that you think are still missing and from the specs? Do you have any criticism on a specific technology that comes as part of HTML 5?
Dave (Jo): Right now Safari (and mobile webkit on iPhone and iPad) is the only solution out there with hardware-accelerated 3D transformations in CSS3, and that's a big disappointment. It limits the "cool" factor for JavaScript apps on 94% of the browser market, or forces us to code things which simply won't perform on a mobile device.
The biggest weakness in the spec is persistent client data storage. Webkit, Gecko, and IE all use their own flavors for local storage and it's irritating to code to.
I'm most excited about "web worker" background processes. So many app coding challenges we have today revolve around breaking time consuming tasks into smaller pieces chained together in some awkward way. The very idea of presenting a list and having a background process populate it without interrupting the user experience is dead sexy.
Faruk (Modernizr): There's a lot to be said about HTML5, the browsers and how the market is responding to it all. Us web developers and standards advocates can sometimes forget the bigger picture, which is that end users don't care. They care about how well (or not) something works, not whether it's made with Flash, Silverlight, HTML5 or CSS3.
It's easy to criticize the process of HTML5 and how certain vendors treat it, but given how complicated and chaotic such a huge undertaking invariably is, I'm actually rather pleased with it all. We can finally do things in browsers now that we were still just dreaming of a couple years ago, and the pace of innovations and new features being added to browsers is incredible. It's the most exciting time to be a web developer right now, which is reflected in the strong community support around Modernizr. Even before it was made fully open source, people were contributing code to it from all over the world.
It is that enthusiasm that people have for Modernizr that keeps us going developing it and making it a better and even more useful toolkit for all web developers who want to build sites the right way.
Jacob (Simpli5): I see additional features added to video and audio components, such as the ability to skin, or composite into the page better. There is still quite a bit of power Flash has with video that the browser isn't going to support. Performance isn't part of the specs, but that's what I see as the next big push on HTML5. JS performance has been continually increasing, but rendering performance will need to increase as well. If you want to build games in HTML5 you are limited to a certain performance level.
You can find much more information about HTML5, JavaScript and other Rich Internet Application technologies right here at InfoQ.