One of the most repeated questions I get when talking about HTML5 is the following:

“How can I protect an HTML5 app from being copied?”

Most of the time the question is not that direct to the point but that’s the gist of it. An example is in the Q&A of my “Keep calm and trust HTML5” talk at Hackernews (40:07 onwards) and this is a more structured approach to answering this question.

In short: there are ways to protect HTML5 apps, but all of them are a lot of effort and will not keep people who want to steal your code off for long. Additionally I’d go as far as saying it is a wasted effort and based on an archaic and ill-advised approach to publishing software. You can’t steal a changing product – you can only try to keep up.

Of course there are apps that need to be protected from viewing. There are also algorithms that need to stay a secret to protect some business models and users from having their data leaked without their consent. Using an open format like HTML5 for these kind of algorithms and apps though is like sending out password reminders in cleartext, storing passwords unencrypted in your database or sending sensitive data over HTTP. Just because you can do immensely wrong doesn’t mean the whole technology stack is not to be trusted.

Protect by packaging – and forfeit a lot of benefits

The simplest way to protect your HTML5 code from being viewed and read (and maybe stolen) is to wrap it in a native wrapper and send it out as a native app (Android, iOS, other OS). By doing that you get the benefits of the closed ecosystems (if your app gets the thumbs up from the app market providers) but you forfeit the benefits of the web: ubiquitous findability, simple, atomic updates and a small code footprint.

Apps code is a constantly moving target

For your normal run-of-the-mill game (think Puzzle Games) or app (productivity app anyone?) spending your time and effort on trying to protect them from being source viewed is time spent on the wrong goals. If you think about it, the code of your application is not what makes it a success:

• Good apps change all the time – Twitter for example became the success it is by observing how people use it, and add functionality accordingly (Follow Fridays and Hashtags were not inventions of Twitter, but of their users
• Your code will be forced to change – this happens mostly when companies get bought and the code of the app needs to start talking to other products by those who bought them. So there is no “one version” to steal.
• There is always a new thing to support – the most successful apps branch out to different devices which means you’ll have to change and re-code when a new one comes out that is vastly different to others
• Apps are fueled by data and users – a great app allows us to do things with it, to add content or to get a simple interface to data we need. Instagram wasn’t bought for its filter algorithms – these are available openly on the web. It was bought for its user base and the data they add to the app (and personal information they willingly expose). A travel app isn’t a success because of the HTML that makes up its interface – its success is making it easy for me to get a lot of data from different sources and seeing them in a simple to use interface.
• A good app optimises for its environment – looking at the generated source in Chrome’s developer tools will be different to what Firefox or IE gets – if you play all of them to their strengths (and there are build scripts that help you with that). So “stealing code” in one of those environments gives the thieves only a snapshot of what the whole app is. Much like saving the HTML of a Yahoo page doesn’t get you the original PHP code.

Open and available fuels innovation

A lot of the fears about HTML5 and the perceived simple way to steal code is a failure to understand that code being in the open is one of the main strengths of HTML5 and the web. The web became what it is now because we could look at code. We can look at our own code while we debug it, we can look at other people’s code and learn from it. We can re-use other people’s code and build on it and improve it and release it for others to do the same.

Client side code, HTML, CSS and JavaScript is a commodity. It is there to make things work and boy do we have to do dirty tricks at times to make it work right here and right now. The environment we publish in changes constantly and trying to release a perfect piece of code that will never have to change and is our secret doesn’t work in it – at all. Secrecy is not what makes the success of a web app – adapting and being able to change quickly is.

Owning and locking up stifles growth

I remember making money with a few JavaScript routines and libraries. I was the one who knew about making menus fly in and out more or less smoothly in Netscape 4 and Internet Explorer 5. Looking at this code now makes me shiver and want to roll up in a fetal position. Seeing that some of this code is still in use as the companies I sold these routines to wanted them “protected” (minified and obfuscated) makes me sad. It is incredibly simple to steal this code with today’s development tools, but nobody bothers. Why? Because there is a cornucopia of free, documented and better solutions available now, on Google Code, on GitHub, on Freshmeat, on people’s blogs and in many other places. Many of the sites using my “commercial and protected code” are not working any longer the way they should. And the companies who bought it never bothered to upgrade their sites and use any of the free and excellent code they can get now. It is a matter of principles, not quality of the final product.

Open code is the best job ad

Web developers like to show off. Instead of showing off in a “I can do this and you can’t” we do it by “look what I managed to make a browser do and here is how I did it”. We learned that sharing means getting incredibly worthy feedback. We learned that people playing with our code means they improve it, find solutions to problems they had and we hadn’t thought of and test our products in environments we neither have access to nor understand. The best way to find and hire great developer talent is have them play with your work – instead of having to educate them when you hire them they already come with passion and knowledge about their job.

Problems worth your solving efforts

So, seriously: all the effort you may think of putting into making your app “protected” (which will most likely result in a glass shield) can be used to solve much bigger issues you should be thinking about:

• What makes your app unique – why should users flock to it, how does it give them what others don’t?
• Test your assumptions – is the UX you chose just because another app does it really the best way to achieve this goal? Get some user testing done, don’t pretend you are your user. The best results come from people breaking your work and using it in ways you haven’t thought of
• Think about your legal protection – the theft you should be worrying about it not your code – it is the idea of your app. The hundreds of Angry Birds clones didn’t rip the code, they copy the idea and the characters. Rovio doesn’t check the code of copied apps – they point out the obvious ripping of characters, music and gameplay and get their legal team to react to that

New playground, new rules

The openness of the web, the opportunity to publish on it and additionally in closed environments with an HTML5 app, the future friendliness of web technologies to the markets and environments of tomorrow is what we should be thinking about. A lot of the demands for “protected code” reminds me of a band trying to write a song that nobody else could play. The notes are not the song. The overall mixture of music, lyrics and delivery is what makes it unique and the band’s product. The same applies to our apps. Let’s not limit ourselves to repeat what has been done over and over again and try to protect it because we think nobody else can do the same thing we did. Let’s embrace that everything is a remix, that ideas are derivatives of other ideas and that our users are the ones that will shape our apps and games with their demands, their data and their time and effort to play and use them. By using an open format thieves could always only get a snapshot of what we do right now. If we spend most of our efforts on trying to put a lock on a door that was meant to revolve we spend our time focusing on the thieves instead of our users.

When the discussion is about HTML5 vs. Native code to deliver apps it is very hard to come to a consensus. There is a massive animosity against the web and myths prevail over realities and opportunities.

I find more and more that this is not a matter of technology and development environment but I feel that it goes deeper than that. We are at a tipping point in web development – technology progresses and our user base progresses – but the people who brought web development to where it is now are still believing and advocating a longevity that might not be there any longer.

A few days ago the social channels around web development – aka our echo chamber – was full of people donning blue beanies on their photos and avatars to celebrate the success and remind people of the need of web standards and Jeffrey Zeldman’s breakthrough book on the topic of designing with them.

Using web standards instead of writing browser specific code and forking for each browser to come meant first and foremost a few things:

• You built in a robust, future proof way and not for the current state of play
• You craved agreement, you built on agreed principles and ideas which meant that the next person can use your code without having to pester you for information on how it works
• You craved clean separation of structure, presentation and behaviour, thus making your code easier to maintain by people who specialised in each of those departments

All of this plays to the concept of the longevity of the web. From the get-go the concept of the web was to be built to last. Cool links don’t change and all that. The web grew because of a few reasons:

• It is incredibly simple to start publishing on the web
• Content created is in an open, simple to convert format – HTML written a decade ago is still readable now
• Creating content and allowing people to add, amend and edit was simple. Wikipedia, IMDB and thousands of forums revolving around the most random topics prove that
• Adding knowledge and content on the web – even in the most ridiculous Geocities rainbow divider ridden format – meant that it gets archived and people can find it years later when all the university papers writen on the same subject are on non-readable floppies and their printouts faded

In essence, we saw the web as a big archive and Archive.org and Google’s caches prove that it can be done. The web does, seemingly, not forget.

Fleeting content, first edition

Of course there were web products that had a due date and got bad after a while. Movie web sites, conference and festival sites, product ads in web form – anything locked in time and costly to keep up was created and vanished from the web. These sites were also the ones that didn’t care much for web standards – their job was to be amazing for a short while and get people excited about a certain product. As web standards advocates they annoyed us as they violated our sacred principles and were beautiful and successful at the same time. I remember websitesthatsuck.com saying that if you want to play as a designer and not care about boundaries and longevity, movie web sites are the best to make quick money and move on. I also remember Andy Clarke giving a talk showing how rich and beautiful for example the (now defunct) Watchmen web site was and how we as web designers should see this as a goal to reach – a beautiful, interactive and media rich web.

This is the chip we have on our shoulders as web developers – the cool and amazing is most likely not possible with standards as we want to make everybody equally happy. We want to build for the long term, we don’t want to add to the already large landfill of outdated, unloved and unmaintained products out there that clog up search results.

A product of our environment

Our environments were desktop computers, then laptops and we are very likely to keep local copies of our work on CDs, DVDs and external hard drives should something happen to our servers or should we be offline. Our main drive was to add to the awesome that is the web and to keep things lasting for a long time. A broken link and a resource that vanished annoyed and hurt us. This is not why we spend hours making things maintainable, right?

The web is a given and consumption is king

Fast forward to the now. The web is not this magical cool thing any longer that everybody wants to be part of. A large series of publishing communities coming and going (Geocities, Google Pages, MySpace, Livejournal) and the rise of the “real time web” with timely updates and image and video uploads instead of writing longer content has made the web a much more ubiquitous and “given” thing for people. You are more likely to catch trolls and spammers with an open comment system than people who give you feedback. Feedback to things you write and publish happens on Facebook, in Google+, on Reddit and on Hackernews. And none of that lasts – you have a few hours window to be awesome and then the next thing will be around to keep people’s attention and incite discussions and GIF uploads to the thread. The attention span is shortened and the MEME-ification of everything and getting things viral is more important than the content or if what you said holds true a few weeks later.

Downloads and non-changing links are not that needed any more, faster and more stable connections allow for streaming on demand instead of getting a song or a movie and going through the pains of tagging and naming them so you find them later on.

We have to face that the web is becoming just another consumption medium. That doesn’t mean the old web of longevity and archiving doesn’t exist any more – it just means that it is the playground of a few whereas the big market just wants to have a quick fix and some fun. If something can’t be found any longer – no big deal, let’s read/watch something else instead.

A need better answered by apps

This is where the mobile environment, with native apps and closed app stores and environments excels. It is a very fleeting space, nothing there cares about longevity, it is all about the immediate success and the next new thing around the corner. The market we target with apps doesn’t care about the long term, it is about instant gratification and the cool and new. When was the last time you played the original Angry Birds? How many of the apps you have on your phone do you really use, and how many are orphaned?

For developers who just started this is incredibly interesting. They want to build something quick, make money and move on. For this, learning what you are doing is boring and in the way. They want an environment to download, install and build things in and ship it to the newest coolest device of the very moment. Doesn’t run on older devices? Who cares?

Changing our tactics and answering the now

Of course this feels terrible to us and – in my case – makes us very angry. Just from a sustainability and environmental point of view seeing mobile devices a year old being blocked out from newest software updates disgusts me and makes me think of “Brave New World”:

“Ending is better than mending. The more stitches, the less riches.”

- Aldous Huxley, Brave New World, Ch. 3

It is Flash part two – back when Flash was hot we got smirked at by Flash developers who rolled out hard to maintain, short lived products and made a lot of money and told us that this is the future and our environment will be history soon. Whilst that did not quite work out the way these shortsighted Flash developers thought (and by all means I don’t describe all Flash developers with that – far from it) we have exactly the same situation now – except that the focus of marketing and people’s buying habits is focused on native apps whereas back then nobody cared what tech your game/site was built in. We don’t play on the same court any longer – we lose people to the one with the locked gate.

Here’s the irony of our fight for web standards: if we really want the web to succeed and HTML5 be an interesting opportunity for developers now we need to partner with the people who used and built in Flash. This is so not about semantics and static pages any longer, it is about apps. It is also not about our way of working and adding to the web in very maintainable ways for a group of experts to work together. Developers now want to do it all from beginning to end. We need people who rolled out apps for the web that followed the same rules OS native apps did. And that was Flash/Flex, and it was good at it. We don’t need more repetition of what made the web great – we need to roll out a massive amount of developer tools that can hold their own against the things iOS and Android comes with. Our web standards world is a labour of love – we build complex and beautiful chippendale furniture that can be thrown about without breaking but the market wants a lot of IKEA Billy shelves that can be put up quickly and break when you dismantle them. We don’t have the answer how to build those.

The web needs to be the thing that allows you to roll out code quicker, in a more convenient way and across devices than native environments do. And we don’t get there by wearing blue caps and talking about benefits that applied years ago. We need to be as flexible as the technologies we stand for.

Disclaimer: While I work there this post is on my personal blog and does not necessarily reflect the opinion of Mozilla. Feedback bickering about how Firefox fails to meet your needs will be blocked out by me by means of looking at cute pictures online (this one for example which kills me every single time). Thank you.

“What should a browser do to really make you more effective and allow you to build great products?” is an interesting question to ask. I’ve asked it a few times in different environments and I got a lot of different answers. When you dig deeper and ask for details why browsers need what people wanted it gets interesting – most of the time they can’t say why.

New toys with older and better implementations

In many cases as developers we want new toys, we see a cool experimental feature in one browser and want that, right here, right now, regardless of its usefulness.

Many of these hot new and cool features in browsers have been in Flash and implemented in a more flexible way so to a degree, we still play catch-up. This is annoying as we could have learned from what Flash gave the web and how it moved it ahead (yes, without Flash we would have no video, audio or gaming on the web, let’s face facts) and copied and enhanced instead of going on a parallel innovation stream.

A battlefield with not-so-hidden agendas

In addition to this urge of wanting the new and shiny there is a need for some companies to sell their browser and get mindshare of developers to point them to their other products. This results in a browser battlefield that tries to impress with cool and new rather than building a predictable and stable platform. Granted, this is mostly the impression you get through marketing materials and not talking to the browser engineers, but, for example, I don’t see any of the players making a real effort to get all HTML5 input types supported and style-able – a need we really have as forms will not go away any time soon.

Regardless of the lack of support for a few of the basics in HTML5 when it comes to moving browsers forward I think the main feature we need is feature testing APIs in the browser. What do I mean by that and why do we need them? Well, here goes.

We need native feature testing

Web development always came with a choice:

• Do you want to use a feature and demand that your users have the ability to consume it and risk broken experiences or
• Do you want to test before you use a certain feature and give it only to those who can consume it?

The former are the sites that come with disclaimers like “this web page feature $x and needs a modern browser like $y” and can look extremely silly a few years down the line. The latter is what we call progressive enhancement, giving everybody what they can deal with and not more. There is also an unhappy middle ground called graceful degradation, which means you build something with all the features and a fallback solution and hopefully maintain both.

If you go for the progressive enhancement approach you need to provide several solutions or you need to test. The several solutions approach for example would be to ensure you do not have a button with white text on white background by providing a fallback background colour for browsers that don’t render gradients:

button {
	color: #fff;
	border: none;
	/* defining a background colour for all browsers */
	background: #0c0;
	/* defining a gradient for those who can */
	background: linear-gradient(0deg,#000, #0c0);
}

This is not much work and should be easy to do for everybody (that there are a lot of buttons with only webkitlinear-gradient backgrounds is baffling to me). It gets harder though when you want to use more advanced features.

Testing mechanisms

What we want to do is to test a feature before we apply it. The worst way of doing that is by trying to detect the browser and make the assumption that it really is the one you are targeting and that it can do what it promises. Reading out the user agent string of the browser is the standard way of doing that and let me just tell you now that this is where madness lies. Forget trying to detect the browser, they will lie to you and you lock yourself into an ever-changing game of hide and seek with new browsers coming out all the time.

The more robust way of testing is feature detection, you plain and simply ask the user agent if it can do something before you apply it. This could be as simple as asking if navigator.geolocation is an object before trying to call its methods. This can result in a lot of code though and there are browser quirks to consider, which is why we have to be very thankful for the people who build and maintain Modernizr to do all that work for us. Using modernizr we have handles in the form of class names on the root element and a very handy JavaScript API to test for features and under the hood it checks thoroughly and forks for several browser quirks – pain we don’t need to inflict onto ourselves.

To me the existence and success of Modernizr shows that there is a massive need for being able to test features in browsers before applying them and getting a definite answer back. This is where browsers don’t do too well yet.

Native testing mechanisms

As shown with the background example our native testing in most cases just means applying things the browser might not understand and rely on it skipping the bits it doesn’t know about. This works in CSS, as CSS doesn’t throw errors and stops executing. JavaScript, on the other hand, does.

CSS is doing a lot in that respect at the moment. Media Queries, for example, are feature detection mechanism. I love that I can apply a style only when the browser window is a certain size or in a certain orientation. It is simple and works. More of that.

Well, funnily enough there is more already. The current Opera and Firefox Aurora support the CSS3 Conditional Rules Module Level 3 which means you can test for CSS features with an @supports block:

@supports (-webkit-transform: rotateX(0deg)) or
          (-moz-transform: rotateX(0deg)) or
          (-ms-transform: rotateX(0deg)) or
          (-o-transform: rotateX(0deg)) or
          (transform: rotateX(0deg)) {
 
  // this will only apply to browsers with 3D transforms
 
}

This also comes with a JavaScript API to test for features whose syntax is still currently discussed. You could end with window.supportsCSS('display:flex'); or CSS.supports('display:flex') respectively, but still the power of this idea is staggering and it could mean Modernizr would be not needed in the future (or a lot smaller as we could for @supports and lazy load the rest of Modernizr only on demand).

If you want to learn more about @supports check Chris Mills’ Native CSS feature detection via the @supports rule.

Pointers in the right direction

All of this makes me hopeful that the next generation of browsers will give us developers what we really need: a way to test that what we do can be applied before we do it. Right now we need to spend far too much of our development time on adding polyfills and libraries to test for and – if needed – simulate functionality we should be able to just use. A great case is touch and mouse support in browsers which right now is not fun to apply which is why we do have to use libraries like pointer.js.

Fact is that we will never have one browser and one environment for the web. That would neuter it and violates its main principles. We can dupe ourselves into believing that we can control and demand what our users take to look at our products, but this is a fool’s gambit. Hundreds of web sites and enterprise systems out there demanding you in 2012 to use Internet Explorer 6 to get the best experience should teach us that this is a mistake not to repeat.

The much more likely future is that we will have to have a much more diverse environment to support. The web design community is already harping on about that for quite a while under the Future Friendly label. Seeing the amount of smartphones, tablets and web-enabled TV sets and game consoles out there it is not hard to grasp that testing and being flexible in our approach of web development is the future indeed.

Native testing for all the things!

What’s happening in CSS is encouraging, we need to move that idea further ahead. Some other parts in browsers less so. For example when we got native video we realised early on that it would be great to have a feature test for which video formats are supported. I agree, this is very needed indeed, but getting an API that returns “”, “maybe” or “probably” is a joke and not a helpful addition. On the other hand the Page visibility API and its under-the-hood implementation in requestAnimationFrame is a wonderful addition and exactly how it should be. I can ask the browser if the user sees what I do and if she doesn’t it stalls until it needs to animate again. The WebAPI work of course is also very encouraging – we just need to get them supported cross-browser.

Retina displays and their need for large (by dimension and file size) images are the big new issue. Should you add large images and risk people on a mobile device with a small screen burning through their data allowance plans or should you risk a blurry view and load larger files later on demand? When on demand though? When the display really can show larger images or when the connection is fast enough to load them?

Right now there is no way of detecting the speed of a connection and if it is OK to load lots of data. PPK is doing some research to see what that could look like and it is not easy. But we need that, I am not kidding here. Simply assuming people can load lots of data is not delivering a good service.

Quick example: I got that a lot on my blog when I embedded HTML5 videos. I thought this is a good dogfooding exercise but got feedback that I should switch back to YouTube embeds as their Flash versions delivers lower quality streaming versions of the video to people on bad connections. HTML5 video doesn’t do connection negotation yet (which is a dirty hack of chunking a video into 4k bits and sending as many as possible at a time). So in order to deliver a good service, I needed to go back to “closed” technology as I had no means of testing if my readers can consume what I gave them.

We push browsers to their limits these days and we don’t get much feedback as to what is possible. Say you do a massive CSS animation with complex transitions, drop shadows and transparency. How can you be sure this will be smooth and not an annoying flickering slide show experience? Imagine a browser telling you the FPS it runs the animation on, imagine – even better – that it would have an internal threshold to stop animations and automatically move to their end when the browser is too slow (something YUI had for quite a while now).

There are many things we need to be able to know in the nearer future, and I wish browsers would add a few of those testing features:

• What is the connection speed/reliability?
• How busy is the machine? Does it make sense to start this animation or will it be laggy anyways?
• What is the battery status? Should my app offer a low-level experience to be alive for longer?
• Is the audio/video channel of the machine busy already? Why play a sound when the user is listening to music anyways?
• Are there already fonts available or do I need to load a web font?
• Can I store content locally and what is the quota already used up?
• Is this a touch device with gestures or a kinnect or a mouse-enabled device or what?
• What codecs are installed, what media can be played?
• What is hardware accelerated and what isn’t?
• Is the browser talking to an assistive device layer and what assistive technology is in use?
• What is going on in the browser cache?

A lot can be added to the list and I really hope that browser vendors understand that we can only work effectively if we have the right tools. Right now I feel we need to resort to libraries, polyfills and shims for far too many things. Which might be an alternative future, but I for one would love the browser to do that work for me so I can concentrate on building apps running in it.

Yesterday evening I gave the closing keynote of the HackerNews meetup in Old Street, London, England. I joined about 200 developers, lots of empty Pizza boxes and beer cans to as them to “Keep calm and trust HTML5”. Here are the slides, an audio recording, the notes and a screencast on YouTube. The video of the talk should be on Vimeo in a week or so is now available on vimeo.

Chris Heilmann – Keep Calm and Trust HTML5 from HN London on Vimeo.

You can get the audio at archive.org as MP3 (29.6) or OGG (16.1MB).

Notes

The honeymoon period of HTML5 seems to be over and as developers we seem to feel confused and wary of the hype about it. Instead we compare HTML5 with the other booming tech and wonder if it really is something we should put our efforts in. In this talk Chris Heilmann of Mozilla will cut through the hype, show what’s ready to use and around the corner and help you do your part to make HTML5 work without adding to the confusion.

Today I shall attempt to set your mind at ease about HTML5 an whether you should bet on it or not. Spoiler: you should. Another spoiler: you are not forced to.

About that HTML5 thing…

HTML5 - like any other new technology – follows The hype cycle. We are past the inflated expectations stage and are going down into the trough of disillusionment. This is good, it means that we can concentrate on making the technology work for us rather than coming up with impressive made-up facts around it.

A lot of the players in the HTML5 space have spent an enormous amount on impressing people with shiny demos of new technology and “pushing the envelope of what we can do with the web”. A lot of them were pointless and even more were scarily similar to the things we did with Flash in the past.

A depressingly large amount of those demos only work on a certain browser with a certain setting and tell users that they should download that one. This is a product marketing ploy but very much hurts the web. HTML5 is not about telling people what to use, it is about giving them the best experience in the current circumstances. For developers it means upgrading what we already do on the web and giving it more predictability.

A lot of the demos we see are beautiful, but heavy and expect a lot from the machine they run on. That’s not good. Of course it is great to give a beautiful and rich experience to those who can consume it, but our mistake is that we see them as a given rather than working towards them and giving less rich, but delightful experiences to others.

The other thing we very much do wrong when it comes to HTML5 is to simulate the native environments. We try to make HTML5 apps behave like native apps and wonder when this doesn’t quite work out the way we want.

Catering to a hipster market…

A lot of the work in HTML5 we right now is trying to cater to a very current market. Pascal Finette just explained in his blog post “The False Economy of Apps” how little closed app markets allow developers to earn and what the issue with them are. App markets are hot right now and there is quite some hype about it. The problem with hypes is that they happen very fast, so if you want to play that game, be quick about it or your opportunity is gone.

A new market…

The amazing thing is that the next market is already around the corner and it is interesting. According to a presentation by Anna Debenham at the Full Frontal Conference, teenagers in Britain are connected at home to 95%, but only 10% own a Smartphone. 46% have a mobile phone and 44% an own computer.
Of the teenagers involved 69% have a handheld console and 86% a games console connected to the TV. This is where a lot of them surf and consume the web. Given the constraints of these devices this will become interesting indeed.

The web is ready for it!

This is where the web comes in. Instead of having native apps on these devices and the next to come (cars, toasters, connected furniture?) we can build apps with web technologies that easily adapt to the new needs of the device.
My former colleague Mike Davies put it quite succinctly in the “WebApp mistakes we are condemned to repeat” article lately that the main power of the web is that it is not dependent on any platform. This allowed it to survive quite a few that came and went already:

The Web is platform agnostic, its success isn’t chained to the continued success of a specific platform.

Another great point he made is that we try to simulate widgets and interfaces that are native, and thus build interfaces that promise a lot but fail to deliver the same way native ones do. Instead of using what is there we shoe-horn another environment into the one we play in. Instead, we should embrace that there are differences and deliver different experiences according to the device and browser in use. An Android device should not get something that looks like iOS and feature a back button that does a different thing than the one the OS gives us.

This platform independent characteristic is a feature of the Web, not a shortcoming. It’s not meant to emulate Operating System graphical widgets. That’s the browser’s job (or the operating system’s job), not the web stack’s.

But isn’t that fragmentation? Doesn’t that mean we need to build lots of different versions for different browsers? Won’t our app look different from browser to browser?

No, it is the internet experience! The internet is there to participate, people should not be be blocked out because of their environment or ability. This always meant and will always mean that people have different experiences on it. And that is good. Why should we force everybody to have the same experience when they can have a better one or one catered to their needs?

The cutting edge will hurt you!

Disappointment comes with the territory when you live on the bleeding edge of any technology. The same happens with HTML5. A lot of initial messaging promised us that everything is simple and just works when it clearly does not. Again, this is to be expected. We are experimenting here.

Here’s the thing: the web as a platform revolution is happening – no matter what. Browsers are performing better with each version and there is a new version every few weeks. You can enjoy that and reap the rewards or complain about a currently annoying and broken thing for months. Probably by the time you calmed down it will be fixed and you realise that your energy could be spent more productively.

If HTML5 is not you, that’s OK…

If you don’t want to be part of the ride, that is totally fine. There is space for all of us on the web. Build native apps, stick to one environment, make money, be successful. But don’t waste everybody’s time by comparing apples and oranges. It is possible to sell your services and products by badmouthing the alternatives, but is this really how you want to live your life or sell yourself as an expert? Sounds like a waste of effort to me when your creativity could speak for yourself.

It is not that complex…

All in all it is not complex to start with HTML5 and having success. It might not be as quick as it is in a closed environment, but it is very much likely to be more rewarding in the long term.

So if you want to get started with HTML5 in a relaxed and sensible fashion without the hype and the hate here are a few things to remember and a few to check out.

Five HTML5 mistakes to avoid in 2013

I was asked by .net magazine to come up with five HTML5 mistakes to avoid in 2013. Here they are.

• HTML5 is not “building for iPhone” – The web is littered with web sites and apps that only work with Webkit browsers as they rely on functionality that only the iPhone provided. Granted, it was the groundbreaking product to get HTML5 off the ground, but now others have emerged that play nicer with the standards, perform very well indeed and also need support from you. So stop sniffing user agents and provide non-webkit prefixed, standards-compliant fallbacks to whatever you code and you’ll be smiling when the next killer product not backed by Apple comes out.
• HTML5 doesn’t mean “write whatever” – The HTML5 parser is amazing and allows you to do incredibly random things in your markup and still get a predictable outcome. You can omit closing tags, there is no need for quotes around attributes and many other things that were considered bad in the past. The reason why the parser is so lenient is that there is a lot of bad and broken code on the web and new browsers should not punish users for our mistakes of the past. Let’s not make new mistakes to add to that landfill. What the browser displays should not be your guiding principle, what the person who maintains your code gets should be.
• HTML5 has to work offline – The main opportunity for HTML5 lies on mobile devices and in the app space. Apps have to work offline – period. Build a small shell for first load that gets the rest of the content on install and store it offline for later use. Yes, AppCache is bad and could be very much improved, yes, we have browser differences with IndexedDB and WebSQL. These are temporary issues though and we can only fix them when people use them and report issues. So go offline and don’t expect a great connection every time people load your HTML5 solution.
• HTML5 should be mobile-friendly – A lot of HTML5 and responsive design showcases look like Flash pages a few years ago, except that they are heavier and don’t support streaming content and connectivity negotiation like Flash does. We should move to a leaner, “use what you need” approach rather than simulating the richness of Flash without having the same opportunities. We got tired of Flash loading animations – doing them in Canvas doesn’t make it better.
• HTML5 can adapt – let’s allow it! – Last but very much not least – let’s move past the “demo” and “showcase” stage with HTML5. A lot of of what we call HTML5 expects a certain browser in a certain setting and shows off what could be done. “Could be” is over, we now have to deliver if we want to be a serious alternative to native solutions. HTML5 can deliver a sensible experience to all environments and a beautiful one for the high-end. Let’s deliver that instead of a high-end experience for a few who care enough to alter their browsers and are on the bleeding edge.

More things to know

Here are some more things that help you keep your sanity when plunging into HTML5 development.

• JavaScript is here to stay, learn it! – JavaScript is the language of the web. It is a weird language, but powerful. Go and learn it. Yes, jQuery is simpler, and Coffeescript more structured, but when push comes to shove and you are on a very restricted piece of hardware you need every bit of performance you can get.
• Don’t rely on experimental features – A very dangerous thing we do right now is to rely on experimental features with browser-specific prefixes in our products. The idea of browser prefixed features is to test them out and find a consensus in the end that lives without the prefix. Prefixed functionality will not only go away really soon, it will also change constantly. You can not rely on it. Give anything a fallback that works in legacy browsers and use the non-prefixed version. That way you can test new features and you don’t have broken code when browser un-prefix the feature in the very near future.
• The browser is developer environment – The missing HTML5 developer environment people coming from native environments bemoan is here – we call it a browser. All browsers have developer tools, many even have remote debugging for phones. This is where it will happen. And it makes sense, as we debug where our users are.
• Build in HTML5, render natively – The fun bit about HTML5 is that you can create native apps from it using PhoneGap (and many others). This means you can reap the rewards of having an app that can be found on the web and you can submit it to the closed markets, too.

This is not new either. As mentioned by Mike Davies in his latest post about web apps, we’ve been building installable apps with XML, CSS and JavaScript for quite a while – Firefox being one of them.

While webapp ninjas complain about their tools and environment, entrepreneurs create these applications with the web stack. – Mike Davies

Splendid stuff in the making

But that’s not all – there is a lot of great stuff happening right now.

One big annoyance of HTML5 on mobile devices is that we don’t get access to the hardware from JavaScript. This limits us to a degree, and needed changing.

The Web APIs work tries to fix that problem – open source drivers with JavaScript interfaces to access all the hardware of the phone.

The Web APIs power Firefox OS, the thing Mozilla is right now going full force to bring out to the market. Firefox OS will be the first truly open operating system for mobile devices. It has a market, it supports installable apps that have a URL on the web and it will be shipped next year on mobile devices.

Another big thing are Web Components, which define the missing app widgets we need, X-Tag which makes those available cross-browser and the Mortar and WebGame stub systems. Both of those allow any developer to start an app or game from building blocks and with a deployment script that uses GitHub as the host. They even create the offline and app manifests for you.

Google is also working on a very clever system called Yeoman which is a packaging system for web apps that automates a lot of optimisation and deployment steps for you.

In general I think tools is what we need much, much more. A very interesting move is that Adobe released Brackets, which is an editor that also ties into live rendering in the browser. It is pretty alpha but the very important point here is that the company who makes all their money with tools and rules for example the graphic creation market supreme is playing with open source. They want developers to work with them and make Brackets better and see how it works for them. This is a good chance to work with a company that knows how to build good tools and get them to open up more. Brackets is written in JS/CSS/HTML5 and targeted at writing these languages with it.

The vanilla web diet

Last but not least I am working on a new book explaining how you can use web technologies in a very simple way to build future-proof solutions without relying on a lot of third party libraries and writing a lot of code. Check out the demo page to see what I mean. Very few lines of JavaScript, no images, and a nice fallback for small screen devices and old browsers.

All in all it is now the time to get your hands dirty in HTML5. We have a great time ahead, if we embrace the idea of the web as a diverse environment and not another closed platform.

I am a trainer and I love to give trainings to “crowd-source” my knowledge. I take training seriously, having suffered far too many boring and bad trainings myself and swearing myself back then I will do better if I ever get the chance.

Training is treated as a nice to have

There is, however, a certain laxness in IT when it comes to trainings, and it makes me sad. Trainings are not to have a jolly off work, they are also not a nice to have. They should be the most efficient way to learn new things and get ahead in your career and should be treated as such. Instead of having bright and bushy-tailed training attendees many a time you find yourself in front of a tired group after an event half of whom didn’t show up, others are delayed, not prepared or people interrupt halfway through trying to “just join in”. This is a waste of time and bizarre considering how much training costs.

Training is expensive and precious – treat it as such

Sending engineers or managers to a training is a high cost. Not that I charge a lot (I should, most other trainers do!) but you are going to be out of the normal work flow for quite some time. For myself preparing a training means 8 hours of research, preparation and planing for every hour I am in the room. This is a large chunk of my life – professionally and personally – and it should be worth my while. I judge the success of my trainings by how much people learned and what they did afterwards, how they used the knowledge gained. If I don’t get the chance to learn any of that I wasted my and probably your time. Success of trainings should not be accidentally, it should be measurable and obvious. This is why from now on I will not take on any trainings any longer unless the following points are met.

My training manifesto

• We don’t start as strangers – the overall number and each attendee of the training should be known to me. This involves a quick email by attendees telling me about the training:
  • Who they are
  • What they expect from the training
  • Relevant knowledge they have with examples (“here are talks I gave, I want to be better”)
  • Special treatment that is needed (Proficiency in English, Disabilities, Materials)
• We are on time – or we don’t take part – my trainings are planned minute by minute to make the best out of the short time we have. If you are late, you delay everybody and disrupt an ongoing part of the training which will impact the rest and leave you without prior knowledge needed for the advanced lessons later on
• The door is closed – there will be breaks for human issues and there will be drinks and snacks (healthy ones, nuts and fruit, no point getting you sugared up and sleepy). So no leaving halfway through and no interruptions from the outside. This is our time and we use it as such.
• Laptops are closed, phones are on silent and in the pockets – for the most part you won’t need your computer in my trainings and it is just rude to be distracted by your emails, tweets or kittens. You are in a training, you are not available. Nothing your boss or colleagues need is more important, your attendance is very expensive, and should mean you are incommunicado to those not in it
• The group is responsible for the documentation
  • I will only give out very few materials about the training (mostly links to learn more from)
  • You are much more likely to really learn when you document yourself in the way you understand the most
  • There will be no binder at the end to collect dust on a shelf, keep your own notes
  • There will be times allocated to documenting in the training
• There will be a test and homework – I want to know what you learned and if you need to know more. The only way of doing that is to make you use the things we talk about

If these things can’t be met by the training I am not giving it. I don’t want to be a person collecting money or spending people’s time without making sure they get a lot of out it.

Compliance with this means you need to put more dedication into the training than you probably are used to. It also means though you will get much more out of it. I promise that.