Don't Panic

During the 90s the world changed completely. It was a revolution. The web made things possible for normal people that weren't possible before. We entered this new century as a global community.

Nobody can deny that the world looked a whole lot different. A whole lot smaller. And that is something that "we" did. We build on the work of network engineers. We build on the work of the developers who created the browser. But we – web designers – we created this new world. And it had an immense impact on the whole of humanity.

And that is amazing, we. Just normal people. We changed the world. Us. By just dicking around with animated gifs of flames and copying cool techniques using view source. A revolution of the people. Now compare that to the 60's, you had to be a literal rocket scientist to change the world.

React actually feels really new to me. But even that is already 4 years old. Frameworks come and go so fast, it's easy to miss one.

In fact, two of these were actually fake. Completely made up. And most of you probably don't know which. I just thought of two frameworky-sounding names. And ironically, when doing a last minute check, I found out that both of them actually did exists and were actual frameworks.

Now frameworks are really useful. For serious development. For business. But with each abstraction on top of abstraction, frontend development is starting to look a whole lot similar to that thing that I dreaded the most during university... developing enterprise Java applications.

That's okay. The web apps we're building right now are so much more complicated than 10 years ago. We need tools..... But don't forget every browser already has a framework build in. Don't be afraid to use the webplatform.

Nowadays we're no longer just web developers. We need to specialise. I have no idea how some areas of the web platform actually work. Reading React source code looks foreign to me.

The concepts behind WebAudio with convolvers and oscillators and other nodes is something I really don't understand. And with each release of JavaScript I struggle to keep up. And I'm very happy to use an abstraction on top of, instead of directly using IndexedDB.

I had no idea how WebGL worked. It doesn't feel like a web API at all to me. 3d models and shaders went totally over my head.

But this is also exiting. We can now experiment and play with technologies that were once the domain of native developers. I attended this workshop earlier this year with Martin Splitt - who talked here last year btw. An introduction to WebGL. And it was so much fun. Not that I am any good with it, but that's okay.

15 years ago we had Internet Explorer. And some other minor browsers. Yeah, sounds harsh. But marketshare wise, that was the case. And that wasn't healthy.

Then 10 years ago came the rise of mobile browsers. Mostly dominated by WebKit. Not only Apple used WebKit for Safari, but almost every mobile phone browser did so too. The Android browser was based on it, but also Nokia S40 and S60, the BlackBerry browser, Bada, webOS, Meego and Tizen.

And this was a time of great innovation with CSS3 and HTML5. And that's great. But it was also the time of webkit prefixes and Apple thinking of great features and implementing them without any consideration about standards and other browsers. This wasn't healthy.

I've read so many articles and tweets that advocated that Microsoft and Mozilla should move to WebKit. One rendering engine for the web as a utopia for frontend engineers. No more compatibility issues. Yeah right.

When Google launched their own browser, they based it on WebKit and after while growing frustrated by Apple, and feeling held back, they decided to fork WebKit and create their own rendering engine: Blink.

All the while, Opera couldn't keep up anymore and moved to Blink. And so did Android. All of the remaining WebKit based mobile browsers died, or eventually moved to Chromium. All, except Safari.

So we've moved from a Internet Explorer monoculture, to a WebKit monoculture to a Chromium monoculture. And this isn't healthy.

Browser diversity is what the web makes... the web. It's good for competition and pushes the whole platform forward. The web wouldn't be here if it weren't for the browser wars and each browser trying to one-up the others.

We see an acceleration of new features originating in the Chrome team. Just like Microsoft before and just like Apple before. That why we see things like service workers and web components first in the Chrome browser. They think of a great feature and the implementation and specification go hand in hand.

Sometimes implementations happen so fast that when the standardisation is finished, the implementation is already outdated and we have a unoﬃcial "version 0" of the spec and the browser now needs to be updated to support the oﬃcial standard.

So we're faced with exactly the same issues as 5, 10 or even 15 years ago.

We've got all of these different browsers and different rendering engines and a whole bunch of features. And not every feature is available in every browser.

So how do we deal with this. The difference is that we've now got a tool that didn't exist yet 15 years ago. Well, we've talked about this before. Progressive enhancement.

But when do we consider a feature to be part of the core experience? When do we drop support for browsers or when do we try to find a workaround?

Over the last year I've heard multiple developers mention they were dropping AppCache in an existing web app in favour of Service Workers. But I think that is irresponsible and extremely user hostile. Just because we now have a better oﬄine experience for Chrome users, does not mean we can simply drop the off-line support for Safari users.

It is fairly easy to get too excited about a new feature. Or just lazy. Sometimes it feels like we haven't learned anything from the past.

So when the Starbucks Progressive Web App launched last month, it had off-line support in Chrome for Android. But apparently not in the latest version of Samsung Internet. It wasn't recognised as a PWA. So why?

Because we've become spoilt. 10 years ago we were forced to test and test and test. And fix problems and then test again. Now we just build and expect it to work. Because everybody uses the latest version of their browser and browsers are compatible. Right?

So what caused this? Samsung Internet supports Service Workers, so that's not it. No, the only reason was that Starbucks used the Workbox library and that used async/await. And Samsung Internet uses a slightly older version of Chromium which doesn't support that yet, so the service worker script caused JavaScript errors.

So when did we get async/await? Chrome 55, Firefox 52, Edge 15, Safari 10.1. About 6 months ago. And apparently some of us are already using it in production without any regard for backwards compatibility.