skip to content
Podcast cover art for Live at Vite Conf
Podcast

Live at Vite Conf

Hosts chat about frameworks, Vite Conf highlights, static site generators, and offer practical advice to a beginner developer exploring Node.js

Open .md

Episode Description

JavaScript Jam Live discusses ViteConf highlights, advises a beginner on learning paths, and explores the "What the Framework" tool for choosing JS frameworks.

Episode Summary

This episode of JavaScript Jam Live opens with a recap of ViteConf, a 24-hour virtual conference featuring talks on Vite integrations with various frameworks, including notably short lightning talks that attendees found packed with value. The conversation shifts when Rahma, a self-taught developer of two years focused on vanilla JavaScript, asks for advice on leveling up. Ishan recommends solidifying core JS fundamentals like closures and arrow functions, then picking a framework by exploring TodoMVC, while Anthony Campolo encourages her to understand state management as the motivation behind frameworks and suggests building a Replit clone as an achievable starter project. The bulk of the episode centers on "What the Framework," an open-source site at whattheframework.dev that guides users through a simple flowchart to recommend a JavaScript framework based on whether their site is static, hybrid, or fully dynamic, and whether it needs cross-page state. The hosts praise its plain-language framing but note it omits questions about developer experience level and team context. A guest introduces Zola, a Rust-based static site generator that built a hundred-page markdown site in seconds compared to eight minutes on Gatsby. The episode closes with a broader discussion about framework fatigue and "shiny object syndrome," with Anthony arguing that real mastery typically comes from being paid to use one framework consistently rather than cycling through many.

Chapters

00:00:00 - Introduction and ViteConf Recap

Scott opens the show with the usual welcome to JavaScript Jam Live, explaining the format and inviting audience participation. He and Brad discuss ViteConf, which ran as a 24-hour livestream the previous day, re-streaming talks overnight so viewers worldwide could catch them at convenient times.

Brad shares that he attended React Alicante in Spain and caught COVID there, and mentions that ViteConf's recordings were pulled after the stream ended, with individual talk videos expected to be published later. They highlight several talks including a Deno Deploy with Vite demo and note how the shorter lightning talks—some as brief as five minutes—felt especially dense with value compared to longer presentations.

00:05:21 - Welcoming Audience Participation and ViteConf Talks

Scott reiterates the open-mic format and encourages beginners and experienced developers alike to come on stage. He previews some of the ViteConf talks he and Ishan are most excited about, including a desktop apps talk featuring Tauri and a frameworks panel with prominent figures like Daniel Rowe from Nuxt, Ben McCann, and Brett Little.

Brad and Scott compare the value density of lightning talks versus full-length presentations, noting how cramming content into shorter windows forces speakers to cut filler and deliver focused, actionable material. They discuss how several framework-specific Vite integration talks were on the schedule and express hope that the individual recordings will be posted to YouTube soon.

00:12:37 - Beginner Advice: Rahma's Learning Journey

Rahma joins the stage and shares that she's been learning JavaScript on and off for two years as a hobby, recently exploring Node.js and APIs. She asks whether her approach of tackling unfamiliar SDKs to push herself beyond her comfort zone is effective. Scott affirms her strategy, emphasizing that discomfort signals growth.

Ishan digs deeper, asking about her goals, and Rahma reveals she's inspired by educational tools like Replit. Ishan advises mastering vanilla JS fundamentals—click handlers, closures, spread operators—without letting perfectionism stall progress, then picking a framework using resources like TodoMVC to compare implementations. He recommends choosing the framework with the largest ecosystem relevant to her geography and interests, and building hands-on projects to cement understanding.

00:23:52 - State Management and Framework Motivation

Anthony Campolo suggests Rahma explore why frameworks exist by studying state management concepts, arguing that understanding the problem frameworks solve provides motivation to learn them. He proposes building a basic Replit clone as an achievable beginner project, breaking it down into an editor panel, an output panel, and real-time saving functionality.

Anthony acknowledges the hosts' React and Next.js bias but recommends Vue as a friendlier starting point due to its code structure, while also suggesting React's larger resource ecosystem makes it practical. He points Rahma toward Redux and React's Context API for state management fundamentals. Ishan adds nuance, noting the tradeoff between piecing together prebuilt components quickly versus truly understanding underlying principles.

00:29:00 - Exploring "What the Framework" Tool

Ishan introduces whattheframework.dev, an open-source site designed to help developers choose a JavaScript framework through a simple flowchart. He walks through its three entry points: purely static content sites, hybrid sites with some personalization, and fully dynamic per-user sites. He praises its plain-language questions that avoid jargon like "Jamstack" or "SPA."

The tool recommends different frameworks depending on whether the site needs cross-page state management, surfacing options like Eleventy and Astro for static sites, Next and Nuxt for stateful apps, and Qwik and Redwood for stateless dynamic pages. Ishan highlights how the tool uses familiar examples—Gmail, Discord, Twitter—to explain technical concepts like state persistence, making the decision process accessible even to non-technical users.

00:36:42 - Zola: A Rust-Based Static Site Generator

A guest introduces Zola, a Rust-powered static site generator he discovered while evaluating Astro. He explains that Zola built a hundred-markdown-file site in seconds, compared to roughly eight minutes on a patched Gatsby setup. Its appeal lies in being a single binary with no plugins and minimal configuration overhead.

Ishan notes that Zola is already documented in Layer Zero's framework guides and compares it to Hugo, another fast generator written in Go. The guest explains his use case—a personal markdown wiki he wants to eventually connect to a CMS—and Ishan suggests Eleventy as a JavaScript-based alternative offering more customization escape hatches, while acknowledging Zola's simplicity is ideal for straightforward markdown-to-HTML workflows.

00:43:42 - Framework Selection, Developer Experience, and Progressive Enhancement

Scott and Ishan discuss dimensions missing from the "What the Framework" tool, particularly developer skill level and team structure. Ishan notes that framework choice depends on ecosystem needs, UI library compatibility, and theming options—factors the tool doesn't address. The conversation touches on Vue's progressive adoption model and the Enhance framework's accessibility-first, web-components-based approach.

