Alex Russell: Sure. So my name is Alex Russell. I’m a product manager, I guess, now, on the Edge team at Microsoft, and I’ve been working on browsers for 14 years, something like that. I joined the Chrome team before 1.0. But prior to that, I’d spent something like a decade building extremely large JavaScript applications, often for folks who had real problems. So I was the lead for the Dojo toolkit project, which was the conglomeration of a bunch of other sort of proto DHTML libraries back in the early 2000s… And that became kind of the corporate standard for IBM. We used those tools to build things like business intelligence dashboards, Ajax business intelligence dashboards for folks like Informatica; we built entire PIM suites out of it, helped Sun build stuff… I think some of those systems are still running. For a bunch of years, they were – the AOL email client was based on our technology, calendaring, chat, email, the whole thing.

So around the same time, a lot of my friends in the early kind of proto JavaScript days had been getting hired by Google, and eventually they pulled me in, and so then I spent the next 14 years or so working on browsers, but specifically the web platform. So I helped lead projects that developed various aspects of ES6, things like arrow functions and classes, promises, async and await… We developed at the same time what became web components… We’ve prototyped a bunch of new things in CSS that unfortunately had to wait a much longer time to make it into the world… And then from there, develop PWA’s and service workers, and helped lead the team that did push notifications, and then we did project Fugu, where we’ve been expanding the power of the platform to do things like serial, and HID, and USB, and Bluetooth, and NFC, and access to low-level camera stuff, web transports, web codecs… Oh, and I spent about a decade on TC39 in the middle there, and then ran standards for the Chrome team.

So these days, I spend about half my time working directly with Microsoft’s largest web products. And before that, since 2015 or so, I’ve spent a ton of time doing this kind of incidental consulting with people who are building PWAs. Not because I want to care about performance. In fact, I actually kind of don’t want to think about it; it’s just that whenever we sit down to work with teams, trying to figure out what hurts, that’s always at the very front of the list, whether or not the team knows it. And that’s been extremely depressing, kind of Groundhog Day thing, since about 2015.

I remember we’d sit down before every Google I/O, or for every Chrome Dev Summit, with a set of teams that we wanted to highlight their incredible work on a product, working with these incredibly smart engineers, and they will have built it out of the new hotness in JavaScript land, and it will perform like absolute dog***t. Just not okay. Just absolutely not okay. And so then it turns into this remediation process.

[08:07] These are - and I cannot stress this enough; these are not bad engineers. These are people whose houses that they’ve constructed are extremely flammable, not because they didn’t know how to join the corners, and put up joists, but because the materials that they were sold were not fit for purpose. So a lot of things ended up in their hands…

And so then we would sit down… And a lot of this work turned into sort of more incidental consulting. And again, I can’t stress enough - performance is just the first thing on the way to getting to where we really wanted to go, which is to say, “Okay, have you tried out these cool, new APIs we’re trying to make the web more powerful with? We want to like help you learn about what you need, and then identify the next set of problems.” Because that kind of consulting, that collaboration is how – if you’re a platform maker, you can go around and like you could give everyone a survey and say, “What do you need?”, and you’ll probably get a bunch of answers that are just like “Please make me a faster horse.” And the only way that you really learn about what people actually need for their products is to go sit with them.

So it was an attempt, and it’s a continued attempt to try to learn directly from people building products about what’s hurting most, so that we can go and like add those things to the platform. But this performance thing is just this constant irritant. It’s an ankle-biter at every moment. We just can’t seem to get past it… So here we are. Yet another team at work was extremely let down by a bunch of tools that have been sold to them on scalability, and the only way that those tools scaled was directly downwards, like a lead balloon. And it’s not the team’s fault. They are extremely strong engineers; extremely strong engineers. I can’t stress this enough. I work with great people. I’ve been lucky enough to work with like more than 100 organizations over the last eight years… They’re filled to the gills with good engineers who have been absolutely let down.

