Project Fugu 🐡

Hello, JS Party listeners. We’re back this week, talking all about the web yet again… Surprise, I know… We’ve got a really special guest with us today. Before we introduce our guest, on the panel with me today is my - I would say almost regular co-pilot these days, Nick… Oh, well, I just – well, anyways… I feel I always spoil introductions. So Nick, welcome! Welcome on the show.

Hoy-hoy! Good to see, Amal.

Good to see you. This is the first show that I’m back in my own home. I’ve only been home for 12 hours, and I’ve already had A/V issues, and internet issues, and all the things; all the things that you can imagine, all the tech issues have concentrated into this show. But anyways, regardless, the show started now, and we’re super-excited for our amazing guest…

Oh, yeah.

Yeah, mega-amazing. He’s so amazing he’s got a Ph.D. Tom Steiner, Senior Developer, Relations Engineer, who works on the Chrome team at Google. Welcome, Tom.

Thank you very much. Hello.

Hello. Tom, why don’t you tell us a little bit about yourself, for folks who might not be familiar?

Well, my name is Tom, I work on the Chrome team, but what I like most about my job is that I work on the Chrome team, but actually I’m not that much advocating for Chrome. I do as well, of course, but I’m very much also advocating for the web. So the web is the product that I advocate for, and specifically, more specifically, Project Fugu these days, which is all about making new use cases possible on the web by adding new APIs to browsers. And browsers, by definition, is plural, not just one browser.

that sounds like an amazing job. I have to say, for many years - I’ve been following the Chrome team for almost a decade now, and it’s been amazing to see kind of… I think that team specifically set the standard for how to do developer engagement, and how to do developer advocacy, and how to do developer education well. I always think of the Chrome Dev developer relations team as a whole, and there’s different roles within the developer relations team… There’s folks that work on engineering projects, like Tom, there’s folks that are really more focused on advocacy… I’ve always thought about that team as best-in-class. I do have to admit though, just to be fair - Tom, I don’t know how often you listen to this show, but I’m not sure we have a ton of Chrome users anymore on the panel. I use a Chromium flavor as my primary browser these days, Brave. I also use Firefox… But I think regardless of our usage of Chrome, I think I’m a fan of the Chrome Developer Relations team, and I’m super-excited to have you on the show today… So thank you, and welcome, Tom.

Yeah, thanks for having me.

Yeah. So Tom, we’ve invited you here today to tell us all about Project Fugu. We’re super, super-excited to finally have this topic on the show. It’s been on my to-do list for a very long time. One of my really good, very good friends, and I would say he’s like my frientor… I don’t know if you know what a frientor is, but he’s like a friend and a mentor to me… Alex Russell was the tech lead on this project, and helped really galvanize it… And he’s at Microsoft now. But he was on my list, I was like “Alright, I’ve gotta get Alex to come on the show to talk about Fugu. I’ve gotta get Alex…” And we just never made that happen… And I’m so glad to finally be talking about this. So can you tell our listeners, what is project Fugu, and why are you working on it? It’s such an important project to the ecosystem, and there’s so much to unpack, so… Educate us, please, Tom.

[06:00] Yeah. So let me start… You should definitely get Alex on the show.

Oh, for sure.

He’s still around. He’s still at Microsoft. He still does web stuff, obviously… So very much do make sure that you get him on the show. And I will tell you my view of project Fugu, but obviously, Alex has been around for way more time than I have been, so he will have a different view, so also get his, for sure… But what I will tell you is, when I started working on the Chrome team, I was looking for my niche. And on the Chrome team back then everyone was doing amazing things, like CSS Houdini, and all the hot topics were being dealt with… So I looked at “What are people doing on the web?” I noticed this tendency where more and more people were building amazing applications on the web. And in many cases, these applications were lacking certain APIs. So there were gaps in the platform that the platform just didn’t cover… And Fugu was his effort that people around Alex - but there’s a lot more people behind this - have started. And they started by filling all those gaps.

So initially, there was ChromeOS as an app platform, and they had a backlog of all these APIs that they [unintelligible 00:07:11.07] of sorts to be on the open web. So not proprietary ChromeOS application platform, API Interfaces, whatever, but like proper, on a standards track, developed in the open APIs that people could agree on universally, where browsers would say, “Hey, this is a good idea. Let’s do it that way”, but browsers also could say, “Yeah, we’re in general okay with this API, but we don’t like the shape, so let’s refine it a little bit.” Or - and this also did happen, where browsers would be like “Oh, that’s a terrible idea. We don’t want to have this on the web platform.”

So with all these three different options of how APIs could play out, Fugu was or is still this effort of making stuff and use cases happen on the web. And in general, what we do see is there’s developer enthusiasm, there’s also skepticism when it comes to “Can I really use this on all browsers? What is the right strategy for building applications today?” And yeah, I guess we can discuss some of these questions during the show.