Ishan connects progressive enhancement to both developer experience (adopting a framework incrementally) and user experience (ensuring pages work without JavaScript). Scott mentions a recent conversation with the Enhance co-founders about their progressive design philosophy and hints they may appear on a future episode of JavaScript Jam.

00:51:01 - Framework Fatigue and Shiny Object Syndrome

Anthony raises the issue of "shiny object syndrome," where junior developers cycle through frameworks without mastering any, learning the same introductory steps repeatedly instead of progressing deeper. He argues that real specialization typically comes from being employed to use a specific framework, which forces sustained focus and eliminates decision paralysis.

The hosts compare this to the Ruby on Rails era when a single dominant framework simplified the choice. Ishan pushes back slightly, praising Astro for deferring the framework decision by supporting multiple component libraries within one project. Scott closes the show by teasing next week's episode on developer relations, thanking the audience, and reminding listeners they broadcast every Wednesday at noon Pacific.

Transcript

00:00:01 - Scott Steinlage

Hey, hey. What's up, everybody? So let me see here. I'm gonna bring myself in here. There we go. Boom. Start listening. There we go.

00:00:23 - Brad

And...

00:00:25 - Scott Steinlage

Invite myself as a co-host here. Ta-da. There we go. Welcome, welcome. Welcome to JavaScript Jam Live. Okay. Boom. D.B., what's up, dude? Welcome. All right. Just trying to get my bearings here. Looks to be good. Perfect. All right. Welcome to JavaScript Jam Live. This is where we talk about everything JavaScript and web development related. We do this every Wednesday at 12 p.m. Pacific Standard Time, and we have a good time doing it. If you're out there in the audience and you're a beginner or you've been doing this for a very long time, either way, we want to hear from you. Really do. Like, seriously. So get up here. No, I'm kidding. We really want to hear from you guys, so feel free to click on the bottom left-hand corner there and request to come up. Sup, Brad? What's going on? Thanks for coming. Just request to come up, and we're more than happy to have you, whether you want to state an opinion, ask a question, say something about the current topic at hand, whatever. Feel free. We'd love to hear from you today. We had, well, earlier yesterday mainly, we had ViteConf going on. That was interesting.

00:02:05 - Scott Steinlage

We might touch on that a little bit. Yeah, it was interesting how they did this 24-hour thing with it, where it went on from 9 a.m. yesterday to 9 p.m., and then it was like, after that, the schedule showed, right? And then after that, for the next 12 hours, making it 24 total, they re-streamed those talks. I believe that's how they did it, which is kind of interesting, and I guess that's so everybody all around the world could have it at a time that's convenient for them, which is pretty cool. Definitely thought out, for sure. So yeah, Ishan will be joining us here shortly. Looking forward to having him jump on here with us. As always, we're gonna have some great conversations. Looks like we have a request from Brad. What's up, bro? That is a speaker. There you go, Brad. Connecting. There's always a nice delay.

00:03:34 - Brad

Hey, Scott.

00:03:35 - Scott Steinlage

Hey. Oh man. Long time no talk. How you doing?

00:03:39 - Brad

Yeah, I've been chilling in the audience these last few weeks. I was off with COVID, unfortunately, which on the good side, I caught it at a React conf. So a few weekends ago, we had React Alicante down here in Spain.

00:03:55 - Scott Steinlage

Right.

00:03:56 - Brad

Good talks. Met some good people there. Yeah, I got an unfortunate takeaway from the conference. But yeah, coming back from that. And yeah, you were just chatting about ViteConf, so I thought I'd jump on board. Unfortunately, I missed it, but I saw the recording was up, basically what you were just saying there, the 24-hour thing, today. So I was like, oh, it's still up on YouTube. I'll just play it back later. And I just, a couple of hours ago, tried to do that, and it's gone now. So they took it down once it finished, and they're gonna put videos.

00:04:30 - Scott Steinlage

Yeah, I was gonna say, I think they took the stream down and then hopefully they put it back up on YouTube as individual talks or something, or, you know, they were...

00:04:45 - Brad

Saying that in the chat, like, we'll let you know on Twitter or something when they've got all the talk chapters put up on individual videos. Yeah, yeah, looking forward to seeing that. All I saw was the Deno talk about Deno Deploy with Vite, which, yeah, pretty cool.

00:05:07 - Scott Steinlage

Yeah, there were lots of good ones with different frameworks with Vite. Yeah, yeah. I know there's some big

00:05:14 - Brad

names up in there, and the sponsors, I was like, yeah, you're going to get some pretty good content from that.

00:05:20 - Scott Steinlage

Yeah, for sure. There were definitely some big names. Awesome. So anybody else in the audience participate or attend ViteConf yesterday, or this morning, last night, when they were streaming it over again? Feel free to raise your hand if you want to come up. All right, so I'm just going to finish my little spiel here. So like I said, if you're a beginner or you've been doing this for a long time, on JavaScript or web development in general, it doesn't matter. We want to hear from you, so feel free to put your hand up. Come on up. In fact, that's when we get some of the most value out of this, just like when Brad raised his hand and came up here and started talking. We love it when you guys do that. We love to have you guys participating and joining us up here, so we've definitely gotten some really good talks when it comes to that. Yeah. So I know Ishan should be here in a couple minutes and really kick things off even more. So, but let's see here. Speaking of ViteConf, I know there were some good talks that I was looking forward to checking out as well, and so was Ishan.

00:07:21 - Scott Steinlage

There was like the... which one was it? There's so many good ones in here. And actually, I heard a lot of people saying that the shorter talks were actually really good, right? Because it was so jam-packed, good stuff in such a short period of time, instead of kind of spread out over 15, 20 minutes or whatever.

00:07:59 - Brad

I must say, where I was this other weekend at React Alicante, same for the talks there. Obviously you've got long talks, but what they call the lightning ones were like, I think, 15, 20 minutes or something instead of 40, 50 minutes. I guess the person putting on the talk has got so much to share, and they cram it down into this smaller presentation, but there's still so much value in there. And you come out of that talk, I did anyway, feeling like, oh, you've learned a lot there. Where, when you're in these longer ones and it's more about one topic, I mean, they provide you with value, obviously, but it's spread out a bit. There's more space to put in some memes and jokes in there and stuff, whereas the lightning ones are like, boom, straight to the point. I'm talking about this, and this is what it is, sort of thing. But I don't know if it's based on the same sort of idea.