Jerod Santo: I just feel like we built this house of cards, and then we took a bunch of popsicle sticks, and we’re trying to frame it up around the outsides with the popsicle sticks, and TypeScript is the popsicle sticks. And that just leads us to one last thing to say… [Christopher Hiller] “JavaScript should be destroyed!” As always, Chris gets the last word… And we really can’t top that.

This has been JS Party. All the links to all the things are in your show notes. If you haven’t subscribed yet - hey, maybe consider subscribing. We’ve got some really cool episodes coming down the pipeline. Docusaurus is coming up, we have Kevin Powell, the great CSS-based YouTuber coming on the show… A couple of book authors, Martine Dowden and Michael Gearon talking about tinycss projects… We’ve got Thomas Steiner coming on, talking project FUGU from Google… So lots of interesting guests. And of course, we always mix in fun and roundtable discussions, or whatever this one was… We mix these kind of ones in as well throughout. So subscribe to the pod if you haven’t yet, and that’s all. Any final words from you guys? I guess I said Chris gets the final word, but then I happened to open it back up again. Move quickly…

Eric Simons: Yeah, I think to start we’re pretty focused on the development aspects, because the benefits are pretty immense, for the reasons you outlined. Setting up local environments is a pain for experiences devs and a huge barrier to entry for people who are entering the market. So being able to have this stuff open in a tab – I mean, companies spend weeks having developers get onboarded to a codebase. The idea of being able to crack-open a browser tab and be able to commit code on your first day at a giant Fortune 500 company is pretty wild, right?

But I think there’s an interesting future here though that you’re pointing out… And this is what the Chrome team is doing with their Fugu initiative - can web apps replace desktop apps that are currently using Electron? And the answer is increasingly becoming like “Yeah, they can.” But they do lack right now some of the APIs and developer experience that you would need for some of these things… And so we’re kind of interested in seeing “Could this be something that other developers could use to ship desktop-grade applications in the browser?”

Amal Hussein: Yeah. I have to echo – a couple shout-outs to some web APIs that I think have helped smooth the link communication in mobile apps… The Web Share API - I don’t know if y’all are familiar or remember it. It’s not that old. Essentially, it’s a way for you to share information, with anything, from your phone. So you can actually implement it, which is really nice. It works beautifully on Android and iOS. But I think for me the walled gardens, like the areas where you’re interacting with the web through a device that’s perhaps owned by a proprietary company, and the company has interests in you using their app store… I feel like the web has had a really tough battle, both with devices getting smaller and faster, and better to use, and the long arc of the web - how long it takes for things to get updated etc. Not all websites really caught up with it, so you don’t have this graceful, beautiful, out-of-the-box experience.

So there’s just so many uphill battles that I’ve seen for the web. We’re still very much in the thick of it, specifically also for new internet users, like folks coming online for the first time. There’s millions of people in Brazil and in India coming online for the first time every year, and they’re kind of learning about the internet through apps. And when I say apps, I mean native apps that come pre-installed on their low-end devices. And I can say the same thing about my younger siblings, that are much younger than me.

[12:17] So the web has a lot of catch-up to do, I would say, in certain areas… But obviously, if you take the accessibility of the web and you kind of supercharge it with the powers of native apps, that’s what you’re supposed to get with progressive web apps, and potentially projects like FUGU from Chrome.

Amal Hussein: Exactly. So it’s interesting to see how this is – history may be repeating itself in an interesting way… But IE – and I’ve had this conversation with Alex Russell, whose Twitter account we will link in the show notes, because he’s a very interesting person to follow if you’re into this stuff… Alex is actually the technical lead for the Fugu Project at Chrome, and I remember asking him “Alex, I don’t get it though… You’re basically becoming IE again now.” And he’s like “Well, think about it - is that a bad thing?” He’s like “IE was so good at what they did that they’re still relevant today”, right?