Click here to monitor SSC

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

HTML5 and JavaScript: Worse is Better?

Published 12 April 2013 11:13 am

HTML5, by which I mean the combination of HTML5, JavaScript and CSS3, is in the place where Java originally wanted to be. It is truly cross platform and if not quite “write-once-run-anywhere”, then it is much closer to that ideal than anything else has ever been. If we want to target Macs, PCs, ChromeBooks, tablets, mobile devices, then about the only thing they have in common is that they all run HTML5.

We are now at a stage where HTML5 is wielded as a serious application development platform. Consider the fact that Spotify builds its apps using HTML5, CSS and JavaScript, and that the Spotify product is essentially just another Spotify app; if you go to an artist page, it’s the same on play.spotify.com as on the desktop client.

To many, the burgeoning ubiquity of HTML5/JavaScript is a cause for celebration. On the client, with help from Adobe Air, or the framework formerly known as Metro, it can perform some intimate acts with the operating system that supports it. With Ext Js, or one of the many other JavaScript libraries, it can behave more like an application and less like a traditional browser, in order to make its use more palatable. Sure, there is plenty to criticize in JavaScript, but it can be made to work well and gets the job done. On the server-side, the emergence of node.js makes it easy to create event-driven asynchronous services, for applications and websites. It means that they can create HTML5-based applications using just one language.

Even five years ago, people would have deemed Spotify mad, building desktop apps in HTML and supporting cast, and many find little to celebrate in the emergence of an application development “platform” based on languages originally designed for presenting textual documents. They deride JavaScript. They point out that node.js uses a non-blocking style of writing code, without anything in the language that helps escape “callback hell“.

Ultimately, it’s true that the result is a compromised, “glued together” platform that by sheer dint of its ubiquity will triumph over “properly engineered” solutions, but that’s nothing new. It’s the superior survival characteristics of “worse-is-better” over the “right thing”. A solution that’s good enough, easy to implement and easy to use will usually beat the “better” solution. UNIX isn’t perfect, but Plan 9 wasn’t superior enough to displace it. C is straightforward to implement, so it’s the most common systems language. Likewise, HTML5 is on every device, and lets our desktop client and web application share the same user interface. So let’s accept its flaws and work on refining the solution. What do you think?

I’d like to acknowledge useful chats with Mike Williamson and Andrew Hunter, in writing this piece.

6 Responses to “HTML5 and JavaScript: Worse is Better?”

  1. originalmusic says:

    I’ve been working on a team implementing JavaScript single page architecture. Development time has been longer than expected, the tools for debugging seem less sophisticated. That wing said, it was a team of .Net developers. I think the technology is great but not the panacea for all things computing.

  2. BuggyFunBunny says:

    – Ultimately, it’s true that the result is a compromised, “glued together” platform that by sheer dint of its ubiquity will triumph over “properly engineered” solutions, but that’s nothing new.

    Doesn’t that accurately describe the transition from Rome to the Dark Ages? Yes, we got rid of emperors, but we also rid ourselves of intelligent progress, while gaining lowest-common-denominator society. There’s a chilling graphic at the NY Times: 62 senators (largely rural and southern) on one side, with 6 (largely urban and northern/coastal) on the other. Both represent 25% of the USofA, but, of course, not really. How does one check the aggressiveness of the Stupid Mob?

  3. Keith Rowley says:

    In the end a “good enough” solution that works across all devices so we no longer have to custom build a solution for each device is going to save enough development time to be worth the cost of dealing with a less than optimal programming stack. I think developer time is rapidly going to become the most important commodity in computing, because developers can’t be moved to the cloud and virtualized (yet).

  4. paschott says:

    I know that we’re trying to move towards more of a “good enough” solution for several areas for mobile apps. That will let them run on whatever platform the user wants. In some cases, we do need platform-specific code because we have to interface with other hardware, but on the whole we want to make these device independent as much as possible.

    This won’t work for all coding, but if you can get your app out there for all platforms by writing once, I think there will be significant benefit. That way you don’t have to rewrite your app for each platform you want to support. It also results in a more consistent interface in many cases.

    The major problem I see then becomes the different web browsers and interpreters available. Even with IE 10 developers hate working with IE for web development. Add in Chrome, Safari, Firefox, and Opera and each of their small differences and you end up tweaking a lot of code to get it to work properly on all platforms.

  5. BThompson says:

    I am only starting out in the development world, and JavaScript is something that I never thought I could like or enjoy, however after playing with it a little bit for an MVC project I realised that it is really rather powerful and then I started delving into Node.JS which really opened my eyes to the power of JS these days and how much potential it holds!!

  6. Timothy A Wiseman says:

    Ubiquity is in and of itself a powerful force. The ability to write code that would work on almost any platform without substantial rewriting has long been sought and the HTML5 stack comes closer than anything else yet. This is a good thing and it should be celebrated and the HTML 5 stack should be used where that is appropriate.

    With that said, it is not one-size-fits all and there is also a place in the world for better engineered solutions. While the performance that some web browser wring out of HTML5 is truly a testament to the engineering skill that goes into some of those rendering engines, it still falls short compared to most compiled languages. So when performance is a major factor, HTML5 and its assistance is likely a poor choice. In those cases, it is not good enough.

    There are also times when a more domain appropriate language makes the problem set simpler, and this trumps the ubiquity that HTML5 would bring. R for instance is far superior to HTML5 when trying to handle statistical analysis. It also helps that in many specialized domains the code is not likely to be run repeatedly accross numerous systems and there is little reason to worry about its portability.

    So, in short, we should accept HTML5′s and continue refining it, but we should not abandon the other tools we have available while doing it. It is an excellent choice for any things, and that will likely broaden as it is evolves. But there is still plenty of room for more specialized tools alongside it.

Leave a Reply