Fronteers — vakvereniging voor front-end developers

HTML.future - what the web needs next by Bruce Lawson


I spoke here two years ago and you've invited me back, which is extraordinary, so thank you.

I'm Bruce.

I work for Opera.

And when the Fronteers guys contacted me, they asked me to talk about what the web needs next, which is great because I already had a two-hour presentation already prepared waiting for somebody to ask me.

Don't worry.

I've probably got this down in 50 minutes because some of the things that I planned to talk about, like web components, Angelina talked about and responsive images Marcus talked about.

But first I need to give a great big disclaimer.

This is me talking.

This is not me representing Opera.

Unusually, I'm going to show a few things Opera are doing, not because the marketing guys have said, you've got to sell this, but because I think it's relevant.

And it's also important that the views I'm expressing do not represent the company viewpoint, and some of my colleagues vehemently disagree with some of the things I'm going to say.

It's just me.

So beat me up afterwards if you want to.

I'm an English gentleman, a classic English gentleman, and like Harry who you've seen and like Paul Lewis you've seen, even though I work at home I still wear a top hat and a frocked coat when I'm working.

And at the end of the day, I go to my bedroom where my servants have left me my evening mankini and the newspaper to read.

This is my local newspaper.

I always follow my local news, and I follow the publisher on Twitter.

And he said, everybody, come and download our app.

And I wrote back and said, why do you have an app? And he said, because people love apps.

I said, but you have a website and he said, sure, he said, but users tend to read five times as many stories via the app as the desktop site.

And this worried me because I've long thought that apps are a bridging technology, kind of like Flash was a bridging technology.

It was designed-- you know, Flash kicked the web up the arse, made us do better, and it's disappearing, and I assumed apps would do the same.

But here's a report from Nielsen last year.

You can read the numbers.

Anybody here partially sighted and need me to read it? No? Cool.

So 2011 to 2012, US mobile web users up 82%.

In the same time, US mobile app users up 85%.

Pretty much the same.

Time spent using the mobile web up 22%.

Time spent using mobile apps up 122%.

Five times.

So this is an anecdote from somebody I know, substantiated by a report from people called Nielsen who are big and everything. published

a blog post, It's an App World and The Web Just Lives and It.

Basically, 80% of time that people spend on their smartphones and their tablets is spent in apps and the other 20% is on the mobile web.

Four times-- this is the breakdown.

Thank you very much, Flurry, for letting me use your diagram.

The web is falling behind.

Apps are eating our lunch, I think.

It doesn't feel to me like this is a bridging technology.

It feels to me like this is potentially an open web killer.

And I like the open web, and I guess you do too because that's why you're here.

So I got wondering, what's the gap there? Why do people like using apps rather than the web? I got talking to Mark and he basically said-- he's guessing-- he hasn't done much research, but he guesses it's because the app works offline.

When people are on the bus, they can still read the content that's been sucked down earlier.

And we know, of all the HTML5-- and I'm using the term not as an umbrella, but as the markup language-- of all the HTML5 apps, it's fair to say the Appcache is probably the least loved.

If that's web workers, local storage-- Appcache is the guy not snogging and clutching the cheap bottle of beer.

Jake Archibald two years ago.

[APPLAUSE] He pointed out that Appcache is a douchebag.

And I guess that you all have read his reasons why.

If you haven't, trust him.

He's a Geordie.

So the clever Google guys invented something called Navigation Controller, and it took me awhile to understand.

The explainer doc is very dry.

I think actually a lot of these explainer docs will be better received by the design community if they had a nice logo.

So I spent quite a lot of time working on this logo, which those guys are welcome to take.

It's all open source.

You've no idea how long it took to Photoshop that roller on top of the woman on rollers.

I only used this logo once, and it's just as well they changed the name because it was unfortunate.

But nevertheless-- [LAUGHTER] They've now changed the name, which gave me an opportunity to make an even better logo.

It's called service workers.

I'm going to leave that up there for an unnecessarily long time because that's going to save you a lot of euros in a coffee shop later.

Service workers are great.

It's Appcache done right.

I've heard a few people make a joke about the name Service Workers related to the employment of people in the red light area, but I tend to think of service workers as McDonald's people on low salaries at McDonald's.

So think of Service Workers as like McAppcache.

Like a Big Mac Appcache.