Yeah, oh my God, thanks for that great summary. There’s so much to unpack here, and we’re gonna get into some of the specifics on specific APIs that Fugu is enabling within a browser that’s already near you, or coming to you, I don’t know… But I think what’s more important is to discuss why was this project created. And Alex and I have had many chats, and I’m certainly going to have him back on this show, but it’s going to probably be a wider discussion about like “How can we save the web?” That’s gonna be a three-hour conversation, we’re gonna need some alcohol for that, it’ll be probably a special edition show… But focusing this on Fugu, can you tell us a little bit about why this project was created? Can you tell our listeners about why, like what are we actually trying to do here?

So talking to a lot of partners, so customers, companies Google works with, we always got sort of the same message, which was, “We need apps, we need different apps for different platforms, and we essentially need to build the same app two times, three times, four times”, depending on what platforms they needed to cover, or thought they needed to cover… And most companies don’t really like doing that. So there’s a couple of companies who actually have the resources and actually do like building apps for platforms, but most companies, they do it because they think they have to, and they’re trying to avoid this as much as possible. So they try to build cross-platform, so using in the old days something like Cordova, or they would go React Native as a route… Flutter these days is becoming very popular for this promise of writing once and then running everywhere… But yeah, in the end, people also always need a website.

[09:59] So it can be a web application, it can be just a gateway into your application that you then install for Android, or Windows, or macOS, or whatever… But essentially, yeah, this desire of “Why not just have one app that we can use universally?” And there’s a couple of companies who have started doing that, and most companies are not there yet… But yeah, we see a lot of companies interested in at least reducing the number of platforms that they build upon.

And I would also say COVID has played a huge role in it, because COVID made desktop important again. So between - like, 2015 was the year of mobile, and everyone was looking at mobile web, and we still do, but COVID has sort of helped us roll back a little bit, and look at “Hey, desktop is a very important platform, and there’s a lot of applications that people build for the web”, and they run in the browser, and people on their big 20-inch, or whatever, 27-inch laptop screens – or not laptop screens… Desktops screens –

27-ich laptop screens - I’m like, “We need to meet these people, we need to get them on the show… We’ve got to talk about backpacks… We have a lot to talk about with them.”

Absolutely. So anyways, big screens on whatever device - they run web apps, in many cases. Looking at my computer right now, there’s a handful of apps, and most of them are really just web-based. Everything else is – macOS Finder, and some emulation software, but that’s about it. So everything else is just on the web. And they are not websites, they are web applications. So I can create stuff here. We are creating stuff here right now, so this is a web-based podcasting software… So there’s a lot of web applications that we just use, and we live in the web, and this is why Fugu was and is being built.

Yeah, absolutely.

It’s really cool.

So this idea of reducing your stack, right? And JavaScript being a universal stack… I mean, we’ve kind of been trying to do this for, I would say, ever since Node became a thing. We made that shift with our server-side stack, so teams kind of, okay, using one language in the frontend and “backend”, right? I say “backend” because for me, what is backend even these days, really? Is it really a backend? Every backend has a frontend and a backend? I don’t know, at least the backends that I’ve worked on… So unless you’re working on the data layer… I don’t even know, really. Is it the backend? I have no idea.

So teams are trying to say, “Okay, we can’t write iOS apps, Android apps, and JavaScript apps. We can’t staff them, we can’t maintain them, it’s too much”, and it’s I agree; it’s a huge permutation to manage, especially across Android. Creating a quality Android application is like an act of God, in some cases, really, because there’s tons of permutations that you need to support.

So can you tell us a little bit about this play for the web? We’ve got React Native that’s been in this space, you’ve mentioned Flutter… It sounds like we’re really trying to save the web from being engulfed by native applications, and for me, that’s kind of how I’ve always read this – this is how I’ve smelled this project. Can you speak to that a little bit, Tom?

So I think on mobile specifically people still have the tendency to look for apps on the app stores. So on the Play Store, on the App Store… And even on desktop, Apple tries to very hard make people look for apps on the App Store first Windows System Microsoft Store… So I think stores and the way as a distribution mechanism stores work is still very much important. And looking at what we can do about that - so stores have advantages, you can get your applications there, you can get reviews there, people can get a feeling “Is this application addressing the needs I have for it?” If you have an image editing application, what do others say about this application? Can it deal with (whatever) JPEGs? Does it struggle with large files? …and so on.

[14:09] So these kinds of things - people believe in reviews. So there’s a lot of advantages of having apps on the app stores. And one trend that we’ve seen as people want to get their progressive web apps onto app stores - you may have heard of PWABuilder, that is a community project run by Microsoft folks, that helps with that. So native apps and progressive web apps on app stores can coexist, and they do coexist pretty well, I would say.

