Plenti with Jim Fisk
Jim Fisk discusses building Plenti, a Svelte static site generator written in Go, Svelte's advantages over React, and the evolving JavaScript bundler landscape.
Episode Description
Jim Fisk discusses building Plenti, a Svelte static site generator written in Go, and explores Svelte's advantages over React and the evolving JavaScript bundler landscape.
Episode Summary
Jim Fisk joins the show to share his journey from agency work with traditional CMSes like Drupal and WordPress to building Plenti, a Svelte-based static site generator written in Go. He explains how maintaining small nonprofit sites exposed the pain points of CMS technology—security updates, slow performance, and hosting costs—which led him to explore the Jamstack through Jekyll and eventually build his own tool. The conversation covers Plenti's git-backed CMS approach, where content lives as flat JSON files in the repository, and how the project is considering adding broader API capabilities to connect with headless CMSes like Strapi or Ghost. A significant portion of the discussion compares Svelte to React and Vue, with the hosts exploring how Svelte's identity as a superset of HTML contrasts with React's JSX-driven approach, and why the absence of a virtual DOM results in smaller bundle sizes for many use cases. The episode also traces the evolution of JavaScript bundlers from Webpack and Rollup through Snowpack to Esbuild and Vite, with Jim explaining how he built a custom Go-based tool called Go Pack to eliminate bundler overhead entirely. Throughout, the conversation highlights the tension between ecosystem maturity and developer experience, and why Plenti's focus on speed, simplicity, and minimal dependencies represents a distinct philosophy in the static site generator space.
Chapters
00:00:00 - Meet Jim Fisk and the Origins of Plenti
Anthony introduces Jim Fisk, whom he met through the Jamstack Denver meetup, and Jim shares his background working in agency life with CMS platforms like Drupal and WordPress. He recounts building sites for major clients including the City of Boston and Big Brothers Big Sisters, where large-scale CMS deployments worked well with proper caching and reverse proxies.
Jim then explains how working with smaller nonprofit clients revealed the downsides of traditional CMS technology—neglected security updates, slow performance, and unsustainable hosting costs. His discovery of Jekyll in 2016 and exposure to Netlify CMS concepts in 2017 opened his eyes to the Jamstack's potential, culminating in a production Jekyll site for Boston's budget portal that pulled over 1,600 pages from a JSON API using a component-based architecture.
00:04:35 - Building Plenti and Choosing a CMS Strategy
After years of waiting for the perfect tool, Jim decided to build Plenti himself, having tried Hugo, Gatsby, and other generators without finding exactly what he needed. Anthony draws a connection between Plenti's approach and full-stack thinking, noting how Jim treats JSON flat files as a database alternative while managing the entire data flow from storage to rendering.
The conversation explores Plenti's git-backed CMS philosophy, inspired by projects like Tina CMS and Netlify CMS, where all content lives alongside code in the repository. Jim acknowledges this model's limitations for large sites and discusses the team's pivot toward building better API capabilities so users can connect to headless CMSes like Strapi or Ghost. He emphasizes Plenti's transparency—users define whatever JSON key structure they want and pull it directly into templates without navigating framework-specific abstractions.
00:10:37 - Data Normalization and the Content Mesh
Jim and Anthony compare Plenti's lightweight data approach to Gatsby's content mesh, where everything gets normalized into GraphQL regardless of the source. Jim explains that Plenti aims for minimal transformation—grabbing data from a source and splitting it into individual content files with as little processing as possible, prioritizing simplicity over powerful normalization.
Anthony connects this to his own work at StepZen, where they convert various data sources into unified GraphQL schemas. The discussion touches on the practical constraints of open-source development with limited contributor hours, and how focusing on incremental progress allows small teams to build meaningful tools over time. Jim stresses that Plenti's goal is to stay out of the developer's way between data fetching and template rendering.
00:13:43 - Svelte vs. React: A Framework Philosophy Debate
The hosts pivot to a deep comparison of Svelte and React, with Jim explaining why Svelte's HTML-first approach felt more natural to him than JSX. Anthony frames the core distinction clearly: React is a superset of JavaScript that lets you embed HTML in functions, while Svelte is a superset of HTML where you insert JavaScript as needed. Jim shares that he switched Plenti from React to Svelte early on because he wanted to lower the barrier for newcomers coming from plain HTML backgrounds.
Chris raises the pragmatic question of why someone comfortable with React should consider switching, and the group discusses ecosystem trade-offs. They acknowledge that React's massive component ecosystem and job market dominance are real advantages, while Svelte offers smaller bundle sizes and a gentler learning curve for certain developer profiles. The conversation avoids declaring a winner, instead emphasizing that the right choice depends on team needs and project goals.
00:24:07 - The Virtual DOM, Compilation, and How Svelte Actually Works
Chris asks why the virtual DOM matters, prompting a technical breakdown of how React uses an intermediary layer to diff and update the actual DOM, while Svelte compiles components directly into vanilla JavaScript that manipulates the DOM through event listeners. Anthony draws a parallel to TypeScript's compilation model—Svelte lets you write in a developer-friendly syntax that gets transformed into optimized browser-ready code without shipping a runtime.
The discussion also covers Svelte's single-file component model, where HTML, JavaScript, and CSS coexist in one file with automatically scoped styles, eliminating the need for libraries like styled-components. Jim notes that Svelte's abstractions, like the reactive dollar-sign syntax, technically hijack valid JavaScript but feel transparent enough that developers experience them as writing plain HTML and CSS. Chris and Jim compare levels of abstraction across frameworks, placing React at the high end and Svelte significantly lower.
00:30:21 - Bundlers, Build Tools, and the Rise of Esbuild
The conversation shifts to the JavaScript bundler ecosystem, tracing from Webpack and Rollup through Snowpack to Esbuild and Vite. Anthony explains that Rich Harris created both Svelte and Rollup, which is why they work so well together, and notes that Esbuild's Go-based architecture makes it dramatically faster than JavaScript bundlers. Jim shares his experience trying Rollup and Snowpack for Plenti before building his own tool called Go Pack, which handles ESM imports natively in Go to eliminate bundler overhead entirely.
Jim explains that his definition of build speed encompasses the entire process from click to result—not just component compilation but also bundling, server startup, and everything in between. By cutting out the bundler step and handling module resolution in Go, Plenti achieves notably fast builds. The group discusses how Esbuild will likely transform frameworks like Gatsby where large sites can take ten to fifteen minutes to compile, and how most developers will experience these improvements indirectly through the frameworks they adopt.
00:40:08 - Speed, CI Pipelines, and Closing Thoughts
Jim explains why cold startup time matters so much for Plenti's vision of a git-backed CMS with real-time feedback. Since every change triggers a full CI build with no contextual awareness of previous state, eliminating steps like npm install and bundler initialization is critical. Plenti ships as a single binary with no dependency on Node.js or Go being installed, and compiles Svelte by hitting the compiler API directly through V8.
Anthony wraps up by praising Plenti as a uniquely positioned project in the static site generator space and encourages listeners to explore it. Jim shares where people can find the project on GitHub under the Atlantico organization and invites feedback and contributions from anyone interested. The episode closes with Chris joking about potentially trying Svelte someday, capping off a technically dense conversation that spans CMS philosophy, framework design, and build tooling evolution.
Transcript
00:00:00 - Anthony Campolo
Jim, meet Chris. Chris, meet Jim. Let's get right into it. Welcome to the show, Jim.
00:00:12 - Jim Fisk
Thanks for having me.
00:00:18 - Anthony Campolo
So you and I know each other from Jamstack Denver, and this is a funny story because I had been staying in Denver with my sister and, for no real reason, contacted the Denver meetup because I was there. But at the same time, it wasn't an in-person meetup. I did my very first Redwood talk for Jamstack Denver, and this was the beginning of September. I then went to the meetup after and I watched. You gave a talk about Plenti, which is a Svelte static site generator. Why don't you explain what Plenti is, and a little bit of your background and who you are?
00:00:57 - Jim Fisk
Sure. Anthony, I feel like we run in the same circles. I feel like we met maybe in Denver, but I've seen you in all sorts of Jamstack and Svelte-related meetups after three or four interactions. We were like, okay, I think we have the same interest here, and it's been fun connecting with you on that stuff.
Plenti is a Svelte static site generator, and I started dabbling with Svelte a little while back. At the time, there weren't a lot of options for static site generation in Svelte. There was a project called Sapper, which is like a full-stack Svelte framework that can do static site generation. But there wasn't anything really focused on the Jamstack, so I thought Svelte and building something myself might be a good way to go.
So just to take a step back, I come from the agency life. I worked in an agency for a while and focused mainly on CMS technology, like Drupal and WordPress.
[00:01:47] I started my own agency back in 2015 and continued on that paradigm. I've worked with some pretty big brands doing that stuff, like City of Boston, Big Brothers Big Sisters, National Bureau of Economic Research, and stuff like that. At that scale, CMSes can work really well because there's lots of resources you can throw at caching, like setting up a reverse proxy with Varnish and making things really fast and secure.
But I also have a lot of clients in the smaller realm of things, small nonprofits where CMS technology kind of falls flat. I often inherit sites from folks who haven't maintained their site in a long time, and things like security updates and slow sites and all those problems rear their ugly heads if you're not careful with CMS technology.
So I think my first introduction to Jamstack technology was back in early 2016. I started playing with Jekyll, the static site generator, which I believe was created by Thomas Preston-Werner, who you guys had on the podcast.
00:02:47 - Anthony Campolo
Right. I was just listening to that last night. That was an awesome talk.
Yeah, we talked about the whole history of that and his blog post, Blogging Like a Hacker, and how he just wanted to be able to get pushed and have his blog be deployed to the world.
00:03:00 - Jim Fisk
So it's funny. My friend who lived down in Austin did a bunch of Rails work. He turned me on to Jekyll. At first I thought it was just a prototyping tool because I couldn't wrap my head around how it could be used in any sort of real way. I was like, well, this is really cool. I wish I could build sites this fast. Too bad it's not practical to do anything besides prototyping. That quickly changed. I played around with it a little bit more.
I think when I really saw the light of the possibilities was when I was listening to a talk. I can't remember if it was at a conference. Jamstack Conf didn't exist at the time. It must have been early 2017. Matt Biilmann from Netlify was talking about Netlify CMS and building a git-backed CMS with React and things like that. I was like, this could be super powerful. So I was totally bought in at that point.
[00:03:41] I actually built a big production Jekyll site somewhere around that same time for the City of Boston. It was the budget.boston.gov site, and we were basically pulling from a JSON API to build a couple thousand pages. I think it was something like 1,600 pages we were pulling in.
It was a hybrid build. We were using a lot of Gulp to preprocess things and pull down a wrapper from the City of Boston website to build out some of the pages and templates and things. But it was pretty cool because it was the first time that I pulled everything out into a component-based architecture in the Jamstack. We basically built our own little API so you could create Markdown on the fly, and it would pull in structure in a dynamic way.
So I was starting to see the possibilities for a more dynamic build process with a Jamstack. I was really thinking that maybe this could be the solution I was looking for, for some of my clients that were falling behind on their security updates and really couldn't pay for the hosting and all the expenses that go along with maintaining a CMS.
[00:04:35] So I was bought into the vision, and basically I sat around for a couple years waiting for someone to invent exactly what I was looking for. There were a lot of projects that were getting close, but maybe I'm just too controlling. I basically decided to step in and try to make something that was exactly what I was looking for, because I'd been playing around with Hugo and Gatsby and some other things, which are great projects, but I wanted something very specific for my needs.
00:04:57 - Anthony Campolo
Yeah, this is really interesting because you're coming from the Jamstack world, which is awesome because this is the Full Stack Jamstack podcast. We've had lots of people on to talk about their history with the Jamstack. It seems to be a common thread: people get really into it, love it, see the potential, and then stretch beyond it to fit their own use case or needs.
I found the direction you've gone really interesting because it is, in a sense, full stack. You still are worried about where the data is being saved, how it's being accessed, how it's being rendered on the page, and how that whole data flow is working. But you're not thinking about databases; you're thinking about a CMS. A CMS and a database are like, what's the difference? What is not? It's such a strange, nuanced thing. I remember this actually confused me when I first saw your talk because I couldn't quite wrap my mind around the fact that the database was, like you say, just JSON.
[00:06:04] It's just a bunch of JSON being turned into what you want it to be. And you also said at the very beginning that Sapper is full stack. I find that's so interesting because Sapper is not full stack. Sapper is like Next, which is also not full stack. And everyone says these things are full stack. I get why you say it, because people do say Sapper is full stack. But this is about SSR. It adds the server-rendering part, but it doesn't give you a database. That's why I don't consider it full stack.
00:06:34 - Jim Fisk
Interesting. Yeah, that's a good point. I guess I never really thought about it that way. I always thought that if you have to worry about running a programming language on your server, then you're full stack, in the way that I was defining it. So if you have to worry about running a server with Node.js or Go or something on it, then you're thinking full stack versus just deploying something to a CDN where you're not worrying about that backend.
But that's a good point. If you're not really setting up the database, I guess you're not fully going into the stack, right? You're like three-quarters of a stack.
00:07:04 - Anthony Campolo
How did you decide what type of CMS you want? Because you're also building a CMS for Plenti at the same time. This is a huge world that I have barely scratched the surface of. But when you start building a CMS, what do you even think about? How do you approach that?
00:07:24 - Jim Fisk
That's a great question. This is kind of where I have to distinguish between vision and reality. I tend to get ahead of myself with where I want to go with some of this stuff, and Plenti is a part-time project for me and some other folks who are working on it. We're trying our hardest to get things done, but it's a constant work in progress that we're changing a fair amount because we're not at a stable 1.0 release yet. We still do break things, but we try to be pretty conscious of making it easy for folks to upgrade.
We even release a dedicated Docker image for every release. So if you want to continue using an older version of Plenti after we've changed the API, you could continue using that for a very long time.
But in terms of building a CMS, I fell in love with the model of the git-backed CMS. People like Tina CMS and Netlify CMS are doing this thing, and it's not for everybody.
[00:08:11] I used to, at the Jamstack Boston meetup that I started, do some sessions way back in the day when it was in-person meetings, where we looked at Netlify CMS and setting it up. And some people really hate the idea of writing back to the repository and storing all their content in the same repository. You could do some things to separate those two things, but the basic way that I envision things is to have a really simple workflow where everything's stored in the same spot. It's all flat files, and there's not a lot of thinking outside of that, and I think it works really well for small sites.
But of course, if you have a site with thousands of pages and nodes, that could become a difficult thing because your build process gets slow and there are all sorts of challenges with that. But I really like that model, a git-backed CMS. We've recently been discussing that it might be better for us to build better API capabilities into the project early on because there are so many great headless CMSes out there.
[00:09:02] And if we focus too much on our git-backed CMS and we don't allow you to plug into other ecosystems, I think we're really shooting ourselves in the foot a little bit because it's going to take us longer to build what we want in the git-backed version versus just allowing you to pull from some kind of REST endpoint, like Strapi or Ghost or something like that.
So we're stepping back to the drawing board a little bit. We're thinking about building that capability a little bit better. I think our project has some advantages because we don't define any custom keys in our data source. The data source is completely up to you. And that's one of the goals of Plenti. We wanted a really transparent model for where you're storing your content and how you're writing your content structure into your layouts.
I think this is really hard in the CMS world. If you come from Drupal or WordPress, when you can create structured data through an interface, it's really nice. But when you come to pull it out in your templates, if you're using Twig or something like that, it's really difficult to get raw data values. You have to go into nested field structures and a lot of complexity. Even some of the static site generators out there aren't doing a great job with this because they have all these defined keys and things like that, where you have to do a little digging to find out where your data is coming from. You can pull from certain fields, but you have to name them just the right way.
I think Plenti is great because it's really transparent in the way you can define whatever JSON key structure you want, and you can just pull into your template. You don't have to really think about it. I think that makes the API capabilities easier too, because we can basically just copy JSON down to local storage and then pull it into your templates. Whatever the structure is you're getting from your API, you can accommodate in your template, if that makes sense.
00:10:37 - Anthony Campolo
Yeah, it does. And so it doesn't really matter what type of API you're pulling from because you're making Plenti kind of like the normalization layer. Is that what you're doing?
00:10:50 - Jim Fisk
Yeah. I mean, not to the level that something like Gatsby is. Gatsby is great because it'll pull everything into a common language, right? Everything's going to be GraphQL by the time you get it, even if your plugin is pulling from a REST endpoint. So I think that idea is really cool. The whole content mesh idea is powerful. I don't know if Plenti is going to be that powerful, at least in the beginning.
I think our concept is just making things simple. We're going to try to get in your way as little as possible between where you're fetching your data from and how you're using it in your template. I would think that somebody could read an API from a public endpoint, look at the structure, and build their site off just looking at that if they wanted to, because you're going to get the same content down locally. It's just going to be happening at the build process, right?
[00:11:36] So every time you build, it's going to look to the endpoint, copy that down, and rebuild those pages based on that.
00:11:41 - Anthony Campolo
Yeah, I'm just asking and thinking about this because this is something I'm doing right now with my coworkers at StepZen. We're taking things like WordPress and DB2 and turning them all into GraphQL schemas. So you have one, and it's very similar to the Gatsby content mesh thing, but it brings in a larger range of API types. We have REST connectors, all sorts of stuff. And I remember I made a joke about GraphQL and Plenti at one of our meals. I was like, hey, you should just add GraphQL to it. It'll only take you a weekend, you know?
00:12:18 - Jim Fisk
Yeah, I would love to do all that. It really comes down to being conscious about what we're focusing on and what we're doing because we have so few effort hours we can put into this. So I think for now we're going to do as little transforming as possible. It's just going to be: grab from a data source, point to whatever key holds the array of information, and split it. So say you're trying to get events and you're looking at an endpoint with a bunch of events. Make sure you know where you're splitting it, and then copy those down to individual content files. As little transformation as possible for the beginning, I think.
00:12:51 - Anthony Campolo
I think that's the way to go with any of these open source projects because they build over time. If you can think long term, that's where you can scale yourself because you have a small amount of people. But if you put in consistent work, it can build over time. So yeah, I think that's great.
Let's get into the Svelte stuff. We haven't had anyone on the show to really talk about Svelte. I have talked about Svelte a lot because I've been messing around with it on the side for about as long as I've been doing web stuff. I started learning React and made a very conscious decision to learn React because I wanted to get a job, and I knew that was going to be a smarter bet than Svelte. But I found Svelte more interesting just because it's newer and different.
[00:13:43] In a lot of ways, it's made as a reaction to React because it's consciously not using the virtual DOM. But we're probably getting ahead of ourselves. So let's give the high-level elevator pitch. How do you explain Svelte to someone who is a web developer but doesn't know Svelte?
00:14:00 - Jim Fisk
Yeah, that's a great point. Chris, we were talking about this briefly before the call. I think you have a background in React, right? I did not have that. I came into React, did some React projects, and some Gatsby projects here and there.
For me, React is kind of difficult. I know a lot of people say it's easy and it should be easy to hop into, but for me there are a lot of challenges. JSX is kind of confusing. My guiding principle for a lot of things is less abstraction, even though you could argue that Svelte has more abstraction. But the idea of JSX is that you have to do some interesting things in there to make it work. There's a little bit of abstraction versus when I'm using Svelte.
I feel like even though it's HTML and it's not real HTML, it's all going to be compiled. It feels like I'm writing regular HTML in a one-file component, and then I'm sprinkling in JavaScript where I need to. I can add a script tag and that goes to that component. Then I can add a style tag as well, and that's scoped to that component. So everything's component-level scoped, which is nice.
I feel like if I was someone coming from an HTML and CSS background and I didn't have a lot of web development experience, Svelte might be easier to get on board with than something like React because it's syntactically simpler. That's subjective, but it seems syntactically simpler from my perspective. For me it was just a lower barrier.
00:15:26 - Anthony Campolo
Yeah, what you're saying is a really great point, and it's what I try to hone in on with Svelte. But we need to really dig into what you're saying. React is a superset of JavaScript because it's using JSX, which is a JavaScript extension, whereas Svelte is a superset of HTML. It's building on top of that, and that is the way you should really think about these two things and how they're different from each other. One is trying to basically give you all the powers of JavaScript and let you stick HTML inside those functions. Whereas the other one, Svelte, is saying we're going to take an HTML page and then insert JavaScript where we need it. That's the mental model of how you can think about these two things.
00:16:17 - Jim Fisk
Yeah, I always hear the argument that people love React. I think people prefer React because they're saying, well, I'm writing JavaScript and I can understand it better, but when you start putting a template into JavaScript, you're still dealing with a template at some level. So it's like, do you want your template embedded in your JavaScript, or do you want your JavaScript embedded in your template? Maybe it comes down to personal preference for me.
00:16:43 - Christopher Burns
I don't know React, but I do understand the fundamentals of JavaScript well. To understand where React is doing things in JavaScript is, I think, a lot like a car. Straight after you've learned to drive, you normally get a car, and then when you sell that car and you think about the brands, you go, "Oh, I had a Ford. Ford's a pretty good car to me. I'd buy a Ford again." It's the same thing as I learned React first. But is it necessarily the best way of doing everything? Is it a very heavy-handed way of doing a lot of things? Yes. But it tends to be the most popular option right now.
This is where things like Svelte and Vue really interest me. But then the hardest question is why should I learn it? Why should I reap the benefits? Because it's a two-pronged question: what's the benefit I get, and what benefits would my team get from swapping to it? And I think that's actually a really hard one because you could say with React the benefits for a single developer are that there are a lot of components out there that are already built and you can just hook into. And when you're on a team level, you're normally the ones building component libraries and going a lot more in depth.
It's not necessarily a better or worse way in my mind. It's just like I need a car to get to A and B. When this one breaks down, you look at the horizon and think of what's next.
00:18:29 - Jim Fisk
Those are great points. I can only give my perspective. If you're driving now, I'm extending your analogy probably to places where you didn't intend. But if you have some basic mechanical skills, you can change your oil, and you're comfortable with your car, then honestly, for me, it would be a hard sell to tell you to stop using Ford or React or whatever it is. If you're very comfortable and your team's efficient, then I feel like everyone's going to pitch you to change something all the time. Today it's Svelte, and tomorrow it's something else.
So for someone like you, it might be hard to sell now. If you're worried about React being difficult for your team and taking on new members all the time, and you're having a lot of spin-up time to get people to a proficient level, then a long-term goal might be something that has a lower barrier.
Now I feel like Svelte has a lower barrier, but that might not necessarily be true for everybody. Svelte could have a higher barrier for someone else who has a different technology perspective than I do. So it's a hard sell. But for me, it was simpler.
Basically with my project, I'm trying to onboard people who are coming from HTML websites or are tired of the CMS world and just want something that's as simple as possible. I actually started Plenti way back on React for a very short period of time. But as I dug more into Svelte, I switched it because for my mental model, it seemed a little simpler. I wanted to capture that low-end newcomer environment, and I thought Svelte would get me there easier than React might. So that's just how I look at it.
00:20:15 - Christopher Burns
Yeah, I don't necessarily think React is the best thing in the world. There's a lot of people that think, why do we write JSX? And there have been quite a few projects that have tried to replace that. They've never really gained massive traction. But they are out there. I guess my ultimate question, Jim, without talking about technology, is what is a safer choice for somebody who is an independent JavaScript developer who needs to achieve a goal?
00:20:54 - Jim Fisk
So if your goal is getting a job, then probably React, right? If your goal is to join some larger team, then that might be your choice if you're in a position. So my position is I have this small agency that I direct, and my clients don't necessarily know about the technology that's being used to achieve their goals. I personally can achieve their goals faster with Svelte than I can with React, but that might be my own limitation in React, right?
So for someone who just wants to build something and wants to have not a lot of headaches maintaining it, then I think Svelte might be a good choice. Of course, like I said, it's subjective.
00:21:30 - Anthony Campolo
So there's a couple of things I want to hone in on here. We're talking about whether Svelte is better or not for beginners. I agree that it is simpler in the sense that you're writing less code. This is actually one of the things Rich Harris said a lot when he first created it and was putting it out into the world. The more lines of code you have, the more potential there is for bugs. Every line of code is a liability because that line of code could be wrong. So it gives you nice, clean, simple, concise abstractions, which is really nice.
The problem is that when you have a smaller ecosystem, you have fewer resources, fewer docs, and fewer extra libraries that can simplify weird, specific edge cases. So that's where you're going to run into issues. Svelte by itself is much simpler, I think.
[00:22:34] But there's so much more to build with these things beyond the actual thing itself. Now, in terms of the benefit and how we should be trying to sell or not sell, the real benefit for experienced developers is that you have a much smaller bundle size and a much more lightweight toolset. As you say, you can move a lot faster because your tools actually move a lot faster.
Now, this could change with Esbuild, but as of now, Svelte has been living this super-awesome build lifestyle for years. Everyone's using Esbuild now and they're freaking out and they're like, oh my God, this thing is so fast. It's a whole different kind of programming. And people who have been doing Svelte have been saying, yes, we know. This is what we've been saying for years. This is why they were the first ones to hop on this with Snowpack, months and months ago, with SvelteKit, which is interesting because now they have dropped Snowpack and have changed to Vite.
00:23:30 - Christopher Burns
I've got one more question before we move on. Why should I learn Svelte when I hear Vue is pretty good?
00:23:37 - Jim Fisk
That's a great question. In my opinion, I'm not the best to talk about Vue and React because I'm not that experienced in them. I've touched them a little bit, but I feel like if you like the Vue experience, Svelte is very similar in the way that it feels when you're writing it, except you're getting away from the virtual DOM completely and you're building it with a different compiled environment.
So if you're going to start heading the Vue direction, just go all the way to the dark side and join us over on Svelte. That's my opinion.
00:24:07 - Christopher Burns
So why is the virtual DOM such a big point? Because you can say to me the virtual DOM, but why do I care?
00:24:16 - Jim Fisk
There's a theoretical limit where it's not going to matter. But for small sites, you're loading less to the browser because you need less to actually run your code, because it's just compiling down to regular JavaScript that you can run in the browser. It doesn't need this other layer to actually run your code.
So if you have a really small site, then the virtual DOM is just extra overhead. That's potentially going to make your bundle size bigger and slow everything down a little bit. At some point, there is a crossover where your virtual DOM sites will probably be faster than your compiled Svelte site. So if you're really worried about performance, then you might want to know where that crossover happens.
00:24:53 - Christopher Burns
So just so we know, the virtual DOM is technically the thing that decides to inject HTML into the browser, into the wrapper. Basically, say you're using React. This is all theory that I've built, so I guess someone can tell me if it's true. You have an element that's based on a boolean, the boolean is now true. So then React tells the virtual DOM, now add a div tag here into the virtual DOM, and then the virtual DOM will add that div tag into the actual HTML. Is that right? I think it is.
00:25:33 - Jim Fisk
I believe so.
00:25:34 - Christopher Burns
Anthony's nodding.
00:25:35 - Anthony Campolo
So yeah, that's the point of the virtual DOM: it does the diffing for you. It looks at the DOM, it looks at the change you want to make, and it applies that change. Whereas with Svelte there is no virtual DOM. With Svelte you write all your Svelte and then you run it through a compiler, much like you would do with TypeScript. You run TypeScript, you run it through a compiler, and it spits out JavaScript, and JavaScript gets sent to the browser, or even some kind of crazy mashed-up version of JavaScript that gets further minified.
So Svelte is just another step in the chain of letting you write something that is nice and makes sense to your brain and does all the things it needs to do, but then goes through steps of transformation to end up with something that the browser can understand. It's also nice because it does it in a way that doesn't require shipping a runtime, just dependencies.
[00:26:25] So that's why you're able to just send regular JavaScript. Because if you think about it like, how did we do this before React existed? I've had this conversation with people like, how does it work if there's no virtual DOM? I'm like, how did it work for 15 years before React existed? That's how it works.
00:26:42 - Christopher Burns
And I think a lot of it was maybe because we've kind of degraded CSS. Everything was just in the DOM, but hidden with CSS. But now we're to the point where you can have loads of things in the DOM that are just hidden with CSS, and it'd be fine.
My question was, you have an accordion in React. It could actually remove the code from the DOM. But I guess with Svelte it will just keep it there and hide it with some CSS.
00:27:12 - Jim Fisk
It will actually remove the HTML if you need it to. It will manipulate the DOM.
00:27:16 - Christopher Burns
So it manipulates.
00:27:17 - Jim Fisk
Yeah, it does.
00:27:18 - Anthony Campolo
Because JavaScript can manipulate the DOM.
00:27:20 - Christopher Burns
But then why isn't there a virtual DOM if it's manipulating the DOM? How does it know? It's a question for much smarter people than I am.
00:27:30 - Jim Fisk
Yeah. Same here. So I guess it is shipping some instructions, right? So it's like maybe you could call it mini virtual DOM. I don't know.
00:27:37 - Anthony Campolo
It's event listeners. It's just event listeners. That's how JavaScript works. You have event listeners, which is what tells JavaScript what manipulation to do, like innerHTML or querySelector, like all these things that no one knows anymore and no one learns because everyone uses these frameworks that are all DOM frameworks.
00:27:55 - Christopher Burns
Yeah. And it's that thing when you talk about abstraction. React is five out of five. They've abstracted everything away, where if you try to use window, React cries. But Svelte would be about two out of five, maybe lower or maybe higher.
00:28:14 - Jim Fisk
It's hard to say. Things are abstracted away. For instance, they made a shorthand reactive syntax. You can use a dollar sign, which is a valid JavaScript syntax, but that's not how it's used. They're basically hijacking that syntax to make it a shorthand reactive statement. So there is abstraction. The stuff that you're writing in your components, the JavaScript and the HTML and the CSS, it looks like regular JavaScript, HTML, and CSS, but it's really not. It's [unclear] HTML because it's all getting compiled into something else.
So there is abstraction. It just doesn't feel like it to me. As long as it doesn't feel like it, I'm happy. It feels like it's just regular HTML.
00:29:01 - Christopher Burns
I guess my last question before we go deeper into some of the things is: do you have things like styled components over there, styled components like CSS-in-JS?
00:29:11 - Anthony Campolo
Yeah, this is an awesome question. This is the whole thing with single-file components. The point of Svelte is that you don't need a library like that because it's designed from the start to have your CSS scoped to your individual components. Everything is going to be three chunks. You're going to have your HTML, then you're going to have your styling, then you're going to have your script. Every single page you have is a single-file component.
This is similar to Vue. This is one of the things that people really, really like about Vue and Svelte: the single-file component. This is why, when Redwood came out, Swyx wrote an article that said single-file components have come to React because of how you could do cells and stuff like that. So there is no need for styled components because of how Svelte was designed from the ground up.
00:29:59 - Jim Fisk
Yeah. Your styles are automatically scoped to the HTML in that file. You really can write a whole site without adding any class names whatsoever. If your components are reasonably scoped, then you can target those things specifically. If you're adding styles that aren't targeting anything or are redundant, it will automatically get shaken out of the build. It'll warn you about a lot of things. It's a really nice experience.
00:30:21 - Christopher Burns
And you don't even touch Babel or any of those crazy things, kind of?
00:30:27 - Anthony Campolo
You have Rollup.
00:30:28 - Christopher Burns
I thought Rollup was dead. Well, not being maintained, just sitting there.
00:30:33 - Anthony Campolo
No, Rollup's actually just as active as Webpack. Rollup is being used by a lot of projects because it's been used by Svelte. This is a perfect segue into the whole question of the bundler and all this kind of stuff. The important thing to separate first is whether you're talking about bundling in development or bundling in production.
When you bundle in development, that's like having your Webpack server running all the time and watching your project. This is now changing to projects like Snowpack or Vite that are using Esbuild instead. The question of using that in production is a whole separate question. So let's just talk about development now. First, let's define some terms here. I've gotten pretty deep into all this stuff, so it's all fresh in my brain.
00:31:25 - Christopher Burns
So start with Webpack. We all know what Webpack is that requires 20 different configs and tutorials on the internet just to get it working. How is Rollup different from Webpack? Because for React, you can use Rollup instead of Webpack.
00:31:45 - Anthony Campolo
I'm pretty sure Rollup and Webpack are very comparable in the sense that it was just kind of a newer, slightly, I think, re-architected version of a similar thing. So it's still JavaScript and it's still a bundler doing minification and all that kind of stuff. Is that kind of right, Jim?
00:32:05 - Jim Fisk
Yeah. You can use those almost interchangeably. They have different plugins and different things that you can hook into them, but Rollup and Webpack are very similar.
00:32:13 - Christopher Burns
Even Webpack is not a React tool. React just uses Webpack.
00:32:20 - Jim Fisk
Yeah, exactly. I think you could technically use Webpack with Svelte. I think people just tend to use Rollup because Rich created Rollup as well, Anthony.
00:32:30 - Anthony Campolo
Yeah. So Rich Harris, the creator of Svelte, is also the creator of Rollup. So all these tools he built together, and they fit very well together. But people like Rollup just by itself. That's why they've used it for other projects also. And people, like you say, some people just really like Webpack, so they're familiar with it and they already know how to use it. So they can bring that into Svelte as well.
But with the newer generation of build tools is where this starts getting interesting. This is where Esbuild enters the picture, because Esbuild, the thing that makes it cool, is that it's written in Go, which is funny because Plenti is written in Go. So there are some interesting similarities here, and it just does the bundling really fast because it's written in a different language. It's also leveraging ES modules, which is a much larger rabbit hole that we don't need to go down.
00:33:25 - Jim Fisk
Oh, I think we should.
00:33:26 - Anthony Campolo
Maybe if we have time. So Esbuild is being used by Snowpack and Vite. These are higher-level abstractions that are being built on top of Esbuild. SvelteKit, which is this new Svelte framework that's kind of replacing Sapper, was originally using Snowpack but has now changed to Vite. So I'd be curious to get your perspective on all of this. Jim, if you've used Vite, Snowpack, Esbuild, any of these kind of things, where your head is at with them?
00:33:57 - Jim Fisk
Yeah, I've used a few of them. I haven't used Vite, which I should use now because of the whole SvelteKit inclusion. But when I was starting Plenti, the first thing I used was Rollup. As most people know, when you use a bundler, it can slow down that whole process of being able to get your site ready to be viewed.
So for people who aren't familiar with what bundles are doing, they can do a lot of things. But essentially, when your JavaScript files are broken up into many different files, there used to be no way that a browser could read files across the project like that. A bundle is basically putting everything into one spot. It's going through all your CommonJS require statements, and it's building everything in a way that a browser could use it.
There's a new way to do this called ESM imports, which basically means the browser can now read import statements to different files. The challenge is it comes with a different syntax. Node.js uses a syntax called require to pull in different JavaScript files. There's this new syntax, the import syntax. Things like Deno are based on the new browser-based syntax. That's why you're seeing these different versions of things.
But there are also projects like Snowpack which are saying, hey, why don't we just use these imports so we don't have to bundle everything and preprocess everything every time. So it's kind of an interesting thing. When I was starting with Plenti, I was using Rollup, and it was really slow. Slow is relative, but it felt slow because I wanted that build to be really fast. A lot of times when projects are talking about build speeds, they only care about the actual compiling of components. For me, the build is the whole process from when you click to when you see the result. If you have to run a bundler, start up a web server, that whole thing that it takes from when you click to when you see is the build, right?
So for me, I could get my compile step down pretty quick, but the bundler was still taking up a huge chunk of that time. I moved over to Snowpack. Snowpack was significantly faster, but it was still slow. Snowpack for me took about half a second to get everything into the ESM import syntax and get it ready for the browser. Then the way that I'm using a Go-based project, we had to use something called an exec command, which allows us to execute Snowpack that's on your computer through npm. That was taking about another half second. So this whole thing was taking a second, which if you're used to bundlers, you're probably like, wow, a second. That's way fast. But for me it was way slow.
So I ended up building my own little tool called Go Pack. That basically is a less capable version of Snowpack. It doesn't do nearly as much, but it gets the base project working.
Essentially what we're doing is going through npm modules and finding your .js file. A lot of npm packages will have a .js file which is an ESM-ready version of their package. We try to find those and we bring them over to your client-side app. Then we also go through all your Svelte components and convert all the paths. A lot of times people use relative paths or shorthand paths, and we convert those to real paths that can be read by a browser. Then we move everything over.
So basically cutting out the bundler can save a bunch of time. Now, if you want to get things production-ready, you might want to still wrap things up and get things a little faster. That's where something like Esbuild comes in. That's something we're definitely going to focus on down the road. It's not super urgent because even our non-optimized sites are decently fast.
[00:37:17] We want to make things better and more production-ready. We'll probably pull in Esbuild. We had it in the project for a little while. Esbuild is super fast and it has an API, so we can just run it from our command line tools so we don't have to manage it outside of that, which is pretty cool.
But yeah, that's basically where our head is at there. We wanted things to be as fast as possible, so we figured we'd cut out the bundler and do that process natively in Go if we could.
00:37:38 - Anthony Campolo
Okay. So you said you were using Esbuild or you still are using Esbuild.
00:37:42 - Jim Fisk
We had Esbuild in the project for a little while to do some other things. We'll probably pull it back in to make better production builds and potentially allow for a larger ecosystem of projects that you can pull in. But right now, we don't use anything besides our own homegrown Go Pack tool.
00:37:57 - Anthony Campolo
Gotcha. Cool. It's one of those things where I look at a thing like Esbuild and I get excited about tools that are on the cusp of being kind of production-ready. It doesn't surprise me that you've experimented with it, but you still haven't gone all in. I always get excited about these things, but I was trying to stress to listeners that I want to be measured about these things also.
You want to pay attention to the things that are going to transform your workflow because it's going to be one of those things where people aren't really going to realize once the switch has happened. People are going to start using frameworks that have Esbuild in them, and people who don't ask a lot of questions about their tooling won't know that something's different. They'll just notice that it's going to be way faster, way nicer, and way more awesome. And that's just going to be, you know, slowly but surely, the direction this goes.
00:38:50 - Christopher Burns
The excitement for me is that I instantly think, like, just buy a better computer. And I have done that before as JavaScript is getting too slow. Goddamn bundlers, buy a computer with more RAM, more CPU, but it just doesn't work like you think it's going to work. That's where Esbuild really does change the perception.
And it's so sad. You're in a business, you're like, I'll buy myself a new computer. I'll be faster because time is money, and then you buy a new computer. Then two months later you're like, why do I feel like I need to buy a new computer? But it's because the tools we use as we start building more complex projects really do slow down. Things like Esbuild in things like Gatsby will completely change that framework because big websites in Gatsby can take like 10 to 15 minutes to compile them. So it's this thing that the hidden complexities are very much hidden, and that's where things like Esbuild can help. Not necessarily show them to you, but just help as projects get bigger and bigger.
00:40:08 - Jim Fisk
For sure. I'm definitely conscious of the speed of things. The idea of going back, and I know this is still just visionary at this point, but the whole git-backed CMS integration, this whole integrated Jamstack approach where it feels like you're using a traditional CMS but lighter and easier, the cold startup time for building things is super important to me because everything is going to happen in CI. CI doesn't have contextual awareness of anything that's happened before. You have to spin up a container, rebundle, rebuild, do npm install. If you have to do that every time, and those steps slow down every time, it's going to be a challenge to have a real-time feedback loop.
So basically the idea with Plenti was to cut all that stuff out and have a really minimal container with just the binary on it.
[00:40:54] So Plenti is kind of cool because you don't need any programming language. You don't have to have Node.js or Go or anything installed to use it, and that end-to-end process should be a lot faster. Our compile step is probably faster than a lot of other projects compiling Svelte because we really dug into the API. We're actually hitting the compiler directly, and we're doing that in V8. That stuff is pretty fast in general, but we're really just cutting out all those steps around it to make it faster. I think that's where our biggest gains are being made at this point.
00:41:24 - Anthony Campolo
Awesome. Well, we're getting close to the end of our time here, Jim. We covered a lot of ground here. We've had some listeners who really want the very dense, technical kind of episode, so I hope this one satisfied them. We went very deep into a lot of topics in this one, and I really recommend people check out Plenti. I think it's a really cool project, and it's really different from... I can't think of many other things that it's similar to.
So I always enjoy people who really stretch out to what can a framework be. What can you do with a framework? It sounds like you still have a lot of ideas of where it could go and how you could continue to grow it. So definitely recommend people check it out.
Why don't you let people know where they can find you, where they can contact you, where your hub is?
00:42:12 - Jim Fisk
Sure. Yeah. You can always reach out to me personally on Twitter. I'm @JimFisk. Or you can reach out to the Plenti project, it's Atlantico. Plenti is spelled with an I, not a Y, just so people who aren't familiar. If you want to check out our GitHub, it's github.com/Atlantico as well.
But yeah, we'd love to hear from folks. So definitely give us feedback, positive or negative. It helps either way. And if you're interested in helping out, just contact me and I'd be happy to onboard you in some way.
00:42:39 - Christopher Burns
Thank you for joining us. And maybe I'll give Svelte a go one day. Maybe.
00:42:47 - Jim Fisk
Great. Thank you both for having me on.
00:42:49 - Anthony Campolo
Have a good one.