Much better.

I'm not going to go into it in detail because we don't have two hours and you can both read, but this is what a service worker does.

Basically on the first load of the page you can download a controller, CTRL.js, register it

so that it doesn't block the page, the page renders, and the next time you come, all fetches and all navigation will be first routed through the Service Worker.

It's like htaccess, but in the client I guess is a crude way to explain this.

And that will allow you, subsequently, to grab content, stick it in an IndexedDB database, and then when your service worker that you have to write-- there's no magic.

You have to write it all.

When your Service Worker detects that you're offline, it can then grab content from the IndexedDB and render your page and you're working offline.

The best thing is that normal resource loading is fallback behavior.

It's offline by default because CTRL.js still works offline,

and it forces you to have URLs.

One of the central themes of this talk is the importance of URLs on the web.

To me, URLs define the web.

If you boiled down the web, you would get URLs and pictures of kittens.

That is the essence of the web, if you like.

The web should never lose URLs.

Lexi, or Alex Russell-- since he changed the name of the thing midway through my talk preparation, I'm going to change his name.

So Lexi Russell said, when you combine Service Workers with IndexedDB, you have power.

And you do.

A note about IndexedDB, who likes the API? Yeah, you don't need Jake Archibald to tell us what the DB stands for, do we? Douchebag.

Thank you very much.

The thing is with IndexedDB is the guys who made it never really expected us to use the naked API.

They expected libraries to be built on top.

And that's very much a theme-- Dominic and Angelina both touched upon it-- the extensible web manifesto.

Again, I'm not going to go through it in too much detail, but a lot of the people on the W3C tag-- see what I did there? I'm Robin Berjon.

The W3C-- on the standards-- the feature developers, when they've written high level APIs like Appcache, it's kind of sucked probably because a lot of the people who are brilliant at writing specifications don't actually do the industrial web development that you guys do.

I don't do it anymore.

So the extensible web manifesto is a righteous, righteous thing signed by many of the tag, but it's not, as far as I know, officially a tagged document.

Basically, in order to hasten iteration of standardization, it is the browser manufacturers giving you guys new low level stuff that you can build a corpus of best practice and feedback in a kind of virtuous cycle to make the specs better.

And we're seeing this with polymer.

People are using polymer and then feeding back their experience to improve and iterate on the web components spec.

This is good stuff.

This is what the web needs to advance and be better.

We don't need to repeat the Appcache debacle again.

This should go some way to preventing that.

If anybody has a pitchfork, get it sharpened now.

DRM or, as some people call it, EME, which is a euphemism like calling browser sniffing device detection or like calling a fart passing wind.

It's a euphemism.

But we'll call it what it is.


This slide was made not by me.

This slide was made by a six-year-old boy called Jack, and he has a website called Jack Draws Anything.

And if you give him 20 pounds, he's trying to raise money for a hospital that treats his chronically ill brother.

He aimed to raise $100 pounds.

I think he's raised $125,000 pounds now.

So I gave him 20 quid and asked him to draw me a slide of the letters DRM.

If a six-year-old knows that DRM is ugly and scary, I think we can draw our own conclusions.


Not Opera.


This, to me, adequately summarizes DRM.

I don't think it works, personally, boss.

But people do think it works.

If you have a torch, you should light it now.

I think the web needs DRM for videos.

I don't think it's unicorns and double rainbows.

I've come to the conclusion reluctantly and kind of against my optimistic nature, but I think we need to throw the battle about DRM in order to win the wider war, personally.

We can beat each other up after.

Somebody said, much debate about EME DRM.

But little mentions that Google and Microsoft are the browsers pushing it.

Convincing them is the only way to stop it.

Now, I don't speak for Google and Microsoft.

God knows.

Imagine the salary if I spoke for both Google and Microsoft.

Imagine the schizophrenia if I spoke for Google and Microsoft.

But I can't imagine that Google and Microsoft woke up and thought, this web think has been really great for us, so let's go and fuck it up.

I think-- am I right? Cool.

I think the people who are pushing for DRM are the people who own the content.

So if you are opposed to DRM, what you should do is never go to the cinema and never buy a DVD and write to those people and tell them why because I don't think it's Google and Microsoft's unilateral decision to introduce DRM.

I tried to look for-- well, I didn't try to look.

This was the explainer for me.