00:08:55 - Scott Steinlage

Yeah, absolutely. And some of these were even really short. There were several that were like four, five, six, eight minutes long. Yeah. So it's interesting if they actually stuck to the six-minute talk, or if that was literally it, because I don't know, some of these are probably prerecorded, I would imagine. Right, right. And so yeah, that would be interesting to hear, like, how much value they put out there in like six minutes. But I know a couple JavaScript Jams ago, we were talking about Tauri, T-A-U-R-I, excuse me, for helping to build better apps for native applications and things like that.

00:09:45 - Brad

Right.

00:09:45 - Scott Steinlage

But there was a talk here on desktop apps actually utilizing Tauri, however you would say it, which would have been cool to check out as well. But I know a big one that Ishan wanted to listen to was a panel that they have, the frameworks panel, that included Daniel Rowe, Ben McCann, Brett Little.

00:10:18 - Anthony Campolo

Nice.

00:10:19 - Scott Steinlage

A few of those folks, right? So that was, like, a 45-minute panel, essentially. But I bet that was a really good conversation. I'll be looking forward to listening to that when that comes out, hopefully soon as well. Feel free to come on up if you want to talk, or if you were interested in Vite or anything else you want to bring up. Yeah, it looks like there was also... so you were speaking about the Deno and Vite. Yeah, that was supposed to be five minutes long. Man.

00:11:11 - Brad

Oh yeah, that's what I mean. They were literally showing what the title says. You know, there's no going deep into what Deno was or anything. Like I said, that's the only thing I've seen of it, and some chatter from the presenters, sort of, however you call them. But yeah. And it was literally, you know...

00:11:33 - Scott Steinlage

Okay.

00:11:34 - Brad

Showing you, from a code perspective, getting up a Deno-built app with Vite and stuff.

00:11:44 - Scott Steinlage

Yeah, right, absolutely. There's a Bun and Vite on here too, but that's a three-minute conversation. Oh, looks like someone's requesting here. Let's see. There we go. What's up? Looks like you're still connecting here. Give it a chance to catch up. Can you hear us? It looks like you're muted there. You can hit the little mic button. Come off mute if you'd like. How do you pronounce your name?

00:12:37 - Rahma

Hi. My name is Rahma.

00:12:39 - Scott Steinlage

Hi. Is it Rachel? Is it Rahma? Okay, cool.

00:12:42 - Rahma

Yes, [unclear]. Okay.

00:12:49 - Scott Steinlage

Don't be nervous.

00:12:51 - Rahma

Yeah, I think it's kind of hard for me to relate with all that you guys have been talking about. I'm kind of like a beginner. Well, not really a beginner. I've been learning on and off for about two years. It's been more of a hobby for me, trying to understand JavaScript and build really cool projects with it. So recently I've tried to do more with Node.js, and it's been a really tough ride. I tried to take this approach of looking at APIs and SDKs and seeing what I can really just put together, so that kind of forces me to learn beyond what I already know. So I think there's a whole lot to learn, it gets really overwhelming, and I'd just like to hear from you guys. What do you think about that approach of mine? I think it's been the easiest way for me to not get discouraged. Yes.

00:13:50 - Scott Steinlage

Absolutely. That's a great question, and I'm so glad that you came up. Yeah, no need to be nervous. Thank you so much for that. Awesome question. We love hearing from people, whether they're beginners or they've been doing this for a long time. It doesn't matter. Thanks again. Yeah, so I'd say, you know, you're doing the right thing. You're taking action, right? You're moving in this step of trying to get uncomfortable. Because if you're comfortable, you're not learning, right? If you're uncomfortable, you're learning, and you're becoming someone that you weren't before, right? So that's really cool that you're making that transition for yourself, and not just that, you've realized that, hey, I can't be sitting in the same spot, otherwise I'm not going to get anywhere, right? So whether it's looking into Node.js and doing that like you've been doing, or whether it's... Ishan, I sent you the co-host invite... or whether it's looking into APIs, or whatever, like you said, right? And yes, it can get overwhelming just because there's so many different things out there, so many different platforms and so many different frameworks, and all these different things, right?

00:15:18 - Scott Steinlage

Especially when it comes to JavaScript, just, you know, so many things out there. But you're doing the right thing by just taking action and getting started in those particular areas. Now Node.js, obviously, that's more kind of like the back end of JavaScript, right? And then there's the front end of JavaScript, which is more like React or any of these other frameworks that are out there for the front end. There's a lot, right, to choose from, or there's just, hey, vanilla JS, you know, vanilla JavaScript, which is just no framework. Plain old vanilla JavaScript is what it's called. So if you want to learn that too, that might be something to look up. Granted, nowadays you could get hired by a company just from learning a framework and not even knowing vanilla JavaScript. So will it help you in your career to know vanilla? Yeah, but there's other people up here that are way more qualified to talk about this than I am. I'm probably just as much of a beginner up here as a lot of people. So with that, I would love to introduce our co-host, Ishan, who's going to take us into maybe a little bit on what he recommends for someone who's really been doing this for a couple years, but they're wanting to get more into learning more and they're taking some action.

00:16:56 - Scott Steinlage

But maybe you have some suggestions for Rahma, right?

00:17:02 - Ishan Anand

Yeah. So sorry I'm late. So the question is basically how to take it to the next level in your experience in web development, is that correct?

00:17:15 - Scott Steinlage

Yeah, she's still very much a beginner, she said. But yes.

00:17:21 - Ishan Anand

What does beginner mean? HTML, CSS, no JavaScript? HTML, CSS, some JavaScript?

00:17:29 - Scott Steinlage

There you go. Yeah, good question.

00:17:32 - Rahma

Yeah, there's HTML, CSS, JavaScript. Although I tried to learn the frameworks, but I just don't find it really as interesting as I find trying to grasp the plain JavaScript, the vanilla JavaScript. That's been pretty much it, just HTML, CSS, and vanilla JavaScript.

