The State of the Web Platform

Thomas Steiner: Yeah, thank you very much for the kind introduction.

I'm the last talk between you and the pub.

Sorry for that.

So the state of the Web platform, nothing more, nothing less in 15 to 20 minutes.

Challenge accepted, but with a big caveat, it will be subjective and incomplete.

So how's the Web doing?

We can't really ask it directly, but to get an answer, I checked its Facebook page.

And you know what it's doing mostly great according to the sources that I could.

It has 4.9 billion friends?

Users?

Users.

But then the relationship we have with it is complicated.

For example, in 2022 and almost 2023, we still don't know how to hold even basic things like HTML, right?

Use divs as buttons.

And buttons as links and place hold us as labels.

We could actually say it's an HTML hell, credits to htmhell.dev.

So this is not me, this is you can see the source in the right corner, htmhell.

But then on the other side, if you asked Ted Nelson, the inventor of the first HyperText project called Project Xanadu, HTML is precisely what we were trying to prevent.

So maybe, it's not that bad.

But then well, to be fair, Mike Sandal, who was at the time, Tim Berners-Lee's boss rightly said that the idea of the Web was "vague but exciting".

But why stop at HTML?

We obviously likewise don't know how to hold CSS.

CSS is render blocking.

So, Henri.

Hello.

And yet it's so easy to find pages that don't use more than 90% of the CSS that they ship-more than 90% of the CSS that they ship.

They don't use.

We also don't know how to hold JavaScript.

In 2022, instead of holding it, we ship it and a truckload of it on every single page load.

Ask Alex Russell, or ask Henri for the details.

But why is that?

Where did it all start?

It probably all began with Ajax, Asynchronous JavaScript and XML, a term coined by Jesse James Garrett, which represented a fundamental shift in what's possible on the Web.

It arguably allowed us for the Web to become an application platform, not a document platform, an application platform.

But recall what happened?

All applications Ajax became something we don't even mention anymore.

If I were to submit a talk titled 'Building Amazing Ajax Apps', this would probably not fly in 2022.

The same actually happened, to HTML5.

Remember how everything cool on the Web was HTML 5?

But in 2022, do we talk about HTML 5.1 or HTML 5.2 and whatever happened to HTML 6?

Is that a thing?

I don't know.

Probably not.

There are people who also version the Web.

They speak of Web one point.

The Read only Web, which includes Google and Web 2.0.

The Read write Web, which includes Google too, but this time with a new logo.

And then Web3, the decentralized Web, which for some reason is not called 3.0, but three.

As I said, this talk is subjective, but I don't personally believe Web three is the future.

So let's take a step back and put ourselves in the shoes of these two gentlemen here, Ben Galbraith and Dion Almaer, who presented on well, the State of the Well Web platform, the title of my talk, but in 2009 and "Dress for Success" is how they prefaced this slide of their 2009 State-of-the Web platform presentation.

Now, quick side.

Dress for success is what I thought too when I wore my wedding suited from my first ever academic conference in 2011.

But yeah, anyway, back to Ben and Dion in 2009.

They had a big dream.

They were building this cool web-based editor called Bespin.

Anyone remembered Bespin?

Couple hands.

Yeah, great.

Cool.

So accessible from anywhere.

Simple to use.

Wicked fast.

Rock, solid, real-time collaboration.

Integrated command line, self-hosted.

Fast forward to 2022.

Go to any GitHub repo, literally any.

For example, go to WebKit's Github repo.

Press the dot key on your keyboard, and boom, a full fledged coding environment loads and within seconds it's waiting for you to change the world.

Luckily I did not touch the WebKit code, but explaining I could, and this works not just in Chrome.

The same works in Safari and the same works in Firefox.

This Github feature is powered by the Monaco editor, which also powers VS code on the Web that you can see on this slide.

If you go to vscode.dev in Chrome, you can click 'open folder', choose any project folder from your local disc that you're working on and hack along.

If you try the same on Firefox, you get a message that says 'Opening local folders is unsupported', but you can still open individual files, not just one file, individual files plural.

The same happens on Safari.

Microsoft don't block you from using their product.

They operate within the limits of the current browser and clearly point out the missing piece, which is opening folders.

Since forever we call this idea 'progressive enhancement'.

