HTML5 *Is* Ready

In what has to be one of the weirdest declarations of 1990’s Netscape4 vs. IE4 thinking the W3C’s Philippe Le Hegaret has suggested that we not deplay HTML5 yet in web projects.  I’m pretty sure that if we wait until all the web browsers are ready for HTML5 we’ll get the go-ahead in 2036, about the time I’m ready to retire.  Some poor blokes will still be on IE6 with more malware and viruses than Windows ME can deal with and the W3C will be telling us that we should still step into the HTML5 pool with gingerness.  Forget about HTML5 as a stable standard since we have things like HTML5Boilerplate, and JavaScript patches as well as things like Google Chrome Frame.

The idea is not that we should try to implement every fringe, unverified hack and standard, but we’ve been working with bleeding edge HTML4.1/ECMAscript and de facto browser standards for over a decade.  If that’s not clear to the W3C then I’m pretty sure they’re not prepared for 2011 when every major browser vendor will announce that they’re HTML5 ready.  Will there be interoperability issues?  Certainly.  Will there be hacks to get around them?  There already are!

HTML5 is a great concept and I think it will be the de facto standard moving forward from 2011 further.  I’m going to be updating all of my blogs to use HTML5 as time allows.  HTML5 will save money (working on a blog post for that) for companies that deplay the markup, ISPs who have to have provide bandwidth, and save time for end users who do almost nothing but upgrade their browsers to HTML5 ready versions and get the benefit.

One of the problems that made the HTML4/Netscape 4/IE4 wars so difficult was that bandwidth was scarce and unless AOL shipped yet another CD to your house with IE (5 or 6) on it, upgrading could take so long that your grandma’s call on the dial-up connection could be blocked.  However, with DSL and various other broadband mechanisms in place on top of auto-updating browsers the cost of the upgrade is minimal at best.  HTML5 is not the future, it’s the present.  Google pushed Google Wave as HTML5 goodness May 27th 2009 as a presently capable, functional application.  That means that very large corporations reaching millions of users have been using HTML5, even if it required a sub-set of browsers, for a hear and a half.  That means that my iPhone, my BlackBerry, my Droid and an array of other devices running Webkit and my desktop browser are all generally HTML5 capable.

I believe we can use HTML5, even if we don’t get to use it every single day for every possible feature it could provide if cross-browser perfection were achieved.  It’s ready.

Design & Development Links

Along the line of software craftsmanship on the web here are some handy sites I’ve seen recently:

JS Patterns
JS Patterns is a site dedicated to the design and development patterns that are not only industry standards, but also patterns that are native to JavaScript (which C++ or Java cannot do natively). This is definitely worth adding to your RSS feed reader.
Dustin Diaz
Dustin happens to work at Twitter, but his site is loaded with good JavaScript tips. If you’re not following his writing I’d suggest you consider doing so.
BlackBerry WebWorks
The WebWorks development/widget framework for BlackBerry devices looks interesting [disclosure: I work for a RIM subsidiary and have nothing to do with this project]. Download the toolkit from github or from RIM’s site and check it out. It’s focused on giving web developers a web-focused interface to develop for the webkit based smartphones.

Toolkits, Frameworks, and Libraries, Oh My!

On Monday the 4th of October Chris Coyier of CSS Tricks wrote on Twitter:

What they call themselves: jQuery = Library YUI = Library ExtJS = Library MooTools = Framework Prototype = Framework Dojo = Toolkit [cite]

I just got some crap for “not knowing the difference” – which I don’t. It’s just semantics (literally) as far as I know. [cite]

While I think it’s absolutely bad form for people to attack him on his use of those terms synonymously, it connected two apparently opposite ideas in my mind.  It resonated with some ideas I had about a debate that’s been going on in the last few months since Rebecca Murphey suggested that jQuery was not up to the task of being used as a framework in a browser based web application [cite].  Then there’s the jQuery forum discussion of adding JavaScriptMVC as an enterprise branch of the jQuery project [cite].  But here’s the big “revolutionary” idea: jQuery is just a library.  It is not a framework.  It goes well beyond a simple toolkit, but it is an excellent library.