00:17:54 - Ishan Anand

Okay, then do you have a specific goal in mind? Like, I want to get hired, or I want to get promoted, or I want to work on websites, or I want to work on web applications. Like, I want to build the equivalent of Gmail in the browser, or I just want to make nice-looking websites that are fast. Like, what are your goals?

00:18:24 - Rahma

So I think, I can't really say for goals, but the things I find, should I say, interesting or fascinating is being able to build tools for education. So I've been looking at a number of, should I say, startups that do stuff like that, that make learning really way, way easier. For example, we have Replit. They have an IDE, which is more than an IDE. It's very good for learning, for kids to learn, and yeah, so stuff like that, tools like that. Although I know I can't just build stuff like that at one go, I'd have to start small, but I'm looking toward being able to, at some point, put together things like that.

00:19:08 - Ishan Anand

Got it. Okay, that's really helpful. And Replit, I think, is the in-browser IDE, so that's really helpful. So here's the tension. I love that you're interested in vanilla JavaScript. A lot of people want to jump straight to the frameworks, and it's great to have that background and that foundation for what vanilla JavaScript is. So I would make sure you know vanilla JavaScript, but not let perfect be the enemy of the good. Feel like you know it decently well enough to add it to a website and sprinkle some level of interactivity onto it. Things like how click handlers work, how closures work, know some of the key things like spread operators and arrow functions, which get used by a lot of the frameworks. But then if you want to be building tools like Replit and similar, those are typically going to require a higher-end framework like React or Vue, just because if you try to manage all the complexity of things that are happening on the page with vanilla JavaScript, it really becomes hard to keep track of that from a code standpoint. I would still say it's good to have a stepping stone in between where you are today and building a full-on Replit.

00:20:50 - Ishan Anand

It might be to pick a web page with some minor level of interactivity and say, I'm going to try and code a version of this. Then the next step would be to go through some good examples of kind of the higher-level interactivity using simple examples with frameworks. The classic one is to-do lists. There's a great site, TodoMVC, which shows you how to write a to-do application in multiple frameworks. I wouldn't try to learn that across all the different frameworks. I would pick one framework, or maybe two that you're considering between, and look at both versions of that to-do application in both those languages and see which one seems to appeal and make the most sense to you. I would also pick the framework that seems to have the largest ecosystem for where you're at, either geographically or the space you're in. Then pick one of those and start learning a framework like React or Vue or Angular. Then the thing that I think will help move you forward is building projects so you get your hands dirty on stuff and setting a project to build. And it's not only something you can show, but when you read the concepts in a book, it's not the same as when you actually play with them.

00:22:17 - Ishan Anand

And that would be kind of my immediate advice. The only other thing I'd say is there's a lot of great online resources, maybe potentially too many, but especially YouTube has a lot of great tutorials on various areas. You could almost Google any particular framework and just say crash course or getting started or for beginners, and you'll find some piece of content that'll help you get started. Let me pause there and see if that helps, or maybe you already knew all that.

00:22:49 - Anthony Campolo

No, I think that was good advice. But another thing to think about also, if you're uninterested in frameworks, maybe diving into the why behind the frameworks would be a good idea. Like, for example, exploring concepts around state management and why the frameworks are used and why state management is tied so closely to them, which lets you make an application like Replit. Even when it comes to making a Replit clone, that's not a difficult project to even start with. That's something you can definitely do. Whiteboard it out, put your cards together, what this looks like. On the basic level, you need the editor, you need to be able to show what's happening on the right side of the screen. You know, that's your basic functionality. And then you need to be able to save in real time at the end of each editing. So like, you're working through everything, you need to build every fundamental application you're ever going to touch in the future. But understanding the concepts around state management is really the core to why it's so important to use that framework, why we even use them in the first place, and how interactivity is done.

00:23:52 - Anthony Campolo

I think that would really help out with giving you motivation toward moving toward a framework. Now I think that we're biased because we always talk about React and Next, but Vue is, I feel like, a much friendlier starting point. It also cuts up the code in a different way that's easier to understand. It's also worth exploring. I learned the concepts around this with Angular. A little bit different, wasn't necessarily the same type of state management it is today, but it also helped out because it followed a lot of the previous concepts that older MVC frameworks followed. But in your case, I think that because of how much there is out there around React and how easy it is to access resources, that's probably your best starting point. And just research into things like Redux or how to use React's context library if you're looking for basic state management, and it'll really help you kind of get to where you're going. But if Replit's the goal, start with Replit. That's definitely an achievable project, even as a beginner.

00:24:58 - Ishan Anand

Just so I'm clear, so I think that's a great callout to understand the why. Are you suggesting coding up something like Replit using vanilla JavaScript as a project? And the reason I feel like it's doable, but I feel like you might, because there are so many components that do pieces of it that you can stitch together, there can be a more immediate sense of less work getting it done, but you may not understand the principles if you just pieced it together. Like, you can find an autocomplete component for Vue or React and stitch it together that way. But I'm curious, what were you proposing there?

00:25:47 - Rahma

I think I find that really interesting. I'm surprised. I've never thought about that before. So yeah, I think it's on top of my to-do list already. I'll just try to see how much I can get done in that regard. Thank you.

00:26:06 - Ishan Anand

Okay, well, I hope we helped out there. So, Scott, I think you probably did the intro already. For folks, this is obviously JavaScript Jam Live. We are an open mic, so feel free to raise your hand and we'll bring you to the stage. And feel free to introduce a topic, just like an open mic. But we have a few things that we always come prepared for. Have you guys started walking through that list already? Scott, should I take it away?

00:26:40 - Scott Steinlage

Yeah. No, we haven't. Feel free.

00:26:42 - Ishan Anand

Okay.

00:26:42 - Scott Steinlage

Although we did touch a little bit on ViteConf, we didn't go too far in depth or anything. I mean, we just kind of touched on a couple things, like how it was laid out, a few of the talks that they had on the list, but other than that, we didn't really get into anything. And nobody here that we know of went to it or saw it or participated.

