In 2020, Shawn (swyx) Wang wrote:
We’re now in year three of this third age and Swyx joins us to look back at what he missed, look around at what’s happening today, and look forward at what might be coming next.
Sentry – Working code means happy customers. That’s exactly why teams choose Sentry. From error tracking to performance monitoring, Sentry helps teams see what actually matters, resolve problems quicker, and learn continuously about their applications - from the frontend to the backend. Use the code
PARTYTIME and get the team plan free for three months.
Vercel – Vercel combines the best developer experience with an obsessive focus on end-user performance. Our platform enables frontend teams to do their best work. Unlock a better frontend workflow today.
Sourcegraph – Move fast, even in big codebases. Sourcegraph is universal code search for every developer and team. Easily search across all the code that matters to you and your organization: find example code, explore and read code, debug issues, and more. Head to info.sourcegraph.com/changelog and click the button “Try Sourcegraph now” to get started.
- swyx’s talk at Reactathon
- Lydia Hallie’s talk on rendering patterns
- The Rise of WebAssembly (Infoworld)
- swyx on The Changelog #467
Click here to listen along while you enjoy the transcript. 🎧
Hello, hello, JS Party animals. It’s me, your internet friend. It’s Jerod, and I am joined today by Nick Nisi. What’s up, Nick?
Hoy-hoy. How’s it’s going?
It’s going quite well, how are you doing?
Are you ever not excited? That’s the real question.
Maybe you would have gotten even more excited.
Contain yourself, contain yourself. We have a special guest, a return guest… It’s Swyx. What’s up, man?
…is what Nick says. I’ve never said such a thing… But to each their own.
Not to foreshadow or anything, but I can’t wait to talk about your talk, i.e. move away from TypeScript…
It’s a little bit clickbaity, but we can talk about that.
And Jeremy Ashkenas.
The part about collapsing layers is really just about understanding our tools. So my favorite way to tell this story is to tell the story of Microsoft Word, the word processor. When the original word processors came out, you had to buy add-ons for horizontal layout, for page count…
For word count as well. Each individual little thing. Because they weren’t viewed as part of the core job of a word processor. But as we grew it in our usage, what was table stakes for a word processor started to grow, so you started to see the platform absorb all those functionality as part of its core, and now you would not imagine a standard word processor not shipping with one of those features.
So that was the original thesis in 2020. So the talk that I did - it’s been three years (2020, 2021, 2022) since. The talk that I did basically covered what I missed in the original blog post… But I’ll stop there, just to get any reactions.
I really like the break-up of that… Like, ten years of different cycles. And there’s a lot of patterns that you can read into each of those cycles that kind of repeat in the subsequent year. I guess we only have two really to go on, since we’re in the third one now… But you know, from 1999 to 2009, about halfway through that you had major things come out, like jQuery, which is still very prominent today, despite us trying to ignore it… Not on purpose. You know, we just don’t realize how prominent it still is.
I feel like you know something, Nick… Do you know something that we don’t know?
Let me introduce my new project… No.
[laughs] “Let me introduce my new project.”
Yeah, so just from there you can see distinct patterns that are emerging, in terms of what innovations – there’s a theme around the types of innovations that are happening throughout each age.
Yeah, totally. So I like to not just be playing number patterns… It’s not enough for me to say “Okay, this seems to have a cycle, or this seems to have patterns…” I wanna have some reason behind why they’re happening, a hypothesis… And that’s why I talked about the changing of the guard. I think it’s just people coming on the scene, taking what exists as a given, and then saying “Alright, what can I build with this?” They wanna make a name for themselves, and then they go ahead and do what they can do. So that’s what you’re seeing here, you’re seeing the movement of people trying to make their careers.
It’s just something I’ve decided not to cover. I don’t know as much about it. CSS has its own complicated evolution… I think the decision of the CSS Working Group to split into separate modules for independent advancement was positive for the participants of the CSS Working Group. But on the marketing side, no one knows what they can use. [laughs]
So about a couple years ago there actually was a movement for a CSS 4 as a pure marketing exercise of saying “Everyone, this is the set of features that we have collectively agreed that is now kosher to use, and you should use them, because they’re just so much better than their predecessors.” It’s not clear. You have to kind of pick it up through trade knowledge, or whatever.
In practice, yeah.
Right. So actually, having version numbers is a really good forcing function for everyone saying “Alright, am I in CSS 4? Let’s look at what’s in CSS 4.” And it gathers people around that. Right now, CSS Working Group - we have to go into “Alright, are we on the layout spec, the Flexbox spec version 2. And what’s in version 2 versus version 3?” It’s just a much more complicated story, that nobody has time to get into.
Yeah, it’s once a year. Yeah.
I see. So you just let Microsoft bless your versions for you…
If it works, it works
Exactly. But that is true about CSS. I see all the time – I think I follow a Twitter account called @randommdn. It just gives you random MDB pages to peruse and look at… And some of them are CSS things, and I’m just like “Oh, that’s cool”, but I have no concept of when or how I could use that today.
As we record this, I still have 34 more days of IE11 support, so… Yeah. There’s a lot of things that I can’t use.
Not that anybody is counting…
It’s dying. So the fun fact is that originally I tried to get a hard date on when IE officially dies, and apparently, people can pay for extended support, so it really depends on what your definition of –
Shh… Don’t tell anybody.
Yeah, so first of all, what you describe there some people call digital gardening, and Maggie Appleton has a really good history of the digital gardening movement. And I think it’s nice. Basically, don’t let good ideas go stale.
Real quick before you dive in… I think the answer is gonna be no, because you write prolifically… But for me, that concept would make me not want to write as much; because every time I write, it’s just another thing to maintain for the rest of my life. Do you ever think about it like that?
Well, no – like, you can set expectations. I have a digital garden terms of service, I might say…
…that says like “This is a tool for thought. This is me thinking out loud, and I don’t have to return to it to update it.” But you know, I’ll make it pretty clear when that piece was relevant, and if you want my updated thoughts, just hit me up.
Oh, fair enough. I like that.
Lower the expectations.
Yeah, I like that. Well played. See, you’ve got an answer for everything. Okay, going to the things you missed… What did you not see coming?
Right. So just to recap, the conclusion of what I foresaw or what I was calling out as the trend… I said third age tools would be faster, would be ES Modules first, would have collapsed layers, in other words one thing doing many things well, instead of many things doing one thing well. Type-safer, securer from dependency attacks. Polyglot because of the need for compiled languages… And then I also called out isomorphism, which is server-side rendering being more of a thing. That’s definitely become more true over time.
[20:11] Essentially, what I accumulated over the past three years was just updates to that. So I have a Twitter thread where I announced the original blog post, and then I just kept adding to it over time, with relevant updates.
Apart from that, the other big trend which I called out at the end of last year was the move towards monorepos. Something I didn’t really think about in the original piece, but just the fact that it’s increasingly clear that monorepos are not just for the Facebooks and Googles of the world. That even small teams have a use case for them, because they keep jumping between repos a lot… And it’s just really your tooling that hasn’t got up to the standards of being able to handle monorepos and make them easy to use… Including GitHub, by the way.
So projects like Turborepo have come up in the past couple of years, and actually got acquired by Vercel, that help you manage monorepos… But then also, of course, Nx from the Narwahl team has also been plugging away at this for a while. But Pnpm is also very monorepo-friendly, and there’s just more and more tools. Just the other day Graphite, which is a stacked diffs tool that works really well with monorepos, announced their seed funding.
So there’s basically a lot of these trends, and I was starting to get overwhelmed. I could go on, I have another piece called “Smart clients versus smart servers.” In other words, why do people try to do server-side rendering and then stream their updates down to the client… And then some other people have very smart clients that have a local cache of the database, so they can do optimistic updates and offline-first apps, and what are the trade-offs between them. Those are also trends that I’m seeing people start to talk about at the edges, and it’s being explored by the likes of React and AWS, where I used to work.
So essentially, there’s no organizing framework for all of this. It’s just like new idea, new idea, new trend, new trend. And I think the most useful thing that I could do for my readers is to give people a framework to sort all this into “Should I care about it now or not?” [laughs] And that was the main insight I had going into this talk.
So that ended up being four levels of concern. The first level is whatever you’re currently betting on, make sure that it was the right bet. So continue to validate current bets. The second level is explore incrementally-adoptable tools. Look at your current toolchain, see if any one of them can be swapped out for something that might be better in some way, whether it’s faster, or simpler, or more consolidated, anything like that. Third would be new architectures; these would require more work. You’re not just swapping out individual tools, you might be swapping entire architectures just to take advantage of something new that might have come up, whether it’s a new framework like Remix, or it’s a new state management paradigm like the smart clients, smart server thing.
I don’t know, but it’ll be interesting to watch. [laughs]
Take a guess! Take some guesses.
Where it might not work best is when developers who are mostly good at developing are being thrust a large sum of money and then told to become businesspeople, with no training.
That might be a concern. So in other words, some of these are gonna fail. And that means that the projects that they promote and maintain may be rushed in some way, or abandoned. In other words, you have more suspicion of a typical open source project than you would a standard open source project, because you don’t know if the license is gonna be changed on you, you don’t know if the core products could be crippled by features just to put a paywall in some product… Or if they just run out of funding and then they just abandon it, which can happen to typical open source as well. So nothing’s new there.
Never discount Excel.
And we’re primarily on the frontend, right? We’re the one that you see.
Yeah. Anticipating user needs as well, and documenting for those. I definitely feel like there’s more of a documentation culture in the frontend versus the backend, but in their defense, there’s more of a testing culture in the backend versus the frontend.
Sure. It’s easier there.
[27:35] Kind of related to VC funding coming in. Or kind of not… Something that I wanted to ask about was how security might shape the rest of this age, or the start of the next age? And supply chain attacks are becoming increasingly more common… And having those VC-backed – we’re getting paid to keep this up to date, to quickly fix vulnerabilities, and to kind of have that layer of support as you give over the keys to the kingdom to any Node module that you install to run on your machine or in your production server. I guess have you thought about the impact of security as this has become the most popular language in the world?
Well, first of all, I’m not the most informed person on security. Probably Feross would be a better person to talk to about this… I’m not optimistic or pessimistic. I’m just kind of neutral on it. I don’t think it’s like a focus of anyone, apart from Feross, who is the founder at socket.dev. [laughter] And his approach is “Let’s just audit everything and give you ten different reports telling you that–” And we have some of these automated audits as well. It’s not clear exactly how venture funding was gonna affect this either way. Obviously, you can have people who are paid better to maintain these repos, but supply chain attacks happen in perfectly well-funded companies as well. It’s not just like someone’s acting out in open source… Which has happened repeatedly, and just puts a Bitcoin miner in a repo, or something like that.
I think it really has to be fixed at the runtime level, or the toolchain level. Deno has an attempt at doing this by locking down the permissions. People are realizing, unfortunately, that it’s just not that useful. You’re just gonna enable all the flags anyway. So it has to be per-module, and as far as I know, nobody’s tackling that, except for a company that I’m hopefully invested in, that might be trying to solve that issue. But it’s kind of an open question right now. I’m not aware of anyone else really tackling sort of per-package permissioning and just reinventing the npm ecosystem. For better or worse, the npm ecosystem is what we have, and therefore the security defaults that they choose - which is none [laughs] - we inherit those decisions.
It’s very true. I probably see that in some of the companies that we know and love today. But also, don’t put it past people - these very smart developers - to grow in those domains as well.
A lot of founders just learn on the job, and often can’t really be taught anywhere else. There is one model which I really like; it’s a friend of Changelog, Sid Sijbrandij, from GitLab. He has started a venture firm, or a venture incubator called Open Core Ventures, where he takes in founders of successful open source projects and he hires a CEO for them, and incubates a company with them.
It’s a pretty smart model. The maintainer gets to be a CTO and co-founder of the project that they build, but they don’t have to do the company building side. And that’s pretty nice, if it works. It’s still a pretty new model, so it remains to be seen what that really looks like… But that’s GitLab’s entire origin story. Sid was the sort of installed CEO – he’s a self-appointed CEO. [laughs]
I think that’s probably a good model, but as far as I can tell, most of these projects just have the original developer founders become business people, and it remains to be seen how well they take to that role.
Mm-hm. And some of them succeed, and some of them don’t, and that’s just the way it goes anyways. That’s the thing about startups as well - so many fail. And now we’re attaching them to open source projects, or projects that – you know, there’s different variations of that, that may be source-available, or business-source, these things… And as users and as consumers in the ecosystem of npm etc. we need to be aware that a lot of projects fail, and a lot of companies fail.
Thankfully, with open source at least they’ll leave their trail behind, and somebody else can pick it up and maintain it, or do what they have to do, hopefully.
So I think Chromatic is probably the example here, with Storybook, which was an abandoned project, and it got picked up by the community, and now it’s mostly run by Chromatic… But it doesn’t happen too often. People would rather build from scratch, rather than take over an existing codebase. Unless, obviously, if they depend on it a lot, then sure; but I just haven’t heard too many examples of those.
So you mentioned four buckets that are important for people to be thinking about in this third age. Their current bets, things that are incrementally adoptable, new architectures, and then finally, new languages. We didn’t get into the details on any of those. Let’s maybe start with current bets, or you can review again, and then we can dive into what that looks like.
Yeah. Mostly, it’s not gonna be a surprise for most people, but some may really want to get on the adoption train, because it’s very clear what’s happening. So the first one is, of course, IE11 is going away, and that has a firm date now, compared to two years ago when I struggled to find a firm date. Microsoft has now come and they’ve said June 15th, so by the time this comes out we should be there.
To me, the most important thing that I was looking for was the U.S. government dropping IE11 support. So there’s a tracker site, I think USanalytics.gov, or something like that, and the proportion of IE11 traffic going to U.S. government sites, across the IRS and everything else, went from 3.6% down to so small that they don’t track it anymore. It’s just in Other. That’s really good news.
[36:17] Alongside that, all the roadblocks that IE11 presented are also growing, and primarily ES Modules are also growing, and there’s a site on Chrome that you can check for what percentage of websites loaded are using ES Modules natively in the browser. So this is not just like you’re using the ES Modules syntax but compiled away by WebPack; this is actually you’re shipping ES Modules to the browser. I think that is up another 2x, from going 3x the year before. I think I worked it out to something like - if it continues at the current rate, by 2026 or 2027 ES Modules will be half of the web. That’s a pretty big shift.
Obviously, we’re not saying that everything should be ES Modules, because even with HTTP/2 there are recommendations against doing time watches for everything, because that causes a pretty big waterfall. But I think it’s just growing in adoption, and I think that’s one of the hard data points that we can rely on.
The other fact is just React vs. just other frameworks - React is just winning. And within React, Next.js is winning hard. It’s accelerating, in fact, compared to other frameworks. So I think whoever has just bet on Next.js and bet on React has been validated tremendously. That’s not to say the other frameworks are not doing well; they’re just not growing as fast as React.
It’s always useful to keep an eye on downloads, on the state of JS, just to see what the meta is, but it hasn’t really changed in the past three years. I don’t expect it to in the near term.
The last thing - I didn’t put it in my notes, but I called it out in the slides, was that TypeScript almost definitely won the compile-to-JS wars, if there was even a fight. Maybe five years ago there was more of a fight between TypeScript and Flow, but now it’s pretty clear that everyone’s just gone to TypeScript. And there’s been no corresponding growth in the other alternatives, like Elm or PureScript. So yeah, that’s the validation of current bets.
How do you feel, Nick? Are you feeling pretty good about your bets?
Pretty good, yeah…
In your talk though there was one thing I kind of alluded to at the beginning of the show, and that was - on one of your slides you mentioned a… I don’t know if you called it a regression or a change, but it had TypeScript over to JSDoc. Do you wanna talk about that?
Yeah. So this is more about noting counter-trend things that might be interesting… Like, now that TypeScript has won, what is the next frontier? So I presented two paths. I actually heard some feedback from the TypeScript team that that slide might have been misunderstood. And first of all, I’m shocked that my talk reached the TypeScript team… But second of all, it wasn’t meant to be that controversial.
So there’s two paths. One, which is build TypeScript into the language. So there’s a stage one proposal right now for types as comments, which just means that you can get rid of the TypeScript build step. It’s unclear to me if all of the TypeScript syntax will be included… So in the attempt to formalize a standardized TypeScript, are you gonna end up with like a crappy half subset of TypeScript that now people have to keep in mind?
The other question is “Is this the way that people want to write TypeScript?” So if your goal is to strip out the build step, maybe don’t even write TypeScript. Just use JSDoc types, and use the language server that TypeScript comes with to give you the type safety, but you never actually have to write TypeScript, so you don’t have to use the build step.
So the most interesting projects that have gone in this way are Deno and SvelteKit, which have moved from a TypeScript codebase to a JSDoc type codebase, specifically for this reason, for build speeds, and – I think primarily for build speeds. [laughs]
Yeah. I know that strategy is what JS Party panelist Chris Hiller does day-to-day, and he sings its praises; he really likes to just do it.
I tried it for my site, and I was like, “Yeah. It makes sense.” It’s the right combination of types when I need it, and then when I don’t need it, it gets out of the way, and it doesn’t complicate my build chain.
Yeah. Nick, you’re nodding against what I’ve just said. Are you –
I don’t give Chris’ ways any validation, that’s all I’m saying… [laughter] No, I just don’t like writing comments. The TypeScript syntax feels very natural to me, whereas – I don’t know how to describe a lot of more complex things in JSDoc, and it seems overly verbose. But that’s just me.
[40:19] Right. So the syntax can be a little ugly, that’s for sure, but you can still sort of write your types in a separate file, a TypeScript file, and import them, if that’s your concern.
Oh, okay. Yeah.
So there’s ways around it; it’s just a matter of how much are you willing to futz around with your toolchain if you don’t have it set up. Or if your toolchain already understands TypeScript natively, then you never worry about it, which is great.
And there’s the other factor, Nick - if you start doing that, will they still let you MC a TypeScript Conf? You know, you might lose your MC spot, so…
You can’t do that.
Yeah. I know for a fact that the TypeScript team doesn’t like this, the fact that people are –
The JSDoc typing stuff is meant to be a stepping stone to TypeScript, and now people are using it to step away from TypeScript.
That one backfired.
But now the type annotations proposal is a way to step back to that…
Well, yeah, so - I’m just not gonna pay attention to it until it reaches stage two or three. But the concern there is that it’s a subset that isn’t full TypeScript, and that causes problems… But who knows.
Yeah, that’s a valid concern, for sure, and it’s not meant to be a way for TypeScript. It’s meant to be a way for TypeScript flow, other implementations to put their type annotations in there. It might be hard to satisfy all requirements of all languages in the way that they’re currently formed.
Right…? Alright, so that’s validating Nick’s current bets, but let’s break his confidence with some of the future things. What’s the second bucket of things that people are paying attention to? Things that are incrementally adaptable is what you said earlier.
So WebPack, you might wanna try – so Node, you may wanna try out Deno, WebPack, Vite, Babel, you might wanna shift to swc… Jest to Vitest, Prettier to Dprint, ESLint to RSLint, Nvm to Fnm… I think those are other linting materials as well.
So a lot of these are sort of Rust rewrites of the toolchain, and there may be one for one, or in the case of swc it may be more of a platform shift. I think that’s the vision for swc. But either way, I think those are easy to swap, with no big rearchitecture. That’s why they’re a bit safer to explore. Especially because if you run them a hundred times a day, you might have significant savings, so why not.
Yeah, we’ve seen a lot of specifically the Vite adoption, and I think Kball recently was singing the praises of that inside of his engineering team, of that just really changing their day-to-day work… Because these are things that you run a hundred times a day.
Yeah. The thing about Vite - it’s gonna be interesting whether or not, when we stand here and we do this again in 2030, whether or not we’ll be talking about Vite or swc. Because Vite has the current momentum right now, but it was never really the intention of Evan, the author of Vite - and the author of ES Build, actually; both are called Evan - to be the core toolchain of everything. He actually kind of called it a proof of concept; an existence proof that your build tool is gonna be faster. Whereas swc is meant to be more of the platform.
If you look at Next.js, they’re not adopting Vite, they’re adopting swc as the sort of Rust-based platform of choice. So I think it’s a very interesting debate right now. We may have just rushed to Vite, just because it was the first to be a fully-features bundler, with a really good dev story… But long-term we might be shifting to swc just because the architecture might support more things that we wanna do. I don’t know. This line of thinking is about two years old now, and I haven’t really engaged with either of the authors to check my assumptions.
[44:06] At the same time, it does seem like it’s getting just exponentially easier to migrate between these different things.
You know, five years ago when I had a super-complex thousand-line WebPack config, to now I have a 20-line Vite config… And if I wanted to switch over to swc or a toolchain around that, I’m not gonna write a thousand lines and do it again. It’s gonna be pretty straightforward. So just a lot of standardization.
Yeah. Part of that is just standardization of all the things.
Yeah. I prototyped moving our app from Create React App to Vite, but then we also had to maintain a separate Babel config for Jest, because it doesn’t work with ES Modules.
Right. So Vitest is the up and coming, and probably one of the fastest-growing projects of the last year to do that.
So are you going to adopt Vitest, Nick? Or did you do that? Or you just abandon the project.
When I did this prototype it was like two weeks before they publicly announced Vitest, so… Yeah, the plan is to look at it. And I think that it’s very telling… You know, when I looked at it back then, it was like “Oh, don’t use this yet, because it’s very experimental.” And now Vite has moved over to Vitest. So it’s grown a lot.
They move fast in that world.
Absolutely. So yeah, it’s definitely something that I want to investigate further, and I think that it could be a very good fit.
Let me mention two other things in the incremental adoption phase… So at first I mentioned the monorepo thing; that belongs here, the Turborepo and Nx, Pnpm as well… The emphasis on incremental adoption of monorepos may or may not matter to you, based on whether you’re doing brownfield or greenfield. But I think the developer productivity is definitely there, and people are recognizing that. Whether or not you like it – like, you’re working across multiple repos anyway, and it’s just a matter of dev workflow if you wanna do that.
There’s also the trend of browser IDEs, which are also incrementally adoptable in your review workflow. So there’s StackBlitz, GitPod, GitHub, Codespaces, Coder.com - all these solutions for you to run deploy previews in a web-based environment.
When they give me a web-based terminal, then I will be super-happy.
I think they do…
I mean, you can do that with Codespaces, and things like that, but at what cost…?
We recently did a show with Warp founder, Zach Lloyd. And Warp - they’re macOS-only. They’re reinventing the terminal - I’m not sure if you’ve heard of that one - and they’re very much looking at their next target beyond macOS. It’s either gonna be a Linux-native client or a web client. And I think putting the terminal in the browser is an interesting proposition. I know there’s people that have put things that look like the terminal in the browser… And StackBlitz has put Node right in there, and there’s lots you can do… But it’s definitely a space that’s heating up. All this VC money is just trying to put Vim in the browser for you… [laughter]
Well, StackBlitz is even crazier… They’re putting Chrome, in Node, in Chrome. Something like that.
Yeah, something like that…
Because they’re running Electron in the browser. [laughter]
Well-funded experiments, I’m sure. So let’s move further out into the more experimental edges. Rearchitecting, or new architectures… Kind of like getting more aggressive here with our adoption, right?
Right, right. I actually view VC-funding as a new architecture, and that’s kind of like a hidden – like, it’s not in the code, but it’s behind the code, because it’s gonna determine the evolution of the code. So that’s one thing. But there’s been a lot of developments over incremental rendering versus static rendering…
So both Vercel and Netlify are trying to drive different perspectives on how to do incremental rendering right. Netlify’s approach - they call it DPR (Distributed Persistent Rendering), and then Vercel’s approach is ISR (Incremental Static Regeneration). And there’s pros and cons to that. I wanna actually point to Lydia Hallie’ talk at Reactathon as the current best state of the art on the five or six different options that you can choose, and the trade-offs between them.
So there’s a lot of acronyms here, and probably you don’t really wanna get too much into those, but I think it’s worth understanding the options available to you, because they are significant shifts. I have shifted my own blog over from a fully statically generated approach to a rendered on demand approach, and… I mean, it makes sense; my deploys are really quick.
The last I’ll cover here about this approach is React Server Components, which is not fully out yet, but both Remix and Next.js are working on approaches to ship this such that – essentially, you are able to render React components in the cloud and stream them down in a serialized format to the client-side, where they can render them out again. And that will fundamentally cut – I think when they tested it at Facebook it cut their bundle sizes by 30% to 40%. It was pretty huge.
So being able to seamlessly choose whether or not you’re rending on the client versus the server and to move between those things flexibly is kind of the theme of what I’m calling neoisomorphism.
Word salad today. We have lots of – neo-iso-morphism…
Ryan Florence also had a really good talk at Reactathon, calling it a lever. Essentially, there are trade-offs to all of these approaches. Sometimes you want the fast layout, sometimes you want the instant response… And so not needing to move a bunch of files around, or to adopt a totally different toolchain just to achieve different parts of that rendering effect - that’s kind of the goal of Remix. And I think that’s kind of the goal of a lot of these tools, which is to try to make it easy to move code around; to achieve the dynamic parts that you wanna achieve, and the static parts that you wanna achieve.
This is the speculative part, in the sense of like - I don’t know what I’m talking about, because I haven’t built a WASM project yet… I just try to keep up to date on what’s going on.
Everyone talks about Figma, but there’s a really good InfoWorld article on the rise of WebAssembly that is actually talking about the non-famous examples. Disney streaming uses WebAssembly as a sort of cross-platform solution… There’s a lot more in there… I just picked Disney because everyone has a Disney subscription, especially if you have kids…
Also, it’s just not a place where you would expect it. It’s kind of an unexpected use, right?
Yeah, what a fascinating turn of events that would be, if all of a sudden WebAssembly became the new Docker of our server-side things… Just - didn’t see that one coming, you know? It turns out maybe that’s the case. That’s cool.
Plus, if I’m like a really awesome C++ developer, I’m probably gainfully employed doing some cool C++ stuff, right?
Good question. Nick, any final thoughts or questions for Swyx before we let him go?
No, I think this is just a fascinating way to look at the past, present and future of the language, the platform, the ecosystem, and I’m really excited to see where it goes from here. To see if it really does die in 2035, too.
Well, it’ll definitely die at the heat of the Universe, so…
Just some infinite loops and you’re good.
There you go. Can’t stop. Won’t stop. Alright, Swyx, where’s the best place for people to connect with you on the interwebs?
You can find me on Twitter @swyx, or on my blog at swyx.io.
Our transcripts are open source on GitHub. Improvements are welcome. 💚