But a lot of companies that support DRM, you might argue-- I wouldn't argue because I'm up on stage and probably legally liable, but you could argue those people are a bit evil.

But the thing that persuaded me was a really non-evil organization's reasons for supporting DRM.

The BBC.

The BBC supports the publication of the first draft of the Encrypted Media Extensions Proposal.

That's DRM.

And the reasons they give, I think, are compelling if you were the BBC.

Excuse me.

One of the things they can do is for me because I'm a UK resident and I pay a license fee.

I get the content free for seven days, whereas-- well, you guys probably do as well because you have know how to VPN your way around it, but other people worldwide, they buy DVDs or the BBC sells their state broadcasters the programs.

And that funds the BBC and allows it to do good things and I'm content with that.

But they can only do that because of DRM, which at the moment is done with their iPlayer.

They also note, and you can't fault this, is in their programs they have music that other people have written and maybe it's a film or a dramatization of a book and somebody else owns the rights to that.

Even if they wanted to give it away free, they legally can't because they've signed contracts with the copyright holders of the script writers.

They note, and this is interesting because this is exactly the same argument that we use against native apps-- they note that there's so many different platforms upon which they have to make the iPlayer with its DRM that that's unsustainable.

The complexity of delivering across to PS3s and iPads and Android, et cetera, et cetera, is becoming unsustainable.

This is exactly what we say to people about using the web.

They say that if they can't be DRM, they won't be able to make this stuff available only on closed devices and app stores.

And I don't believe this is a threat.

This is simply a statement of their legal responsibilities and the massive morass of contracts that they've signed.

And they finally note that if there is no DRM, it will be lost to the worldwide web entirely because its difficult to link to and difficult to reference for the rest of the web.

URLs again.

So this is what persuaded me that, in order to win the wider war of stopping native taking over the world, it's worthwhile throwing the battle for DRM.

I think it's too dangerous to say to megacorps, no, we will not allow you onto the web.

Go native.

There's already too many people going native.

We don't need to give more people an absolute cast-iron rationale to do the same thing.

In my opinion.

Geolocation is what started all the hassle because, of course, four years ago if you wanted to access the location chip on your device, you had to use a native app.

And a group of browser manufacturers got together, and my boss was the co-chair of the working group that came up with the geolocation API, and we all think it's super duper and lovely.

And there are more and more.

There's a file API on orientation and sensors and web RTC and drag and drop.

All these things are available now.

One of the projects that's interesting is PhoneGap.

You know PhoneGap, and the aim of PhoneGap is to bridge that gap between the native device APIs and what the web allows.

And Brian Laroux, the curator and the starter of PhoneGap, has said clearly, the aim of PhoneGap is to make itself redundant.

So I asked Brian why developers use PhoneGap, because I was always told developers use PhoneGap to access the device APIs, but most of those are available in browsers now.

And Brian was kind enough to allow me to quotes him today, even though it was a private email, with full proper attribution.

So what Brian "Bubbles Bon-Bon" Laroux told me-- thanks, Brian-- is that it's not actually about device APIs anymore.

It's about app store discovery.

I asked him about monetization.

Is the reason why people want to be in the app store so they can get paid? And Brian said, well, I don't buy the monetization story because if I did that means I endorse $1 business models based on manufactured scarcity.

Brian's a lot more sunny-eyed and optimistic than I am.

I think it is one of the reasons that people want to go into app stores.

I don't believe you can get rich writing apps unless you're Rovio, but people do.

Monetization is something we need.

That was an hour's part of this talk that I've cut out, but we do need some mechanism for monetization.

What he also said is push notification for the engagement part of the story.

And this word engagement is interesting to me because fundamentally I'm somebody who mucks around with angle brackets and occasional curly braces, and the usability and the user experience stuff, whereas I understand it's vital, it's not something I've ever really paid much attention to because other people do it so much better than I did.

But two years ago, Aral Balkan stood on the stage and said, the age of features is dead.

Welcome to the age of user experience.

And at the time, I kind of thought this was sort of flim flam about this bridging technology that is native apps.

But I went back and watched the video again and talked to Aral.

And thanks for your help, Aral.

His talk was called The Future is Native, and not troubles me because it just very well could be.

So I started to look at why people like native more than web apps, and I couldn't actually find that much stuff when I was doing a search in Yandex.


