JS Party – Episode #258
The rise & fall of JS frameworks
with Chris Ferdinandi
Fastly – Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com
Fly.io – The home of Changelog.com — Deploy your apps and databases close to your users. In minutes you can run your Ruby, Go, Node, Deno, Python, or Elixir app (and databases!) all over the world. No ops required. Learn more at fly.io/changelog and check out the speedrun in their docs.
Notes & Links
|1||00:00||It's party time, y'all|
|2||00:59||Welcoming Chris back to the pod|
|3||01:28||Introducing today's topic|
|4||03:10||Hot take: jQuery is better than React|
|5||04:37||So, what's the next big thing?|
|6||10:20||Requirements for the next big thing|
|7||13:40||Do we need to change the DX mental model?|
|8||16:50||We're constantly reinventing the wheel|
|9||18:31||React vs Preact|
|10||20:38||Steps toward reducing how much JS you ship|
|11||24:30||Web components were almost awesome|
|12||25:42||On sanitizing third-party data|
|13||28:02||Chris' timeframe on React's dethroning|
|15||32:35||How new tools will come to be|
|16||33:54||A very good VR tangent|
|17||34:42||An argument for state-based UI libraries|
|18||36:03||Are we really transitioning off React?|
|19||38:25||How the pandemic impacted web dev|
|20||41:18||How "Back to Office" affects web dev|
|21||42:06||New frameworks adopting React's API|
|22||43:50||Advice to new web developers|
|23||44:45||Maybe KBall & Chris are just dinosaurs?|
|24||45:55||Vim, why can't KBall quit you?|
|25||47:37||Summarizing why this time's different|
|26||48:04||Go check out Chris's amazing resources|
|27||48:40||January 5, 2028|
|29||50:45||Outro (take the FF survey!)|
Click here to listen along while you enjoy the transcript. 🎧
Hello, JS Party people. Welcome to the first recorded JS Party of the new year, though I will say it’ll be the second published, because we’re coming right after the New Year’s party… I’m Kball, I will be your host MC today, and I am joined by a special guest, the vanilla JS guy himself, Chris Ferdinandi. Chris, how’s it going?
I’m doing great. Thanks so much for having me here again. It’s great to be back.
Yeah, good to have you on. So let’s start by setting the context for this conversation. So you have a bit of a background as the vanilla JS guy, and you have these opinionated takes… And you pitched me on a new take that you want to talk through, and I’m excited to kind of dig into it. So do you want to introduce your topic?
…but at its core, the key thing here is that I feel like we are at the start of another wave of change in our industry. We tend to see these waves every like four to ten years, where some new kind of approach or methodology or thing comes along, that creates a shift in the way that we build things… The last one we had was kind of this big shift towards state-based UI, and client-side libraries is the way we build all the things. And I, just kind of based on some new tools that I’m seeing, and kind of these emerging talks and articles I’m seeing people write, I think we’re at the start of another wave, and we’re going to see a lot of the way that we used to build for the web go away, as some new best practices emerge… Which I think might be a good thing. Not a perfect state for me, but I think it may be a good thing compared to the way we do things today.
That’s a bold statement. I don’t think anyone has React going away on their 2023 Bingo card yet… Unless you do, and you’re actually putting it out there.
To be clear, I’m not saying 2023 is the year React dies. Actually, quite to the contrary; I think React will be around - I don’t want to say forever, but like jQuery is still very much around on the web.
And you know what? For the type of simple problems that it solves, it’s still phenomenal.
Mm-hm. If we’re making bold claims, I’m gonna go on record as saying that jQuery is better than React…
…at solving the problems it aims to solve.
Another conversation, but…
Yeah, I know. Well, we’ll dive there a little bit…
we can do it.
I mean, you could scope that down to jQuery is solving very different problems than what React is solving.
Oh, yeah. I specifically mean not just jQuery better in the absolute sense, although I also mean that. But I think for the problems that it aims to solve, jQuery does a better job of that than React does. But yeah, the jQuery thing is really relevant, because most of what jQuery does has been replaced, or can be done with the same level of ease using platform-native technology now. Sometimes a little bit more verbose, and the documentation for platform-native stuff is garbage compared to jQuery’s documentation… But jQuery doesn’t need to exist. It just – it persists nonetheless, mostly through kind of inertia and good documentation. And I suspect that tools like React and Vue will continue on that same trajectory, even though kind of like the new hot way that we build for the web will potentially – I don’t even wanna say leave it behind, but will kind of evolve past it.
So should we dive into what I actually think is coming next, or do we want to make fun of React some more? Because I can do either. I’m totally happy with–
[laughs] We had a spicy React show a little while back, where we were debating the premise that React is only good at being popular… Which - one can actually dive into the benefits of being popular; like, there’s a lot of value there in and of itself. But okay, before we make fun of React, which I’m here for that – I mean, there’s a lot of things I love about React. I argued the side that React is actually really good at a lot of things, and while that was an assignment, I actually do believe that. That said, it’s fun to pick on the gorilla… Let’s get the premise of where you think things are going before we pick all the preliminary pieces to shreds.
[05:57] And so over the last year or so we’ve seen people try to address some of these shortcomings in a few different ways. You’ve got the smaller versions that do kind of the same thing. So you’ve got like SolidJS use similar patterns to React, but is a lot smaller. Preact is probably the most popular of this kind of genre, which is almost a verbatim copy of the React API, but a 10th of the size. And as a result of that, and having fewer abstractions under the hood, it also actually like renders the UI a lot faster… So in many ways, it is a superior React to React. And kind of this trend has caught on so much that Evan You, who created Vue, was inspired by Alpine.js, which aimed to be like the Preact of the Vue world, and ended up creating his own little mini Vue called Petite Vue, which is a six-kilobyte spin-off that has a more narrowly-focused use case.
[09:50] So for me, I’m kind of in this place where I don’t know if these tools are the next thing, or they’re transitional to whatever the next big thing actually is. And so to give this a little context - Kball, you’ve been around for a while… Do you remember when – you’re not as old as me; you still have hair, which is nice, but…
Oh, good genetics. My hair is just going gray. [laughs]
It would be, if I had any left… So do you remember when jQuery – like, the modern web could do some stuff jQuery could do, but not all of it. And people were like “Hey, we still need jQuery for some things, but not all… So what if there was like a smaller thing that worked kind of the same way?” You’ve got things like Umbrella.js, and Shoestring, and all these micro DOM manipulation libraries that were supposed to be smaller… So they all went away; like, jQuery’s still around, but they all went away, but they kind of got us from that point to “Okay, I can do all that stuff with other tools.”
And so I’m not sure if things like Svelte and Astro are the next big thing, or the thing that gets us to the next big thing. And so that’s kind of – that’s the “Thank you for coming to my TED Talk.” [laughs]
Can I dig into a few different pieces here?
Yeah, yeah, for sure.
So that developer experience and mental model is one piece of this. Then there’s “What am I shipping to the browser?” And there’s a couple aspects of that. There’s “What is the runtime there?” Old-school jQuery, a huge amount of what was shipped was essentially papering over browser differences, and giving you a common UI over this thing that was still very much the Wild West… And that problem is solved, right? Like, we have standards for browsers now, and all of the browsers that are still in use today pretty much - except you’re on the very bleeding edge of things - match up. We don’t need to ship kilobytes and kilobytes of code to paper over browser differences in the same way that we used to. We might ship a polyfill here or there, but it’s not this massive problem.
So what I want to kind of get a sense of is, is your take here that – like, these mental models may be sticking around, but we’re getting better at the optimization problem, and we’re starting to care about it? Or is your take that actually the sort of developer experience mental model piece is shifting as well?
Yeah… There are challenges that come with doing that though, right? So being able to debug your code gets a lot harder when the thing that gets like run in the browser isn’t the thing you typed, and when that’s not the source code, it becomes harder to debug, and to pin down what’s going wrong, and kind of figure out issues. So there are trade-offs to this approach.
Back on your theme of relearning things - we might have to relearn some of the lessons that statically-compiled languages and compilers have learned…
I feel like there’s this constant process of reinventing the wheel in our space…
It gets really tiring after a while… Which is why I tend to not chase trends very much until the dust settles, because – here’s just a little pro tip, by the way, for anybody who is earlier in your career… You don’t always have to chase every new – like, one of the things I hear a lot from students is like trying to keep up with all the new things that come out is really, really exhausting. And I agree. So you don’t have to do that; you could just wait until one of them emerges as the clear leader, and then go with that. These days I think it’s really obvious that if you’re just looking for like broad marketability, you can’t really go wrong picking React, because it’s on so many job descriptions… Whereas four or five years ago it was maybe a little bit fuzzier if it was going to be React, or Vue, or Angular, or whatever.
Yeah, React has pretty much won that space.
Yeah. Tangent aside, but… Yeah.
Yeah, for sure. To be fair, to kind of like throwback to the other episode you were talking about, like “How much of React’s staying power is its current popularity?” It’s the old “No one got fired for hiring IBM” kind of thing applied to the frontend. Like, React is the gorilla. And so if you choose it, it’s hard to go wrong. So in terms of API reduction, to be honest, I’m not 100% sure where kind of the drop-off is, like what’s missing from Preact that you would get from React. And from what I understand from some folks who have done conversions, the challenges tend to be more around certain components that you’re trying to use don’t always line up 100%… So that can be a little bit of a challenge at times.
But one of the other things that makes Preact a bit smaller is it was created a few years later, and so it uses some kind of native browser tech under the hood that didn’t exist when React was created, and that they at the time wrote some abstractions, or some helpers, just for Reasons of if “It’s working, don’t – don’t break it by trying to fix it” remain in React, that don’t in Preact. I believe React may also have slightly deeper backwards compatibility as a result of some of that.
[20:12] Well, and that is honestly one of the benefits that came up in that episode about React, is that they care more than possibly any other framework out there - except Ember, which is basically a non-competitor anymore - about backwards compatibility. And so you’re not going to lose your job betting on React because when you have to update because of whatever it is, XSS bug, or whatever, your application may just work.
Yeah, totally fair. So you asked what are these incremental steps… So there’s a few different layers, depending on what you’re trying to do. On one hand, dropping in Preact for React is a pretty easy one. Or if you’re starting greenfield, choosing one of the smaller alternatives might serve you well.
On the other hand, Astro is really interesting, because it allows you to drop your existing projects in and spit out more performant code… But it’s still kind of new. So I think one of the barriers to entry for it is, on certain projects, where if you’re working with like a bigger kind of thing, it’s really easy to be like “React is battle-tested, whereas Astro is kind of new, and it’s maybe still ironing out some kinks, and things like that.” I now see their website is using the “island architecture” buzzword, which is kind of one of the hot, new buzzwords in the frontend here.
But yeah, so I think a next step is migrating front – or not migrating, but adding that compile step with Astro, especially if you’re someone who’s currently using Next. Switching over to Astro feels like a no-brainer. On the other kind of – or I guess related to that, if you’re starting completely from scratch, Svelte is also a really nice alternative that – Rich Harris, the creator of Svelte give this really nice talk last year at JAMstack conference… Or I guess it was two years ago now, because we’re in 2023… So a while back.
Still adjusting the brain…
Right, yeah; still kind of trying to rewire here. But you know, a while back, he gave a really nice talk about what’s coming next with Svelte, and just kind of his general thoughts on the future of compilers in general… And one of the things he talked about was how with these tools you can use them to - with SvelteKit anyways - render files where you don’t have to choose “Do I want this to be a client-side or server-side application?”, without doing what Next does and shipping the entirety of React, and also running it in the server. So things that are static get rendered statically, things that are a little more dynamic get rendered mostly statically, with some JS for the dynamic parts. And I believe, based on his talks, SvelteKit also provides a server-side fallback for certain things… So like if you have a form, it’ll do the Ajaxy form submit. But if that fails, we’ll still give you a backend to kind of call the old-fashioned way.
So yeah, again, it really feels like we’re coming full circle to these old WordPress sites, with full-page reloads, but with some niceties; possibly better developer ergonomics, and things like that.
Yeah. That sounds to me a lot – like, that trend of “Hey, wait, we can actually do something on the server, and doing everything on the client side is an optimization, not a necessity.” That definitely seems to be coming around. It’s there in the React world as well, with – oh, shoot, now I’m blanking on the name of the framework… That just got acquired by Shopify.
Oh, I did not know…
[23:49] Kent C. Dodds was on there. Why am I blanking on the name of this framework? Remix. Remix. There it is. They do a similar type of thing to what you’re describing. They’ll have the form, and they’ll optimistically do it via Ajax, but the fallback is just a server-side action. And they really leaned into that, “Oh, let’s actually take advantage of all the things the web does for us.” And it turns out that HTTP, the web, all these different things were well-designed.
Yeah, right? It’s almost like they are the really smart folks who did all that, and kind of knew what they were doing.
I mean, we do keep learning… And I think this does come to – the platform does catch up, eventually. Things do – I think what Laurie Voss called “transcend”, from like the frameworks that work well… You talked about it a little bit with jQuery, right? A lot of the things that jQuery did was expose these new, really convenient APIs for grabbing elements of the DOM and manipulating them, and the platform eventually absorbed some of them. I would love to see it do that with a state-based or functional approach to UI. That was what everybody hoped Web Components would do, and then Web Components exposed this extremely imperative-style DOM manipulation, which, it may be – like, I’m not a browser developer; it may be that’s just how the browser – it’s really hard to do that abstraction layer, but clearly, all of these different frameworks are doing it.
I was literally just talking with a student this morning about how Web Components come so close to being awesome, but just miss the mark, for what – at least what everybody thinks they could be, or wants them to be, which is a replacement for React Components. I don’t think they’re that. But yeah, so that’s the dream, right? …is that the browser supplants a lot of this stuff. Hopefully, it will, at some point… So we’re kind of sort of veering in that direction.
One of the things that libraries do for you that’s really nice is sanitize third-party data before rendering it into the UI. React has their set unsafe innerHtml, or something… I know they have some really scary-sounding property…
Dangerously set innerHtml… Oh, if we had our soundboard, Amal had a great – [Amal] “Dangerously-set inner HTML… What’s so dangerous about HTML’s inner parts…? I don’t know… But they’re dangerous on the internet… Of React. React’s internet, of course.”
Right, yeah. So most libraries will provide a way to kind of prevent you from doing bad things with third-party data. They’re not bulletproof, but they get you a little bit of the way there. And historically, there hasn’t really been a good way to do that in the browser. There is a sanitized API that’s in the works though, that will allow you to do that. So you can pass in an HTML string and get a sanitized version of that back. It replaces either using a library like that, or something like DOM Purify, which is very big and very heavy. So I look forward to things like that.
It is really my dream that someday there will be like a diff property, or a diff function that you can run to just throw some HTML strings out there and make things happen.
One of the other things I always hear is like “Well, why isn’t JSX in the browser?” And for me, template literals get me 90-something percent of the way there. They do a majority of what I want, that I would do in JSX.
And you could build a whole framework around template literals. In fact, I feel like somebody’s done that. I can’t recall, but I saw that.
Yeah, htm or htx… I forget the – it’s htmx, isn’t it? And I’m just – I’m dropping a letter.
That looks right, teah.
Yeah, htmx is built around template literals. I think – actually, that’s maybe like the parent, and then there’s like a few different tools within it… I’ll drop a link to that in the chat if you want to drop it somewhere…
Cool, cool, cool. Yeah, so you’re right, we are headed in that direction… That said, stuff has inertia.
[28:10] As you highlight, jQuery is still hanging on… It took – React was growing and jQuery was still at 90% of the world’s web for years and years and years. So what timeframe are you seeing this play out on?
Yeah, so… Multiple years. So just thinking back historically… Well, so it’s interesting, right? I want to say in five years’ time we’ll still see a lot of React sites on the web. But React still represents a relatively small amount of like the web; it feels like it’s a majority of the web, because it’s like the very popular thing that we use now, and so many job descriptions have it, and it gets talked about a lot at conferences, and it’s kind of like the standard now. But still, just as a percentage of the web itself, it’s still actually a relatively small amount. Like, something like PHP and WordPress still vastly dominate over–
Well, new WordPress installs ship React now, right?
They do. Not always client side. You can, but it is by default primarily used in the dashboard area as part of the editor… Whereas kind of the frontend of most sites is still server-rendered, with – so many plugins still use jQuery… Which is another reason why jQuery will not go away, it’s because of WordPress. But yeah, that’s kind of an interesting thing. So timeline-wise - this is one of those like weird and fuzzy things. So I want to say in about four or five years we’ll probably start to have some other tool that is maybe the new standard, or that has emerged as a clear winner. Maybe. A lot of that depends on whether or not things like Svelte and Astro are the next big thing, or just the thing that gets us to whatever that next big thing is. It’s tough for me to say. I’m not sure… Like, it’s very clear to me that something like Solid and Preact are similar to Umbrella.js and Shoestring in the jQuery era. Like, they do the same thing, just smaller. Astro and Svelte - they have a similar kind of methodology, a certain way of authoring, but the way they actually kind of work is fundamentally different, where you’re compiling things, and you’re shipping mostly HTML. Preact isn’t really built on a progressive enhancement model. It’s like “Here’s a smaller way to do client side JS.”
So yeah, I guess that’s really for me, the big kind of fundamental unknown, is “Are Astro and Svelte ‘the thing’? Are they the next React?” Or are they also in that same kind of bucket as Preact, and Solid, and other tools like it, that will eventually be replaced by some other new thing? …which - one possibility here is that the browser catches up, makes a lot of this stuff native, the tools persist for a really long time, and then some whole new suite of tools comes around to solve some crazy web problem that we haven’t thought of yet… Like Web VR, or just some new stuff that people are trying to do… I don’t think it’ll be VR, but you know…
Or all of these compile-to-WebAssembly tools catch up, and WebAssembly is able to directly access the DOM, instead of having to jump out, and all those things.
A guy can dream.
That’s interesting. Yeah, to be fair, I’m not very familiar with WASM, so I don’t –
[31:58] From a performance standpoint, you can think about it similar to image sizes, right?
Yeah, it’s very true. So related to this idea though, of like maybe all these tools just kind of become that thing grandpa used to do when he built for the web, and now we’ve got this other thing… So people forget that Angular was kind of a really big deal for a short period of time… But when tools like Angular and Vue and React were first emerging, the idea of building large user interfaces with state-based UI was pretty novel. Not that it didn’t exist as a concept before, but as a popular one that people really latched on to - it wasn’t a particularly popular approach to building for the web. And so I do really kind of wonder if the platform absorbs these approaches, like what will that next thing be? Because the tools always emerge to solve a specific set of problems. For React, it was “Oh, here at Facebook we have this really overly complex UI that has a lot of moving parts, and managing it sucks. So let’s build something to make that easier.”
I will be really curious to see what problems emerge in the next few years with the web that we have to build a set of tools to try and solve. I am not imaginative enough to kind of come up with what that might be. I heard someone suggest VR once… And maybe, but - I mean, they’ve been talking about doing VR in some fashion for years, and it’s always one of those things that’s exciting for like a hot minute, and then it goes away. Like, the Metaverse made it so laughable, I’m not entirely sure it’ll –
Yeah, I mean, I think VR is one of those things where – there’s a lot of really valuable niches, where I can see the value prop immediately. There’s also some very wealthy companies trying to make it a consumer product, and it’s not at all clear to me that that’s going to fly.
Yeah. I can remember being a kid, and Disney was talking about doing some Aladdin rod on a magic carpet VR thing, with this like massive headset as like a ride at Disney. But yeah, whether or not that gets popular on the web will be an interesting one. I’ve taken us on a tangent though, so I’m really sorry, Kball. I’m very good at that.
That’s okay, you can look it up offline and we’ll drop it in the show notes.
Yeah, for sure. And there was a – just a quick shout-out, my friend Steph Eckles did like a “12 Days of the Web” series a couple weeks ago, around the holiday season, and one of the articles was specifically around this. I’ll see if I can dig that up and drop that in for everybody.
And framework adoption has not gone down. If anything, I think it’s gone up. In fact, we’ve seen it take over more and more of the not-web, right? Things like React Native, things like writing React applications and packaging them up as desktop applications… These frameworks have gone bigger and bigger and bigger. So why now? What makes this time different? Why is the argument this time that we’re entering this transition period and we’re going to transition now?
Yeah. So before, for me it was always like a want. Like “Hey, I’d really appreciate if we’d stop using all these tools.” I think what’s different now is that there’s actually some tools that can replace what we’ve been doing in a more responsible way.
I don’t know if we just hit a tipping point where we started to ship so much that it became much more obvious, or we just had more people talking about it… And so you’ve started to have more kind of just general awareness in the industry than just Chris the lone nut.
I wonder if the pandemic and everybody suddenly shifting to home networks, instead of fast office networks, made people suddenly start to realize that this stuff ain’t free.
Oh… That’s an interesting theory, right?
Because at my last job, which I have left - I’m now back to being independent. Woo-hoo!
But we had an environment where there was no completely local dev server. You had a shared development database, but it was in the cloud. And that worked great in a fast office network, and it was bloody slow developing at home.
So one thing I take for granted – I have fiber at home; fiber optic. And it is just consistently the speed I pay, for all day, every day, regardless of how many people on my street are also using internet. I’ve kind of forgotten that when you have coaxial internet, which a lot of our countries still does, and a lot of other places in the world still do, or satellite, or DSL, or something that the weather can really mess with, your speeds can be really variable, depending on how many other people are also using it at the same time.
[39:52] The analogy I’ve heard used - that maybe not 100%, but I like - is the idea that if you have like a hose, or like a pipe with water, and you open four or five spigots, the water is going to come out of each one slower than if you just open one. So it’s like a similar kind of concept. So with the pandemic, if you’ve got everybody working from home, even if you were previously a remote employee, now when all your neighbors are also home, using the internet all day on video calls, which are very bandwidth-intensive, suddenly that internet speed is going to drop for everybody. Yeah, that’s a really interesting idea, that I had not considered. So maybe that’s it; a good thing to come out of COVID.
I mean, we’re looking for every silver lining we can find. Right?
Right, grab them while you can. But I actually think that has a lot of teeth, because I really did – it’s just been in the last couple of years, I’ve started to see people talking about the performance implications of the stuff we do a lot more, in a way that nobody really seemed to care about. Not nobody; you cared. We talked about it a lot. But a majority of our industry did not seem to care for a long while. And I think it’s one of those things where - you might be right, where people have to experience that pain themselves to actually develop the empathy, which is unfortunate…
I feel like that’s true about a lot of things, right? There’s a lot of lessons that can only be learned through pain. No amount of someone else telling you about it will fill you in, or get you to really understand it. I do wonder if the back to office trend will then steal some momentum from this…
Oh. Yeah… The back to the office trend is interesting, because a lot of people are fighting it…
So I mean, there are definitely people who prefer to be at the office.
It’s lovely, fast internet…
And if you’re someone – like, if you have a family, and it’s like noisy in your home, I know some people just prefer having a quiet space, or being able to socialize, whatever it happens to be… But there are also a lot of folks who just don’t want to. And digital-nomadding is becoming a lot more common… So my hunch is, even as kind of businesses start to try to go back to normal, I don’t expect that this trend is going to buckle at this point. It feels like we hit a tipping point, which is great.
Yeah. And the tooling is making some of the things easy enough. That will help. It’s interesting, because - coming back to the React question… Like, React has such of a mental presence out there. Everybody thinks React-first. New frameworks are then finding ways to adopt the React API, and make it look like React, make it feel like React. We talked with Misko Hevery, who is working on this new Qwik framework, which if you haven’t checked out, also check this out. It’s really interesting. A lot of the same concepts we’re talking about now - compiling things away, having pre-compilation… He has this idea of resumability that is really big… I’ll drop a link in the show notes to the episode we did with him… And I’m scheduling another one, so we’ll go deeper on that as well. But they’ve very deliberately adopted the React API. They’re like, “Everybody’s learning how to write React. If we want adoption of this new framework, the simplest path - not “we’ve gotta”, but the simplest path is to make it feel like React.”
Yeah… I think you see that a lot now, where React has really become kind of the – they weren’t the first, but they are definitely the standard bearer. They’re the one that everybody tries to emulate… Even when new things come out. Like, SolidJS uses some different terms and things, but the feel and the methodology is all Reacty. I’m still a Vue guy, personally. But if I had to choose one, if someone was like “Pick a framework!” But yeah, I love my HTML, that’s why.
[laughs] Yeah. I mean, I think – it’s hard. As you highlight. There’s so many things to learn. You’ve got to pick and choose, especially early on in your career… And React is a pretty safe bet, right? You’re looking for jobs, pretty much – a very, very large swath of them have React in the job description.
[43:49] Yeah. It catches people by surprise, because I’m so vocally against libraries… But whenever I get asked, “So what should I learn if I really want to like make sure I can get that job?” I’m like “Honestly, just learn React.” And they’re like “But you said no–” “No, no.” I want us to use last React. It’s great to know how to get by without it. But it is kind of the – I don’t wanna say the gold standard, but the industry standard now. It just is what it is. Hopefully not forever, though…
I’m looking forward to tools like Astro and Svelte kind of changing the way we build.
Totally. Well, and if you’re in the privileged position of not being desperate to find that next job, try exploring something else. Try out Svelte. I’ve been playing with Svelte again recently. It’s fun. I enjoy it. It’s neat, and it has that kind of like indie vibe to it, in a way that… I don’t know, I like.
Yeah. Where I always get hung up with new tools is so many of them just use a mental model that is not how I like to build for the web. But I’m also a dinosaur who really prefers a very like Spartan kind of dev experience, and I know most people aren’t like that. I’m in a vocal minority here.
Yes. Well, you’re talking to the guy who still writes everything using Vim, so… [laughter]
Well, that’s only because you can’t figure out how to exit though. That’s not –
[laughs] Oh, man… I have trained so well. I will say, my hands feel a lot better ever since I mapped Escape to Caps Lock, so I don’t have to reach as far…
[laughs] Oh, my gosh…
I did that because I had one of those old Macs with a touch bar, which - thank goodness they got rid of those. So I needed a tactile Escape. But now every computer, I just map Caps Lock to be Escape, because it’s so much easier on your hand.
Huh… But what do you do when you need to shout at someone on the internet? You’re holding down Shift like a maniac?
Should I ever be in that position, then yes. I’m rarely shouting at someone…
I’m just giving you a hard time. Caps Lock is a nuisance key. That’s a clever hack, I like that.
I am not the old man shouting at the cloud, I’m the old man hitting esc:q to get out of my editor
[laughs] Do you really still do everything in Vim? That’s amazing.
Oh, absolutely. So my development environment - I have a terminal, I use Tmux. I have Tmux set up with Vim bindings. So I can do everything. Hopping around, running things, going from process to process - all of that without my hands ever leaving the keyboard.
And it’s great.
I’ve long since done the investment to map those bindings into my brain such that it’s not worth trying to go somewhere else… And I at some point was trying to play around with VS code, because it turns out it’s, I think, better for recording videos of yourself coding, and things like that… And I tried to get it to these Vim bindings, but I got so frustrated, because I could get within a file mapped to the bindings I wanted, but I couldn’t get good keyboard bindings for swapping between files and navigating the file structure and all of that, and I kept having to go to my mouse. And I was like “Why would I do these things? I can do everything with my hands and my keyboard.”
Yeah, that’s pretty sweet. I love a good keyboard shortcut…
Anyway, that’s a diversion… I don’t think that people generally should be learning Vim as their new onboard to the web, but if you are –
Actually, it’s the future of web development… So it’s time. Get on.
Periodically, they do these surveys about “What are the top coders using as their editors?” and Vim is always up there. But I think it’s just because it’s all of us old people who have spent 20 years learning all these different things, and so we’re super-productive now, because we’ve spent 20 years working on our productivity… But it has nothing to do with the editor.
Oh, for sure. For sure.
No, I think that those were really the highlights. It feels like we finally have some inertia in the industry for this… So yeah, between tooling and this renewed focus on performance, I think we’re just headed in that direction.
Awesome. Anything else about this trend you want to highlight before we wrap things up?
[48:08] No, just - if anybody kind of wants to dig into this more, over at gomakethings.com/jsparty - I’ve cobbled together a bunch of kind of articles, and thoughts, and other conversations I’ve had around this, if anybody wants to explore the idea more.
Relevant links, and things like that.
We’ll include a link. That’s a clever way to both give people resources, and self-promote, because I see the Get Daily Developer Tips forum right there.
Oh, fancy that. I did not know that was there – yeah, no, that’s effective.
I suspect it’ll be somewhere in the four to five-year mark, just because these deeply-entrenched habits take a while to kind of unlearn. You’ll have a bunch of people who kind of dabble in it, and then some companies will start to use these tools, and then eventually it’ll feel like it was what we’ve been doing for ages. Once the conference talks and stuff starts to really pick up.
Alright, so put a pin on your calendar - January 5th, 2028.
There you go.
“Nobody’s using React anymore”, right?
Nobody. Not a single person. [laughs]
Awesome. Well, thank you, Chris. This has been JS Party. I think we’re about here now, so go check it out. All the different things we talked about will be included in links in the show notes. And then Chris has his resource list, which looks pretty massive. Lots of great stuff on there. You can check that out as well, and I’ll link to that from the show notes.
This has been fun. This is JS Party. We’ll catch you next week, and this is Kball, signing out.
Our transcripts are open source on GitHub. Improvements are welcome. 💚