On the other hand, we still see a lot of lower-quality apps, that are essentially very much still web applications, websites, sometimes in the worst case that are poorly wrapped… And people leave reviews about those and say, “This is really just a website. It’s not a great app.”

I think if you go this route and say “I want to get my application alongside native applications, listed in a store”, you need to make the effort of really making an app blend in, and make it feel an app, and not like a wrapped website. So this is my sort of rambling answer to your open question.

No, that was a really good point, too. The app store is – it’s got its hooks, right? It’s a well-paved cow path for users, right? It’s the thing that they know, it’s the thing that they’re familiar with. And for me, I have this burning question of “What happened to PWAs?” In the sense that I thought PWAs were supposed to save us from this hellhole of native applications. And I say that because, quite frankly, I’m very team pro open web. Native apps are maybe slightly better for user experience, but not really great for the health of the web, specifically user privacy as well; user privacy, user data - there’s all kinds of stuff that’s not so great, So browsers being this sandboxed environment, and more kind of a trusted environment, always kind of a safer place to browse.

With that, that’s something I was thinking about, too. It’s great adding these APIs and capabilities to the browser, but just going towards what you said, Amal, the browser is a trusted place, but it’s also a place I heavily distrust, and it’s very obvious in the amount of content blockers, ad blockers, things that I add to my browser to make it more of a safe place; get rid of those cookie banners, things that. And those things - it adds a distrust, and then the first time I try and visit something that I would just obviously trust on the web, but it’s broken because of my overabundance of trying to block everything, I immediately start distrusting the platform more.

I don’t know where I’m going with that… Just to call that out is a problem. It’s a trusted place, but because there’s so much distrust among the content there, it sours everything, because I’m overly cautious about the dangerous stuff. And it can break my experience for the good stuff.

Yeah, I can maybe speak to that. So whatever happened to progressive web apps? So first, maybe, Amal, to discuss this point that you brought up… Do you remember AJAX? All uppercase AJAX. A little bit later, it became first letter uppercase, and the rest lowercase, so more of a regular word…

You mean we’re not doing asynchronous JavaScript in XML? [laughter]

Here we go.

What?! Here you are, busting dreams and facts, Tom and Nick Nisi… Some naughty…

So yeah, at some point no one talked about Ajax anymore. It just had become the way we build single-page applications. And the same goes with HTML 5. Do you remember HTML 5 and CSS 3? All these logos that we put on our conference slides… Nowadays everyone does GTML 5 apps. Or do we do HTML 6 apps now? Or I don’t know… So we just stopped talking about this…

I still remember my very long DOCTYPE…

[18:03] [laughs] And a little bit the same is happening with - if I could just continue with this… The same is happening with progressive web apps these days. So people build progressive web apps of sorts, but I’m like “Is it a P, progressive web app, if it’s, not installable? Or is it just a web app?” What about the just? Do we need the just? Is it a web app? Is it just an app? Is it good?

If you go to GitHub and you browse any kind of random repository, and you press the period key on your keyboard, the dot, it all just of a sudden launches a full-blown code editor? Is that a progressive web app, or is that a web app, or is that an app, or whatever is it? In many cases, it’s not distinguishable from VS Code as a native application that you download and run, but it’s an Electron app. It’s not distinguishable, in many cases.

So these kinds of experiences where we just become used to using apps in a browser without really realizing that we’re using a progressive web app, or a web app, or an app… So what I’m getting to is maybe progressive web apps have just succeeded because we’ve built them and don’t really think about it anymore. So that’s that.

Nick, for your point about cookie banners and all these horrible things… I guess what we’re seeing as people just being really careful on the web - because in many cases, all these cookie banners, or some of these cookie banners wouldn’t have to be. People just put them up just in case, to not get sued. Native applications, I think - and I’m not a lawyer, but in many cases, there would have to be some sort of GDPR notices as well, but people just don’t put them up, because it’s just so hard to inspect what a native app does compared to what a web application does. So a lot of the things that native applications do, and spy on us, and sync periodically with whatever server while we’re sleeping, and these kinds of horrible things - they’re happening, but we don’t really see what’s going on there.

That’s a great point.

Yeah. So on the web, people can inspect and can see what’s going on, and… It’s just so easy to get in this unfair comparison between the two platforms. I’m a web person, so I’m very much biased, but at the same time, I’m trying to understand what is going on on native as well, and they’re doing horrible things as well. And the web does horrible things…

Oh, for sure. The web is not innocent, by all means. I agree.

Yeah. It’s more out of sight for the native ones, but you’re absolutely correct.

It is, for sure, yeah. So we are here to fix both, hopefully. So if you talk to people from the Android dev del team, they will tell you “Look, a lot of Android apps do horrible things”, and Android as a platform is also getting stricter about what apps can do in the background, and so on… So there’s some development happening there as well. Google has the privacy sandbox for the web, but now there’s a privacy sandbox for Android as well.

