Russell Beattie

In the immortal words of Bill Cosby, "I told you that story to tell you this one."

Over the past six months or so, I've been heads down on a couple different web projects which make heavy use of HTML5, and more specifically dynamic, Javascript-templated designs. At first, I have to say I was quite hesitant. It was only a few years ago that I was completely uninterested in Javascript because it wasn't supported by most mobile devices at the time. Now suddenly I'm creating pages that are almost 100% generated with Javascript? Really?

It took me a bit of thinking before I realized this is not just some passing development fad, but an actual shift in how the web itself worked.

If you think about it, the power of the average web browser is greater than it ever has been before. Not only because of Moore's Law, but because of huge improvements in speed, quality and functionality over the past few years, pushed mostly by Google and Apple. This in turn has spurred Microsoft and Mozilla to finally get off their asses and create competing products as well. Combined with the movement towards HTML5's new capabilities, we are all using a browser today that is far, far more powerful just a few years ago. (With so much recent focus on cloud services, I think this has been overlooked, or at least it was by me.)

More powerful browsers mean we can rely on them to do more work, rather than doing it all on the server - specifically we can start to push the line between where the Content or User Interface starts waaaay over to the client side, letting the server be dedicated to back-end logic and data management. This has been tried before lots of times, but this time, I think, is different.

I was trying to pinpoint why I think this, and realized in my case, there was more to it than just HTML5 support. In addition to the beefed up browser and new buzzwordy spec, there's a few other important parts in the equation as well: Developer tools, JSON data, non-PC browsers and Apps.

Huh? Let me explain...

Developer Tools are the new View Source. It's pretty accepted wisdom that a big part of the web's adoption early on was due to the fact that anyone could 'view source' on the page they were looking at to see how it was created. View Source is almost a religion in many ways, and there's not a PC browser that exists today that still doesn't have it prominently displayed in their menus somewhere. But what happens when you view source and the entire page has been dynamically generated? Well, you get nothing but a mostly empty HTML page, a few script tags and a div tag or two. But Developer Tools like Firebug, Chrome's "Inspect Element" and the equivalents in IE and Safari, re-enable this fundamental feature of the web, allowing you to view the DOM and the scripts of the page, even if it was created dynamically in the browser. This lets other developers learn from these sorts of pages, and then go off to develop their own. It's a cycle I think was broken for a time, but now is back and is just as important now as it was during the first era of the web.

JSON is the data exchange standard we've been waiting for. I lived through the full hype cycle of XML and all the related technologies like XSL, XHTML, etc. At one point in my life, I was seriously considering developing using Apache's Cocoon, which is to say, I was insane. XML has its place it the world, but it's not as a part of the web, especially in terms of exchanging basic data with well known systems and APIs. JSON is simple, it's flexible, it's fast and best of all, it's a great cognitive match for what it's mostly used for - which is shunting data around from websites to web browsers using Javascript with minimal hassle. That last part is key - developers have had their fill of over-architected XML-based systems which constantly fail for various inconsequential reasons, and are nigh impossible to change once implemented. Moving to JSON both enables more rapid development, and encourages web developers to think in terms of APIs, rather than in pages. This in turn makes moving functionality to the client all that much easier.

Browsers are now everywhere, and they all work pretty great. The newest buzzword is the Responsive Web, and though I bristle at it every time I hear it (do these guys think they invented "mobile first"?!?), I think it's generally a great idea. A web page should as flexible as possible, being able to work just as well on an iPhone, an iPad, a regular PC or even a wall-sized display. In order to do that, you need to have as much intelligence on the device as possible. Doing device detection on the server with User-Agent databases just doesn't work (I know from personal experience): Devices lie, databases go out of date, etc. If developers really want to create responsive interfaces which adjust dynamically, the device itself is the only place to learn about its capabilities. That means moving more UI to the client.

"Apps" can be developed like tiny dedicated websites. Apps are becoming a fundamental part of the web landscape. Whether you're an established content site or a new start-up, you have to have some sort of app as part of your strategy. Increasingly, developing these types of apps rely in whole or in part on web technologies to ease portability between devices: Embedding Webkit or using PhoneGap, then developing the UI in HTML/Javascript and communicating with servers and services via JSON APIs. Netflix, Logitech and LinkedIn have all talked about how they're using HTML5 to create apps targeting multiple devices across platforms, from a mobile to a set-top box.

All of this, in my opinion, adds up to a new way to look at web app development. It's a browser-first focus, where the server is simply there to serve up data as needed. Again, that's not a new concept, but this time it's really going to happen. Now that I've actually tried it a couple times - having a web server that does little more than serve up static files and JSON data to be formatted dynamically on my phone, tablet and PC - I see how fast, flexible and functional this approach is. It's hard to go back (well, except when I'm being lazy).

There are problems, of course. In addition to the above laziness (a trait many web devs will share with me, I'm sure), Google only parses some Javascript, so creating a site that depends totally on the browser to format pages essentially makes it invisible to it and other search engines without some sort of work in the back end. Sites that have done that work have permalinks that have been polluted beyond recognition by the horror that is the hash-bang. Anyone who wants to turn Javascript off, or still uses a less-than capable browser or device won't be a happy camper. And of course some sites will go insane and just go overkill with Javascript - a great example is Github, which uses 10,000+ lines of Javascript on its pages for reasons completely unknown to me.

Still, I'm convinced it's inevitable - 20 years of shoving data into HTML templates is coming to an end, I can feel it. Long live the new dynamic web!

-Russ