Slinkity with Ben Holmes
Ben Holmes introduces Slinkity, a framework combining Eleventy and Vite to let developers use component frameworks like React without shipping unnecessary JavaScript.
Episode Description
Ben Holmes introduces Slinkity, a framework that combines Eleventy and Vite to let developers use component frameworks like React without shipping unnecessary JavaScript.
Episode Summary
Ben Holmes, a 22-year-old developer at Peloton, joins the podcast to introduce Slinkity, his open source project that bridges the gap between static site generators and JavaScript-heavy frameworks. The conversation begins with Ben's background, tracing his path from a high school internship with Angular One through a breadth-first exploration of modern frameworks. He explains how Eleventy works as a spiritual successor to Jekyll, converting Markdown and templates into pure HTML and CSS with no JavaScript overhead. This sets up the core problem Slinkity addresses: developers currently face a binary choice between lightweight static tools like Eleventy and full JavaScript frameworks like Next.js or Gatsby. Slinkity resolves this by gluing Eleventy together with the Vite bundler, allowing developers to insert React components into static templates using shortcodes and choose on a per-route basis whether to hydrate with JavaScript. Ben discusses why he switched from Snowpack to Vite, explains the islands architecture that enables mixing frameworks on a single page, and walks through a practical e-commerce example showing how static product pages can selectively add interactive elements like image carousels and cart buttons. He acknowledges current limitations around global state management while outlining a roadmap toward layout-aware page transitions and pseudo state persistence.
Chapters
00:00:00 - Introductions and Ben's Background
The hosts welcome Ben Holmes, creator of Slinkity, with some lighthearted banter about the project's name and pronunciation. Chris and Anthony introduce Ben as one of their younger guests at 22 years old, currently working at Peloton, and the conversation quickly turns playful with jokes about biking while coding.
Ben shares his origin story in web development, which began not with WordPress like many of his peers but with a high school internship involving Angular One and jQuery. He describes how listening to podcasts like Syntax FM expanded his awareness of the framework ecosystem, leading him to explore React, Svelte, and the Jamstack. This breadth-first approach to learning ultimately inspired him to build a tool that treats frameworks as interchangeable rather than requiring developers to commit to just one.
00:05:05 - Frameworks Converging and Astro's Influence
Chris observes that modern JavaScript frameworks are increasingly similar under the hood, which leads into a discussion of Astro and its spiritual connection to Slinkity. Ben explains that he was independently working on integrating JavaScript modules into his Eleventy-based personal site before discovering Astro was pursuing a similar vision.
He outlines two philosophical approaches to the problem: Astro's ground-up strategy of building a new templating language versus Slinkity's approach of gluing existing tools together. Slinkity leverages Eleventy's shortcode system to let developers insert React components directly into Liquid, Nunjucks, or Markdown templates, with Vite handling the JavaScript bundling. The result is a workflow where static templates remain the foundation and component frameworks are layered on only where needed.
00:08:46 - Understanding Eleventy and Static Site Generation
The conversation steps back to establish what Eleventy actually is for listeners from a React-heavy background. Ben traces the lineage from Jekyll, one of the original Jamstack tools built on Ruby, to Eleventy's JavaScript-based equivalent. He explains how both tools convert folders of Markdown and template files into plain HTML pages with no JavaScript output.
Chris and Ben then compare this static-only approach with frameworks like Gatsby and Next.js, framing the current landscape as two camps: simple tools with shallow learning curves and perfect Lighthouse scores versus feature-rich frameworks with steeper learning curves and heavier JavaScript bundles. Ben argues that Slinkity and Astro aim to create a spectrum between these camps, letting developers choose on a route-by-route basis how much JavaScript they actually need rather than committing entirely to one approach.
00:15:00 - CMS Integration, Builds, and the Vite Decision
Chris raises a practical concern about CMS workflows with static tools, and Ben explains the options available including incremental builds and Eleventy's serverless setup through Netlify. The discussion acknowledges that Next.js still has an edge for seamless CMS-driven content updates but notes the ecosystem is rapidly closing that gap.
The conversation shifts to why Slinkity uses Vite as its bundler. Ben recounts how Anthony pushed him to ship the project on a tight deadline, leading to a sprint where Snowpack's setup created friction but switching to Vite took only ten minutes and resolved the issues. He breaks down Vite's architecture as essentially esbuild for development speed combined with Rollup for production optimization, plus a built-in dev server and SSR capabilities that provide a strong foundation for Slinkity's two-step build process of static rendering followed by selective hydration.
00:25:05 - Versioning, Tooling Philosophy, and Slinkity's Architecture
A brief tangent on semantic versioning leads to observations about how library maintainers decide what 1.0 means, with Anthony noting the practical reality that teams often can't adopt pre-1.0 tools for production work. Chris characterizes the current JavaScript landscape as a particle collider of tools being smashed together.
Ben clarifies that Slinkity is fundamentally a glue layer with a CLI, orchestrating Eleventy and Vite in parallel rather than doing anything radically new on its own. Eleventy handles the static rendering while Vite picks up the JavaScript bundling, and the CLI simply coordinates these two processes. The discussion moves into ideal use cases, with Ben suggesting Slinkity shines for sites that are mostly static but need selective interactivity, while acknowledging its current limitations with global state management.
00:30:00 - Islands Architecture and the E-Commerce Example
Anthony introduces the islands architecture concept, and Ben illustrates it with an e-commerce scenario where different parts of a product page use different tools: a React image carousel here, a vanilla HTML form there, and a Svelte-powered add-to-cart button elsewhere. This piecemeal approach lets developers match the right tool to each interactive element on a page.
The hosts walk through the full e-commerce workflow, examining how a product page renders statically in Eleventy while interactive elements like the buy button and cart icon become React islands managed through Slinkity. Ben explains the hydration options available, including eager loading, lazy loading triggered by scroll position, and no hydration at all for design system components that only need HTML and CSS output.
00:36:11 - State Management, Single-Page Apps, and Cart Persistence
Chris pushes further on the cart example, asking how state persists across page navigations without a single-page app architecture. Ben explains the current limitation where each route resets its state and discusses the workaround of server requests, while outlining a future where Slinkity could use shared layouts to maintain state across navigations similar to how Gatsby and Next handle page transitions.
The conversation takes an interesting turn into local storage and cookies as underused tools by React developers who typically rely on hooks and context providers. Chris and Ben explore the fundamental difference between DOM-level navigation in single-page apps versus full page loads in static sites, and how this affects state persistence. Ben notes that the real appeal of single-page apps comes down to page transitions and persistent UI elements like navigation bars, features he plans to bring to Slinkity through layout-aware routing.
00:42:16 - The Future of Web Frameworks and Closing
Ben shares his vision for the next five years of web development, predicting that UI frameworks will become more dispensable and developers won't need to commit to React, Vue, or Svelte upfront to build a site. He positions Slinkity and Astro as early examples of tools that provide data fetching and layout rendering while letting the framework choice remain flexible per component or page.
The episode wraps with Ben mentioning current limitations including the lack of Vue and Svelte support, inviting open source contributors to check the issue tracker. He directs listeners to slinkity.dev for the quickstart guide and shares his Twitter handle for questions and meme exchanges. Anthony reflects on his positive experience getting started with the project and helping find early bugs during the alpha phase.
Transcript
00:00:00 - Anthony Campolo
I know you've already listened to a couple episodes, so you should kind of get the format. It'll be pretty straightforward. Yeah, let's kick it. Oh, and I've got a truck beeping now. Wow.
00:00:10 - short split/interjection
Wait for that.
00:00:11 - Anthony Campolo
Chris, do you want to do the intro? Yeah.
00:00:23 - Christopher Burns
Welcome to the podcast, Ben Holmes. People now know you for Slinkity, Slinkity, Slinkity.
00:00:30 - Anthony Campolo
Slinkity.
00:00:31 - Christopher Burns
Slinkity. There we go.
00:00:32 - Ben Holmes
You said both names it was going to be, so good job.
00:00:36 - Christopher Burns
Ben Holmes is the creator of the brand new project Slinkity, Slinkity, Slinkity, Slinkity.
00:00:45 - Ben Holmes
Well done. I'll be correcting people till the end of time. It's fine.
00:00:49 - Anthony Campolo
Now this is what Chris specializes in. Don't worry.
00:00:52 - Christopher Burns
Chris's specialties are quite special because we just finished an episode on crypto. I listened to it and I was like, I sound like the dumbest person on earth. And I run a fintech platform. Not crypto, just a fintech platform. I sound like the dumbest person on Earth.
00:01:07 - Anthony Campolo
You also had someone tweet saying, hey, I'm really glad Chris is asking these questions. So, you know, sometimes someone needs to ask the dumb questions.
00:01:14 - Christopher Burns
Exactly. But when I listened to it, I felt like I was swallowing nails. It was that bad. But, you know, there's questions for everyone, and I am an Eleventy noob. Slinkity is not something that I've fully booted up yet, but I do definitely want to try. Let's get into it and start chatting about it.
00:01:32 - Anthony Campolo
Let's also know who you are first. Give us a little bit of your background. You're one of our younger guests. You said you were just 22, right? Twenty-two, but you already have this really cool project going on, and you work for Peloton?
00:01:47 - Ben Holmes
I do.
00:01:48 - Anthony Campolo
No one can see you right now, but you're furiously biking as we speak, right?
00:01:52 - Ben Holmes
Yes. I just set my laptop right on top. We just bike our day away. We actually did have a setup like that in our office. A little wooden plank you could just ride the bike on. It was cool.
00:02:03 - Christopher Burns
I'm surprised that you need a laptop. I thought you would have one of these Peloton dev kits that's just a computer in the bike. You just have to keep pedaling to keep it on. Just keep pedaling.
00:02:13 - Ben Holmes
That's top secret. You've seen nothing. Which question to address? Who am I? I'm Ben. I work at Peloton. I've been doing web dev for a little while now, mostly on the front-end side. I do some full-stack stuff as well. I also want to compliment the little jazz intro that probably played before this, because I never hear podcasts that use jazz, so good on you for that. Yes, I pick up on it. I think it's really nice.
I do a lot of web dev and some blogging. I like teaching web dev as much as I like writing the code itself. Jumping into open source seemed like a good direction to go in. That wouldn't be super terrible, but I assume as more people start using it, the issues roll in. I'll have a rude awakening there, but it's been fun so far, just doing a little pet project and seeing how it goes.
00:02:58 - Christopher Burns
You're around my age range, so within five years. I'm going to guess your first experience of web dev is probably WordPress. Is it?
00:03:06 - Ben Holmes
It is not.
00:03:08 - short split/interjection
Oh.
00:03:08 - Christopher Burns
It's a close one. Most people our age, at 15, they're like, I'm gonna code. And then they find out about WordPress and you're like, PHP is the coolest language ever, and then you grow out of it.
00:03:19 - Ben Holmes
Yeah, the stories I hear are like people who are in bands, like rock bands, and they needed to make a website, and then they just go and build one, and that's their first web experience. I don't know why. I've heard that from Jay Lengstorf, for example.
00:03:31 - Anthony Campolo
That's right. You guys both just listed both of my stories. I started with WordPress, and I started making a band website.
00:03:36 - Ben Holmes
See, it's par for the course, I guess. What did I start with, though? I think I actually did an internship back in high school that got me into web development, which is very weird. They should not have let me into that codebase at all. I was asking stupid questions day in and day out for sure.
00:03:50 - Anthony Campolo
Was it written in a framework?
00:03:51 - Ben Holmes
Yeah, it was Angular One and Bower, copying jQuery code from somewhere. Not really any packages to speak of. It was just wild-westing my way through an image cropper that took me over a month to figure out and make accessible, and then slowly getting my feet wet, getting more comfortable with Angular One, which I still think is a great little framework to pick up.
I used it on some projects in college even, and then I worked through some stuff with React. I started drowning in podcasts like Syntax FM, which really got me into that world. At first I barely understood what they were talking about, but then I started understanding all these frameworks that actually exist. Then it became, what is the Jamstack? And then exploring Svelte, all sorts of things, and just kind of going breadth-first instead of depth-first and getting a little taste of everything that's out there.
I think that's part of what drove me to build something like Slinkity on top of Eleventy, where it's just like I'm comfortable in any framework. I see similarities in how they all sort of function. So I'd like to make something that brings them all together and treats them as these expendable things where you can say, I want to spin up React today, or I want to spin up Svelte over here. It should just be as easy as saying, insert Svelte or insert React somewhere.
00:05:05 - Christopher Burns
I find that the more time you develop, the more you see everything is the same. And I'm especially seeing this with React. Every framework has their benefits and their uses, but 90% of your code in React, in any of these frameworks, is all the same. It's a hook with JSX with CSS, and then you can easily swap all those frameworks out for different things. You want static rendering, then you want Gatsby. You want SSG, then you want Next. And these things are really, at this point, all the same. Even though people don't want to say they're the same, most of them are pretty close these days.
That's when I heard about this tool called Astro. It sounds mind-blowing that you don't need to use React while using React, and I believe it's exactly the same with Slinkity.
00:05:59 - Ben Holmes
Slinkity. Yeah, you just lost your voice there. No, I got it.
00:06:03 - short split/interjection
Sorry.
00:06:03 - Christopher Burns
Yeah. Slinkity.
00:06:04 - Ben Holmes
Yeah. Yeah, perfect. I will say it was going to be called Slinkity for a while, but SvelteKit came out and I realized that was going to be a little odd, given how similar they are. And also Eleventy ends in a Y, Slinkity needs to end in a Y. It's just that simple.
I also want to sell Slinkies as merch. That is the only motivation for the name of the project, so it had to sound as close to slinky as possible. A little backstory there, but you're totally on the money about Astro and Slinkity being very spiritually similar. I was actually working on this project before I had explored Astro. I was sort of messing with it at the end of last year. I think I was just trying to build something for my personal site where I was using Eleventy, and I just wanted to get some JavaScript modules to work. I was actually trying to make it like a single-page app with page transitions and all that stuff. And then I sort of dove into these modules.
I realized Snowpack is really good at bundling stuff. It's much more user-friendly than the old Webpack and Rollup standards. So I started messing with that. And then I heard what Astro was doing and thought, oh, they stole the idea. Dang it. I mean, of course not. It's just that we both arrived at the same sort of conclusion. I realized there are really two ways to go about it. You can either go scorched-earth and build a brand new tool from the ground up, which is what Astro is doing, making their own templating language and letting you insert components wherever you want to. Or you could go the approach of trying to just glue as many existing tools together as possible, which is kind of what I'm doing, where I'm gluing together Eleventy and the Vite bundler in order to pull off something kind of similar, where you have all of your static templates that you're building, maybe using Liquid syntax. If you've used Shopify, that's their language for doing things.
It's also something that Eleventy supports. You could use Nunjucks to build out your pages. You could use plain HTML. Maybe you're using Markdown to write blog posts, any of those existing templates, and then you just want to insert components into those templates that you've already built. That's sort of the ethos for what Slinkity is trying to do. It's using a syntax called Shortcodes, which is a very significant feature in Eleventy, I guess.
00:08:05 - Anthony Campolo
WordPress people know Shortcodes.
00:08:06 - Ben Holmes
You know, Shortcodes in WordPress. Okay, I've never used WordPress, but yeah, it's basically just saying, insert code here. And when it's going to render out that template, it'll say, okay, this shortcode says React and I have a function over here called React. I'm just going to pass whatever parameters I need to, to that React function. And then whatever HTML it spits out, I will slot into your page where you told me to slot it.
We just piggybacked off of that idea and said, let's throw components at your page using that same sort of approach. And then how do we hydrate it with JavaScript? How do we add bundlers? All that fancy stuff that we can get into. But that's the general approach: taking tools you're already using and adding some JavaScript spice onto it.
00:08:46 - Christopher Burns
Before we go too deep on Slinkity, we should first talk about Eleventy.
00:08:53 - Ben Holmes
Why should we?
00:08:55 - Christopher Burns
We're a very React-heavy podcast, and Eleventy doesn't even use React as the base, right? It's just HTML, correct? No JavaScript?
00:09:04 - Ben Holmes
Yes.
00:09:05 - Anthony Campolo
I would think of it as Node as the base.
00:09:08 - Ben Holmes
Well, sure. Yeah. Have you heard of Jekyll before or used it?
00:09:13 - Anthony Campolo
Yes, we had the creator on episode four.
00:09:15 - Ben Holmes
Did you?
00:09:16 - Christopher Burns
For the listeners, what is Jekyll? What came before Eleventy?
00:09:20 - Ben Holmes
Great question. How far back do we want to go?
00:09:23 - Christopher Burns
As simple as possible.
00:09:25 - Ben Holmes
Visual Basic back in the... yes. So Jekyll was, I would say, one of the first Jamstack tools. It's based on Ruby, is how the engine works. But the crux of it is you have a folder and you want to take in maybe some Liquid templates, some Markdown, some sort of templating language that's not just basic HTML. And you want to point a tool at that folder and say, hey, I have these Markdown files here, convert these into HTML that a browser can understand.
So then Jekyll will come in and say, all right, I'm going to loop over all these files that you have in this folder, and I'm going to turn them into actual HTML pages that you can go visit in your browser as a route. So if I write up some stuff in blog.md, it'll spit out a /blog page where I can actually visit it as a website. And of course, there's no JavaScript involved with that. It's just letting me use some slightly nicer templating syntax in order to build a basic HTML page.
[00:10:23] I know Jekyll also helps with styling your site with Sass, and it'll automatically process Sass stuff for you, which is a nice little convenience. But if you want to add JavaScript to it, you don't have a lot of options. You have to set it up yourself. Eleventy is very similar to Jekyll's approach. The only difference is that they're using JavaScript instead of Ruby.
So if you want to write your own plugins or your own build setup, it's a lot more approachable. If you're already a front-end developer, you just write a little Node script that says, here's how I process Sass, or here's how I process Stylus. For example, here are the assets that I want to copy into my website. Maybe I have a folder of fonts that you want to paste in. The more significant part that makes it Jamstack is the way that it'll let you pull in data from somewhere. If you also want to write some data fetchers that say, go to this CMS, grab some data, and slot it into my template pages.
[00:11:16] If you have a Liquid page that receives data from a CMS, you can just slot it in saying, my title goes here, my description goes here, and then it'll spit out a nice route in your browser on the other side. That's a basic rundown of what Eleventy does. It lets you fetch data, lets you slot it into templates, and it'll spit out HTML and CSS. On the other side, we just need the JavaScript piece to go that extra mile if you want to use component frameworks and stuff.
00:11:40 - Christopher Burns
When we say no JavaScript, we literally mean there's no hydration. There's no loading. What comes out of Eleventy is just pure HTML and CSS, and that's it. No JavaScript, no pre-rendering or hydration, because it's all done at compile time, right?
00:11:57 - Ben Holmes
It's all at compile time. Yeah.
00:11:59 - Christopher Burns
Would you see it as a downgrade to something like Gatsby or Next that can do things like pre-rendering? They use JavaScript when Eleventy uses it all in the compiler stage. So Gatsby has a compiler stage where it puts it all down, and Next can do it on the fly, but it also has a compiler stage. So is something like Eleventy a sidestep to something like Gatsby and Next, or is it more like a distant cousin that still kind of does the same thing?
00:12:30 - Ben Holmes
Yeah. He's the weird kid in the corner that's just like, no, we got to get back to the fundamentals. And it is a very simple tool in that way. I've actually phrased this as the two camps of static site generation right now, or the two camps of Jamstack, where on the one side you have the very simple tools that are easy to pick up for beginners.
If you took an HTML/CSS class in high school or college or something, you're pretty confident with like, okay, I just make a folder of Markdown files, I run this little tool in my command line, and I have a website. I didn't have to learn state management. I didn't have to learn what React is. I just have a website now. I can apply styles to it. I can do whatever I need to do.
So it's a shallow learning curve and you have no JavaScript shipped. If you're worried about client-side performance and getting perfect Lighthouse scores, it's going to work great for that.
[00:13:15] If you have a very simple website that doesn't really need JavaScript, then you have the other camp that does need some dynamic stuff. Gatsby lets you have a single-page app, so if you need global state management and stuff, it's got you covered. If you need an animated image carousel, a multi-step form, more dynamic interactions that React can really help you with, Gatsby and Next are going to be great for that too.
But the compromise is there. The build times might be longer because it's processing a bunch of JavaScript. The learning curve is steeper because now you got to learn React. You got to understand JavaScript better, or Vue or Svelte, if you're using those tools. And the Lighthouse scores and user performance might be worse than it needs to be. Sometimes you do need that JavaScript and you're getting like an 80 or 90, and it's great. I know Next.js has put in years and years of work into making it as efficient as possible, and it really shows. It's amazing what they managed to pull off, but sometimes if a page doesn't need any JavaScript whatsoever and you're still shipping a big old hydration blob, it's a tradeoff for your users that you maybe didn't need to make.
[00:14:18] The goal of Astro, as well as Slinkity, I guess, is to treat sites along a spectrum between those two camps. I shouldn't have to choose Eleventy and then regret it later when I need JavaScript, or choose Next and feel guilty about my JavaScript. I should be able to say, all right, my site's like 80% static and I'm going to build Markdown files for that 80%, and then 20% I need React. Then you could have a hybrid approach. I'm just going to use basic tools here, but then for that 20%, I'm going to reach for React.
Or maybe you're at the other end and you need mostly JavaScript. And then you have a home page and an about page that doesn't need JavaScript. Just finding some way to exist between those two camps and choose on a route-by-route basis what tools you actually need for the job.
00:15:00 - Christopher Burns
I feel like some people, I can say hand on heart that I've done this myself, have jumped the gun on things like Eleventy. There's probably been a lot of projects I've done that Eleventy would have been completely perfect for, and I've just gone, just jam Next.js in there, you know, jam Gatsby in there. And because they're what I'm used to, I've never really thought about the other side.
My biggest question with these more traditional ones is: what about CMSs that aren't Markdown? Can you have Contentful or GraphQL?
00:15:33 - Ben Holmes
Yes.
00:15:34 - Christopher Burns
So you can. But the caveat is you update that content on that CMS, you have to then re-click that build button.
00:15:42 - Ben Holmes
Yes, there's obviously incremental build options that all of these offer. Eleventy is no exception. They have incremental builds as well with the cache setup, so you only rebuild the routes that actually changed. They also have a serverless setup.
Now I know there's this really modern way of handling that that I don't want to get too much into, but Netlify lets you build only when the content changes on this one page. And it's kind of running on a serverless function, but it's also caching the build. So it's like this in-between state. If you have content that updates semi-regularly, you can say this one route is a serverless function now, and I want it to rerender every day or every ten user visits or something. There's flexibility there to not rebuild all the time if you have super dynamic stuff, but it is the compromise of a static approach. I know Next.js lets you just run a server, like server-side props, no static building whatsoever. And if that's your jam, then do it.
[00:16:37] Yeah, there's always going to be tradeoffs there.
00:16:39 - Christopher Burns
I think one of the biggest reasons I got pulled into Next.js is such a simple thing. Somebody less technical can go on the CMS of the website, change a word, click publish, and Next.js is done. Next.js is just rebuilt in the background. The word's changed now. Good. And that's obviously the issue they really don't talk much about.
But there are obviously other things on the market, you know, because we're paying for this stuff now in the open source community that is really coming together. One of them is a plugin for Vite called Vite Plugin SSR. I don't know if you've heard of it. Yes, but it gives that kind of Next.js system, I believe, to Vite to allow you to do those kinds of rebuilds in the background. This is all out of my depth because I've never used Vite, but I've heard people talking about it. Doesn't Slinkity use Vite?
00:17:40 - Ben Holmes
That is correct. I hate to be that guy, but it's Vite. I think it's Vite. I'll check my sources on that. We do use Vite. It does have that SSR setup which we are looking into, actually, because we have a two-step build process right now.
At the first step, it'll statically render your page. We support React only right now, but it could support Vue and Svelte very soon. If you create a route on your site like blogger.jsx and you want that to become blogger.html on the other side, so it's actually a page you can visit as a route, first it'll look at that JSX file and then apply any layouts to it that you may have, apply any CMS data or whatever other data you pull in, and then it'll spit out some raw HTML that can just be visited.
You can actually toggle a setting to just stop at that step and say, I don't want to ship any JavaScript. I just want to ship whatever HTML this JSX file has in it. You could treat it like a pure static site render if you want, but then you have step two if you want it, which is we also ship the original component alongside that HTML file. So then Vite is able to come in and say, oh, look, we have a component over here that I can slot into this HTML that you rendered. I'm going to hydrate it for you and then ship whatever JavaScript I need so that the browser can understand it and hydrate correctly.
The SSR piece would help us with step one, which is instead of us trying to render the HTML or squeeze the HTML out of your components, we could have Vite do that for us. And that's what SSR would help us with: say, Vite, go look at this component, tell me whatever Node-friendly stuff you can get out of it, and then we'll use that to statically render your page.
If you do that with a serverless function, which is something that Eleventy offers as well, then you could do that pure SSR approach. You'd basically have this dynamically rendered page that could be static, could ship JavaScript. I got a ton of flexibility, but in general, every time I see CMS changes, I'll see that new change reflected on my page and it'll just rerender every time using SSR and then also shipping that JavaScript bundle. I said a lot of buzzwords there. Does that make sense?
00:19:48 - Christopher Burns
Yeah, no, it all totally makes sense. One of my big questions is why Vite? What is Vite? Why is it different to Webpack, and why did you choose Vite?
00:19:59 - Ben Holmes
Great question.
00:20:00 - Anthony Campolo
I was gonna ask you about this too, before I kind of hop in real quick.
00:20:03 - Ben Holmes
Sure.
00:20:04 - Anthony Campolo
I wanted to make sure Chris got a chance to ask all these kinds of level-setting questions, because this is one of those projects that I'm already so deep in and so deep in all the tech, because I personally have been learning both Eleventy and Vite kind of separately in the background over the course of this year, and I've been very excited for Slinkity, and I even hopped in and wrote the very first blog post about it, which you helped me out a lot with.
00:20:27 - Ben Holmes
You're on page one of Google. Good job.
00:20:30 - Anthony Campolo
Yeah. That's right.
00:20:31 - Ben Holmes
Nailed it in that journalism.
00:20:33 - Anthony Campolo
Oh, yeah. And it's great because of all these newer pieces of tech that you're smashing together. I was on the Semantic Stream with Ben talking about Vite, and he was like, is there an Eleventy plugin for Vite? And I'm like, ah, yeah, probably. But what you're doing is much deeper than just creating a plugin. You're actually creating a framework that integrates the two, and it's more akin to, you mentioned SvelteKit.
SvelteKit has tried to integrate Snowpack and then ended up switching to Vite. And you actually went through a similar process here. So I think that would be a good explanation of what Vite is by talking a little bit about why you started with Snowpack, what limitations it had, and why you switched to Vite.
00:21:15 - Ben Holmes
I hate to join that crowd of like, we're dropping Snowpack. But I know Astro is built on top of Snowpack and has done some very incredible work with it. I just need to talk to that community more to understand the setup that they've created.
Because the reason I switched to Vite, I originally was going to put off publishing this package at all. I was going to publish it, maybe not even by the time we're doing this podcast right now. I had no set schedule, but then I talked to the React Podcast community about what I should do, when I should start shipping things, and when it's ready to go. I think it was you who said.
00:21:49 - Anthony Campolo
I said, ship it yesterday, I think is what I said.
00:21:51 - Ben Holmes
You said ship it yesterday, and I said, okay, Tuesday is my deadline. I don't know what I'm going to ship. I don't know what features it will have, but something will be announced.
On Tuesday, I decided to rewrite Slinkity for the fifth time, building up the bare-bones features that I think would be useful to people, and that ended up just being like, get React working as a template, get it working as a shortcode, and that's pretty much it. Maybe figure out a way to ship JavaScript or not, like an on-off switch. I ended up doing a little more than that, but to get it out the door, I had a one-week sprint to do that.
I was hitting some roadblocks with the Snowpack setup. It's very technical. I'd like to work it out with them to sort of see what I could do. But switching to Vite, it was literally ten minutes of just deleting Snowpack server, replacing it with Vite server, and suddenly everything was working great, at least with the setup that I was running.
[00:22:43] So I said, all right, in order to get this out the door, I guess we got to switch to Vite. If we go back to Snowpack, if there's a compelling reason to do it, then we will, because it's an early alpha project. Everything's kind of up in the air.
But things that I do like about Vite now that I've been using it more: first off, it's pretty mature. They have SSR set up. They also have a demo for statically rendering things like a static site generator. So there's a lot of legwork that's gone in there.
I also know that it will be nicer to implement Vue because it's created by Evan You. Vite was originally kind of the Vue bundler, and they sort of expanded it to be the just-everything bundler. So that should be exciting for anyone anxious to try Vue and Eleventy together.
But the last thing is for production builds. They use a bundler called Rollup, which has been around for a long time. It's similar to Webpack and sort of the bundler tools that you might be used to, and that allows for really good minification, squashing down variable names to those single-letter variable names that you barely understand if you look at your bundle. But it's efficient. That's kind of the nice thing about Vite.
They sort of recognize that the modern bundling tool, which is esbuild, if anyone has heard of that, is a new JavaScript bundler that runs on Go. It's an early project right now, but it's very quick and very good at what it does. But it's missing some of those JavaScript minification steps and some efficiency around bundling your CSS, stuff that'll just take a year or so for them to work out. Snowpack uses esbuild all the way down the line, and Vite said, okay, we don't think esbuild is 100% ready yet, so we're going to slap Rollup on top for your production builds.
It just has a little bit nicer out-of-the-box setup in order to give you the best production build possible, and also the best sort of dev server experience. So that's the reason we ended up using Vite. Time crunch plus a few sort of future-proofing features. If there's a good reason to use Snowpack, we will, because of course Astro is very similar to our project and they live on Snowpack, so I'd be interested to know.
[00:24:42] But did I do enough to explain what Vite is in there, by the way?
00:24:46 - Christopher Burns
Yeah.
00:24:46 - Ben Holmes
Okay. Good.
00:24:48 - Christopher Burns
Yeah. So obviously Vite is created by the same people that create Vue and also Rollup. And basically Vite is Rollup plus esbuild.
00:25:00 - Ben Holmes
Pretty much.
00:25:01 - Christopher Burns
Golden.
00:25:02 - Ben Holmes
And also a dev server.
00:25:03 - Christopher Burns
And also a dev server.
00:25:05 - Ben Holmes
Which is nice.
00:25:05 - Christopher Burns
Exactly. And I have to think, somehow Webpack got to 5.0. Have we ever truly hit a Rollup 2? Of course they've versioned it past two, but they've not been like, this is a brand new breaking version of everything, for how many years?
00:25:21 - Ben Holmes
Yeah. It's interesting. I've always wondered how library maintainers sort of decide on versioning.
00:25:25 - Anthony Campolo
Flip a coin.
00:25:26 - Ben Holmes
Because I'm going to have to deal with that myself. Like, what does 1.0 mean? If you didn't know, Eleventy isn't 1.0. They're not even 90% of the way there according to their roadmap at the moment. But I personally think it's like 2 or 3.0 at this point. I don't know. That was Eleventy's approach to things. I know that some hold off on 1.0 for a while, and then Snowpack is on version 3.1, I believe, even though it's more early days.
00:25:51 - Christopher Burns
What I think it truly is, is some developers get in their mind that 1.0 means I can post it on Hacker News and Product Hunt saying, here you go world.
00:26:00 - Ben Holmes
And no one will get upset.
00:26:02 - Christopher Burns
Exactly. It's perfect.
00:26:04 - Anthony Campolo
No. It's about being able to tell your boss that you can use it. I think that's the real thing, is that you can't tell your boss you're using a zero-dot thing.
00:26:11 - Ben Holmes
It's true. You can't.
00:26:13 - Christopher Burns
Yeah. It's like, what do you mean, zero dot? We should really start good these days and start with minuses. You know, we're going to start negative 20 and make our way to zero.
00:26:23 - Ben Holmes
That's how indices work, right? Zero is a starting line.
00:26:25 - Christopher Burns
Well exactly. So there's obviously all these tools that are out there right now. And it kind of feels, you know, a bit like a spicy Hadron Collider for JavaScript. Everyone's just going, I've got a tool on the left, a tool on the right. Let's smash them together and see what happens. And that's what Slinkity is, right?
00:26:44 - Ben Holmes
Yes. You said the name confidently. I like that. It's literally just the glue between a bundler and Eleventy. It's not doing anything crazy fancy. The only reason that it's considered more of a framework than a plugin is because we have a CLI tool that looks nice where instead of running eleventy serve, you run slinkity serve. We mostly just did that because we're orchestrating two things at once. Eleventy is running in one process and Vite is running in another, and Vite is going to look at whatever Eleventy puts out.
It's kind of like a tag team where Eleventy statically renders everything for you, and then Vite picks up the JavaScript bundling that Eleventy left off for it to do. We just needed a nice little CLI that would run the two in parallel without it being a lot of setup on your part. It ended up working like that, but it's really just a plugin with a nice little CLI on top.
00:27:31 - Anthony Campolo
Throw Prisma on there, and you'll be fine in no time.
00:27:34 - Ben Holmes
Pretty much. You can throw anything you want at it.
00:27:36 - Christopher Burns
How long is it going to be until you're persuading your bosses at Peloton to use Slinkity? Second to that, what's the main use case for Slinkity? If you were going to pitch the perfect use case to a developer, you know, developers looking for a framework to use to build a project, what would you say your go-to de facto project would be to build with Slinkity? And I hope it's not Hello World or a to-do list.
00:28:00 - Ben Holmes
You could do that. Yeah, I think that's like the peak of Slinkity, if you can get a to-do list working. First question, I don't know. I mean, it all depends on how the experience works out. I'm on the e-commerce division.
00:28:13 - Anthony Campolo
It's a very honest answer. I like that.
00:28:16 - Ben Holmes
When it hits 1.0, I'll try to schedule a little meeting, see what goes on, because I do think Slinkity is a very flexible tool. As I mentioned, it sort of slides between the world of all JavaScript, all the things, and no JavaScript anything.
The only thing that it doesn't do very well, and I think this is more of a fundamental issue, is global state management, orchestrating stuff between a ton of pages, because every route is considered this independent little entity. On my blog page I'm using Markdown. Maybe I'm importing React. I'm doing something fancy with that, and I'm going to bundle it on its own.
There's no way to say, I'm going to throw a React context up in the air and I want all of my pages to access it. There are definitely options. I know XState is very flexible and works in any framework you want. So something interesting there with state machines could be interesting to have that global state set up that isn't just like local storage or something.
[00:29:11] So that's where it kind of falls flat, is if you're in that 100% JavaScript camp where you have everything dynamic. I need global state management. I need my React trees for that. I would say Next.js and Gatsby are still best.
But first off, if you're learning web dev for the first time, I think Slinkity is finally a good answer to that question. I've gotten really frustrated when a friend asks, how do I build my personal portfolio even, or a promo site for this organization that we're building? I could tell them Eleventy, but if they see a cool React library that they want to use, then they're kind of out of luck. It would be a lot of work for them to set it up, so I've set them down the wrong path. I didn't give them enough tooling.
I could also recommend Next.js, but then it would be really hard for them to get team members if people don't know React, and that would be its own can of worms.
00:29:58 - Anthony Campolo
Are you familiar with the islands architecture?
00:30:00 - Ben Holmes
Yes. I was going to hold off on that because I didn't want to go too deep on it. But it is islands now.
00:30:05 - Anthony Campolo
It is a good time to talk about that. Yeah.
00:30:07 - Ben Holmes
For those unaware, islands is basically like every little set of JavaScript is its own island on the page. I guess an example could be like an e-commerce site where you have a preview of what the product is, maybe an animated image carousel. And you say, okay, I'm going to make a little island of React on this page, and I'm going to use React to make an animated image carousel through all of this stuff.
For this product, off to the side, you have a form where people can configure that product and add it to cart. And for that you might do a little island of just basic Liquid or vanilla HTML in order to create a form that people can fill out.
Then maybe the add-to-cart button itself has a little loading spinner and some dynamic stuff, and you make a little island of Svelte in that one area just for that one button, and you plug that into your page. That's essentially islands, where you can use whatever tools you want on the same page. If you've ever heard of micro-frontends, it also comes up a lot when talking about that sort of architecture.
[00:31:05] It's a way to piecemeal your site together, and that's something that Slinkity helps you pull off. What was the original question? What is Slinkity good for?
00:31:12 - Christopher Burns
What is Slinkity good for? For example, if I'm going to build a dashboard, Slinkity doesn't seem like the tool I should use. Or is it?
00:31:21 - Ben Holmes
It all depends. Like if you just have a dashboard on one route.
00:31:25 - Anthony Campolo
A very simple dashboard maybe.
00:31:27 - Ben Holmes
Yeah, well, if you have a dashboard on one route, you can say dashboard.js is the page. And now for this route, I can use whatever React libraries or React madness I want to use, and it'll all work on the client. I would say it actually could work if you want to do different things depending on the route. That's what it's really good at right now.
00:31:46 - Christopher Burns
What about this question? I feel like this is a really good question because we're all so deep in JavaScript. 2020 web dev. Let's call it 2020 web dev.
00:31:56 - Anthony Campolo
Hashtag deep.
00:31:57 - Christopher Burns
Deep. You know, razor's edge at this point. But what about someone who's been working at an agency for the last five years? They've left the agency and they've left behind old tech stacks in PHP. They're going to build a website. It's going to be a website for a client, and it's an e-commerce website. Would you say Slinkity would be a really good tool to help them get away from everything they've been using, but they still have the fundamental knowledge to then pick it all up, make it go 95% of the way with minimum effort, and really get the job done as easily as possible?
00:32:34 - Ben Holmes
I do think so. I definitely see it as being good for an e-commerce environment where you just want to have an independent route for every product on your site. For example, Eleventy has a lot of tools to pluck off the slug as a query parameter. So if you go to /products/name-of-product, you can pluck off that name, pass it to your CMS, and get whatever information about that product you need, and then slap it into whatever template you want.
If it's a purely static page that just describes the product, then maybe you just use Markdown and whip that up. It'll go ahead and build that. You can add a little hook that says, every time I see CMS updates, rebuild this one page. That will work great too. At that point, you're not even using Slinkity, you're just using Eleventy to build your e-commerce experience.
But then if you say, I made my Markdown file, I describe my product, now I want a little animated image carousel just on this one part. I just want to insert React right here for all of my images. You could add a little shortcode that says React and then your image carousel component, and then you can slot in that CMS data or whatever you need to add that interactivity in that one place, and then from there add-to-cart form, whatever you have set up. In order to actually pass those requests somewhere, you'd probably need a server for that. But in the Jamstack world, it's pretty common to have a server in your front end sort of decoupled. So one talks to the other. You could set that up yourself and then you could go from there.
00:33:55 - Anthony Campolo
Yeah. My blog post that I do to demonstrate this is I just have a Markdown file and a JSX file, and the Markdown file imports the JSX. And that was, like, to me how I could get the very, very simplest thing that Slinkity does. Obviously that's not even close to everything it does, but I thought that was kind of cool because it makes it almost like an MDX kind of replacement in that sense.
Like, you could very easily just get some React into your Markdown. And that, to me, is really powerful, especially for someone who loves Markdown, knows React really well, and can combine those two in a very simple way with nice conventions. That's already really powerful to me.
00:34:31 - Ben Holmes
Yes, I do want to mention there's also the flexibility of how you want to render that little island. If I want to render a big JavaScript bundle right when the page loads, I can say, load it eagerly. It'll pop up on the page, it'll hydrate, and it'll be interactive. I could also say lazily import that JavaScript. It'll have no JavaScript on the page whatsoever, but if I have to scroll down to that carousel, I can wait for you to scroll to it and then start downloading React and all of that interactivity.
So I get that great Lighthouse score, that great time to interactive. And then when you actually scroll to the JavaScript stuff, I will go ahead and hydrate that for you. Or you could say never hydrate anything. I got a tweet recently from someone using it to scaffold their design system, where they have a whole design system in React, but they don't want to ship JavaScript with that design system. So they can just say, all right, import all of our design system components and then don't hydrate them.
[00:35:25] So I'm able to use this as just a vanilla templating language. I have all my scoped CSS with CSS modules and stuff; that all works. I just want to ship HTML and CSS at the end of the day, but use React to accomplish that job. You have that flexibility as well.
00:35:40 - Christopher Burns
My last question is with the e-commerce example. Let's hook something like Shopify. Shopify is this hybrid thing now where you can build your own front end. You don't have to use that templating language. One of the big things is a shopping cart.
So when you said Eleventy, I thought, okay, yeah, I can see you building the pages statically and all, that's fine. But what happens when you click Add to Cart that requires JavaScript? So is that going above Eleventy? Is that where we're starting to take over?
00:36:11 - Ben Holmes
Yes.
00:36:11 - Christopher Burns
Okay. Because you might forget that when you're looking at a page, of course it can be 100% HTML, but as soon as you click that buy button or that add-to-cart button or click a different size or color button, that's obviously interactivity. Also, you need to record that data and then send it somewhere, i.e., to a checkout cart. That's where you would say Slinkity is, you know, the whole page.
We're looking at our product page. The product page is rendered in HTML, but the buy button that's in React, when you click buy, it's going to trigger a hook. The hook is then going to update the cart. Then when you click the cart icon that's also in React, because obviously you need to know what's in your cart. You're using that islands architecture to only bring interactivity to things that need it. Is that correct?
00:37:02 - Ben Holmes
That is correct.
00:37:03 - Christopher Burns
There we go.
00:37:03 - Ben Holmes
The one little wrinkle there, of course, as you mentioned, is: who stores this? Once that add-to-cart button hits and we store it in a hook, where does the cart information go?
I guess in our example it would be a React component that sends a request to a server. The server keeps track of all the user's carts so that when you navigate to other pages on the site, we sort of make that server request again to remember what the cart is, and then put that into our add-to-cart. That is the issue that I mentioned, which is we're not in single-page-app land anymore. You have to reset everything when you go to a new route.
That's not to say that is the future of Slinkity. The original demo video I did was actually a single-page-app example. This is something that we're going to move towards because with Eleventy you can have layouts that all of your pages use. For example, something Gatsby has, something Next has: wrap it in a nice layout and then it'll slot in your page just under that layout.
[00:37:57] Because we know the layouts that are being stitched together, there's a pretty easy way to say, okay, all these pages share the same layout. So when I click on this route that goes to another page with that layout, I'm going to animate in the changes between those two pages, but I'll leave the layout the same. A classic example would be a layout that has a navigation bar. When I click on one page that uses that same navigation bar, I want the nav bar to stay stationary on the page. But maybe I do like a PowerPoint-style transition between the pages under that nav bar. That is totally possible because we know the layouts that these pages are using, so we can sort of diff them and figure it out.
Another feature that unlocks is you can leave the state in those layouts as well. So if you had a cart icon that describes your cart, instead of having to do that server request every time you go to a new route, we could be smart enough to say, okay, all these routes have the same layout, only make the request once, and then change the parts that change underneath that layout.
[00:38:55] Very early days on that sort of setup, but I could definitely see a future there where you have pseudo state management.
00:39:01 - Christopher Burns
I think the real answer here is that you should go all the way and teach React developers about cookies and local storage.
00:39:10 - Ben Holmes
Also local storage. It's there, it's there.
00:39:13 - Christopher Burns
You know how many React developers do you think have ever used local storage? Because I don't think I have inside React, because obviously there's the hook mechanic. There's a provider mechanic that can store the information you need. So there are these very underlying JavaScript abilities, functions that technically, you know, could hold the state for things like a cart between the different pages.
Because the big thing we tend to run over with single-page apps is that the page is not actually changing. It's the DOM that's changing, not the actual page. So you have to imagine it with a single-page app. You're rendering all this HTML and then you go, okay, now drop all that HTML out of the DOM. Now load all the next HTML into the DOM. And that's a page change in a single-page application.
It can store things like hooks and things because technically the navigation has not changed. But obviously when you click reload on a single-page app, it completely starts from the beginning. It's got to rehydrate everything. Completely different experience. And that's what technically something like Slinkity is doing, isn't it? It's like every time you navigate a page, it's checking out everything and starting from the beginning. And because it's only HTML, it's rendering. It's super fast.
00:40:34 - Ben Holmes
Exactly. Yeah. I almost regret not bringing up local storage in that example, because if you have a cart, you would definitely use local storage in order to persist it, because a reload would get rid of your cart, which no one wants.
But I do recognize people really like Redux. They really like React context and things like that. And they do have nicer APIs than just local storage itself, unless you have a great hook to do it, which a lot of people do. But there are a lot of ways to persist state beyond the single-page-app approach.
I think the main appeal of single-page apps is just the ability to do page transitions, which I honestly don't see enough of. I want the nav bar to stay the same, and I want to do a fade in, or I have a tab bar along the bottom, and I want to sort of paginate between those sliding panes. And that's like the really big thing that, if you're doing server-driven routing, you're not going to get right now.
[00:41:25] Google, I know Chrome's doing some crazy stuff, but I'm very curious where you end up.
00:41:31 - Christopher Burns
Yeah. Chrome on the 17th did an article by Jake Archibald talking about how they can basically diff single-page apps and only navigate the inside things. But that's all up in the air right now about how is it actually going to work. Can Chrome do it on any website, or can they only do it on, say, Next.js where it knows everything about Next.js?
At this point, I think there's some super interesting things there about how the industry is going to go forward, because at one point we thought PWAs were going to be everything. PWAs have never died, but they've never gone anywhere. In the next five years, what are we going to see? What do you think we're going to see? Obviously, creating one of these tools, you're thinking about the next five years.
00:42:16 - Ben Holmes
I guess it's a leading question of what we would expect. I think we're going to see UI frameworks become a little more dispensable. You don't need to commit to React to build your entire site, which is the landscape we're in right now where we've built the same tool three times over. You got SvelteKit, Nuxt, and Next.
There's a lot of nuance in how they do things, and they are very different. And because they're tied to a framework, they can do some specialized stuff. But I think the direction Slinkity and Astro are going in is, in order to build a static site, you shouldn't have to choose your framework up front. You should be able to use whatever you want. All you need help with is some way to get data from a CMS and pipe that data into the layouts that you're creating. So that's the bare bones of what Slinkity and Astro could provide: a nice API to go get some information from somewhere and statically render it. And then the choice to use React, Vue, Svelte, MDX, Solid, I think, is one of the new ones.
[00:43:13] There's a ton of approaches to writing HTML at this point, and I think we'll see the need to commit to a framework fade away, and all-encompassing tools become a little bit more common. That said, SvelteKit is really amazing out of those three, and I think they've got something really interesting going on by just committing to Svelte.
00:43:29 - Christopher Burns
You say you can use anything with Slinkity. Can you use Pug and Handlebars? They're the two OGs. Or even CoffeeScript.
00:43:37 - Ben Holmes
Eleventy uses Pug and Handlebars, so we can too. The only problem is they don't support shortcodes. If you want to insert React, we don't have a great solution at the moment, but we will.
00:43:47 - Anthony Campolo
So yes, it just won't work.
00:43:48 - Ben Holmes
So yes, but yeah, I'm a Pug fan myself.
00:43:52 - Christopher Burns
A Pug fan.
00:43:53 - Ben Holmes
Yeah, I like the syntax. I think it does a lot of stuff for you that even Nunjucks maybe doesn't. But I know Nunjucks and Liquid are kind of the norm, so that's what we've been testing for the most part. But I will say Slinkity does not support Vue and Svelte at the moment. If any listeners want to contribute to a blossoming new open source project, please go look at our issue logs. We do have some Vue tasks and Svelte tasks lined up at the moment.
00:44:22 - Christopher Burns
Pug is that HTML language where, you know, it's that meme where that woman looks at it and goes, disgusting. And then I go, actually, you know, I can see it.
00:44:34 - Ben Holmes
I mean, that's why it's called Pug. It's like, it's adorable. It's a love-hate relationship.
00:44:39 - Anthony Campolo
Cool. Well, thank you so much, Ben, for being here. I've been very excited about Slinkity and have been diving into it as you've been building it. One of the things that gets me excited about these projects is seeing how people kind of respond to community members wanting to engage with it. And you've been very helpful in helping me get spun up. And I found a couple bugs in it. Even with the first version, which was a lot of fun, we figured out how to get it deployed to Netlify, and that was awesome.
Since we're closing out here, why don't you just let our listeners know, first off, where they should go to find information about Slinkity, and then how they can get in contact with you?
00:45:16 - Ben Holmes
Slinkity.dev is where we have info about the project and a nice little quickstart guide. It's really short and it should get you up and running, just starting from an empty directory. Even so, it's pretty flexible there.
If you want to DM us and ask questions and maybe want a tour of the framework, DM us on Twitter. We have Slinkity.dev as a Twitter handle as well, and you can also contact me, devhollams, like Sherlock Holmes. I'm that handle pretty much everywhere. If you want to talk shop or tweet memes at me, please do.
00:45:48 - Anthony Campolo
Awesome. Thanks so much.
00:45:50 - Ben Holmes
Awesome, y'all. Cue jazz.
00:46:23 - Anthony Campolo
Cool. That was good. That was good.