00:27:10 - Ishan Anand

Yeah, I'll just say it had a really impressive lineup, which I'm sure you probably already covered. And the talk I most wanted to watch was actually the frameworks panel. It had like a who's who. You had Daniel Rowe from Nuxt, who's actually been a speaker for JavaScript Jam at the Composability Summit. You had Fred Schott from Astro, who's been on the JavaScript Jam podcast. You had Ryan Carniato from SolidJS, who's also been on the JavaScript Jam podcast, Misko Hevery, who's the creator of AngularJS and now QwikJS, which is an impressive, interesting framework. It was a really impressive lineup. I look forward to them publishing a recording because that's the one I definitely wanted to tune into and see more about. So hopefully they'll post those recordings and we'll be able to get a chance to watch them. I misinterpreted, as it seems like many did, the format, and I thought I'd be able to watch it a little bit more after the fact. But it is what it is, so moving on. And do you have the link for the newsletter, Scott? We can just post it up there.

00:28:40 - Scott Steinlage

Yeah, I can grab it. I'll tweet it first.

00:28:44 - Ishan Anand

Okay, perfect. So, you know, speaking of frameworks, there was a site somebody recently created and blogged about called What the Framework, and its lofty goal is helping you pick the framework for your next project. And you know what's interesting is you might think, as I think a lot of us do, it feels like every week there's a hot new JavaScript framework. But the creator argued that there's a gap in the ecosystem, more gaps than you might think. And you kind of have to make this really hard decision about whether your site is going to be a multi-page app, so it's more like a classic website, or it's going to be a single-page app, if you want to do both of those, or if you're going to blend between the two of those. She was like, you've got fewer options than you might think, especially if you also want server-side rendering. She found there weren't as many options as you might think. But I think it might be useful for us to just take a stab. And if you want, go ahead and try the website out yourself.

00:30:18 - Ishan Anand

We'll walk through it live. It's a very simple, open-source site. It's called whattheframework.dev, all one word. The flowchart's actually pretty simple. When you first land on it, it asks you which of three different types of sites you're trying to build. One of the things I liked is it doesn't even ask you, in the way I would instinctively phrase it as an expert, so to speak, do you want a multi-page app or a single-page app? It's really contextualized to something that even a non-technical user potentially could understand. So the questions that are asked are, is it a content-based website that provides the same content and experience on every visit? And I know what that means technically. I would phrase that kind of instinctively as, is this a multi-page app that's highly cacheable, right? But this is a much better, more plain-English explanation for it. And then the other two options are a website where most of the content is the same for everyone, but may also need to cater for unique content on visits to certain pages, just really saying, hey, I'm going to personalize some parts of it.

00:31:37 - Ishan Anand

And then the third is a website that needs to write custom and dynamic content for each visitor. An example of that might be something like Gmail, or I log into a dashboard of some kind and it's only the information for me about my stats that I'm looking at. Or maybe it's like Twitter or Facebook, where the entire experience every time you log in is custom for that particular user, their feed, and maybe even for that point in time. It looks like we've got a request. There we go, there's Matt. So follow along if you want, whattheframework.dev, and if you pick your website as the first option, website provides the same content and experience for every visitor, then its recommendation is right there for you already. Your website is probably a static site made of prerendered HTML pages and static assets. And what I thought was really interesting is it did not use the buzzword, which is Jamstack, which is how a lot of people would historically describe this. So that's a website where all the pages are basically built right when you deploy the site. And anytime somebody comes to visit the site, the CPU, the computer, doesn't have to do any work, doesn't run any code.

00:33:01 - Ishan Anand

It really just serves up that HTML, the same HTML, to every visitor who visits that URL. There's a lot of options here. You get your classic ones that people know, like Eleventy, but frameworks like Gatsby, Next, Nuxt, Redwood, even Angular support this. Astro is also called out, which is, I believe, what this site is built on. And then Docusaurus. What's interesting about some of these is some of them support both purely static and more than that. And then the other one, if you go back to the homepage and you say my website is more content is the same for everyone, but I might need to personalize some parts of it, so maybe it's, say, like an ecommerce site. The next question it asks, it's probably the most technical question. It says your website is probably a hybrid site, and they ask, do you need to maintain state across multiple pages? Which harkens back to what we were talking about earlier with Daniel's answer, like understanding state. Again, things I like here is they highlight examples. So examples of sites that you probably know that maintain state across multiple pages: Gmail, Discord, Twitter.

00:34:21 - Ishan Anand

As you navigate through Gmail, Discord, and Twitter, it needs to know if you go back to the previous email what you did there, or you're through multiple complex operations. Replit would be an example of this. If you click that, it says your site is probably suited to a single-page application, in which case they recommend Blitz, Gatsby, Next, Nuxt. If you say no, and the examples they give are sites like Google, BBC, and Amazon, right? Google's a good example. It's going to give you different results to different users depending on what they type in in the search results, but you don't need to maintain state across multiple pages other than maybe if you're on the third page versus the first page of search results. You don't need to, you know, Google as of yet doesn't show you like, here are the things you searched for over the last five days, although they actually do for certain users, but let's leave that aside. So if you say no, then you're a multi-page application. You don't need to maintain state between them, so Eleventy and Redwood are example frameworks that are called out.

00:35:28 - Ishan Anand

And then there's, you know, if you go back to the homepage again and you say, does your website need to provide custom content for each visitor? Then again it asks if you need to maintain state, and if it does, now we're getting to the ones that we're all familiar with for very JavaScript-heavy clients. So React, Angular, Vue, Svelte, Solid, Blitz, Nuxt, Ember, Remix, Preact. And if you don't need to maintain state, you can look at frameworks like Qwik and Astro and Redwood. Hopefully you guys are following along there. The first thing is I want to just pause and see if there are any thoughts or any questions, and then I want to just see with our speakers here, is there anything you agree or disagree with in terms of how they cut up the landscape? In terms of the questions asked, did they miss a question they should have asked? And then in terms of the recommendations, did anybody feel like there were recommendations they disagreed with? Like, no, I don't think that framework was appropriately categorized.

00:36:42 - Speaker 6

