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:
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
Sorry I missed this comment!
I invite you to read over Jo's documentation, in particular the section on objects and coding patterns:
IE 9 is an irrelevance for the next few years unless someone can persuade MS to put IE9 on Win XP.
Exploring the Nuxeo REST APINuxeo