So what I’m getting at - this is a general movement. Apps in general becoming more privacy-aware, privacy-sensitive, information not being shared in the background, and so on… So there’s a lot of development going on there.

Yeah, that’s a great answer, Tom, and a very, I’d say, scientific and diplomatic answer as well. I like your kind of “Innocent until proven guilty” stance for examining these types of issues. I’m just kind of like “Guilty!” But yeah, so we have so much to get into, and so much to unpack, so we’ll be right back after these short messages.

Alright, Tom, we’re back. So exciting to be talking about this topic, finally… Because for me, Fugu feels like the browsers kind of breaking free. It’s got legs now; this kind of traditional idea of the sandbox browser that can’t access file system, and can’t talk to the Bluetooth, and “Oh, we don’t know–” Connecting with sensors, and all these little things, you have to go through hoops, and… Right? This idea of your browser being limited, and consequently, JavaScript apps also being limited - this is just kind of shattered now, because Fugu is just like “Nope, the web can do that. Nope, the web can do that. Oh, the web can also do that.” Right? So can you tell us about – let’s just walk through what you think are the shining stars of the Fugu project, especially the ones that are gaining a lot of traction. I would love to start with your first hit, Tom. What’s your number one?

So when it comes to apps, definitely my number one app example is still Photoshop on the web. They launched it, they made it made it happen. What I want to call out about this - in the early days, when this really just launched, people were like “Oh wow, they brought Photoshop to the web.” And then of course, haters were quick to point out “Yeah, you open this in Firefox and in Safari and it doesn’t work at all.” But - and this is where the but comes in - Adobe from the very start said “Look, we’re working super-hard with Mozilla and with Apple to make Photoshop on the web happen on the web, and not just on Chrome.” They put out the version on Chrome first, because Chrome was the first to implement the APIs and get them ready, but if you went to the Photoshop website, on Safari, on day one, you were just greeted with this message of “Hey, you’re not using a supported browser.” The classic Chrome-only thing. But if you do the same today, you can open files in read-only mode, and you can see the application Chrome is there, in the sense of the UI is there; it’s just read only at the moment. But the message that they say at top is “This is not working yet. We’re working with Apple and Mozilla to get these APIs into the browsers.”

And there’s a double negation in this tweet that Shawn [unintelligible 00:25:40.07] sent. So Shawn works on Adobe, and he said “There’s not a single API that we’re working on that is not on the standards track.” So what he’s saying is every API they need in their application is on a standards track. It’s just not implemented yet. So I think this is very important. If you are a big company, like Adobe, of course you have a lot of say when it comes to talking to Apple and talking to Mozilla, but I think the same can be sort of leveraged for companies of all sizes. If you’re not a big company Adobe, you can still, in some; if you’re a lot of small companies and you talk to these other vendors, and you say, “Hey, we have this application it’s working fine in Chrome, and we don’t want to tell our Firefox users to download Chrome; we want them to continue using their browser of choice, but we’re needing this and this and this API. It’s not implemented yet, or maybe it’s buggy, or whatever…”

[26:35] So talking to browser vendors, and bringing forward use cases that you want to cover, and making sure that you communicate well why these APIs are needed can be a recipe for success. And we’ve seen it with Adobe, which acknowledgedly, as I said, is a big company name. But so, in the sum, a lot of smaller companies can add up and they can get the same pressure on other browser vendors to implement APIs.

I’m not saying this is a recipe for universal success. We’ve very clearly heard for example Apple say (I don’t know) WebUSB is an API that they probably won’t support, ever. Maybe they will in the future. Who knows? If we bring forward the right use cases, maybe there’s a change in how security on the web is handled.

There’s a lot of debate also when it comes to APIs on the web. What is the right way to ask for permission? Do people understand when you ask for permission? Is there a way to communicate really all the ways an API could be abused potentially in a small permission prompt? What is the right way there? And I think this is also a way for browser vendors to just innovate and say “We are Firefox, and we’re going [unintelligible 00:27:40.22] way that is different from all other vendors.”

For example, very recently Firefox supported or started supporting Web MIDI. The way they do this now, if I understand the concept correctly, is they sort of build an ad-hoc extension that they can then block and say “If we see that the API is being abused, we have an escape hatch”, and they can just sort of I think revoke the ad-hoc extension that was created. I might be misrepresenting the idea, but… The core idea is they innovate on the way the permission prompt is being shown by introducing a different vendor-specific way of doing so. And yeah, maybe this is the recipe for success for getting more obscure, and maybe more powerful APIs onto the platforms.

You said you worked through standards… I was curious, is that WATWG, or what kind of standards process do these APIs go through? Or does it vary?

