Hot Takes on Frameworks
A panel of web experts compares today's top JS frameworks, exploring performance trade-offs, job market realities, and evolving best practices
Episode Description
Four web developers debate whether React's dominance is fading as frameworks like Solid, Qwik, and Astro rise, plus hot takes on TypeScript, JSX, and learning paths.
Episode Summary
This episode of Modern Web brings together hosts Tracy Lee and Dustin Goodman with Full Stack Jamstack podcast hosts Anthony Campolo and Christopher Burns for a wide-ranging debate on the current state of JavaScript frameworks. The conversation kicks off with the provocative premise that React finally has credible alternatives — Solid, Qwik, Astro, and others — built around a shared emphasis on performance through smaller bundles, resumability, and smarter server-side rendering. The group explores why React remains entrenched despite these advances, pointing to its massive ecosystem of libraries, tooling, and job market demand as a moat that newer frameworks haven't yet matched. A lively detour into TypeScript surfaces both frustrations with React's typing ergonomics and enthusiasm for tools like tRPC and the T3 stack that deliver end-to-end type safety. The hosts clash on whether new developers should learn React first for employability or master fundamentals before touching any framework, reflecting broader tensions between pragmatism and idealism. The discussion closes with each panelist predicting which framework will lead in five years — Qwik, Solid, or a still-dominant Next.js — while agreeing that JavaScript's perpetual identity crisis is ultimately what drives its innovation.
Chapters
00:00:00 - Introductions and the Full Stack Jamstack
Tracy Lee and Dustin Goodman welcome Anthony Campolo and Christopher Burns, the hosts of the Full Stack Jamstack podcast. Anthony explains the show's premise — exploring how developers attach databases and back ends to Jamstack projects, creating true full-stack applications within a single codebase using tools like GraphQL and tRPC.
Christopher adds historical context, recalling how the movement grew out of early Gatsby experiments and the arrival of frameworks like RedwoodJS and Blitz. The segment sets the stage for a broader conversation about how JavaScript tooling has evolved from static marketing sites toward fully integrated application development.
00:03:32 - React's Reign and the Rise of Alternatives
Tracy opens with a playful "React is dead" provocation, and Anthony reframes the narrative: React now has genuine alternatives that prioritize performance through smaller bundles, better SSR, and resumability. He highlights Qwik, Solid Start, and Remix as frameworks that bake performance in from the start, so developers no longer need to be niche performance specialists.
Christopher argues that React will persist like jQuery — always present but gradually losing share — until competitors match its ecosystem of component libraries, CI/CD integrations, and plugins. The group notes the irony that React was once celebrated for being lightweight, yet is now considered the slower option compared to zero-JavaScript approaches like Eleventy and Astro.
00:09:16 - Solid, Qwik, and the JSX Future
The panel compares Solid and Qwik in detail, with Anthony explaining that Qwik intentionally copied React's syntax while replacing internals, whereas React's hooks coincidentally evolved to resemble Solid's original API from 2018. Dustin asks whether JSX-based component writing will dominate permanently or yield to something new.
Christopher favors JSX but concedes that a future where any syntax works is plausible. Anthony points to Astro's bring-your-own-framework model and the Mitosis compiler as two approaches to syntax flexibility, while noting that DSL-based frameworks like Svelte and Marko will always appeal to certain developers. The discussion also touches on Svelte's struggle to gain enterprise traction despite developer enthusiasm.
00:14:41 - Enterprise Adoption and React's Staying Power
Anthony contextualizes Svelte's origins at the New York Times, arguing that enterprise adoption depends on how "enterprise" is defined. Christopher highlights the gap between Twitter thought leaders championing new frameworks and the reality that roughly seventy percent of job listings still call for React, suggesting React could become the new COBOL for B2B software.
The conversation turns to Facebook's continued stewardship of React and whether corporate backing from Google similarly sustains Angular. Christopher wonders how much React's future depends on Meta's commitment, while Tracy and Dustin note that many Facebook-originated projects have moved to open-source foundations — but React has not.
00:18:09 - Should New Developers Learn React First?
Anthony makes a pragmatic case that aspiring developers should learn React as quickly as possible to access the job market, drawing on his own bootcamp experience. Dustin pushes back hard, arguing developers should master fundamentals first so they can move fluidly between front end, back end, and mobile.
Christopher shares a personal anecdote about teaching his partner's twelve-year-old brother Swift via Apple's Playgrounds, sparking a side debate about Python versus Swift as a first language. Tracy notes that she learned fundamentals briefly before jumping into a framework and found that approach effective. The group agrees there is no single right path, but the tension between employability and deep understanding remains unresolved.
00:28:09 - TypeScript, tRPC, and the T3 Stack
Anthony surprises his co-host by announcing he has finally embraced TypeScript, thanks to the Create T3 App stack combining Next.js, Tailwind, tRPC, and Prisma. He explains that tRPC delivers end-to-end type safety without the overhead of building a full GraphQL API, which finally made TypeScript's benefits click for him.
Christopher and Dustin agree that TypeScript shines for API-to-client interactions but remains painful inside React itself — particularly around useEffect, useRef, and prop typing. The group debates the many ways to type React components, with Christopher lamenting the lack of a single canonical pattern, while Anthony argues that opinionated frameworks like Redwood and T3 solve these issues through enforced conventions.
00:35:07 - Conventions, Meta Frameworks, and Picking the Right Tool
Tracy observes the irony of React developers now craving the conventions and guardrails that Angular and Ember offered years ago. Anthony agrees the pendulum is swinging back toward opinionated tooling but believes it will never fully return to a Rails-like monolith. Christopher compares JavaScript's evolution to a metronome, oscillating between maximum and minimum abstraction.
Dustin highlights Astro's explicit documentation telling users not to build dynamic dashboards with it, and Anthony argues every framework should clearly state its intended use cases. The group discusses how Gatsby's attempted comeback, Next.js's ISR feature, and Remix's positioning each carve out different niches, reinforcing the theme that choosing the right framework for the right job matters more than chasing hype.
00:44:20 - Predictions and Farewell
Each panelist gives their one-word prediction for the dominant framework in five years. Christopher picks Qwik, Anthony sees Solid and Qwik as the top contenders but questions whether they can win hearts and minds, and Dustin pragmatically bets on Next.js retaining its lead thanks to Vercel's backing and community responsiveness. Tracy agrees with Dustin but hopes Solid and Qwik join the top tier.
The episode wraps with Tracy summarizing the core takeaway: JavaScript lives in a perpetual identity crisis, and that restless reinvention is both its greatest strength and its most exhausting trait. Christopher closes with a parting quip that the identity crisis only exists if you spend time on Twitter, leaving the conversation on a lighthearted note at the 00:47:36 mark.
Transcript
00:00:01 - Theme song
Come on, everybody, let's go. Da da da da da da da da da da. Yay! Query. Yay! Query the whole lot. Yeah, the query too.
00:00:22 - Announcer VO
You're listening to the Modern Web Podcast. For more podcasts, videos, and events, find us online at [unclear], or follow us on Twitter at Modern Web.
00:00:36 - Theme song
For you.
00:00:37 - Tracy Lee
Hi, everyone, and welcome to this episode of Modern Web. I am so excited today. I have very high hopes for this dynamic conversation we're about to have. My name is Tracy. You can follow me on Twitter at [unclear]. I'm always excited to chat with y'all, and I am joined by my co-host today, Dustin Goodman. Hi, Dustin.
00:01:00 - Dustin Goodman
Hey, Tracy. I'm excited to be here. I'm excited to talk to these guys.
00:01:03 - Tracy Lee
Yes. And if you want to hear more about Dustin after hearing this podcast, you can talk to Dustin on Twitter at Dustin S. Goodman. It's all good. And we have two amazing guests today. We were actually recently on their podcast, Anthony and Christopher. So tell us a little bit about yourselves, your podcast, and let's get going.
00:01:30 - Christopher Burns
Of course. Who wants to go ahead and tell us about the Full Stack Jamstack? Anthony.
00:01:36 - Anthony Campolo
Yeah. So we are the hosts of the Full Stack Jamstack podcast, and we've been doing it now, and we're about to hit the two-year mark at the end of October. So we've been going for a while. We have close to 100 episodes. Twenty of those have not been released yet, but will be released within the next couple of months, so that includes your episode.
And yeah, the Full Stack Jamstack is about: how do you take the Jamstack and stick a database on the end? That's kind of the simplest way for me to describe it. Some people will do that with GraphQL. Some people will do it with tRPC. Some people will do it with all sorts of different tools. But the idea is that you have a full stack in the sense of a front end and a back end. Those two talk together. It's the same project. It's not two projects that become a project; it is a single project. So that is kind of how I would describe it these days.
00:02:27 - Christopher Burns
I would say that's a great description. When I came to start the podcast with Anthony, it was, you could say, almost still a new dynamic on the web. We all had been watching it ourselves, using things like Gatsby in the early days and serverless APIs.
00:02:48 - Tracy Lee
Watching it using Gatsby. Hot take number one. All right.
00:02:52 - Christopher Burns
That was, I would say, Gatsby 2. I've played around with the latest versions of Gatsby, and they're not that bad these days. They're not that bad. But back in the day... Then obviously RedwoodJS came out, Blitz, Bison, and it really started this, I would say, new wave of JavaScript.
And we wanted to jump in and start communicating our love for it, and really tell people what it was all about and how it was different from the Jamstack, and how we could take this more marketing-website kind of technology and build full-stack applications. And that's where Full Stack Jamstack came from.
00:03:32 - Tracy Lee
FSJam, I love it, and I'm so excited about the conversation today. We were recently on y'all's podcast, and we had so much fun chatting. So, hot takes: React is dead, new frameworks are up, down with React. This is a terrible way to start the podcast, but it's probably not too wrong from the conversation we're about to have. Although React will never die, I truly believe that.
00:04:06 - Anthony Campolo
Yeah. The way I would frame it is that React has alternatives now, like good alternatives that offer different benefits based on what you're looking for, whether you're looking for a smaller bundle size or better SSR support, or no need for even a client-server split whatsoever because you have this totally resumable app that can be started up on the server or the client and do that kind of independently of any sort of hydration step.
So that's where you have things like Qwik coming in, and you have things like Remix and now Solid Start, which are leaning really heavily into server-side rendering. I think it's very heavily based around performance. Performance is really kind of the main thing, either making it more performant itself or making it more lightweight so that it performs better on the actual device. And I think this is great because performance is something that has been talked about by niche performance specialists for a long time. You have people who get really deep into Lighthouse scores and Core Web Vitals and things like that, and people who get very into benchmarking.
00:05:14 - Anthony Campolo
And those people tend to be really deep in that world. Then the rest of us are just building stuff, and every now and then someone will yell at us that our thing's not performing, like, "Oh no, what do we do?"
So now we're actually thinking about it from the beginning. How do we make our tools enable us to build performant websites from the beginning so we don't necessarily have to think about it? We can have the nice DX we've had with all these other tools, but not accidentally ship this huge, giant, ridiculous, unusable app in the process.
00:05:43 - Tracy Lee
Does everyone have an edge story? I mean, I know, like, you know, Fresh, for example, has an edge story. Is everybody talking about the edge? Do we care?
00:05:54 - Anthony Campolo
Yeah. We've talked about the edge a lot on the podcast, Christopher.
00:05:57 - Tracy Lee
Is everyone edging?
00:05:58 - Anthony Campolo
Thoughts on the edge?
00:05:59 - Christopher Burns
I think, first, to give my thoughts on the edge, I'd love to give my thoughts on React. I personally think that JavaScript is nothing without a constant identity crisis.
00:06:18 - Tracy Lee
Talking about the developers or React? I mean?
00:06:21 - Christopher Burns
Just JavaScript in general. You know, now it's one of the most popular languages. But if you cast back ten years ago, how we coded JavaScript with jQuery and script tags looked completely different from how we use it today. And I think going forward, if we fast-forward five years in terms of just JavaScript as a whole, could it be typed by default? Could it be TypeScript by default? There's a lot of thoughts around that.
But I think when it comes to React, it will always be prevalent. It will always exist, like jQuery. It will never disappear. But I think as time goes on, the split will continue to grow. And as Anthony said about alternatives, the stories for them need to be as good as React. When those stories are as good in terms of tools, plugins, component libraries, CI/CD, all of the things that React has done well and React has done right, except for performance...
00:07:33 - Christopher Burns
Then I think we can see a mass shift away from React. But until that point, I think we're still stuck with React, personally.
00:07:41 - Dustin Goodman
And it's interesting you say that. Oh, you go first.
00:07:45 - Tracy Lee
I was just going to say it's also really funny that we're talking about React being the non-performant person, or framework, in the room. Whereas, you know, a few years ago it was like, yeah, React is the most performant. It's the most lightweight. That's why we use React for performance. And now it's like, no, React is the slowest.
00:08:09 - Anthony Campolo
Well, it's about the different categories. React was the most performant web framework back in the day, but even at the time it would be more performant not to use a framework at all.
And this is the case with Eleventy, which Chris is a big fan of. They're saying you don't need a web framework at all. So if you remove that need, then you're asking for more performance. You're just shipping HTML with inlined JavaScript to do whatever kind of functionality you need, which then plays into kind of the whole islands architecture mindset.
00:08:41 - Dustin Goodman
That feels a lot like what Astro's doing. For instance, they're saying, hey, here's your bundle. You can have a framework kind of around what you're doing, but at the end of the day, we're just going to ship the HTML. That's all you need. You don't really need the JavaScript.
And we actually just had a great conversation with Misko yesterday about Qwik. And it's the same thing: we're not going to ship any JavaScript when we load your website, but then on interaction maybe we'll load stuff as needed. And now it's this optimistic behavior rather than the eager approach, so to speak.
00:09:16 - Christopher Burns
And I completely agree that I think the future is in Qwik and Solid, personally. But like I said, the user story, the one person that I can really say has started to knock it out of the park, is Tanner Linsley with his decoupling of React into other framework choices.
But I also know that Solid does have a lot of great support out there with its own components. It's just that you're always so used to putting, you know, "I need something like an input field," so I put in "react-input-field" and it just shows me everything. But there is a lot more out there, and Vue's been there for some time.
00:10:04 - Dustin Goodman
It's interesting that you said Solid and Qwik kind of are the future, because I kind of look at them. I also look at what React has done, and you start looking at the syntaxes and they're eerily similar. Not that they're the same by any means or stretch of the imagination, but they both rely on a lot of the same ideas under the hood.
00:10:27 - Anthony Campolo
There's a key difference, though, between the two, which is that Qwik took React syntax and said, "We're going to copy this and then put something different under the hood so that people can write the same way and then it'll be performant." Whereas Solid predates React, and React changed to coincidentally look like Solid. Solid looked like Solid back in 2018 when React did not look like React looks today. So they actually, by total coincidence, happened to retroactively copy Solid, is what React did.
00:11:00 - Dustin Goodman
Well, I think that's interesting because a place I was going to go with that thought is if we look back further, five, maybe five years, like we had Angular and we have Vue, which have completely different framework opinions on how we write our components, how we structure our code, and then React. And the Solid paradigm is okay, well, your components are just functions that render JSX and you have your props and here's your state manager.
And the trend feels like all these new frameworks are heading in this kind of Solid, React-style component writing, and away from what was the AngularJS, Angular, and Vue style of component writing. I'm wondering, hot take, do you think that's the direction we're going to head for the rest of our lives? Like, that's the direction of JavaScript and components. We're doing JSX forever? Or is there going to be some new kid on the block showing up in, I don't know, six months, that we're really excited about that's going to change everything we're doing?
00:12:00 - Christopher Burns
Hmm. My opinion would be that, you know, if it ain't broke, don't fix it. When it comes to JSX, I prefer that syntax over, you know, Vue. But at the end of the day, surely we could get to a point where any syntax would work?
00:12:21 - Dustin Goodman
I think that's Astro's attempt. It's like saying, hey, we have this one syntax. And oh, do you want to use Vue here? You want to use React here? Go ahead. We have no problem with that.
00:12:34 - Anthony Campolo
Yeah. There's the Astro approach, which is to allow everyone to bring their own framework and just write it. Then there's the Mitosis approach, which is from the Qwik team, which is to compile everything down to a certain standard.
So I think JSX is going to be the dominant thing that a lot of people are going to write in, but there's going to be tooling that will allow people to write components slightly differently. And there's always going to be DSLs. Marko's kind of like a DSL in a certain respect, and so is Svelte, really. They're domain-specific languages for writing web apps, and they have a whole compiler built in. I think that's always going to be appealing to a certain type of developer.
00:13:14 - Dustin Goodman
It's funny you say Svelte. I was just talking to somebody on my team. He gave a conference talk about Svelte at enterprise scale, and one of the things he shared, he was like, "So who here is actually doing Svelte in the enterprise or was looking to do Svelte in the enterprise?"
And he's at a conference, there's a room of 50 people, and not a single hand went up, which was very surprising to me. So I'm kind of curious. Svelte is also one of those things that are frameworks, not languages. But I guess you could argue it's both. It's starting to trend itself towards the top of the JS charts, like you were saying. Solid's been at the top for a long time. How does Svelte fit into this equation? How do these styles fit into it?
00:13:59 - Anthony Campolo
Well, I think you have to look at the context of what Svelte was built for, which is that it was built for the New York Times to do like graphics for news articles. So being used by the New York Times, like, that's not enterprise, but that's something that's being used by a huge team of developers, and the thing that's being viewed by millions and millions of people.
So it's a question of like, what is quote unquote the enterprise? What does the enterprise want, and what does the enterprise think the enterprise needs? And, you know, that doesn't mean it can't be a useful tool for people building very large, complicated websites. It's just not really appealing to an enterprise developer. It's appealing more to the solo developer, I think.
00:14:41 - Christopher Burns
I think it's also the mass of developers. A lot of times when we see speakers, people who write, people who have a big following on Twitter, they tend to be more thought leadership and ahead of the curve in terms of programming and JavaScript, I would say. So all of them were like, "Why aren't you writing Svelte?"
But if you look at job ads, you'd see that about 70% ask for React. But I think it's also that React is in this evolutionary form. I think React in the next five years is going to look really different. But one of the things that I really wonder about React is how much Facebook still matters.
00:15:49 - Christopher Burns
Because I would argue React is still important because Facebook won't let it go, like it let go of PHP, just for example.
00:15:59 - Tracy Lee
Like PHP.
00:16:04 - Christopher Burns
Yeah. But also a lot of Facebook projects came to the JavaScript open-source community, didn't they? I forgot what the actual group is called.
00:16:17 - Tracy Lee
Yeah. The foundation.
00:16:18 - Anthony Campolo
TC39.
00:16:20 - Tracy Lee
JS Foundation or whatever.
00:16:21 - Christopher Burns
Yeah. Like Jest, Babel...
00:16:23 - Tracy Lee
[unclear]
00:16:25 - Christopher Burns
But React, GraphQL... yeah. React is still in the hands of Facebook now, isn't it?
00:16:33 - Tracy Lee
And it's funny because we're talking about all these meta-frameworks.
00:16:41 - Dustin Goodman
It's also interesting to say that because Angular... I mean, would you argue then that Angular is still around because Google's still holding on to it for the same reason?
00:16:47 - Christopher Burns
Well, if you go to, what is it, that website that's like RIP Google, like all the products they killed, Angular's on there. But they just list that they killed Angular 1 because Angular 1 was Google, but Angular 2 isn't. I don't know.
00:17:04 - Tracy Lee
That doesn't make sense. But okay. Yeah.
00:17:07 - Anthony Campolo
Chris doesn't know any. Chris has never written a single line of Angular in his life. Never. Whoa.
00:17:14 - Christopher Burns
Whoa. I wrote like ten lines, and then I went, "This isn't the library for me."
00:17:21 - Tracy Lee
[unclear]
00:17:22 - Anthony Campolo
If you want to do cool Angular stuff, Analog is the new hotness. Brandon Roberts built a Vite-like meta-framework with Angular. I'm curious to check that out. That's something that would actually get me to use Angular.
00:17:34 - Tracy Lee
That's exciting. Gotta love us some Brandon in there.
What about, I mean, I think also, do you feel like this rise of new frameworks is related to performance or just the stuff we hear on Twitter? Or is it also because some people are just getting sick of React? They're like, man, React has overcomplicated things now. And why is it so difficult? The new modern React now is obviously something very different than it was a few years ago.
00:18:09 - Anthony Campolo
Chris could use React for the rest of his life and he would be perfectly satisfied.
00:18:15 - Christopher Burns
I think it's also like we're a very specific type of developer that wants to know what's coming next, wants to see what's coming next. If you polled, say, a staffer at Facebook, would they really know why they should pick Svelte or Vue over React? They probably don't, and they probably don't care.
And I think because we are specifically in the Jamstack, where so much opportunity has come up so fast for specific use cases, that we have all of these questions. But the people that are building B2B enterprise software, you could say, I think they'll be on React for the next 25 years and it'll be the new COBOL. But for everybody else, especially in the Jamstack, we're just so in tune with figuring out the best path as fast as possible. Other people, yeah, they go with React, for example.
00:19:21 - Christopher Burns
How many projects do you have that still use classes instead of function components?
00:19:32 - Anthony Campolo
Old bagel.
00:19:33 - Christopher Burns
But I bet you if you went to those enterprises, there would be a lot of classes there.
00:19:42 - Anthony Campolo
Well, yeah. And I have so many, so many thoughts on React, just the React thing.
Because for me, in a lot of ways, I built my career on React. Like I learned React in my boot camp, and my boot camp was 80% React curriculum. You learned a little bit of vanilla CSS and JavaScript. You learned React for three months. Then you learned a little bit of Node and Postgres at the end. So learning it gave me the ability to go to a job and say, hey, I know React. Like, you can give me literally a React interview and I can write you a table and have it sort of thing. It's hard to do and it is complicated and it's ridiculous, and there's libraries for this, but it's the skill that the companies wanted and that allowed me to get my foot in the door. So this is why I will still to this day tell anyone getting into web dev: if you want to learn web dev, learn some JavaScript.
00:20:34 - Anthony Campolo
But as soon as you can, just start learning React and get good at React, and that will open doors for you almost no matter what.
Does that mean React is the best technical tool out there for every job, or even any job? Maybe not. Maybe there is literally a better option for every single use case you can possibly think of at this point, but that means you gotta learn that tool. That means you got to spend some time to understand it, and that itself could add enough time that it becomes an opportunity lost to build the thing with React we already knew in the first place. So I think it's great. There's other options. I think people should still learn React. I think React has been the thing that has defined what web development means for the last decade, almost, and probably will for the next ten years. It's either going to be React or things reacting to React. So yeah, there's no simple answer for why there's React or why there's React competitors.
00:21:25 - Anthony Campolo
It's just like, this is the sum total of the entire history of the web. You need to understand the context of what's happening here.
00:21:32 - Tracy Lee
All the Ember and Angular people yelling.
00:21:39 - Dustin Goodman
Oh.
00:21:40 - Anthony Campolo
They lost. They definitively lost.
00:21:44 - Dustin Goodman
I mean, I'm standing over here. I'm turning over a little bit in my premature grave.
I actually don't agree with that at all. Hot takes, my hot take is I think nobody should learn React when they're first starting to learn development. I don't think anybody should learn a framework. I'm actually anti-framework. I'm super anti-framework.
00:22:05 - Anthony Campolo
And get a job and no company will hire them because they don't know a framework.
00:22:09 - Dustin Goodman
No, I agree with that. I think at some point a framework needs to be learned. But I don't think you start with a framework.
00:22:15 - Tracy Lee
Fundamentals.
00:22:16 - Short split interjection
Use a framework. Learn JavaScript.
00:22:21 - Anthony Campolo
You should learn JavaScript. I'm not saying you shouldn't learn JavaScript. I'm saying this is the reality of the job market and you are telling people who are trying to get jobs bad advice if they want to get a job. That's irresponsible.
00:22:32 - Christopher Burns
I think this is really scoped incredibly to the adult audience, as in, like, I'm a banker and I want to go get a software development career. You would say instantly, you know, React. That's what Anthony's saying.
But I actually had this opportunity.
00:22:51 - Tracy Lee
A banker, would you say Angular because banks use Angular?
00:22:55 - Christopher Burns
Maybe. Maybe. And if they're a banker, they probably wouldn't want to become a software developer because I've already got a career. But what I mean is, I had this opportunity to influence somebody's first language in programming at the weekend. So quite recently, my partner's little brother, he's 12 and wants to learn to program. What do you teach him? Where do you start?
00:23:27 - Anthony Campolo
From Scratch, obviously.
00:23:29 - Christopher Burns
Well, actually, something close to that, right? It's a good question. It's like, what do you show them? And I was like, Apple Swift Playgrounds. Yep. I taught him Swift. Thank me later.
00:23:51 - Dustin Goodman
I like that. I'm like, I'm sitting here like, do I actually like that? Yeah, I like that. I would have said Python. Like, I always lean towards Python because it teaches good fundamentals. And that's always been my big preach. I'm going to get on my throne here for a second and preach.
But I've always been like, you should learn your fundamentals because you can take your fundamentals to front end development. You can also take your fundamentals to back end development, iOS, Android. You can go anywhere with fundamentals and then just learn the tooling associated to it. But if you don't have your fundamentals, you're pigeonholing yourself long term now. You can always learn something back down to the fundamentals and then go back up. But I always felt like that was a detrimental way. Now I also say this: I came from an environment where I learned my fundamentals first. That's how I learned. That's how I am where I am.
00:24:41 - Tracy Lee
I learned my fundamentals, and then two weeks later I was like, give me a framework, got into a framework. I was like, the world is my oyster. And that's really when it started clicking for me because, you know, you can't do much without a framework.
But it's funny you say that, Dustin, this whole learn-the-fundamentals thing, because I feel like, you know, six years ago maybe, when it was kind of like Ember, Angular, and React, Vue wasn't on the scene yet, people were having these arguments, probably still have them now, about you shouldn't use a CLI. You shouldn't use a framework. You should do it yourself because all these tools are doing the work for you and you're not learning what's actually happening, so how are you going to debug? But then you talk to all these new frameworks, and what are they doing now?
00:25:36 - Tracy Lee
You know, during our state of the web events, it's like, yeah, we're basically meta-frameworks. We're creating all these frameworks on top of it so you don't have to deal with all that stuff. So you can just get productive.
And all these developers now who I feel like, you know, five, seven years ago were saying, like, learn the fundamentals, now they're like, man, I just want to get productive. Thank you for giving me everything out of the box. It makes it easy to start, and I am up and going.
00:26:02 - Anthony Campolo
So yeah, and I want to be clear here, I'm not saying don't learn the fundamentals.
Like I've said before, the ultimate combination would be someone who spends four years getting a whole CS degree, learns literally all the fundamentals, learns a bunch of programming languages, like functional programming languages and all sorts of stuff, and then they do a boot camp and get like a year of concentrated build websites, build web applications kind of thing. That to me is the ultimate curriculum.
The problem is, how many years of fundamentals do you tell people they need to learn? Because if someone says, "I need a job today," and it's like, okay, well spend the next four years learning the fundamentals and spend 40 grand on this college, and they have $0, or maybe they're in debt, and they're saying, like, what?
00:26:47 - Dustin Goodman
Look, totally different, completely different perspective.
00:26:50 - Christopher Burns
I went to university, as you say, college, and I did it for three years, and it was the most boring three years of programming of my life. Yeah. I never wanted...
00:27:00 - Anthony Campolo
To...
00:27:01 - Christopher Burns
Program ever again.
00:27:03 - Anthony Campolo
Wasted it.
00:27:03 - Christopher Burns
[unclear]
00:27:05 - Dustin Goodman
I actually agree with Chris. I did a three-year program as well, and I could say I could identify very specifically what over the course of those six semesters, I would take, boil it down to a six-month intensive, and say, this is what you should do.
Like there's six months of valuable college degree CS material they teach these days.
00:27:24 - Anthony Campolo
But you can't learn that, though. And actually, that's not the way learning works.
This is like me having an education degree; it's very useful, and you can't just shove all the knowledge into someone's brain Matrix-style. You can't just download stuff into people's brains. It takes time and reps.
00:27:42 - Tracy Lee
Although it does sound nice, you can also be successful without a CS degree.
You know, people tell me with CS degrees, like my husband has a CS degree and he's like, yeah, I can tell the difference between somebody who has a CS degree and doesn't when you talk to them, but like, does it actually matter? I don't know what I don't know, and I'm still doing fine. It's okay, you know?
00:28:06 - Anthony Campolo
But look.
00:28:09 - Christopher Burns
You know, there's one thing I know about university and one thing I know about React, and that big O notation should probably come in sooner or later when we talk about React performance.
00:28:22 - Tracy Lee
Dustin clapping over here.
00:28:23 - Dustin Goodman
I mean, yeah, I agree with that, I think. If you can take anything out of a four-year, three-year degree, like teach big O as you're teaching React and then we're good. Like, I'll concede.
00:28:37 - Tracy Lee
So anybody who doesn't have a CS degree and doesn't know what this big O thing is, now you know exactly what you need to do, and you are all set.
00:28:45 - Christopher Burns
Basically.
00:28:47 - Anthony Campolo
You can get that from a couple of YouTube videos.
00:28:48 - Tracy Lee
All you need to do.
00:28:49 - Anthony Campolo
You don't need a CS degree to learn it.
00:28:51 - Tracy Lee
I don't even know what the big O is, but.
00:28:53 - Christopher Burns
Can you do big O in JavaScript? That's the true question.
00:29:01 - Anthony Campolo
Can we talk about TypeScript for a second here? Actually, I have a TypeScript topic. This is the first time ever. Chris has always been the TypeScript advocate for the entirety of FSJam, but I finally have a TypeScript topic. I learned a TypeScript framework that I think finally fixed TypeScript, at least for me. Okay: Create T3 App.
So this is from a community of people built up around Theo, who is a streamer and very, like, if you want hot takes, he's the dude to talk to. But the T3 stack is Next.js, Tailwind, tRPC, and Prisma. So it's very similar to something you would get almost like Redwood, but without the GraphQL API, which makes it more similar to Blitz. But the important key point here is tRPC, which creates a type-safe protocol between your front end and back end, which allows you to just write pure functions that call into your back end and get end-to-end type safety. So it gets you the benefits of a GraphQL API with end-to-end type safety.
00:30:03 - Anthony Campolo
A GraphQL project specifically with TypeScript, which you can do with Redwood. It gives you that, but without needing to create the whole GraphQL API because it's using tRPC.
So it's a really interesting project, and I've avoided TypeScript up to this point because of the whole build complexity around it. Just like you're saying with the fundamentals, TypeScript gets you really far away from the fundamentals. You learn this whole new language built on top of the language. But I finally get it. I finally see the benefits. I had a template or a project or a framework that handed the benefits to me in such a nice, immediate way that I was like, "All right, cool, I get this. Yeah, I can see why people would want to do this. I'm probably going to use this into the future now."
00:30:45 - Tracy Lee
This is just such a fun conversation because for me, I'm like, what, not use TypeScript? I don't know how to function. Like, you put me outside of TypeScript and I literally can't do anything. I mean, I'm exaggerating a little here, right? But like, oh my God, TypeScript is like...
00:31:04 - Anthony Campolo
That's what Chris... That's how...
00:31:06 - Tracy Lee
You know. Yeah. Look, I, if anything...
00:31:11 - Christopher Burns
I would say, if anything, at least type any in there. That's as low down as I'll get.
Now, like, JavaScript, I love the language, but to me TypeScript just autocompletes far better than JavaScript. And I think the biggest problem is, as applications grow in complexity and props and prop drilling get so much more prevalent, TypeScript really comes in handy. But also TypeScript for React is still goddamn terrible. Someone should fix that.
00:31:51 - Anthony Campolo
Where it...
00:31:51 - Dustin Goodman
Comes in. This is literally what I was about to say.
00:31:55 - Christopher Burns
It won't fix some things about React and TypeScript.
00:31:59 - Dustin Goodman
It fixes like the thing that tRPC, which is the same as GraphQL... they're both RPCs. So they both solve the problem of you can get types, and that's great for your API-to-client interactions.
But what Chris is saying, 100% agree, is the second you write a useEffect or a useRef or anything that's nonstandard typed context, just stop using TypeScript immediately. I'm with Chris.
00:32:26 - Anthony Campolo
Because this is where React Query comes in, though, because you're not writing useEffects. If you use React Query.
00:32:31 - Christopher Burns
No, you still use useEffects even if you use React.
00:32:35 - Anthony Campolo
But you're not literally writing them yourself. So have they built types on top of it?
00:32:40 - Dustin Goodman
Well, I think what we're both saying, though, is we're not talking about just the data fetch itself. We're talking about actually when you have an effect on the page or something where you need to be listening or reactive.
00:32:50 - Christopher Burns
Props, props, children. We had this with Joshua. How do you type children? And also, what about func: FC? And what is, like, if someone could answer me the million-dollar question, the correct way to write a function: is it function name() or is it const name = () =>? They don't make a difference, but it should, because this is one of these things where it's like JavaScript allows you to do anything. So some people code it one way, some people code it the other. It's like tabs and spaces in React.
00:33:35 - Dustin Goodman
Except I don't think the tabs and spaces is an argument anymore. I saw the accessibility argument and I'm convinced, and I think anybody who's read that and isn't convinced at this point is wrong. I'm saying it. You're wrong if you think you shouldn't be using tabs.
00:33:50 - Anthony Campolo
I've talked to Ben about this. He's like my accessibility go-to person. He says, yes, you're correct. The accessibility argument holds, but it's not like a do-or-die kind of issue for accessibility people. It's a nice-to-have, not a need-to-have. So yeah, I agree with you. But it's not like I think people should super-duper stand on that soapbox.
But to go back to what Chris was saying, the framework does solve those. All those issues you just named are, yes, the things that those frameworks solve because it gives you conventions. It tells you, hey, we're going to type these things this way, and then you're going to get the end-to-end type safety, or we're just going to debug that, we're going to make it work. And so as long as we all agree on conventions, you're a Redwood guy. You get this. Then this stuff will work at the end of the day.
00:34:35 - Christopher Burns
I'm pretty sure it works in terms of the data, but not in terms of prop typing, because component types are like this.
00:34:45 - Anthony Campolo
You'll have to use it to find out, I guess.
00:34:48 - Christopher Burns
Yeah, just make a component with props and type the props. There's like 20 ways to do it.
00:34:54 - Tracy Lee
I have to say, though, that I just feel like coming from Angular and Ember, and React being my third love, not my first or second.
00:35:07 - Anthony Campolo
Be your...
00:35:07 - Tracy Lee
Fourth. I'm thinking maybe. Well, Vue is my fourth love. But just hearing "convention over configuration" and all these things, I feel like React, when you get down to it, from the very beginning the reason people loved it, or the conversations that were had a few years ago, was because you can just do anything. It doesn't have opinions. There's no guidelines. Just write JavaScript. It's totally fine. And now you're just rolling into this like, "We want the conventions. We need this to scale. We want everything done for us. We need a meta-framework built on top of this," et cetera, et cetera. And I swear every time I hear this, I want to go back and pull up all the Angular and Ember and React arguments that happened.
00:36:12 - Tracy Lee
Yeah. Because, you know, the argument is so different now. And the React community is moving towards this whole "please give me stuff, please give me guardrails, please tell me what to do."
00:36:22 - Anthony Campolo
This is why I'm super glad that people have podcasts because I'm a fairly new developer, but I've listened to podcasts going back like ten years, and so I'm aware of all this historical context.
And I feel like me and Chris, we're still actually fairly counterculture here, in that we're advocating for some of the most opinionated solutions that exist. Redwood is the most opinionated way you could make a React app, and most people have not gone that far. Most people really aren't using Redwood right now. Most people are using Next.js. Next.js is less opinionated than Redwood and more opinionated than React, but it sits in the middle. So we have not fully swung back yet to Rails, and I don't think we ever will.
00:37:06 - Christopher Burns
I'm sad.
00:37:07 - Dustin Goodman
By that, I mean I want us to move all the way back.
00:37:11 - Anthony Campolo
We'll start using...
00:37:13 - Christopher Burns
It is. JavaScript is a bit like a metronome. It constantly goes back and forth, and we go from "we want all the abstraction" to "no abstraction" to "all the abstraction." And literally the levels go from Create React App and do everything yourself, and you could even go lower now, all the way up to something like Redwood and Create T3 App.
And I think there's a place and reason and need to have both. I think it really comes down to picking the right framework and choice for the right situation. And a lot of developers will just pick Next.js, myself included.
00:38:08 - Tracy Lee
That's...
00:38:09 - Dustin Goodman
Well, you're...
00:38:10 - Tracy Lee
Just loving it.
00:38:11 - Dustin Goodman
Oh, I want to throw into this: what about Remix? So now you've got something that sits almost between Next and Redwood, Anthony.
00:38:20 - Tracy Lee
Somebody needs to just, like, rank them.
00:38:22 - Anthony Campolo
I would put Remix next to Next in terms of what they do. If you take a Remix starter that has a built-in ORM and deployment target, then you're getting close to the opinionation of Redwood. But that's only if you're using one of the Remix stacks templates.
Remix by itself is essentially equivalent to Next, but with different conventions, in my opinion.
00:38:47 - Dustin Goodman
I think that's a fair opinion, which I think actually maybe brings up an interesting thing that you're starting to touch on a little bit earlier too, which is this opinion, not only on how code should be structured, but an opinion for usage.
So Astro, they have it in their documentation, and I love that they explicitly call this out: if you use Astro for anything beyond a content site, like you're trying to do dynamic dashboards or anything that's really there, don't use us. We're not the right tool for you. You're going to lose all the benefits of what we gave you.
00:39:16 - Anthony Campolo
Why are they building SSR, though? Like, obviously they're still playing for that. They're saying that because they don't want to have to deliver the perfect SSR experience, but they're offering SSR.
00:39:30 - Dustin Goodman
Well, I think they're offering SSR in the sense of like, hey, you can do this dynamic thing. It's possible. And in a lot of cases with these static sites, there's data that needs to come from a CMS that is somewhat dynamic. Or even if you want to build for the edge, you're going to need something that's a little more dynamic.
And so they're optimizing for those aspects and not so much for the, oh, well, here's a database, an ORM, and like do all the things and create all these rich content pages. It's more like get your static content, type it in, display. And I think that's what they're going for. That's been my use case.
00:40:05 - Anthony Campolo
They are, yeah. But I think part of the dream is that you could just slap Prisma on that baby and make it work. So I think it's possible, even if they're not trying to support it.
But that's kind of the case me and Chris have been making for the last two years, that you can do it. Some frameworks make it easy. Some frameworks don't. It's just a question of what are you trying to do? Think about your use case and pick the right tool for the right job.
00:40:29 - Dustin Goodman
Well, and I think that's where I was heading with the question, is, should there be the argument that we go like Astro saying, "You should use us for this use case"? Should other frameworks get opinionated in that direction?
00:40:41 - Anthony Campolo
Yes. Every framework should specifically say what it should be used for and what it shouldn't be used for. And people who say it should be used for everything are lying to you, and they're terrible.
00:40:49 - Tracy Lee
And then everybody will use it for everything else, like building non-static sites on all the static site generators.
00:41:02 - Christopher Burns
I think Anthony is saying my opinion that I've drilled into him through the podcast many times, because I am very much a framework user that has been burned many times. And I think something that's really important to wrap up on, in terms of frameworks, is that when we think about speed, it is always going to change. A website that's compiled down to pure HTML will always be faster than content that needs to be pulled from a CMS. There's no two ways about it. One has more calls in it. I think each category really needs to be defined much better.
And we're seeing cross-pollination a lot right now. Gatsby is coming back from the dead with Gatsby 5, really trying to take on Next.js, but Next.js is saying we can make the whole web faster. I would argue you shouldn't really build in Next.js for a marketing website, but everyone is, even myself included, because every other option just doesn't have that support...
00:42:16 - Christopher Burns
That's the support that I feel Next.js has when the argument is, I need to pull data from a CMS, say every five minutes, because it could change. Next.js does that best. But I think Next.js is way too overcomplicated for everything else. But that one feature, that one feature, forces, I think, a lot of people to use Next.js over everything else.
I think that the times are changing. And like I said at the beginning, JavaScript goes through this metamorphosis and identity crisis every few years. But I think as a language we're getting increasingly faster at working out the best use case. And I think we're all still sitting here going, we're not there yet. This ain't PHP that moves very slow. It's a very fast language. And personally, I like the speed, even though everything breaks.
00:43:16 - Anthony Campolo
Yeah. And I think it's funny that you just said you drilled into me because from my perspective it was the opposite. I spent like a year trying to convince you to use literally anything that wasn't React, and then you eventually built some stuff with, like, Svelte and Vue.
But yeah, I think every different tool is going to be suited for some things, can be used for some things, and absolutely should not be used for some things. Understanding that kind of differentiation between each of them is really important. I try to hit on that anytime I advocate for any of these frameworks, and that's something that we try to ask our guests anytime we have them on FSJam. We talked about this on our Responsible Advocacy episode. I think that being a responsible advocate and advocating for something in a responsible way is really important, and it allows us not to totally get shilled all these things, to get a better understanding of them, and hopefully we can all come to an understanding of what our tools are and what they're for.
00:44:20 - Christopher Burns
Yeah. I have one final question. If you could pick, if you... it's a one-word answer. If you could think this framework is going to be it in five years, like Next.js is today, which framework is it?
I will go with Qwik, which is where I want it to be in five years.
00:44:41 - Short split interjection
Oh, that's a tough one.
00:44:42 - Tracy Lee
I mean, that is such a... that makes me feel good about Qwik.
00:44:49 - Anthony Campolo
I think Qwik has the technological potential. I don't know if it'll be able to make the case to people that it's actually different enough. I think Solid has more momentum than Qwik, even though they're more so technologically riding the previous wave. So I think Solid Start and Qwik City are going to be the two to look at. And I'll be very curious to see how those two face off.
00:45:13 - Dustin Goodman
I'm right there with Anthony, except I think the reality is Next is still going to be winning in five years.
I think they have all of Vercel backing it at this point, and they're going to keep making incremental improvements. They do hear feedback, and they've been very good about hearing feedback from the community. So I'm actually going to put my marbles in that court. But I don't want it to be.
00:45:39 - Tracy Lee
I'm going to have to agree with Dustin, but I feel like the conversation hopefully will be, you know, Next, Solid, and Qwik. I'm also very sad that Remix was not mentioned here, having high hopes for that.
But yeah, I mean, y'all have definitely determined what I'm going to focus on. I've been talking to Dustin about like, why can't we use Fresh? Let's use Fresh. Let's do all the Fresh things.
00:46:07 - Anthony Campolo
Fresh is cool too. We didn't have time to talk about Deno. And I think both me and Chris have tried out Remix as well. I have some reservations about the Remix team, but I think Remix is also a cool piece of tech.
00:46:19 - Tracy Lee
So many hot takes. We definitely have to have y'all back on this podcast. It was so much fun chatting. Again, these guys are always hanging out on FSJam. You can follow them on Twitter at FSJam Org. Again, just amazing conversations. Thank you so much for being here.
I think that my conclusion and takeaway from today is what we started off the podcast with, which is JavaScript is constantly in an identity crisis and will continue to be for the next foreseeable future. So make sure to tune in to our next podcast, and we'll see you soon. Thanks so much, everyone.
00:47:06 - Christopher Burns
Thank you so much for your time. And to say one more thing, it's not an identity crisis if you never look at Twitter.
00:47:14 - Theme song
Come on, everybody.
00:47:18 - Announcer VO
This podcast is sponsored by This Dot Labs, a framework-agnostic consultancy that specializes in JavaScript. You can find them at thisdot.co.
00:47:36 - Theme song
For all of your friends. And you do. Yay! Query, shout it. Yay, queries too. So come on, let's go 'cause we got a show for you.