Why JavaScript is a toy language

I recently wrote an article on why HTML5 is stacking up to be a bad idea and why an Virtual Machine-style solution to web content would be so much better. In that article, I made the claim that JavaScript is a toy language and suggested that few people would argue against this. I have since learned that a lot of people would actually argue against it, claiming that it is a good language really.

To my mind it is self-evident that JavaScript is a toy programming language, but clearly it isn’t self-evident at all. So why do I make this claim and how can I defend it? Read on for the answer… Continue reading “Why JavaScript is a toy language”

HTML5 must not become the future of the web

HTML 5 LogoIn the beginning there there was simple HTML, which sought to define documents in an abstract way, leaving the browser free to render it as it saw fit. Whilst a great idea in theory, it didn’t work in practice as designers of web sites wanted their sites to look the same on every browser, rather than be at the mercy of the browser’s rendering engine.

Fast forward twenty years and things are very different. These days the humble HTML page has been pummelled into submission and supplies the designer with pixel-perfect rendering via CSS, JavaScript and a range of ACID-tests that encourage all browsers to behave the same. Yet beneath all this, the HTML at the heart of the page remains largely unchanged. Even the near-mythical HTML5 – which will likely take twelve years to become fully adopted – seeks to add just a few tags to the HTML specification. Continue reading “HTML5 must not become the future of the web”

Forget Web 2.0 and Web 3.0: a real web upgrade is on the way

W3CIn recent years, we have seen “Web 2.0” technologies push HTML to its limits in terms of making the web act like a set of applications. Google docs and spreadsheets are representative of how far those limits have been pushed, but they also highlight how short of being true applications, HTML-based apps are. This has prompted talk of “Web 3.0” whereby HTML will take a back seat to Flash and Silverlight based Rich Internet/ Interactive Applications (RIAs). Part of the reason for this push to Web 3.0 is that it has been seven years since the last HTML standard (XHTML 1.1) was approved by the W3C. The standard that underpins the web is ridiculously old in internet terms. Four years ago, talk began over HTML 5. Four years on, today finally sees the release of the working draft of this new standard. If the W3C can pull its collective finger out and get the draft ratified in the next year, then it will be a very exciting release. If they continue at their current snails pace, then sadly they will likely have missed their chance and the web will be destined to become a Flash and Silverlight hell-hole.

So why is HTML 5 so exciting? The answer is simple: it fixes just about all the current shortcomings of HTML that Flash, Silverlight, PDFs and Quicktime seek to fix without needing plugins for all of the above (and possibly not getting a plugin for one of the above if you are on the “wrong” browser or operating system.) It also fixes a bunch of problems that none of these plugins successfully fixes by themselves:

  • First there is the new <canvas/> element. This element allows on-the-fly drawing on an HTML page, with lines, gradient fills, drop shadows, transforms and the like using JavaScript. Think Silverlight 1.0 built into the web browser with no need for a separate download.
  • Next there is the <movie/> element. No more having to embed the Flash/ Silverlight/ Quicktime/ Media Player object within the page; just use the built-in tag.
  • Want to do documentation in HTML? Fed up with the lack of proper mark-up tools? Currently this drives people to use PDFs (or, if they are really clueless or just joined to Microsoft at the hip, Word Docs) instead. The inclusion of sections with headers and footers, figures, asides etc now provide a much richer suit of mark-up tools for HTML documentation.

The really clever new stuff though includes:

  • History and location support. The page will no longer be limited to trying to trap the page back event, it will now be able to find out its own history in terms of the page back and forward URIs and state models (state objects that the page can define).
  • Storage. Persistent local storage that includes a SQL database will be available to the page for storing state data locally on the user’s machine.
  • Offline application support. The client will provide an application cache, allowing an HTML-based RIA to ensure the JavaScript, images etc required for it to function correctly offline are stored in local cache before the application starts. So a blog entry editor application for example might download recent posts to local storage and its application model to cache. Then when the user edits a post and saves it, it could be re-saved to local storage for later synchronising if off-line, or uploaded immediately if on-line.
  • Documents become editable. Set the designmode attribute to “on” and the whole page becomes editable. Will the whole web become a giant wiki?

The scope of the changes from v4.1 to v5 of the HTML specification is vast and I’ve only touched on a few aspects. If you want the full story, grab yourself a huge mug of tea or coffee, set aside a few hours and read the HTML 5 Working Draft.