I just had something I wanted to add. Yeah, on the topic of frameworks. So in my hunt for the best static site generator this weekend, I was playing around with Zola. I actually initially started playing around with Astro, and I just kind of stumbled into Zola. It is built in Rust, and it is extremely simple and straightforward, and it's essentially everything I wanted from Gatsby. So I'm a couple of days into playing with it, but so far I'm loving it.

00:37:11 - Ishan Anand

Oh, wow, that's really interesting. Well, first off, you should make a GitHub pull request for Hacktoberfest, which we're in the middle of, to add this to What the Framework. I don't see Zola. Let me go back. Let me see it.

00:37:31 - Speaker 6

And something that's even more interesting is they have Layer Zero in their docs.

00:37:37 - Ishan Anand

Zola has Layer Zero in their docs.

00:37:39 - Speaker 6

Yeah, it's... it's getzola.com.

00:37:42 - Ishan Anand

Oh.

00:37:45 - Speaker 6

Get... what is it? Not dot com. It's...

00:37:50 - Ishan Anand

I'm... getzola.org, getzola.org. So the name did sound familiar. Let me see. So yeah, it's listed.

00:37:59 - Scott Steinlage

Mm.

00:37:59 - Ishan Anand

I'm going to our doc site, our documentation. Yeah. One of our team members has evidently added it to one of our supported frameworks. I see it in our docs. Layer Zero. There's a guide on using it. That's awesome. I knew it sounded familiar. What's interesting is you mentioned it's written in Rust, so it's got to be extremely fast. Why did you go toward that over Astro? What about Astro seemed too heavyweight for you?

00:38:36 - Speaker 6

So I actually liked Astro and didn't really have a problem with it. I was just kind of playing around with a few different ones, and then the site had Zola listed right after Astro.

00:38:46 - Ishan Anand

Yeah.

00:38:48 - Speaker 6

So I kind of abandoned Astro because I also haven't played with Rust at all. So I wanted to just kind of dig in that way and see what was going on. And then when I threw some files in and went to build it and saw that this is a site that would take like eight minutes on Gatsby to build, and this literally built in seconds, I was like, okay, let me go back and see what's going on. So I don't have any sites actually live yet, but I'm pretty excited about it.

00:39:18 - Ishan Anand

Is the like eight minutes, was that an exaggeration, or like you literally tried it or, you know, from experience? Like, how many pages is this site?

00:39:28 - Speaker 6

Oh yeah. And like in Gatsby Cloud it had about like a hundred markdown files in it, and it was taking like eight minutes to build. Extremely basic site. Where I went wrong, and I think why it took so long for it to build, is that I started with an outdated template from ThemeForest actually called Flexiblog that hadn't been updated in a while, so I kind of had to band-aid it myself. So I think the slowness there is 100% from me band-aiding it. But what really appeals to me about Zola is there's no plugins, it's just a single binary, and it just works.

00:40:03 - Ishan Anand

Yeah, that is, I think, very appealing. I think Hugo, if I'm correct, is similar in that regard. And I think Hugo's written in Go.

00:40:12 - Speaker 6

Yeah, I like Hugo too, but even Hugo was too advanced because I literally pretty much just need to display markdown files and images for the most part.

00:40:21 - Ishan Anand

Got it. Okay. So that makes a lot of sense. I'm looking at Zola's documentation. If you're like, I just need to get... I've got markdown files that I'm using with templating, either Liquid templates or something similar, and I just need to get this published out really quickly, and I don't have a lot of JavaScript needs on my page, Zola looks like a good option. Is that an accurate description of the site you were trying to build?

00:40:50 - Speaker 6

Yes, that's exactly what it is. Essentially I have a personal life wiki that exists as markdown files. I've been trying to go platform- and really tech-stack-agnostic. So I just wanted to get as simple as possible. And I used to just have a private repository on GitHub to back it up. But I'm getting to the point now where maybe I want to hook a CMS up to it and actually be able to write to it and use it from different devices. I just use it to play around, really.

00:41:20 - Ishan Anand

Got it. My bias would be to reach for something like Eleventy. The reason is simply because the guts of the thing are written in JavaScript. If I know I need to do something weird that it doesn't support, then I feel like I could do it. But I might even start with something like Zola just to get started anyway, because it's a single binary, like you said, and it looks really simple and straightforward. It has most of what you need, and you're up and running really quickly. That's really interesting. It supports Sass. Yeah, it's got image processing. That's pretty good. I inevitably find, in my experience, I want to customize something at some point, no matter what system or platform I'm on. And I run up against those walls, and I want that ability to have an escape hatch, which is why I'd pick something like Eleventy for this. But Astro I really like, because in a situation where it's not just markdown, but maybe I wanted something more component-driven that'd be more sophisticated, where I might be reusing components and reusing a button or an interaction component across multiple pages, I really like how Astro is laid out in that way. But I don't know if it has, for example, the image processing built in and stuff like that. But for what you're describing, this and Hugo look like really good options. You should definitely do a pull request to submit it.

00:43:02 - Speaker 6

Yeah, that'd be fun. And then I was also looking for Hacktober opportunities, so that would be fun.

00:43:08 - Ishan Anand

Yeah, totally. Any other folks who have thoughts on the recommendations made by What the Framework? It does seem like, especially for static, it's one of the largest lists they've got, but there could have been more added here, like Hugo. It actually appears to be on their list of static sites or static site generators, so there's definitely a lot that potentially could be added here.

00:43:42 - Scott Steinlage

Yeah, it's kind of interesting. Just kind of go back to what Matt was talking about. Would you consider that like a progressive type structure where you're working from HTML to JavaScript to components, adding things in? Is that considered like a progressive approach?

00:44:10 - Ishan Anand

Technically, I would call that progressive, though when people think of progressive, they might think of a different journey. The best example, going back to what Daniel had mentioned earlier about frameworks, is Vue has a very progressive approach. It isn't necessarily about processing. Like, in Matt's case, he's taking a series of markdown documents and he's trying to turn them into web pages. This is really well done for that. But if you start with just simple HTML, CSS, and JavaScript and you don't have Vue doing everything on your page, Vue is a great option because you can just say, oh, this part of the page is Vue. You don't even need to have bundling and a toolchain and webpack set up. You can just add the script tag, and then there's a really easy way. And so Vue, I think they still do, used to call themselves a progressive framework. It's very easy to adopt it very piecemeal.