We start in the WICG, the Web Incubator Community Group. But then once we have incubated, of course, the final objective is to move on to the W3C, the full standards track, where we go through all the different stages… And I just prepared a couple of APIs, and I’m reading them out now, that started on the WICG, but that are now on the W3C. So there’s the Web Share API, there’s Web Transport, there’s the Filesystem Living Standard, there’s Web Codecs, there’s Clipboard API and Events, there’s the Multi-screen Window Placement API… So these are just a couple of examples of APIs that started in the WICG and that then migrated over to the W3C.

Yeah, that’s a great question, Nick… Because you really said a lot there, Tom, and I just kind of want to break things down for our listeners. There’s this idea of standards adoption. We can create a standard, we can agree on how to implement thing A, but if thing A doesn’t get implemented across all browsers, it is kind of is useless to developers, right? To some degree. And so Apple has been – and I know you probably can’t say this, or maybe you can, I don’t know, but either way… I’ll say it; I don’t work for Google, right? So Apple has been a tough player to bring to the table. They’ve really been a hard player to get to adopt a lot of the APIs that supported progressive web apps, and all those other things. And they finally are there. And I think the story that you’re telling, of Adobe successfully launching Photoshop, that works really almost like a progressive web app, because it’s like, it works more fully and richly on Chrome and/or browsers that have adopted the APIs that they support…

[30:19] But this idea of actually having a huge vendor and a huge player like Adobe say “Hey, we’ve implemented this, and we’re going to just tell our users we’re working with Apple to get this working in Safari”, it really flips the script. I love this “Let’s be transparent, and let’s just be honest, and let’s implement stuff, and let’s tell users – it’s not that this doesn’t work, it’s just that hey, this hasn’t been implemented in Safari yet.” If I was a business where my name was on a banner for a very popular website, saying that like “Oh, this doesn’t work on your site”, I would be like “What? What?! No…”

So I think that’s genius, so really, kudos to the Adobe team and the product team that was able to make bold bets and bet on the web, really… Because really, that’s what the product team is doing. They’re like “Okay, we’re gonna take a chance. We’re going to be the first.” Nobody ever wants to be the first. Everybody – trust me, there are so many 10-year overnight successes, right? Projects like Fugu, that have been in the works for years, and you’re finally starting to see the fruits of this… So kudos to that team.

So Tom, let’s get into what makes Photoshop successful. So what specific APIs are they using that are really showing off the power of these new APIs? So filesystem access is one, I guess, but… The floor is yours.

Yeah. So in Photoshop, it of course heavily depends on a decades-old codebase that they’ve taken and translated, or transpiled to WebAssembly using Emscripten. And in Emscripten, there’s different ways of making applications happen. For example, in Emscripten they added SIMD support, so that you can have single instruction, multiple data, so essentially get more things done in parallel. They have pthread support, so you can do stuff in background threads, and so on.

So, Emscripten is a very, very big topic, WebAssembly is a very big topic… I’m not an expert in any of these, but what I have more insight into is the way Photoshop works is they have sort of a big swap file. So in Photoshop, you can open very, very big files, that can reach gigabytes, sometimes. The way this works is they have internally in Photoshop sort of a swap file, where they just randomly can access memory and write data and read data in parallel also, into this file and from this file… And this primitive just didn’t exist on the web. So what Chrome has built for them and what is now being standardized, and what other vendors like Mozilla and Safari implement now as well is the so-called origin private file system, which allows files to be created that are, as the name suggests, private to the origin, like photoshop.adobe.com, for example, that only live in the context of this application, and they have certain performance guarantees. You can write very performantly into them, and read performantly into them… You don’t have to wait for rights to be confirmed, which makes writing a lot faster… So all of these things, if you think web as well, there’s a big problem, if you will; we call it the mark of the web. So if you download a file from the web, before you can execute it or open it, you get this warning which tells you “Hey, this has come from the web” and so on. There’s safe browsing checks that need to happen, and of course, all of these checks take time.

Within the OPFS, origin private file system, these checks don’t need to happen, because technically, they are files that are not really exposed to the user. So they live inside of – somewhere hidden in your browser. Technically, they don’t even have to be files; they could be implemented as, for example, entries in a database. They just behave and feel to the developer like files. And I think this is the core thing here - the actual storage is an implementation detail that you as a developer don’t have to know. And yeah, this makes working with these files so nice, because to you as a developer, it just feels like “Hey, I’m opening a file, I’m writing into it, I’m streaming data into it”, or whatever. So the look and feel is like a file, but then everything else, the other problems with files that you have on the web, you don’t have to be concerned about.

