“HTML5, or as some people call it, HTML” – Jon Buda.

Just about a year and a half ago, I had the distinct pleasure of hosting my first ever Chicago HTML5 Meetup at the COOP coworking space in Chicago. Our presenters were Jon Buda and Sam Rosen. Sam presented the business case and design thinking behind Desktime (www.desktimeapp.com) and Jon Buda presented the tech stack and dev methodology.

It was a great night. A seminal moment for the Chicago HTML5 Meetup that set the tone for the blend of strategic, design and tech content that has become a staple of our monthly events and our great mixed membership.

I thoroughly enjoyed the event, but the thing that sticks out in my mind more than anything from that evening is the quote from Jon above. Not least because I was one of the folks on the losing end of the HTML5 v HTML naming argument.

Which brings to mind another statement on naming. At Brad Frost’s session at SXSW 2013, he was talking about the debate over what to call what we all now just think of as Responsive Web Design and mentioned AJAX as a great example of another epic naming battle. The thing I remember, his point, was that folks might have been freaked out over what to call AJAX, but nobody, NOBODY was arguing the fact that we needed a browser standard for the asynchronous exchange of data using Javascript.

Likewise, we might complain about the naming or even the contents and recommendations contained in the HTML5 specification, but we can all agree on the need for a standard. Well, most of us anyway.

Even though it’s still not fully supported everywhere, and still evolving, the buzz and adoption of HTML5 as a defacto standard has had a huge impact on our industry. The support for HTML5 by the browser vendors has resulted in significantly reduced uncertainty. We’ve moved out of Beta v VHS territory to a place where the risk of investing time, resources and money are much lower risk.

As a result, you can now find HTML5 in the dashboard of cars, in refrigerators, in smart tv systems and many other places where proprietary device native development once would have been the sole option for building an application.

I might be biased, but given that I’ve been a web developer since that was ever a thing one could do with their life, being able to use my core skillset to create things that might be just as likely to appear on a desktop computer screen as a vending machine or an in-dash entertainment system feels like a really good thing.

As a result of this new found stability, I’ve seen my peers turn their attention away from figuring out how to fix bugs in browsers that have dropped the ball on this feature or that. I don’t believe we’ll ever get away from progressive enhancement or graceful degradation. We need to do these things, but having clarity around what the browser vendors support now and at least a general idea of what they will support in the future means that progressive enhancement can legitimately be considered as more of an afterthought than the main event it used to be.

Freed from the drudgery of fixing bugs in browsers, and armed with the power of Github, we’ve seen more and more folks turning their attention to creating new tools to make our jobs easier and more efficient so that we can focus on even more innovation and the building of cool shit.

Good times my friends. Good times.

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required