00:45:11 - Rahma

That's cool.

00:45:12 - Ishan Anand

Yeah.

00:45:12 - Scott Steinlage

And it's kind of cool, though, because when Daniel said that, I started thinking about Vue, and I was like, you know, the one or two times that I did mess with Vue, it was very easy because, like Daniel said, it's so easy to write in that, right? Because you could throw HTML and CSS in there just like anything else, right? And it's so cool. And it also made me think of last week, or... yeah. Anyway, I was speaking with one of the co-founders of Enhance on Spaces and talking about its progressive structure and how it's progressive by nature, and that's why they developed it that way, or whatever. And also the interesting topic came up about how they designed it that way so that they're more friendly from an accessibility viewpoint, which is kind of cool. That's a big thing that they were talking about, accessibility as well. And then I brought up the fact that, well, it's also accessibility as far as being able to work on all these different devices and things.

00:46:48 - Scott Steinlage

Right. But also accessible from allowing newer developers to utilize a framework because it's easy to write it, right? Just like Vue as well. But it's progressive, so you can build onto it, you can add web components, you can add different JavaScript later, per se.

00:47:13 - Ishan Anand

Yeah, you bring up a really good point. One of the things it doesn't ask is how technically sophisticated are you? Where are you in your developer journey, so to speak? What does your team structure look like when you're in an enterprise context? Those are key considerations as to what framework you pick. I need to know, am I going to build a complex site that is going to need a lot of interactivity, and am I going to have to reuse a lot of, I don't know what the right word would be, components or interactivity? I have to imagine, if I'm going to build Gmail, there's no way I'm going to create the in-browser editor and all the different components myself. I need to use something like that. I want to have an ecosystem that has all those components for me, which is why people often go to React. But another key affordance is, like, how good are you at making things look good? That's a key thing for me as well, because I'm...

00:48:23 - Scott Steinlage

Do you have to use Tailwind or are you bootstrapping this thing?

00:48:29 - Ishan Anand

Yeah, like, what are the theming options it works best with? Or what are the UI libraries that are most popular? It should almost, maybe after you've picked the framework, be like, okay, here are the UI libraries that are recommended, which is yet another... the rabbit hole keeps going deeper, right?

00:48:51 - Scott Steinlage

Yeah.

00:48:54 - Ishan Anand

But that's a really good callout. Yeah. And the term progressive can have so many meanings. You're right. We just talked about it with Vue from the developer experience standpoint. The developer can adopt pieces of Vue gradually. And then, for the user, progressive enhancement refers to really the ability to make sure the page is functional with just the basics of HTML and CSS and doesn't require JavaScript to function. You add support for all those things layered on, but if some feature is missing, the entire web page doesn't break. And Enhance is very interesting as well, I think, because they're basing...

00:49:41 - Scott Steinlage

Yeah, we might get the... they actually reached out to me after I had that talk with them, so we'll probably have them on JavaScript Jam here.

00:49:49 - Ishan Anand

Oh, let's get them on. Because, you know what's interesting about Enhance is, if I recall correctly, it's based on... let me pull up the docs. I think it uses web components as its foundation, and there's been mixed traction with web components and custom elements. And there's a really good blog post I read over the last week saying it's still not time for web components, and then I read another one that obviously had the different view. So I'm really curious to see what they think. As I've mentioned before, the biggest challenge I've had with them is server-side rendering. But you're right, that's a good dimension. Is there another dimension besides developer experience and ecosystem that should be called out, or would be other questions to ask here when you're picking a framework, that we haven't covered or that this site isn't asking?

00:51:01 - Anthony Campolo

I am just checking it out.

00:51:02 - Ishan Anand

Give me a second.

00:51:08 - Anthony Campolo

Did you make this?

00:51:10 - Ishan Anand

No, it looks like something I would make.

00:51:12 - Anthony Campolo

Yeah, it does. It looks like an Ishan special.

00:51:14 - Ishan Anand

Yeah, it does. It really does. That's why you need a theming library. No, no, this is somebody...

00:51:20 - Scott Steinlage

That's awesome.

00:51:21 - Ishan Anand

Yeah. No, so when I said simple site, I meant it. No, somebody else that I linked to in the newsletter wrote it.

00:51:31 - Anthony Campolo

Oh, that's right. I do remember that.

00:51:34 - Ishan Anand

Yeah, she wrote this, "I changed my mind about writing new frameworks," and it got a lot of traction in a lot of places. Her homepage is better styled than this, so clearly she knows what she's doing. I think this is just like the start of something. Maybe she made it simple so people like me, who have no style, can contribute to it, and then they'll go make it look nicer. I really like the idea, though, because TodoMVC gives you the same application multiple ways, but it doesn't help, especially a non-technical person or somebody just getting into it, figure out what is the right framework and the why of these frameworks. Like, you can look at the code for the two different versions of TodoMVC and you'll be like, well, which one makes the most sense for me? But it doesn't answer enough of the whys like this one does.

00:52:27 - Scott Steinlage

Yeah, really. Another thing I thought about, though, too, is it answers the question, though, right? And so when you're going through this, I know you could definitely probably think of several different avenues to go down, and therefore other questions to include. But with this being kind of a minimally viable kind of thing here, I guess the great thing is that it takes you out of the what-should-I-do mode and into a take-action mode. It's almost like the mediator between you and doing the work, right? And so it will help you to just start. I don't know. That's what I see as a potential good thing as well from this. I like to see that.

00:53:32 - Ishan Anand

No, no, it does, because what we were talking about is there can be analysis paralysis on which framework. Like, I'm gonna do a blog. How many people, you know, Anthony, who's often a regular guest, just tweeted the other day, and I think he had gone through, in two years, seven different frameworks. Maybe it was five, right, just building his own personal blog. And I actually personally have wrestled with this. Mine is still actually, people will throw tomatoes at me, mine is in AMP. And you want to overcome that analysis paralysis. I also like, though, that this starts with what you're building too, which keeps you focused on why you're doing what you're starting. What may be useful is like a get-started button. Well, what happens when you click on one of these? It does send you to the docs and GitHub. Maybe it'd be like, starter example, right?