Now, let’s get down to brass tacks.  In the first 10 years of web development there was a lack of craftsmanship and instead a lot of do it yourself or self-directed education by the community as we all learned the emerging web technologies.  I learned my first bits of HTML from HTML Goodies.  I then spent time on other sites and read a few JavaScript for Dummies type books when I got started over a decade ago.  Terms like Library, Toolkit and Framework were never discussed.  However, from an academic level these terms imply things about the code’s purpose and therefore are a critical part of the discussion.

Toolkit
A toolkit is a combination of classes or functions that do not define or limit the design of an application.  A toolkit may have a small handful of functions that allow you to do rollover events (see also: Dreamweaver’s JavaScript tricks).
Library
A library is a collection of classes or functions designed specifically to interface with one particular complex task.  Examples of a library might be an image manipulation library or a canvas manipulation library.  jQuery is a library because it was fundamentally a DOM manipulation library.
Framework
A framework is a collection of classes or functions designed to implement a certain pattern for a specific class of software.  A framework is for specific domains or types of applications such as web applications.  JavaScriptMVC is a framework for developing Model-View-Controller based web interfaces.

Did you see what I did there?  I just diffused a bomb.  OK, not really.  Rebecca Murphey’s direct problem with jQuery (and she has stated this) is not that it is a bad library, it is that it is not a complete framework.  That’s OK, because John and the rest of the jQuery developers have not been trying to make a framework.  John Resig doesn’t want an MVC framework as a direct branch of the jQuery library because JavaScriptMVC goes well beyond the purpose of the jQuery library.  However, the work done to build JavaScriptMVC as a framework that uses the jQuery library is really, really cool and powerful.

Across the spread of the web horizon lies the Dojo toolkit, which has expanded beyond just being a toolkit and really has taken on a multi-tiered approach: it has a toolkit presentation due to its name, but it really is a library (for the DOM like jQuery), but it also has a framework for creating MVC styled applications and taking on the details of a larger built application (See the Dojo Builder for Eclipse or the dojo toolbox).  The purpose of the build tools is to allow you to compile the appropriate libraries from within the larger Dojo framework into a final, smaller file (or files) for inclusion in your project.

So fundamentally you need to ask yourself what your project needs: does it need a toolkit?  I would suggest it just might given that there may only be a handful of tasks that you really need to accomplish.  Does it need a library?  If there is very much DOM manipulation you should evaluate the various libraries and confirm that one of them meets your needs (or has the smallest learning curve, or whatever specifications you have) .  Does it need a framework?  Are you making a website or a web application?  If you’re making a web application you probably need a server side framework such as CakePHP or Ruby on Rails.  You probably want to consider what client side framework you’ll need.  Having rolled my own I can confidently say that rolling your own won’t kill you, but you should absolutely consider the frameworks that do exist because it could save you time and be very extensible in the future when your project goes for another iteration that needs more meat.

This hasn’t been a journey down the yellow brick road to the emerald city, but whether you see lions, toolkits, or bears be aware that the terms do have a technical implication and your use of them may help clear up confusion.  And it could help you in that next interview when the project lead asks you if you prefer to use one religious war starting technology over another more holy religious war starting technology 😉  I’m going to stick with using my new favorite library: vapor.js.

From My Dad: Grace

This was something my dad sent me by email that I thought was worth passing along to the Internet:

There are a great many Christians who do not understand what God intended by the word ‘grace’:

  • To the Calvinist, grace is something God forces on you.
  • To the Arminian, God offers a salvation by grace that is yours to both choose and to lose.
  • To the Open Theist, grace causes God to have the best of intentions, but if it doesn’t work out that way, He just can’t help it, and He didn’t know it wouldn’t work out, but at least you can relate to Him better because He’s more like you in those respects.
  • To the Charismatic, grace is real if and when you can feel it, to the extent it’s revealed to you.
  • To the Legalist, grace means that God isn’t quite as uptight and picky as He once was, but you’d better not forget that He’s still pretty uptight and picky – so get to work!

But to God, grace is an infinite aspect of His character, which is now the reigning principle, by which He enables and motivates all that we do, and in which we are to grow now, and which is so truly awesome that He will show – visibly demonstrate – His grace to us for all eternity.