[34:29] Yeah, that’s super cool, Tom. I feel like my head is a little, like – I haven’t been following this specific spec, so hearing where it is now, I’m like “Whaat? What are we doing now?” That’s intense. Also, that sounds powerful. Also, we had Debbie O’Brien on the show last week, we were talking about Playwright and we were pressed on time; I was really trying to avoid tangents, and I would say the same exact situation here - there are so many tangents… I feel we could have an entire podcast on all the things Amal did not say. I will take a really quick tangent for our listeners, because I think this one is an important context I want to set for y’all. So there’s this concept of origin trials within Chrome, and it’s like a fantastic concept. Tom, could you explain what that is to our listeners?

So origin trials allows you to test new APIs with actual users. Why do we have this? So in the beginning, you might remember that the early WebKit-something prefixed APIs. The idea there was we agree this is not an API that is standardized yet, it’s an early test maybe… So vendors thought, “Well, it’s a clever idea to just prefix these APIs.” The problem then is, because these features were in many cases very attractive, developers started using it, and depending on it… Which then ironically caused vendors like Firefox to implement things that are prefixed with WebKit, just to be supporting all these use cases that developers had built. So learning from this, we’re baking stuff into the web platform that then might just become baked in forever, and with no way to get back, origin trials was introduced as a safe way of playing with things that are in incubation still. So you could then just include a meta tag on your site, and if you have this meta tag on the site, the browser would detect it, and then sort of unlock the API in question, so it’s encoded in the meta tag token somehow what API is visible then, if you have the token. And each token is also limited to a certain amount of time. So first, you need to renew your token, so that you really make sure that your web application stays up to date. So maybe there’s been changes in the API, so if you change your token, you also need to change your code, as it will stop working… But then in the end, of course, it’s also important to not bake these maybe not mature yet APIs into the browser.

So every origin trail is also just time-boxed, where we say “It’s supported from milestone X to milestone Y.” And once milestone Y is over, either we just say, “Okay, the feature didn’t work out. It’s something that will be maybe iterated again upon”, or we say “It’s been a success, we can use it now.”

More recently, on the Chrome team we introduced the concept of so-called gapless origin trials, which means the origin trial would go straight into a feature that you could use in production. So this allows really to, if we have agreement on how an API shape should look like, that then the continuation would be there. You could start from the early days, go along the origin trial, and then take your user straight into prod. So that’s the idea here.

Yeah, thank you for that awesome summary. I didn’t know that we had gapless now. That’s great. So the idea is we have this website called “Nick’s beloved typescript.org.” Somebody should buy that domain if it doesn’t exist, and gift it to Nick… So “Nick’s beloved typescript.org” wants to use some API that isn’t standardized yet, but that’s implemented in Chrome specifically… So it’s like, do we put a set of instructions that’s like “User, go to your settings. Enable this flag”? No, we’re not going to do that. Right? So how do we just automagically make it work for our users? So you go to Chrome, you sign up for an origin trial, you give them your domain, and you get approved, and then it automatically just works for your users. It’s basically a feature flag, but for web APIs that’s specific to Chrome. And it’s awesome.

[38:28] That you control, rather than the user, which is really –

Exactly. That you control, rather than the user. Exactly. For better or worse, right? So make good decisions for your users…

And I’m gonna just call out quickly, Firefox has the same concept also.

Oh, of course. That’s awesome.

Very recently I’ve participated in the OffscreenCanvas origin trial, and Edge - so Edge, the Chromium-based Edge, they also use origin trials now. So it’s a concept that I think people like in general, because of all the advantages that I just listed… So yeah.

Yeah. It makes sense. So now that we know what origin trials are, let’s go back to the File System API. So the File System API was not initially on the standards track. It is now, obviously; it’s been for a while… But were origin trials kind of part of the story here for being able to actually experiment in the wild on this feature? I’m curious where the teams like the Photoshop team use an origin trial initially…? Or are they using origin trials? These are all open questions, Tom. I don’t know the answers. Tell me.

So we need to be a little bit careful here… So when you say File System API - there has been definitely more than one.

Okay…

There has been something like the File System Entries API, or something that… So there have been several attempts, also add standardizing; not just proprietary stuff, but really standardizing file system access on the web…

Oh, wow…

What we can talk about specifically now in the context of Adobe - this is the origin private file system part, and more specifically there, the access handles; so the thing that gives you access to these files that are private to the origin. And there is, or has been an origin trial that Adobe has been taking part of. So they went through this entire process of breaking changes, that from one origin trial version to the other they needed to implement, and so on. So now, the origin trial is – I think it’s over, but… Yeah, definitely, there’s the API that is agreed on universally now, it’s being standardized in a living standard… It’s called the File System; I think is just a standard name.

