Kate: Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. And with me today on our podcast hosting team is Paul. Hi Paul, how are you doing? Paul: Howdy. Kate: Thanks for joining us. And our guest today is Ben Holmes, creator of Slinkity. Ben, how's it going? Ben Holmes: I'm doing great. How are y'all doing? Kate: Doing well. Thanks for joining us. Yeah. So just if you could get started, what is Slinkity? Ben Holmes: What is it? So it is a tool that you can add to an Eleventy site. If we'll probably end up explaining a whole bunch of tools on this episode, but Eleventy is like a static site generator that a lot of people in the community have started using. And Slinkity is a way to bring in React components, Vue components, Svelte components, SAS compilers, a lot of things that you need help bundling into your static sites so that you can use whatever tool you want in order to build something that ships as little JavaScript as possible. We let you opt in to what you want to ship to the client. Paul: That was the best elevator speech I've ever been given. Ben Holmes: Really? Okay, good. Paul: Yeah. That was great. Ben Holmes: Because I've only said 10% of its total power, but yeah. Paul: So you said it's a static generator, right? We're playing in the world at static websites here, right? Ben Holmes: We are in the world of static. So I can say right away I guess that Eleventy is a static site generator that lets you use like Nunjucks and Liquid and Markdown, a lot of sort of old school templating languages that are all just HTML, like that's all they do. But they've also introduced a serverless sort of story on top of that says, instead of building all of these templates at build time, you could also build them on server request. Like for this specific route on my site, I want to serverlessly render it based on some query params that you pass in to that URL. And that's something that Eleventy has unlocked as well. So we are a static site generator, and once we support serverless, we can also be sort of like a serverless site generator. The world of Jamstack's gotten very confusing on what the boundaries are. But yeah, we are definitely a static site generator first and foremost, but bringing in JavaScript on top of that as well. Paul: Gotcha. So adding some of that live rendering or whatever you could do to change the Dom structure that ends up. Backing up real quick actually for anybody that's listening, do you think we could go over like, what is static compared to me coding my ReactJS vanilla thing and shooting it up to a Lambda with a Nginx server or something? Yeah. If we could go over that basic, it would help me and I'm sure some other people that might be a bit in a dark about that. And why you would want static, like what are the benefits? Ben Holmes: Yeah. And I do think there are some connotations of static that kind of get confused. There's one side where you think of static as like pure HTML and CSS and no JavaScript at all. Like super static. There's no run time or anything in your browser. And it's also going to be built once and once only when you actually hit the build button on your site, or when you hit Netlify deploy or GitHub pages build or however you're deploying the thing, very static. And then there's the other side, which is like, it's static in that it's still built once. You're only building it when you hit that deploy button, but it could include some client side JavaScript. Ben Holmes: Like if you use create React app, technically a static site, but it's shipping a JavaScript bundle alongside that static div that you rendered onto the site, depends on how much you're rendering. But you're shipping some JavaScript as well that kind of gets booted up in the client and then spins up a very dynamic experience for them to see. So those are sort of two sides there. Paul: But that's where we get the back and forth between the client and the server sort of parsing those requests and dynamically changing the structure of the Dom, but that can still be considered static you're saying. Because of the fact that the transpiling and the packing of the project itself happens once, even though there might be some interpolation down the line. Ben Holmes: Yeah, exactly. Like when you were bringing up like Nginx server, Lambdas, that's where you're getting into like the server side is dynamic and then the clients can also do interactive dynamic things. So it's kind of like, I guess a quadron of like it's static server and client, static server and dynamic client and then dynamic server and client. And you kind of want to gracefully go between all three of those possibilities. And it's that last piece of like, I want to ship some JavaScript to the client that tools like Jekyll or Eleventy aren't going to help you with out of the box, because those involve bundlers in some way. So you got to set up Webpack or you got to set up Rollup, which is kind of the way things have been done for a while. Ben Holmes: But the one thing Slinkity is sort of bringing as a value add is like we bring in a bundler called Vite that has been used in a lot of open source projects. Like a Svelte is using it, Astro is a prominent one that's using it as well. And we use it as a way to sort of look at that HTML page that you're shipping, see that oh, you're trying to import a SAS file at the top and you're trying to import a React component at the bottom. Then we can pass it off to Vite and say, "Hey, transpile that SAS so that they can see it in their browser and then compile that React component so that it'll slot some interactivity into the page." So I mentioned two things there about both styling and JavaScript, because it helps with both. But that's kind of the main benefit is when you bring in a bundler, you can do a lot of very special things to take a static site and make it feel dynamic on the client side. Paul: And this is because the bundler is sort of being brought into that runtime environment when the site gets requested, right? Or is this like during the GitHub stage when we're building the project? Because the way I understand it, it's up there and it's doing the work dynamically up there in a pseudo static environment. Ben Holmes: Yeah, exactly. So I mean the bundler will come in and look at the HTML page that you wrote in your editor and it'll see that in your editor, you wrote .JSX and .SCSS and it's like, well, the browser's not and understand this. Let me go ahead and bundle that up, generate a regular CSS file, generate a JavaScript blob that is your React component or JavaScript blob for your Svelte component for example, and then it just ships those off to view on the client. So the bundler doesn't kind of come along for the ride, but it takes a lot of bundled resources and sends them off in order to be used. Ben Holmes: So there's a lot of different modes that we can talk about there, but that's the crux of it is bringing Vite to standard static site generators to go from using just like regular Markdown to Markdown with some Svelte components inside of it or writing my entire page in Svelte and choosing whether or not I want to also hydrate it on the client and hydrate's an important word. That just means shipping JavaScript alongside it. So if I use a state variable, it does the thing versus if I use a state variable, it doesn't do the thing. Both of those are possible, but you have to opt in to make sure state works. Paul: So the immediate added benefit that I'm kind of hearing from this is you can take advantage of all these really cool CDN networks and kind of like caching networks that are coming out and take your site and deploy it with really speedy time. And so the response time is really fast because you have as much static as can possibly be static and then the rest is just left up to when it needs to be done. So it almost feels like we're going through with a comb right now through like the way we develop and we're kind of like, "All right, what do we really need to be super interactive and ready at build time?" It kind of feels like a shift in paradigm almost, sort of like when Next.js 12 came out, I know they were all those different Lambda functions that you can kind of dynamically render at run time. It reminded me of that. It was like, wow, I got to reorganize the way I write my project now. It could be so much better. Ben Holmes: Yeah, for sure. And there is another shift in paradigm that this is going after which is something called Islands architecture, which is basically a way to start with just like plain HTML. And that HTML could be written with like Markdown. It could be written with a Nunjucks template. That's not really the point. The point is that you start with something that is just HTML and maybe some CSS. And then on top of that, you sort of go through your page and decide, does this need to be interactive? I import this material UI component that renders a heading and a body and I could ship the JavaScript version of that header and body to the client, but it's just static text. It's just a header and a body. So it doesn't make sense for me to ship a big old React blob just for that static text. Ben Holmes: So for those bits, I can say, "All right, I want to render a React component here, but I don't want to ship JavaScript. So don't do that. Just statically render it at build time and then ship it off as HTML." And then when I get to like an image carousel coming from [inaudible 00:09:39], it's like, oh shoot, I need to opt into JavaScript here. So then at that point on your page, you can say, "For this component, I want to hydrate it or ship JavaScript alongside it," and even choose how and when to load that JavaScript. Like load it when it scrolls into view, load it on desktop only, there's a bunch of sort of hooks you can get into to be really specific. Ben Holmes: But for the most part it's like hydrate yes or no. And continue using the React view and Svelte components that you already might like using just with less guilt because maybe build an entire page with no React ship to the client, but I got to write JSX in my editor because it's like, it's mostly about the developer experience at the end of the day. People probably don't want to write Nunjucks for everything. Or at least in my sphere, people are kind of not super happy about using those kinds of- Paul: Or most spheres, you know. Ben Holmes: I don't know. When you're involved in the Eleventy discord, it feels like everyone loves Nunjucks. And I'm like, "I don't know if I want to use Nunjucks for everything." Paul: Maybe there you guys got a special crowd. Ben Holmes: And I feel like that's a stigma around Eleventy as well is like it rode in on the old school templating languages. So everyone thought, oh, Eleventy is just a way to... It's like jackal where it's like, I can use liquid templates and Markdown and that's kind of its future. That's all it'll ever be. But the real point of Eleventy is to have this plugin ecosystem where you could use any templating language ever. And that's something that Slinkity will be released by the time this pod goes up. Ben Holmes: We're releasing on this coming Monday where you could use view as your templating language, you could Svelte, you could use React and you can invent your own plugin that you can add to your Slinkity config file to render lit element, banana-js. I don't know what exists, but if you know how to tell me, here's how I rendered this on the server, then we'll give you a nice way to just use that templating language however you want. So a ton of flexibility on what you want to use to build every route of your site and ways to sort of choose if and when to hydrate those components, if need be. Paul: It's almost like the way the web should be built if we didn't have this vision of unlimited resources at our disposal at all times, you know? Ben Holmes: Yeah. Paul: Just a different way to think about things. Because being a JavaScript developer, you pull down from the black hole universe of NPM and whatever how much disk space it takes, excuse me, however much disk space it takes is how much disk space it takes and that is that. Ben Holmes: And that's basically that. Yeah. Paul: I said that three times. Oh my. Ben Holmes: I hear you. Paul: I'm never going to say that sentence again in my entire life. Ben Holmes: I mean, but I get what you mean though where it's like, whatever I'm downloading from NPM to make my life easier, the user has to download to make their loading spinner longer. It's like why? These are separate worlds where it is very nice to use, I mean, momentJS isn't recommended anymore, but if you wanted to install momentJS and process some dates on your static template, you could totally do that. And then if you didn't send momentJS to the browser, you got to use moment for all of your UI and then you didn't send it at the end of the day. Ben Holmes: So you were able to use the tools that you prefer, but the users didn't have to download them. But you do get into the space of like the users downloading a ton of... You do get to a point where you need to ship JavaScript for most of your site and then you kind of get into diminishing returns. So I guess the nicest thing about this approach is that it's at least route by route basis as well as component by component. So if you have a page that's like JavaScript heavy, maybe your homepage can be really light so that the entry path is really fast. And it's only like your multi-step checkout form that has more of a slowdown trying to download React and get it going with Apollo or something that you're trying to set up. Paul: Yeah, that sounds great, separation of concern because that's what we all want. We want the homepage to be snappy for those Google bots, for whatever. And then the rest of the things you want the full toolbox potentially if that's what you need. Yeah. I mean, I guess pivoting more directly towards Slinkity, I could talk all day about the static stuff because the things that are coming out now are wild with the Cloudflare workers and all the new Lambdas. It's going to be some powerful new paradigm shifts in how we make websites. Paul: But I'd love to focus a little bit on your project, right, Slinkity and just way back when, when Slinkity started. When we start really good projects that are actually worth something, I don't know about you, but it always comes from a need. Like Zoom got started because a guy wanted to talk to his fiance. Somebody will learn how to make Python because to fix a problem. They're like, "Oh whoa, Python, like it does things and it's not hard." So what's your story for Slinkity? What was the problem you were trying to solve? What was the app you were making and how did Slinkity fit into there? Ben Holmes: Yeah. I don't have a super inspirational answer. It started with working on my personal site as one does, towards the beginning of the pandemic I guess, where I wanted to challenge myself to build sort of a dynamic experience with page transitions between routes, maybe using some JavaScript or components here and there, but I'm not allowed to use any frameworks at all. That was my challenge at first is like, I'm not even allowed to use Eleventy. I'm not allowed to use React. I have to build everything with my bare hands. And it taught me a lot of node file system APIs. That's kind of my only way. But it also made me pretty confident in like here's what static site generators are really doing and what they're capable of, I guess. So I ended up sort of solving all those problems myself to see how it works and then stumbled onto Eleventy as like it solving a lot of the problems that I was looking at instead of me having to write it all out. Ben Holmes: So I tried that, I realized this is really flexible. And then I noticed they had a Vue plugin that was like, oh shoot, I could add Vue to this. Interesting. And it was an undocumented experimental thing, but it sort of got my mind rolling on like, could I add React to this? Could I add Svelte to this? Like is there a plugin ecosystem under the hood? And at the time there was no documentation at all. So I just kind of poked the source code until it kind of worked. And then I said, "Okay, it's possible." So then I started getting JSX to work as well as I could and then turning it into a plugin ecosystem from there. So Slinkity was born out of just seeing possibilities in it. And then Astro started emerging in the community around this partial hydration idea. If you don't know, it's a very similar project in what they're trying to accomplish. Paul: I'm not super familiar. Ben Holmes: That's fair. So I guess the way it diverged is that Astro is a very greenfield way of approaching it or they invented a whole new templating language that lets you insert components at will in a very nice way, which is cool if you're ready to take on a new tool that's similar to some things that you're already using. But if you're in the Eleventy community and you just want to keep using your existing tools, but bolt on React, Vue and Svelte as well. It felt like there's kind of room here to just kind of add Astro-like capabilities to Eleventy where it's kind of that meme of we have Astro at home and Slinkity is trying to be that Astro at home. But it's also solving some other problems in the Eleventy community of like, if you want to set up SAS in Eleventy, there's nothing to help you with it or at least recommended in the docs. Ben Holmes: There's plugins for it. But they're basically these big gulp files that look at a directory and compile your SAS. And I thought that's a kind of old school way of doing it. And it means you have to reprocess the entire folder when I change one file, which feels kind of slow. So I thought if we strap a bundler to just everything top to bottom, is there a way I could solve the SAS problem and also solve the use of components problem? And Vite kind of came up at the perfect time. It didn't exist in my mind before last year, but suddenly existed in everyone's mind that was in the tooling space. Ben Holmes: So I was like, "Okay, I guess we'll try using Vite for this and it ended up solving a lot of those problems that the Eleventy community was kind of running into. So did I build it for a specific project? Not really other than my personal site, but I was mostly born out of like I got involved in the Eleventy community, I saw a lot of problems people were running into and wanted to find a more fundamental improvement to it. Instead of making SAS a little bit faster, let's add a bundler to make everything faster and a little bit easier. Paul: I was just going to say, that's very organic growth. You just did what needed to be done. You did the needful, you know. Ben Holmes: Pretty much like it started... I rebuilt Slinkity four times over pretty much. And then I actually went on a live stream with Ben Meyers, where we were discussing adding JSX as a language to Eleventy. Like none of the other features were there, just like let's add JSX from scratch on stream. And then the solution we came up with was put in a repo called Eleventy JSX and then I just renamed it to Slinkity later and said, "We're restarting a fifth time." This was finally the way I wanted to do it because I rubber ducked with someone. So I said, "All right, this is it. This will be the NPM package that I finally end up publishing." And it's the first MPM package I've ever published. Ben Holmes: So that's definitely an interesting first foray into open source. It's been a lot of like rapidly learning things up front to make sure I can support a community and have contributors other than myself. Don't want a hive mind mindset. So yeah, it grew very organically from there and it feels like an eternity, but it's only been like seven months or however long it's been, maybe less. Paul: Its been hard. Ben Holmes: I guess so. Yeah. It never feels like enough, but you got to know to make the project go at the pace of you or the pace of the maintainer instead out of feeling obligated to deliver something to the community. Kate: So the creator of Eleventy, is his name Zach? Ben Holmes: Yep. Kate: So I've reached out to Zach to come on the pod. Zach, if you're listening, come on PodRocket. But he has been public saying like all this is ever going to be is like a part-time project. Like it's never going to be like... It's not going to be Astro level contributors. I'm curious why Eleventy and what's your collaboration with that team? Ben Holmes: Yeah, for sure. So I have collaborated with Zach. We have like a standing state of the slink union on our calendars as like let's talk about Eleventy features and let's talk about trying to align them with Slinkity because before that Vite certainly wasn't on Eleventy's roadmap in any way. And we're seeing like how Slinkity and Eleventy can be more tightly integrated maybe. I don't want to promise anything because I don't know what it would look like, but generally it's just thinking like, because my vision for Slinkity is definitely for it to be just as invisible as possible. It's not trying to a new meta framework that ties Eleventy to other things. It's trying to slot into Eleventy with very little upfront cost. Like we already say, if you have an existing Eleventy site, just replace the word Eleventy with Slinkity in your package JSON and you're good. Eleventy's even a peer dependency. Ben Holmes: It's trying to be a plugin. It's not trying to be a sort of framework on top of it. And we've done that by slotting into Eleventy short codes API. We use the exact same thing. They have something for rendering templates and we modeled ours after how those short codes are written as well. So it's been very tightly aligned I guess, with the Eleventy project and not trying to pull it somewhere that it doesn't want to be. Because I agree that Eleventy isn't necessarily trying to go after some enormous... I mean, I don't want to say anything because I don't know what the future of Eleventy could be now. But how it's existed and how the community sort of treated it is like, this is a static site generator built for people who really believe we should start with the fundamentals of HTML and CSS and then only bring in JavaScript when absolutely necessary. It shouldn't be this thing that we add to all of our pages. Ben Holmes: So it's been very community driven in that way. And there's been a lot of contribution energy, especially now that Eleventy 1.0 is official. We were using it beyond an experimental flag the whole time. It was just like, we don't want to base this off of O dot whatever. We'll just base it off of 1.0 until it's released. And thankfully there weren't breaking changes. There could have been, but there weren't. So it all worked out in the end, but generally yeah, we want to align with wherever Eleventy is trying to go. [inaudible 00:23:23] slip. Paul: I wanted to ask about Svelte a little bit because I've never gotten... I've always been a React and nextJS person. Yeah. Yeah. Have you developed websites much in it and does it work really well with Slinkity? I mean, I'm sure it does because it sounds like you guys have putting a lot of work into this. Ben Holmes: Oh boy, yeah. It took months to extract because we were React only for a while just because that's where I was familiar and that's kind of where the workshopping had been done and we sort of pushed it to the edge and turned everything into like a very plug and play ecosystem of you tell us how to render the thing. We'll give you some defaults of like here's how your renders Svelte, install package and there you go. And we've actually been using Svelte for our new docs where we built a tabs component in Svelte where you can click through different tabs to see panels, very simple UI, but something you need a framework for to get right because focus management's hard. Ben Holmes: So it was super easy to do that. And the beautiful thing about Svelte is like their approach to global state management is very unique where you can access a store that is sort of entirely separate from the component. It's not like React context where you create this context that cascades down the tree. In Svelte, it's literally just a file like store.js. Paul: Like a little KV sitting on the side for you. Ben Holmes: Exactly what it is. Yeah. Paul: That's beautiful. Ben Holmes: Yeah. And that's what makes Svelte I think like one of the better frameworks for Islands architecture, where in our tab views, we just apply Svelte to the tab sections of our docs. The rest of them are static markdown that's rendered to HTML. So it's only shipping JavaScript for the bits that are wrapped in a tab. And then we can keep a store between each of those tabs so that when I click Svelte on one of the tabs, it remembers that you prefer Svelte in the rest of the docs. So it just updates all the other tabs views to say Svelte all of a sudden. And we didn't have to create a context around them, which actually isn't possible in islands architecture. You couldn't do this and React whatsoever, where we can just have these like separate little Svelte components living in their own component trees and they're all tied together with the same state variable. Ben Holmes: And it was so easy to get going. And I just love Svelte in general for their approach to templating and everything else. I could ramble about it for a while. But generally it's like, if you are more of an HTML first person, I think Svelte will appeal to you a lot more than React does. I think it's a great tool for like people just getting into web development who aren't coming at it from like I have a Java background and I want to learn web development. For those people, I feel like React is a better fit maybe because it's a programmer mindset. But Svelte is like start writing some HTML and then when you need a state variable, just put it in this little script tag and bind it to that HTML that you wrote. You start with the markup and then you use Svelte magic to make it interactive markup. So I think that sort of speaks to Eleventy sensibilities too, because a lot of that community is like HTML first and not JavaScript first. Paul: Right. They kind of go hand in hand with the way they're thinking about building a website. Ben Holmes: Exactly. Yeah. I actually wrote a post about it recently of like they're different mindsets where if you're coming from that background, Svelte and Vue I feel like are very similar in that way, but those are really great matches. And if you're coming from like, I'm a backend dev that's trying to write some code. I need to throw some tailwind at it. React is a better choice probably. And I know it's used a lot at the enterprise level. That's definitely like the most background that I have is in React. So I'll always feel comfortable using that tool too. Paul: I'm sure a lot of people share that. Ben Holmes: I know. Paul: React's king, so- Ben Holmes: React is king. And if I could do it all again, I'd advocate for Svelte in.my company maybe, but it all comes down to what your team's comfortable with and where the NPM packages you need are actually going to support it. Like there's the ecosystem as well. So it's a whole lot of things, but the one nice thing about Slinkity is you can start with React and then if you want to try Svelte, you can just throw Svelte on one of your pages and see how it goes. Paul: That is so cool. Ben Holmes: You don't have switch to Svelte kit. You don't have to switch nextJs to Svelte or something. You can just experiment and even put two frameworks on the same page if you really want to go a little bit crazy with like micro frontends, I think they're called. But yeah, a lot of flexibility for sure. Paul: I bet that also saves a lot on the run time because in terms of just thinking about the context, React context, the way we're used to doing things, it has to literally take that context and put everything each individual tree, rewrite it with that context underneath it. Whereas I would imagine for a flat file with a KV storage, it's just sitting there and there's not duplication of that same sort of pointer over and over and over again. Ben Holmes: That's exactly right. Yeah. I think that was at the recent React summit about memoizing all the things, because with React, you rerender everything and you opt out if things is get too inefficient. And with Svelte, you don't rerender anything and you opt into rendering certain state variables, depending on if you want to do that. And since I feel like most people stick with defaults, I like that Svelte is making you ask like, do I want to rerender this thing? Yes or no. It's kind of the same opt in mindset we have about, do you want to hydrate this thing? Yes or no. If you give those choices to the developer, then the default is going to be best user experience, but you use your favorite tooling. And then if you need to ship JavaScript, need to rerender JavaScript, you choose when to do that. So yeah, this turned into a Svelte love podcast, but you know what, it was inevitable. Paul: That's great. Kate: It's not our first episode that's done that. Yeah. Ben Holmes: Oh, I love that. Yeah. Go try it today. Paul: So if I wanted to go try out Slinkity, my big takeaway from today is I'm going to go try out Svelte because Ben Holmes told me to and because it also looks cool and because I guess it works very well with Slinkity. It works well with everything, but it sounds like the paradigms are very similar and they'll be good at shaking hands. Ben Holmes: Agreed. Yeah. The mindsets are similar for sure. Svelte gets a great avenue too, but Slinkity is less lock in if you need to change things later on. It is also more limited though on like if you need to have shared state between routes on your site. Currently not possible without using local storage or something like that. But that story is definitely getting a lot of attention because Astro has a similar issue to work. So we definitely want to improve that to make your websites more app-like if necessary. But if you're trying to build a static site, Slinkity's probably a great choice. And we have our quick start guide that tells you like NPM and nit Slinkity to spin up project. You can hit Svelte in that little dropdown menu or something else if you prefer. And then just try it out in a little sandbox and we have explanatory text on how everything works so [crosstalk 00:30:54]. Paul: Speaking of that resource, is there anything that you would like to tell our viewers about like plug wise or yeah, so where to go for your specific project? Will it be slinkity.dev or .io? Ben Holmes: It is .dev. Paul: .dev, Okay. Ben Holmes: Just slinkity.dev. And we also are commanding the Google search results because Slinkity is a made up word. So if you just Google Slinkity and you spell it right, because some people spell it with an E, it's slink-ity, it's an I. If you do that, you should see a whole lot of resources pop up and Slinkity.dev's the homepage. We have a quick start guide that's you install a sample project or instruct you on how to add it to an existing Eleventy site. So if you're already an Eleventy person, we'll help you onboard and tell you some gotchas that you need to know about. There are a few, but we detail them. Ben Holmes: And then I definitely want to point people to the GitHub link on that side as well, because this is an experimental project. It's in alpha still, just because it's my first project and I don't want to declare beta until I'm pretty dang sure it works well. And when we have more automated tests, we'd love some people who are good with end to end to help us there. But highly encourage people to contribute to the project as well as try it out. Because we detail that contributing guide a lot to make sure it's a nice onboarding experience. And we're also on the Eleventy Discord to answer questions. So try it out and try to make the tool better or use whatever plugins that you want. Kate: Excellent. We'll include those links in the show notes for sure. Ben, thank you so much for joining us at PodRocket. Ben Holmes: Yeah, for sure. Kate: And we'll see you around. Brian: Thanks for listening to pod rocket. Find us at podrocketpod on Twitter, or you could always email me even though that's not a popular option. It's brian@logrocket.