[CHEERING] Thank you.

And I did look on Google as well and Bing and Yahoo.

Other search engines are available.

[LAUGHTER] I was also a really surprised by what Aral said because, of course, when the web first came out it wasn't native at all.

On Windows, for example, to activate something, one double clicks.

On the web you single click, and I didn't notice people refusing to use web browsers because it didn't feel native in a Windows machine.

And I also remembered that when Safari first came out and you couldn't style the form fields, there was hell to pay from designers.

When we first started to demonstrate HTML5 form controls, people would always say, how can I style them? We don't want the native browser controls, but the pendulum swung and people now want everything to look native on the platform that it's on.

So I looked around and found a really good article with lots and lots of footnotes and academic citations on the user experience Stack Exchange.

And one woman or one man-- I don't know who it was-- asked this question.

Why do people like native? First of all, their response said, access to more device-specific functions.

They can be used offline.

Well, that's kind of fading away now.

When Service Workers are heavily, heavily implemented.

That problem will go away.

And we know that we have many, many device APIs and the Firefox guys have made and are standardizing even more, so that's great.


People don't bookmark on mobile, they said.

They install an app.

And actually, the installing versus bookmarking thing is very interesting because I think they're the same thing.

I think most people think they're the same thing and later on we'll look at how we can make bookmarks more like installed apps.

A superior interaction.

Notice they say they can be used offline, but that's not actually cited as a major benefit.

The benefit is that they are faster.

They are more performance.

And they allow the user to access device-specific hand gestures.

I think there's something browsers can do.

This is a 30-second vid of something we've made for iPad at Opera.

The point is, it's all icons.

The screen is full screen.

There's no browser chrome.

All searches pop up icons that you drag and drop those things.

You swipe left to go back in the history.

It feels like a native experience.

What we're trying to do is appify the web-- give it a native feel on the iPad-- but it's still the web.

One of the things we don't do, which I wish we did, was make it easier for customers to find the URL you're on.

URLs are the core of the web.

People often ask us when we're going to port this to Android.

But that's not the point.

You can't just recompile it for Android.

It has to be rethought to feel like native because people want native.

We need to up the performance game and Paul Lewis and his chums are, in my opinion, leading the pack in making the web more performance.

The W3C have an initiative called Closing the Gap, and one of things they site in their gap analysis is scrolling and poor performance.

I believe the Facebook guys cited bad scrolling as their reasons for abandoning their HTML5 apps and going native on iOS.

So the Chrome guys have been experimenting with something called Lazy Block Layout.

I love this because Paul and I had a little bit of a fist fight in an internet car park once because I said, developers shouldn't have to worry about performance.

The browser should just handle it.

I was kind of taking an extreme position, but I just want the browsers to magically make my code better.

I don't want to have to know how they do it and I don't want to have to code to implementation details that might change down the line.

Lazy Block Layout is a holy grail for that.

What it does-- you can read the explainer doc when I post the links online, but what it does is it notices some common archetypical page layouts and it will only lay stuff out when it's just about to be scrolled into view, therefore saving you a lot of time on the initial page load.

Some incredible savings.

Elliott Sprehn, who wrote the explainer document, said that a simple benchmark of 5,000 fixed-height children went down from 180 milliseconds to nine milliseconds.

His demo, that he called Squished Presidents for reasons that I don't understand, went down from three or four seconds to 32 milliseconds with Lazy Layouts.

This will come into blink and they'll send to Chrome and Opera and the Yandex browser relatively soon and it will just magically work.

This is splendid.

Image Lazy Load is also coming.

This allows you as a developer to put a simple declarative attribute on the image element to say, this image is less important.

So for example, you have a web page in which you have your company logo and a lovely picture, and obviously the most important thing for the user is the picture.

The most important thing for you is the logo.

And then you might have little avatars of people leaving comments, and you would put Lazy Load against the avatar images because they are less important.

This is cool stuff.

I really want to see this happen.

It's not just images.

It's any kind of resource.

Audio, links, embeds, videos.

And this is starting to be implemented in IE11 already.

So this is coming to browsers near you, which is great.

Image Postpone is cool.

This says-- it's a bit like Lazy Block Layer-- you're saying, postpone these images.

Postpone downloading them until they're just about to be scrolled into view.

I think the word must is too restrictive there.