Give people a baseline experience and on supporting browsers, make it better.

So back to VS Code in Chrome.

It's an installable app.

So the browser offers this install prompt, this installation prompt, and if you click install, the app morphs straight into a standalone experience.

This experience integrates well with other apps on the desktop, so you can multitask freely.

On the very left, you can see the Web based Code, and then the third item on the right is like the native, the real VS code.

It's the insider's version.

But they're not really distinguishable.

If you multitask, they just appear like any other apps.

The Web version of VS code comes with a cool feature called 'Window controls overlay', which lets your Web app move content up in the title bar area for an even more native experience.

So you can.

The title bar area, where typically you have to the title bar, they use and put useful information up there so they make more use of the screen real estate.

Another really amazing app I wanna highlight is Adobe Photoshop, which you can access photoshop.adobe.com.

And you can see me edit the project Fugu logo here, right in the browser.

This is Photoshop running right in the browser.

One of the Chrome API, one of the APIs that the Chrome team is standardizing with other browser vendors is the origin private file system to be able to open even gigabytes sized gigabytes.

Gigabytes.

Let that sink-gigabytes sized Photoshop files in the browser, adobe needed performant file system, access to temporary files private to the origin of the app.

You can think of them a little bit like swap files.

On this slide, you can see me inspect the origin private file system of Photoshop with a browser extension called OPFS Explorer.

And you can see they have a ton of temporary files that are private to the origin of this particular origin, which is photoshop.adobe.com.

But of course, on day one, when Adobe released this, some of these APIs that are currently being standardized had not yet landed in browsers other than Chrome.

And of course people noticed so well, haters gonna hate, right?

Ah, "yet another Chrome only app", but Adobe were really, quick to highlight that the Chrome only situation, was only temporary.

And they pointed out that Adobe are working hard with Apple and Mozilla to get the new APIs implemented.

I'm happy to report that Apple and Mozilla have made huge progress and based on Adobe working with these two vendors, Safari now opens Photoshop files in read and comment only mode, and so does Firefox.

And the blue banner that you can see on the top says that Photoshop on the Web is not, is not supported yet on this browser.

And the little word 'yet' is the important word here.

As I said, the underlying API, the origin private file system is currently being standardized and cross browser implementations are happening.

It's supprted in Safari already.

It is behind a flag in Firefox.

And the same holds true for more APIs that started in just one browser, but that are soon or already present in other browsers.

For example, the Web Share API Web Transport, Web Codecs, Clipboard API or the Multi-screen Window Placement API.

And apart from core browser APIs, a very important role in modern Web application plays web Assembly.

In the case of Adobe, it allowed them to profit from decades of experience they had on their native platform Photoshop that they could transpile with emscripten and leverage it with this compiler tool chain so that they could transpile it and use it in Web Assembly.

Web Assembly supports powerful features like SIMD-single instruction, multiple data, and also P-threads so that you can have threads that run in parallel.

All these together.

Web Assembly with emscriptem and new browser APIs developed in the context of Project Fugu, allow you to develop amazing progressive Web apps, or Web apps or apps.

Remember what happened to Ajax, and HTML5.

When you build an A, when you build an app in 2023 or 2022, it doesn't really matter that much if you call it a 'Web App', or a 'Progressive Web App'.

Just make su, just make sure it's an amazing experience.

And with that, I want to leave you with three points.

One, the Web is one heck of a powerful platform for amazing Progressive Web Apps.

Now if You believe me, based on the two examples that we've seen, Adobe Photoshop and the coding environments that Microsoft is building, and GitHub is building.

Two, make use of progressive enhancement.

Some of the best companies do, even if not all browser APIs may be immediately supported in all browsers.

Think of ways how your app can work and still give people a baseline experience and a truly amazing experience on browsers that support these APIs, which makes me to my final and third point.

Talk to all browser vendors.

Do what Adobe did, bring your use cases forward and motivate them well.

No browser vendor wants to see you tell your customers to download another browser.

And with that, thank you very much for listening.

I'm Thomas Steiner.

You can find me as tomayac on most places on the internet.

These slides are online.

You can find them at Go, go, sorry, goo.gle/codeleaders Web platform.

Or you can also just scan the QR code.

And yeah, with that, thank you very much.

Looking forward to an interesting discussion.