Important to say is, if you talk about file system access, there’s the File System Access API, that has the so-called picker methods: showOpenFilePicker(), showSaveFilePicker(), and so on. So this is not that. So the file system part that is being standardized now is first how do we work with files in general, as like the file methods - to rename a file, to move a file, to delete a file, to create a file in the first place, to write to a file, and so on. So this is being standardized. The way you can create a file is in the origin private file system, or by using the picker methods. And the picker methods - those are more powerful APIs, and this is also where we still have some disagreement on - like I said, it allows you to open files from your local file system. And as I mentioned before, on the local file system, the user visible files, you have all these problems, like what about ransomware attacks where someone just gets access to your whatever projects folder, and then encrypts everything, so they want to get some ransom from you to decrypt again your files, and so on. So it’s a little bit more interesting when it comes to those picker methods. The other part, this is whether you have universal browser agreement on.

Yeah, and thank you. And like I said, I have not been following this spec, and it’s so interesting to learn from you that it’s diverged into all of these different things… Which makes sense, right? There’s been limitations that have been found. So instead of throwing the baby out with the bathwater, let’s focus on this one narrow part of the spec, and let’s get this one narrow part right. And I love that approach. This is why standards work is – I think I’ve said the word “God’s work” already in this podcast. I’m gonna say it again. It is God’s work. It’s amazing. Hard work. So yeah, so lots to continue to unpack… We’ll be right back, everyone.

So first off, I love the naming Project Fugu. It reminds me of that Simpsons episode, the Fugu Fish… Fan Fugu Tastic! Is there a place, like a consolidated place where we can find out more about what all is going down with Project Fugu, and the different APIs that are being experimented with, and the status of them, and all of that?

Yeah, sure. We have two places. So there’s the Fugu API Tracker, that allows people to just see in the open what APIs are we working on, what is in our pipeline, what features are we implementing, and just working on. And there is the Fugu API Showcase, where we show people who have been building applications, and you can go and see, just get inspiration what people have been building with these APIs; you can filter by API, and you can see “I want to get a list of all the apps people have built with, I don’t know, the Local Font Access API, or the File System Access API”, or whatever. So you can just filter by API, you can search by app name, if you know a specific app and you want to see what APIs is a specific app using… So the Showcase is really your destination for this kind of question.

So if you want to just get inspiration, just purely browsing the API Showcase, launching the applications, testing, and playing with them, it definitely helps. In many cases, there’s even source code links. So you can go there and see “How did they do it? How did they implement Local Font Access in whatever application. So you can see and get a feel for the code as well.

I was just going to call that out. I was looking at the showcase and seeing the links to not only try the apps, but also view the source code. That’s so helpful in being able to mimic what they’re doing, or get an idea of how to approach using the API, which is so, so helpful.

Very much so, yeah. I think we’ve maybe got time for one more API. I feel every single API really requires its own dedicated show. So this is really just kind of a brief overview, ladies and gentlemen, a brief overview. Very brief; brief with a small b. So Tom, what’s another favorite API of yours that you’re like “This one should be it”? Regardless of what stage it’s in. Let’s just take the shackles off the standards process a little bit. What are you most excited about?

You know what, I’m going to cheat. I’m going to mention two.

Okay, cheat. Give us two.

So first, I want to mention the clipboard API.

Oh, yes.

The way working with a clipboard works is very interesting actually, because if you think about clipboard interactions, you can go to the macOS Finder and copy a file and paste it. So then you paste a file. You can go into Photoshop and select everything and copy it, and then you have an image on your clipboard, and you can paste that image file, in the sense of you paste the image data.

If you think “I’m going to a website and selecting everything”, and then you paste it into let’s say Word, and you will see that you have pasted sort of HTML that then magically got translated into whatever word things should be the best representation of this HTML content… So preserving, for example, the semantic information that something is a headline, headline one or so, would be translated into heading level one in Word. But then if you press this magic keyboard shortcut, which is Command+Shift+V on a Mac, you will paste text only. So you’re sort of losing this information, and just pasting the text.

[47:59] This is pretty powerful as a concept, because with a clipboard API, you can do the same thing now. You can put different representations of the same content onto the clipboard. So if you’re building an application that edits SVG files, for example, you can put the image data on the clipboard, but at the same time, you can also put the source code, because it’s XML-based, so it’s all readable; you can put the source code on the clipboard, and then depending on the application context, if you paste into VS Code, you can paste the source code, and if you paste into something Adobe Illustrator, you can paste the image data; you can do the same thing there on the clipboard. And the way it works is super, super-simple. If you look at the code, it’s just essentially creating different blocks of different MIME types, and putting them on to the clipboard.