I can foresee some situations in which basically it takes time for your mobile device to turn the radio on.

And I can foresee a time when, actually, it's going to take longer to keep turning the radio on to grab images later that are postponed than it would do to turn on and grab everything down.

So I think the browser knows best the situation it's in and it should be allowed to make that decision.

But you can give a hint like you can with preloading on videos.

This is good stuff.

Position sticky.

You know this.

It's when you have a table and you say, the table header is sticky.

And it will stay at the top of the viewport until the parent element has gone away.

You see it in the iOS contact lists all the time.

You can do this with JavaScript now by looking at scroll events and working out where you are on the page and then swapping CSS classes between position fixed and position relative, but that's a real bad performance hit.

As browsers are hardware accelerating scrolling, they often can't do that if you're doing loads of scroll handlers.

So this allows the GPU to do the work.

It's a single line of CSS, or it would be without all the vendor prefixes, and it just works.

This is righteous stuff, and this is coming, even though this is CSS and not HTML5.

So I am using the umbrella term.

There's a guy who wrote a guest blog post on the W3C, and he was writing about interaction.

Scott Jensen.

And Scott suggests that what we need is the ability for web apps to appear on your desktop or on your mobile device the same way as native apps do.

So they are there in the task switcher and they are there on the Home screen, not as the browser icon but as the app icon.

We should be able to install a web app from any page, and it should be a safe process to download and install.

Now, I'm not sure that installing is actually different from bookmarking and I note that this week Paul Kinlan of the Chrome dev rel team said that you can add-- from Chrome for Android-- you can add a bookmark to the Home screen.

What's it called? Application shortcut is the official word? Something like that.

Basically you can press a button in Chrome for Android and the icon for your page will appear on the Home screen, and when you click on that it will start up and you have an app.

An installed app.

We had this before, a few years ago.

Marcos, from whom you heard earlier, was working for Opera and he was working as the editor of a spec called Widgets.

And these did much the same thing.

We bagged up HTML, CSS, JavaScript, SVG, with a manifest file and then you installed it, and it behaved in the same way.

But it failed.

And I asked a lot of people why this failed.

There's lots of reasons.

First of all, it was an XML manifest.

And of course, at the time, XML was like a total loser and JSON's the way forward.

And fashion matters in web development.

I think widgets is a stupid name.

What are they? Are they apps? Are they little gadgets? And byte-shedding aside, marketing-- names matter.

We, Opera, marketed it as a differentiator.

And if you market something as a differentiator, other people are therefore unwilling to take it up.

And also, at the time, the web stack was simply not powerful enough.

So you had something that looked like a native app, but it couldn't actually do much, so that was a problem.

There were other problems too.

There was no compensation model.

We need a method of-- (audience) [INAUDIBLE].

Yeah, yeah.


Blah blah blah.

And not invented here.

The Chrome guys made-- one of their iterations of packaged apps was so similar to Widgets that a guy called Scott Wilson who works for Apache wrote a script that would download a Chrome app and translate it into a W3C Widget and you could install it.

The not invented here thing.

But the not invented here thing is problematic, so somebody asked Paul Kinlan if this application shortcut thing would have an API like the Surface.

Paul said, yeah, he hoped so.

And Jake Archibald said that they were looking at using the Mozilla manifest spec.

At the moment it uses metatags, but they're looking at the Mozilla manifest spec.

The manifest spec is this, and Marcos-- Marcos down there-- is the editor of this guy.

Basically it's a JSON document.

It tells you which icon to use on the Home screen, some permissions, tells you to open it full screen, gives you the Appcache stuff but nobody cares about Appcache anymore.

This stuff is righteous and good, and it's good that the Chrome guys are considering using this.

Not Invented Here.

Actually it's No Interoperability so Hand the future to native.

The promise that the web has is that it works everywhere.

And so we fuck up the promise so much by siloing stuff to individual browsers.

We, by doing things slightly differently all the time, actually break the central promise of the web.

And I say we as somebody who represents a browser vendor.

One of the things that a friend of mine, Rich Tibbett who works for Opera, is doing is trying to standardize extensions.

Extensions are everywhere.

We all love them.

They are little apps that live in the browser.

Wouldn't it be great if extensions worked across browsers rather than locking you into ecosystems? Ecosystems is for native.

