Keep calm and trust HTML5 – Chris Heilmann – Hackernews meetupFriday, November 23rd, 2012
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 .
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).
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.
- 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.
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.
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
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.