00:54:31 - Scott Steinlage

It would, like, throw you into [unclear] code.

00:54:35 - Anthony Campolo

I feel like this is also kind of contributing to some of the problems in learning in this space, is that I feel like engineers, especially junior engineers in their early stages, when they're first picking everything up, it's like shiny object syndrome. They see something, they want to try it out, they see the next thing, oh, that looks better, because they're probably stuck on something. They go to the next thing, and it's just a constant try, test, come to no conclusion, go to the next thing, learn a little bit, but they don't ever master any of them. And I feel like that even with companies, a lot of people who have specialized, let's say you've been using Next for the last five years. Well, you're likely using Next because you've been paid to use Next. That's what your contract or your employment or whoever you're currently working for is using, and that's why you've developed bias towards Next or Nuxt or Vue or whatever it might be. Oftentimes that bias, that specialty and mastering a framework, really comes from being paid to master it in the long term.

00:55:45 - Anthony Campolo

And I feel like that makes it a little bit more difficult for those starting off to really choose, because it's not that there's a clear and concise choice. It's what can get you a job, what can get you in the door. And even if you have to switch frameworks in employment, which happens all the time, you're going to end up developing preference toward whatever you're working on every day. They're all basically the same at the end of the day.

00:56:10 - Ishan Anand

Yeah. Sometimes it helps to have that choice kind of handled for you. So...

00:56:15 - Anthony Campolo

Yeah, yeah, if you're choosing between frameworks, you're probably not even at the point of qualification to make that choice. Especially if you're at a job, you shouldn't be leading a team unless you know exactly why you're picking something, you know what I mean? I feel like that, at least.

00:56:34 - Ishan Anand

Yeah, I don't think... but to be fair, I don't think anyone's going to use this to pick the framework for a team. I think this is maybe somebody getting started.

00:56:44 - Anthony Campolo

Oh, for sure.

00:56:45 - Ishan Anand

Maybe a hobby project, or they're trying to figure out what to use for their blog.

00:56:52 - Anthony Campolo

Yeah, I guess, like, just from my perspective, when I went through learning, I feel like I was just thrown all over the place trying everything else. Just pick up, drop, pick up, drop. Until I had a contract where I was like, okay, I'm going to stick to this because I'm being paid to do this.

00:57:08 - Scott Steinlage

Yeah.

00:57:09 - Anthony Campolo

You know, that's... and I feel like it completely stunts the growth of your engineering journey when you're constantly picking up new frameworks. You're not learning anything new. You're learning the same five steps on five different frameworks.

00:57:22 - Scott Steinlage

Yeah.

00:57:23 - Anthony Campolo

Like, what will be better is progressing beyond step five to step 15, step 20, step 25. Like, how do you actually accomplish the entire application, not how to start an application.

00:57:35 - Scott Steinlage

That's true. And that's actually kind of a difficult thing, which we'll talk more of next week, folks. If you're wanting to hear more about DevRel in the world here of JavaScript web development, join us next week as well. We'll be diving in with a special guest whom we'll be announcing in the newsletter. That'll be cool. And we'll probably tweet about it as well. We'll keep an eye out for that. But yeah, no, I very much agree with Daniel on that. I mean, when you're paid to do it, you're probably gonna focus more on it, right? And it focuses the mind, yeah. And it eliminates you having to even look into anything else because you don't have a choice. It's like, hey, this is what you gotta do.

00:58:22 - Anthony Campolo

So it makes you miss the Rails days. Like, when Rails was the popular choice, it was obvious why. You just picked it because it got shit done. That was the main objective, and it did it all, and nothing else really touched it at the time.

00:58:36 - Scott Steinlage

And now everything gets stuff done.

00:58:38 - Anthony Campolo

Yeah.

00:58:40 - Ishan Anand

So you're gonna love... this is like me taking the opposite approach. So the reason I like Astro so much is because it lets you not make the decision. It's like you pick Astro, and then you still have yet another choice. I can use React for this page, I can use Vue for this other page. I can continue being the dilettante.

00:59:00 - Scott Steinlage

And I think it's because you're in that stage in your career, in your life, where you have the ability to make those decisions and you know why you'd want to make those decisions. So you want to leave it open. If you want to put some web components in this specific area, and so this allows you to do that, then you're going to go that route. Whereas if it's more limiting, like Rails or whatever, then you probably don't want to choose that method because you're thinking, well, if I want to do this in the future and I can't now, now I got to switch, right?

00:59:35 - Ishan Anand

Yeah. Well, thank you for not being the therapist and saying you have a fear of commitment.

00:59:41 - Anthony Campolo

So that's 100% true.

00:59:48 - Ishan Anand

Well, I think we're right at time on that note. So, Scott, I'll let you take us out.

00:59:56 - Scott Steinlage

Yeah. Awesome. Well, hey, thank you all so much for joining us today. Greatly appreciate it. Like I said, join us next week because we're going to be talking about DevRel stuff, and it's going to get exciting. I promise you. It's going to have a bunch of people in this room speaking about DevRel. I'll probably get all the DevRels up in here. Anyway, thank you so much for joining us for today, though. We had a great time talking about whattheframework.dev, what that means for you, what it could mean, what it might not mean, the things that they might be able to do to improve upon it. Or maybe we should just leave it as it is because maybe it's not so flashy because everything else is so flashy. Interesting. All right, don't think too hard on that one. Pun intended. Thank you all so much for joining us. Remember, we do this every Wednesday, 12 p.m. Pacific Standard Time. And yeah, we love you all so much. Thank you. And we'll see you on the next one.

01:00:54 - Ishan Anand

Thank you.

01:00:55 - Anthony Campolo

See everybody.

01:00:59 - Brad

Laters.

01:01:01 - Scott Steinlage

Later. All right, thank you all so much. See you next time. Peace.

On this pageJump to section