The app, the web, should work everywhere.

So Rich has proposed NEX.

We did this because, when Opera switched to Chromium, we were using CRX.

But we added some APIs of our own, and we didn't want to pollute the CRX namespace with Opera-specific stuff.

So we proposed that there be an NEX, which is just a file extension and a mime type, and then anybody can use it.

And of course when you as a developer are writing an extension, you just feature detect for those extension APIs for the browsers exactly the same way as you feature detect anything else in JavaScript.

This is a webby way to do it.

I don't know whether this will actually happen, but I like the idea.

It's a righteous idea to make the web work everywhere again.

One of the things that happened when we were trying to standardize Widgets is Apple put in a patent exclusion.

We have the idea that Widgets should be able to update themselves because it was a package format.

It was a snapshot of a website that you downloaded as a zip and installed.

And the Apple thing will fade that away.

But I think a few of us realized that one of the problems with Widgets and packaged apps is it's throwing the baby out with the bath water.

And I checked.

I believe most Germans and Dutch people know this phrase, this idiom.

The web is immediate.

When you go to a URL, you're seeing it as it is right now.

So downloading a snapshot of a website and installing it doesn't feel webby to me.

We should somehow be able to install a real URL, a real website, rather than a snapshot.

The thing is with apps is a lot of them-- and I'm talking about web apps or native apps, whatever-- a lot of them need access to the privileged APIs.

Geolocation, WebRTC, accessing your camera, your microphone.

So we get this permissions hell, and I think one of the good things about native apps is you install them, you grant them permissions, and there you go.

So the problem is that if you are on a web page rather than a standalone packaged app, that web page could be phoning images from your webcam of you relaxing and reading the paper in a mankini, and it could be sending it off to a third party, which you may not want.

You may want it.

I don't know.

This doesn't happen with a package.

So what Rich-- Rich Tibbett again-- what he's proposing, and this is a straw man proposal-- other proposals exist, most notably by Boris Smus from Google-- but this is Rich's one and I understand this better.

What he proposes is there'd be a fourth state of document readiness after complete and that's installed.

And installed basically turns off-- it unplugs the network.

So you can access the camera and you can copy it into Canvas and make pretty pictures and much about with them with WebGL and save them.

But it can't phone information home.

He also proposes there be a fifth stage before installed which is installing, so the idea of this is that you see a splash screen, it tells you what the app does, it tells you the permissions, you say yes I'll install you, and the installing phase is when it grabs all of the chrome of your application, all the CSS and the JavaScript, before it turns the network off.

The problem with this is that you have to ask for approval for navigation.

The reason for that is, if you go to a link, a malicious app could encode the data that you've put in there-- the pictures of you on your bed in the mankini-- and somehow base 64 encode it, add it to the link as a query string, and send it off to

There are ways around this, I'm sure, but what I like about this proposal is it is a righteous way of extending the web-- making it web plus-- and not trying to compete with native apps by crippling central, important features of the web, which is the immediacy.

So that's a bit of mea culpa from me as a representative of a browser vendor.

I think a lot of developers also are guilty of throwing the baby out with the bath water.

This is Project Loon from Google, and this is sending a weather balloon-- kind of a weather balloon-- up into the stratosphere that it will bounce WiFi signals off to bring the web to isolated rural areas.

This is good.

This is righteous. is a project

by Facebook, Opera-- my employer-- Samsung, Nokia, Qualcomm with the aim of bringing the web to the five billion people in the world who don't currently have it.

And I've heard criticisms of both of these initiatives.

People have said, ah, yes, but it's not because they're lovely.

It's Google and Facebook and Opera and Samsung-- they want to sell things to these guys.

Now, I don't speak for Microsoft and Google and I certainly don't speak for Facebook and Samsung and Nokia or even Opera.

But my response to that would be, uh, yeah.

Of course.

Of course we want to sell things.

There's no suggestion that we're going to hand five billion people Samsung and Nokia phones upon which they can only access Facebook through Opera Mini.

This isn't the point.

The point is that markets get opened up and it's the long game.

And also things flow two ways.

There's a group called the McKinsey Global Institute.

They are a management consultant to Fortune 500 companies and governments, and therefore unlikely to be sitting around a campfire singing "Kumbaya" on their guitars.

But these guys points out that the benefits of the web are vast.