So that’s my first API that I really, really, really love. The second one is File Handling. So it allows registered applications and progressive web applications, applications, web applications, whatever, to register themselves as a file handler… Which means if you have an example application that deals with .example files, you can say, “Hey, my PWA can become the file handler for .example files.” Which means if people have a .example file in their file explorer, Windows Explorer, or macOS finder, or whatever, they can just double click, and the PWA will open. Very, very powerful concept. And what I like most about it is it feels so natural. So once you’ve gotten used to it, you don’t think anymore, “Is it a .exe file and Word opens? Or is it a .example file and the example app opens?” And if it’s well made, you can, in many cases, not even spot a difference between a native application and a web application. Sort of what we said in the beginning, and we’re sort of back to there… If you build something that is well integrated into the operating system, people think of your applications like apps, and that’s what you want to be at. So that’s a point you want to be at.

People don’t think, or should not have to think about “How is something implemented?” Especially not users. They should just be using your app and be like “Oh, wow, this is so cool for (I don’t know) editing my video files, or adding my .example files”, or whatever.

So I think this is where you want to get at. People should be using your app without really thinking it’s a web app. It’s just something that fulfills their use cases, covers their use cases well.

That’s so important too, because you’re covering these minute things that users really wouldn’t think about, right? And probably when you’re implementing this, you don’t think about it too much. But when you click on something, you want it to open in the app that you would expect. And that just gives it so much more of a native feel that it starts to become indistinguishable. So bravo on focusing on these little things that really add up to the expected user experience, which is so important for adoption.

It’s that polish, right? And it’s all this invisible work, like you’re saying, Nick… It’s all the stuff that you – this is how you think it should work, but actually, in order to get it to work in the way that you think it should work, there’s actually a lot of gaps that needs to be filled. That’s just not the way it was designed to work, right? And it’s this example, Tom, that you shared, of copy-pasting text with header texts, and things with bullets, and just being able to copy-paste that seamlessly throughout different applications, and Windows, and whatever else… You think that that should just work, right? Like, “Oh, what do you mean? Text is text. Isn’t there a standard?” No, it’s not. Actually, text is really, really complicated, and blah, blah, blah, blah, blah.

So… Amazing to hear that. I think that’s also to highlight – going back to Nick’s point, this idea of “It should just work this way”, I think that’s one of the reasons why standards take as long as they do. People don’t realize just how things don’t actually work the way you think they do, basically. I’m glad that we’re doing that hard work.

[51:54] This may be is a nice tangent as well, a very quick tangent… File handling, as I said, is for installable applications that they can register themselves to become a file handler. But at the same time, if a browser doesn’t have a concept of installation to begin with, so for example, Safari, for example, Firefox - they don’t have proper installation on desktop. So on mobile, you can add applications to the homescreen in Safari… But if you don’t have this concept of installation, if you don’t have this concept of file handling, you can still build the same amazing Progressive Web App, and people can still use your application in a tab, and be very happy users. And if you have a browser that supports installation, if you have a browser that supports file handling, you can add these additional features… But in many cases - yeah, they are a progressive enhancement; they will make the experience better, but you can still live and use the application without. And I think this is a very important concept to take home with - progressive enhancement, in many full API cases, is very important, and once a browser then eventually maybe starts supporting a certain feature, your app will just magically work.

We’ve been using progressive enhancement for a long, long time, but the idea is still fresh, and maybe even fresher than ever, thinking just about something like WebCodecs, that allows you to do video and image and audio coding codecs stuff in the browser as a progressive enhancement; you can do it as a fallback on the server, and if you have a browser that is capable of WebCodecs, you can just do it on the client. So I think this is where we can go to.

That’s amazing, Tom. And it’s very hopeful to hear about all of the work that’s happening, and all of the supercharged superpowers that are going to continue evolving, and continue being added to the web. It’s really – as somebody who deeply cares about this platform, I could not be more delighted to learn about all of this. I would say that it’d be great – I don’t know if the Fugu showcase site has a list of “Here’s all the things a native app can do, and here’s all the things you still can’t do in the on the web, and here’s where we are, here’s how we’re doing. Here’s how we stack up.” I don’t know if there’s a stack rack comparison… But we’ll have to discuss that maybe with Alex on another show, because that’s all we’ve got time for today… But it’s been an absolute pleasure to have you on the show, Tom. Thank you so much for enlightening us, and I hope our listeners are inspired by all the really great things that are coming to the web, that are on the web in some browsers already… It’s really been very exciting to learn, so thank you, Tom.

Yeah, thank you.

Thanks for having me. It’s been an honor.

Yeah. Been an honor. So where can folks connect with you, and learn more about you, and all of that jazz?

I’m tomayac on most places on the internet, so you can find me on Twitter still, but also on Mastodon I’m toot.cafe/@tomayac if you want to reach out there… But yeah, if you just search for Thomas Steiner on Google, you will find me. I’m pretty searchable on the web.

Yeah, I would expect nothing less than for you to be googleable. [laughter] Alright, everyone, it’s been an awesome show. Thank you. We’ll be back next week. Take care, everyone. Bye!

Thank you very much. Bye-bye!