Keeping the streak alive, I was asked to provide a foreword for another book, this time HTML5 in action by Robert Crowther, Joe Lennon, and Ash Blue. So here is what I had to say:

Foreword

Explaining what HTML5 is can be a very daunting task. I’ve been doing this more or less since its inception and I am still amazed just how many myths and how much confusion is there on the topic.

With HTML5 we re-booted web development. The world of HTML4.01 and the non-starter XHTML left those who wanted to use the web as a platform for applications stranded. HTML4 was meant for linked documents and XHTML was far too strict for its own good and it lacked real support in browsers.

HTML5 started with a clean slate. We analysed what was used on the web and added a lot of features we didn’t have before, like CANVAS for creating visuals on the fly or accessing images and videos on a pixel level, native audio and video without the need for plugins and forms that validate in the browser without us having to write extra JavaScript. We also started mudding the waters by merging HTML and JavaScript functionality – a lot of HTML5 will not do anything without accessing the elements via a JavaScript API. This confuses a lot of people. We moved on from a document based web and in that process we need more technical know-how. And this means we need to rethink a few of our “best practices” now which can annoy people so that they spread nasty rumours about the viability of HTML5 as a choice for professional development.

HTML5 is built on the robustness principle, which means that a browser will make a lot of educated guesses what you might have meant when you make a syntax error instead of simply giving up and showing an error. This gives it backwards compatibility and we will be able to show pages developed for a never-to-arrive XHTML world in browsers these days. A large part of the standard is just that – it tells you how to write a browser that renders HTML5 rather than using it as a web developer. Again, this angers some people and they shout about the verbosity of the standard.

HTML5 is also the new hotness. A lot of advertising talk, shiny demos and promises of fidelity that matches native apps on phones make us cynical battle hardened web developers think back on Java, Flash and Silverlight and their promises and sigh. We have a lot of buzz about HTML5 and a lot of things that are not part of the standard are simply declared part of it as it makes a good punch line.

When it comes to extending the language and bringing new features into it we are running wild right now. Every browser maker and web company comes up with great new concepts on almost a weekly level. That can be frustrating for developers who just want to get a job done. Can you rely on the functionality that is currently developed or will the standard be changed later on? We are pushing browsers further into the operating system and allow them to access hardware directly which comes with security and robustness issues that need to be fixed by trial and error. Can you take that risk with us when it comes to delivering your product?

These are exciting times and when you want to be part of the ride you can help forge the future development environment for all of us. If you don’t have the time to follow the discussions on mailing lists, do a lot of browser testing in previews and propose own ideas you can be left quite confused.

And this is where a book like this comes in. Instead of promising you a cornucopia of functionality that will soon be available you get examples that work right now based on examples that worked in the past. Instead of getting experimental demos you learn how to build production code based on proven ideas but using the features in modern browsers that make it easier for us developers and much more enjoyable for our end users. All the examples come with a legend telling you which browsers support the features and you learn how not to give them to old browsers that will choke on them.

You will learn how to use HTML5 now, using secure and intelligent solutions like Modernizr and HTML5 Boilerplate and you will come out at the end understanding how to write things in HTML5 that work right now. This will make you a part of the movement to get HTML5 “production ready” for all of us.

Those who live on the bleeding edge of defining the next browser and language features need implementations in the wild right now. We are past the show and tell stage and we need to get to deliver and enhance. And you can become an integral part of this process by following the advice and applying the examples you find here. Go forth and deliver.

One of the most annoying things to me on the web is new tutorials that are full of assumptions, bad practices and generally outdated. The irony is that when you tell the authors about the issues their excuse in a lot of cases is that the pieces are mainly targeted at beginners.

How does that make sense? Surely when you want to cater something for beginners nowadays you’d want to make it work for them today, and not base it on old technology and practices.

Catered for the audience

Back when I still had a television there was one public service ad in Germany I really liked: it was a man talking in baby talk and acting terribly silly. He then bowed down below the camera, you heard a slapping sound and he re-emerged with sticky tape over his mouth. The announcer then said “we need programs for children, not childish programs”.

This is exactly what we need for beginners: tutorials that are up-to-date, easy to understand and are based on best practices and proven concepts. Not tutorials that cover easy to explain concepts that actually don’t apply any longer or have to be un-learnt as soon as you become professional developers.

Web competence?

The main reason is that it is hard enough for adults to learn things, but even harder to un-learn them. It is hard work to go through the four stages of competence and once you are at the last you don’t want to start again. However, in a fast paced environment as the web becoming unconsciously competent can also mean that you just don’t realize any longer that there are changes you should be covering.

Lowering the barrier

The main reason people write tutorials that promise a lot and don’t deliver is that they want to lower the barrier of entry for new developers. This is a nice enough idea as web development with all its loosely defined standards and unknowns can be quite daunting at first. However, this to me robs beginners of the chance to become great developers.

My personal idea of a good developer is showing the urge to understand and apply – showing the dedication, interest and stamina to learn about the environment you apply your work, not only the technicalities of it. This comes with experience but it also needs to be based on a good foundation.

Leaving them hungry for more

A good beginner’s tutorial should actually not give beginners solutions but make them understand concepts and point to information they can use to learn things for themselves. There is no greater way of learning than finding it out by yourself, on your own terms and in your own time. Anything else is just repetition.

The why of beginner’s tutorials

There are several reasons why people write beginner’s tutorials:

• They want to genuinely help other developers to come in and start learning the right way
• They want to avoid people being scared of learning the job
• They want a quick win – write about the easy stuff
• They want to show off their skills to lesser skilled developers
• They want to have a big audience – promising easy solutions makes for a lot of readers (think of tabloid journalism)

Not as easy as it seems

Now here is the tricky bit: writing a tutorial for beginners is actually a lot harder than writing about a more complex subject for a competent audience. The reasons are:

• you can cause much more damage with bad information – people trust you to be an expert and will believe and repeat what you said
• you will not get much constructive negative feedback – people will not dare to say you are wrong and the ones that could will not read what you wrote – as it is for beginners.
• it is easy to start with a preconception of what a beginner is – however beginners could be people that are just coming from another area of expertise they are very competent in.
• you don’t have a passion to work with – beginners are mostly scared or try to find a fast solution rather than true understanding

The last point is exactly what a lot of bad beginner’s tutorials work with and writing those will actually make it easy for you to get published. However, it will not make you a good trainer or writer, no matter how good the short term feedback and success is.

Danger signs

I know there will always be a lot of tutorials like this, as the number of hits / diggs and quick fame is important to people to make a name of themselves quickly, but I sincerely hope that this quick rant at least makes you reconsider doing another tutorial that starts with some of the classics like “XYZ in 10 minutes”, “quick solution for XYZ”, “ABC makes XYZ easy and fast!”, “You don’t need to understand XYZ when you do it the ABC way” or “XYZ in one line of code”.