3.4% it adds to GDP.

21% to our GDP in developed countries.

2.6 jobs are gained

for every one lost through technology-related savings.

They did a study of 13 countries over 10 years.

75% of the benefits of the web are felt in traditional sectors.

And you can read for yourself-- 10% increase in productivity.

So bringing the web to five billion people-- it might not be selfless, but it's by no means a colonial exploitation exercise.

People will get benefits from it just like we have.

But there's a myth of smartphonification.

Everybody will have smartphones soon, and when everybody has smartphones we can just deliver our apps with a body element that's empty and squirt it all in with JavaScript because everybody has smartphones, right? So this is India.

I like India.

I've been there a few times and I trust their stats more than the Chinese stats.

Last year, the Times of India reported that the smartphone segment grew by 75%.

But smartphones are still only 8.1% of mobiles in India.

So that's changing, but there is not 100% smartphone prevalence.

Does anybody own any one of these devices? Anybody heard of any of these devices? This is 100 Android devices sold in-- shipping already in India, Bangladesh, and Nepal, all of which come pre-installed with Opera Mini by the manufacturer.

Opera Mini is a thin browser that everything happens on the server and JavaScript doesn't work as you expect it.

So why are these people buying Android devices-- smart devices-- and installing Opera Mini, and the reason is simple.

Your smartphone is only as smart as the network upon which it's working.

And these are places with gigantic, gigantic territory-- often challenging territory-- often with data plans where people are paying by the megabyte.

And they prefer to use Opera Mini because it gives them the speed of the web that they need.

So if you do not just make the web properly-- if you make everything a JavaScript app because the world is on smartphones-- these people will have no access to your stuff.

Elvis Costello-- I was going to show a photograph, but I realized everybody here will not know who he was-- but he sang a song called "What's So Funny About Peace, Love, and Understanding?" If he were here today he'd be singing, "What's So Funny About Peace, Love, and Progressive Enhancement?" People just have assumed that the days of progressive enhancement are gone.

This is [inaudible] A guy called Mike Davis points out that, when the CDN was borked, he could still read the text because of progressive enhancement.

And he's sitting on 100 megabits per second broadband in the UK.


They were so excited that their holy grail app was so much quicker because they served real HTML instead of waiting for the client to download the JavaScript before rendering.

This was their holy grail, they were so excited.

It was fully crawlable by search engines, and it was really fast.

Who knew taht just serving HTML, styling it with CSS, and then adding the JavaScript was a good idea.

Notice it's fully crawlable by search engines.

Of course, we all work for businesses and we want SEO.

So you could either just use HTML in the future, like we've always used it in the past for the content, or of course you can do really cool stuff like pre-render in which you browser sniff for the UA string and work out if it's a search bot and then use a node middleware layer to send HTML to the search bot.

So this is hack upon hack with a bit of browser sniffing.

This is not the way forward, ladies and gentlemen.

We need developers and browser manufacturers and people who write standards-- we need to stop emulating failure.

We will not see off the apps menace by emasculating the web in order to compete with it.

We won't.

Even if we manage to see off the menace, we will have lost so much already.

We have benefited from the web.

We have had an Industrial Revolution.

McKinsey again.

The hippies.

They say that we've seen an increase in GDP of $500 in five years, and it took the Industrial Revolution of the 19th century 50 years to bring the same benefits.

There's five billion people in the world for whom this has yet to really realize for them.

Let just keep an open, royalty-free web based upon progressive enhancement and open standards.

Let's not give these guys proprietary, native app lawsuit patent hell.

When the Guardian journalist gave me permission to use this diagram, he pointed out that actually it's out of date because it literally proved impossible for him to keep on top of who's suing who.

We do not need to pass this on to the five billion other people in the world who are getting the web.

That's good.


So what we need for the web is browser vendors to work together for interoperability.

Locking people into ecosystems is emulating the failure of native apps.

We need standards that preserve the core strengths, an end to silos-- devices that will only run one OS, that will only run one browser-- and we as web developers need to preserve the core strengths of the web.

There are more people living inside this circle than outside of it, and it would be a terrible shame if by the time that India and China and Africa had come online, that we, the people who make the web, you, the people who create the web, the people who shape the web, we as custodians of the web had jumped straight from Web 2.0 to Web 404.

Thank you very much.


Post a comment