This is JS Party, your weekly celebration of JavaScript and the web. Check us out on the web at jsparty.fm. There you'll find lists of our recommended and popular episodes, clips, and a request form.

So you can let us know what you want to hear about on the pod. Big thanks to our partners at Fly.io. Over 3 million apps have launched on Fly. Learn how at Fly.io. Okay, hey, it's party time, y'all. ♪

Hey friends, you know we're big fans of fly.io and I'm here with Kurt Mackey, co-founder and CEO of Fly. Kurt, we've had some conversations and I've heard you say that public clouds suck.

What is your personal lens into public clouds sucking and how does fly not suck? All right. So public clouds suck. I actually think most ways of hosting stuff on the internet sucks. And I have a lot of theories about why this is, but it almost doesn't matter. The reality is if like I've built a new app for like generating sandwich recipes, because my family's just into specific types of sandwiches that use Braunschweiger as a component, for example,

And then I want to like put that somewhere. You go to AWS and it's harder than just going and getting like a dedicated server from Hetzner. It's like, it's actually like more complicated to figure out how to deploy my dumb sandwich app on top of AWS because it's not built for me as a developer to be productive with. It's built for other people. It's built for platform teams to kind of build the infrastructure of their dreams and hopefully create a new UX that's useful for the developers that they work with.

And again, I feel like every time I talk about this, it's like I'm just too impatient. I don't particularly want to go figure so many things out purely to put my Sandwich app in front of people. And I don't particularly want to have to go talk to a platform team once my Sandwich app becomes a huge startup and IPOs and I have to do a deploy. I kind of feel like all that stuff should just work for me without me having to go ask permission or talk to anyone else.

And so this is a lot of, it's informed a lot of how we've built Fly. Like we're still a public cloud. We still have a lot of very similar low level primitives as the bigger guys, but in general, they're designed to be used directly by developers. They're not built for a platform team to kind of cobble together. They're designed to be useful quickly for developers. One of the ways we've thought about this is if you can turn a very difficult problem into a two hour problem, people will build much more interesting types of apps.

This is why we've done things like made it easy to run an app multi-region. Most companies don't run multi-region apps on public clouds because it's functionally impossible to do without a huge amount of upfront effort. It's why we've made things like the virtual machine primitives behind just a simple API. Most people don't do like code sandboxing or their own virtualization because it's just not really easy. There's no path to that on top of the clouds.

So in general, like I feel like and it's not really fair of me to say public cloud suck because they were built for a different time. If you build one of these things starting in 2007, the world's very different than it is right now. And so a lot of what I'm saying, I think, is that public clouds are kind of old and there's a new version of public clouds that we should all be building on top of that are definitely gonna make me as a developer much happier than I was like five or six years ago when I was kind of stuck in this quagmire.

So AWS was built for a different era, a different cloud era and Fly, a public cloud, yes, but a public cloud built for developers who ship. That's a difference. And we here at ChangeLog are developers who ship. So you should trust us, try out Fly.

Fly.io. Over 3 million apps, that includes us, have launched on Fly. They leverage the global anti-cast load balancing, the zero config private networking, hardware isolation, instant wire guard VPN connections with push button deployments, scaling to thousands of instances. This is the cloud you want. Check it out. Fly.io. Again, Fly.io.

Hello world, I'm Jared, your internet friend, and I'm joined today by Tomek Solkowski. Welcome to the show. Hello. Hi everyone. Hi Jared. Happy to have you founding engineer, DevRel, and DevX at StackBlitz. Correct. We've done a show on StackBlitz. I think it was a couple of years ago.

Recorded May 27th, 2021. This is when StackBlitz first hit the scene. That episode's called Running Node Natively in the Browser with Eric Simons. So, a companion of yours, I'm sure? Oh yeah, good friend too. Yeah, 21 was crazy with web containers. Yeah, long time ago. So, StackBlitz, still out there, still doing your thing. Today we're going to talk about Tutorial Kit.

which is a StackBlitz open source joint. But first, catch us up with StackBlitz, what you all do, what you're up to, and what your work looks like. Okay.

Okay, so maybe to recap a couple of years in a couple of sentences, we started up as a kind of like an online playground for a couple of specific technologies. We picked the most popular one, initially React, Angular. I think we had Ionic. That was the first three. Then we had a couple of new ones when Vue started getting popular. But that was all very custom-made.

thing based on system.js. So like with every custom thing, you had to re-implement a lot of logic, update it and-- For each new thing, right. Yeah. And still hit a lot of limitations. So that's when in 2021, I think a good year or more of R&D, we've come up with Web Container.

And web containers are super high-level overview. They're in a browser operating system. So imagine like a typical elements of OS, you know, file system, network layer, and couple of typical programs that you might find on OS like Git and things like that.

working on the front end in your browser. So, of course we targeted Node specifically and the idea was to kind of provide everything that Node needs to run normally locally, to run this in the browser. That way we wouldn't have to, you know,

make all these bundlers and custom browser specific things especially as you know the backend in JavaScript became like a very common thing to do so since 2021

We've been building basically on top of web containers, experimenting with a couple of stuff both on the editor side and with the engine itself. So, for example, last year we've released an experimental Python support.

So you can actually run Python scripts in StackBlitz right now. There is a starter. You can go to, I think, Vanilla Group in StackBlitz starters and there's Python...

And I think even WordPress plugins, something like this, we have also some experimental PHP support. So interesting stuff around that, yeah. Yeah. And so these web containers, I think, are what are enabling this project tutorial kit. Is this on top of web containers? At least part of it is, right? Yeah.

Yes, exactly. It kind of consists of two very cool technologies we can dive into in a second. But I think also an interesting thing is how we got there. Because basically a piece of Web Container's development was dictated by tutorials about two years ago, I think.

or even longer. But let's start from the beginning. So you might have seen, even if you're not into Svelte, you might have seen a Svelte tutorial.

It was basically the primary way for people to learn Svelte since its inception in like over five years ago. That was created by mostly primarily by Rich Harris, who is great communicator and educator. So he built that, I think, inspired by Knockout from even...

Knockout.js. Yes, I know Knockout. Yeah, me too. Me too. That was like so cool to remember these things. But anyways, so he built this amazing tutorial. And if you look at any of his tutorials,

talks, actually, like YouTube recordings, like any demos, he's using that tutorial himself as a starting point even to demo specific parts of the framework. So it's not only for beginners and people who are just onboarding into the technology, but it's also for an advocate as himself.

So it's a very, very cool concept, cool tool. But now, if you know anything about Svelte, the most common way of using Svelte is by using SvelteKit right now, right? Right. And SvelteKit has a very significant backend player. So now we're kind of coming back around to web containers because...

it was kind of impossible to build a new tutorial false felt kit without having the node aspect. So, Haris reached out to us and asked if there is some way of using web containers outside of stackbeats.com.

Okay. Yeah. So basically that was our design partner for creating Web Containers API. And now, so you can use this technology, this engine on your website, building whatever you want to build. If you imagine if you had an OS on your website, right? So people started building like

very interesting projects on top of it, like their own code editors and playgrounds. And there's a project that provides you details on any package, something like Bundlephobia, but it's using web containers to actually download the package in the browser and provide you with the proper information about the package.

the structure and what it downloaded. So the direct inspiration for Web Containers API were the tutorials built by Erich Harris, but then it became a very universal tool. And since SvelteKit tutorial was such a big success, people from other teams, from other frameworks were also inspired by it and

There is now, I think, since the beginning of this year, there is an Angular, interactive Angular tutorial. If you go to angular.dev, they have a cool new documentation and an interactive tutorial that looks very similar in structure and functionality to the SvelteKit. And there's also a very cool tutorial in progress

built by Anthony Fu from the Nuxt team. You can see that in his stream that I think there was like 10 video series, you can find it on YouTube, where he actually built the tutorial app from scratch. And again, if you look at it, like it takes him a lot of time, a lot of hours and you know, it's not a trivial app.

But you end up with something similar to SvelteKit tutorial, similar to Angular tutorial. So we took a look at this and it's kind of not something that we...

usually do anymore as developers, like building the same structure from scratch, right? Usually, like, we have a framework for everything right now. Right. So that's what gave us the ultimate push to create a framework for building tutorials. Cool. So that's Tutorial Kit in a bit, maybe with a bunch of history on top of it. Yeah, the background. Well, that's interesting to know.

And if anybody has seen a Svelte tutorial, I haven't seen the anger, the one specifically, but they're powerful learning tools. They're interactive. Like you said, these aren't simple apps. There's a multiple panes. The panes are interacting. There's code execution going on. There's reflections, all kinds of things that are going on that have to make that happen. So yeah,

I love that less people need to worry about that in order to get awesome tutorials out into the world and in the browser, which is so powerful, right? Because there's no...

curl this and pipe it to that and download this or fire up Docker. It's just like if you can run it in the browser, that's a huge win. And we've seen a lot of different playgrounds and tutorials moving into the browser, traditionally backend tools, right? SQLite in the browser via Wasm, people putting Postgres in the browser, all these different things. You guys have Node, a full Node environment in the browser. How does the, just briefly...

How does the web containers thing work? Is it similar to WebAssembly? Is it completely different? Are you...

downloading everything into a browser like a docker container or yeah this is like the name might be implying something like this but it's it's way we have a way easier work because if you think about it node itself is already a wrapper around the browser engine right so a ton of when you download node

a ton of what you're downloading is basically like a copy, let's say, of your browser. And since we are already running in a browser, we can already use this engine. So it's done to us only to implement the missing parts. So that's why it's way more-- it's actually more performant. It's kind of non-intuitive, if you think about it, because we've all--

used a bunch of native apps and desktop apps and browser apps and very often the native apps are like, you think of them as faster and more performant. You don't have a heavy...

wait like video editing apps in the browser yet maybe you do already but it's not something that you think about this way but we've heard from a lot of people who are on like low-end machines that they're using stackblitz because they're let's say like traditional setup of a vs code which has like built on top of electron itself so you have

already one engine. Then you have Node, another engine, and then you have the browser. So it kind of sometimes kills the lower-end computers, while in Stackvids we

we use just one browser. So it's... There's one less browser because there's no local node. You don't need local node. Yeah. You have the in-browser. Kind of like two even because the editor itself is also using... Oh, I see. So VS Code unnecessary. Yeah. So you have just a browser. Mm-hmm. And it's... Free for the price of one. Yes, exactly. And WASM, in fact, yes, as you asked, WASM plays a big part. Actually, like all the... That's...

both the, let's say, limitation or like the rules that Web Containers has to play by and what is possible in Web Containers is basically if there is a WASM version of such a specific binary, then we can run it. That's, for example, why the Python support was possible because there is a WASM version of Python.

And besides that, yeah, we do have to implement some of this stuff on our own. Our web container engineers are high-level specialists in, like, Node spec at this point because...

If you've ever seen a URL parsing spec, you'll know. I have. Unfortunately, I have seen a URL parsing spec. Yeah, yeah. So it's funny because there are some things where actually browser kind of implements it differently than the node, for example, and then you have to do an exception for this. And it's interesting, like the event loop also is something that

We spent weeks of work on just this and different versions of it to make sure it's airtight. Because Node's event loop works differently than the browser V8's event loop works?

How do you rectify that? That's... You'd have to get Dominic Elm, for example, from our team to have one podcast just on Event Loop. Right.

That one section of the code base that nobody else touches because it works right now. So let's leave it alone. You could do it probably maybe on Halloween as a scary episode. Yeah, spooky code sessions. Yeah, I could imagine. Well, the cool thing about Tutorial Kit, as I said earlier, is that anybody now using this tool, which you all have open source and made available...

can have rich interactive tutorials for their library. I imagine you could use it for your design system or your overall UI that you have for your business. You could use it for educational resources, right? Like Rich Harris does, making demos, filming your own stuff. There's tons of different use cases for Tutorial Kit. And most of the heavy lifting, maybe all of the heavy lifting, except for the whole like

how should I communicate my tutorial has been done. The hard work has been done. And because of web containers, you can run it, I assume, on or off StackBlitz, right? Now you don't need StackBlitz necessarily to get this done? Yeah, actually there's no connection to stackblitz.com, as in you don't go to the stackblitz.com domain. The web containers themselves do request...

our part because if you want to like download NPM packages we handle that package management but not necessarily as well because you can we work with several enterprises that have their specific requirements so you can already imagine what I'm gonna say but working with their

own nexuses, their own private packages behind company firewalls, so airtight installations and things like that. So that's possible as well.

What's up friends, I'm here with a friend of mine, a good friend of mine, Michael Greenwich, CEO and founder of WorkOS. WorkOS is the all-in-one enterprise SSO and a whole lot more solution for everyone from a brand new startup to a enterprise and all the AI apps in between. So Michael, when is too early or too late to begin to think about being enterprise ready?

It's not just a single point in time where people make this transition. It occurs at many steps of the business. Enterprise single sign-on, like SAML, Auth, you usually don't need that until you have users. You're not going to need that when you're getting started. And we call it an enterprise feature, but I think what you'll find is there's companies when you sell to like a 50-person company, they might want this. Especially if they care about security, they might want that capability in it.

So it's more of like SMB features even if they're tech forward. At WorkOS, we provide a ton of other stuff that we give away for free for people earlier in their life cycle. We just don't charge you for it. So that AuthKit stuff I mentioned, that identity service, we give that away for free up to a million users.

1 million users. And this competes with Auth0 and other platforms that have much, much lower free plans. I'm talking like 10,000, 50,000, like we give you a million free. Because we really want to give developers the best tools and capabilities to build their products faster, you know, and to go to market much, much faster.

And where we charge people money for the service is on these enterprise things. If you end up being successful and grow and scale up market, that's where we monetize. And that's also when you're making money as a business. So we really like to align our incentives across that.

So we have people using AuthKit that are brand new apps just getting started, companies in Y Combinator, side projects, hackathon things, you know, things that are not necessarily commercial focus, but could be someday they're kind of future-proofing their tech stack by using WorkOS. On the other side, we have companies much, much later that are really big, who typically don't like us talking about them, their logos, you know, because they're

big, big customers. But they say, hey, we tried to build this stuff, or we have some existing technology, but we're sort of unhappy with it. The developer that built it maybe has left. I was talking last week with a company that does over a billion in revenue each year. And their skim connection, the user provisioning, was written last summer by an intern who's no longer obviously at the company and the thing doesn't really work. And so they're looking for a solution for that. So there's a really wide spectrum. We'll serve companies that are in a

you know, their office is in a coffee shop or their living room all the way through. They have a, you know, their own building in downtown San Francisco or New York or something. And it's the same platform, same technology, same tools on both sides. The volume is obviously different. And sometimes the way we support them from a kind of customer support perspective is a little bit different. Their needs are different, but same technology, same platform, just like AWS, right? You can use AWS and pay them $10 a month. You can also pay them $10 million a month, same product. Or more for sure. Or more. I don't know.

Well, no matter where you're at on your enterprise ready journey, WorkOS has a solution for you. They're trusted by Perplexity, Copy.ai, Loom, Vercel, Indeed, and so many more. You can learn more and check them out at WorkOS.com. That's W-O-R-K-O-S.com. Again, WorkOS.com.

So let's imagine that I'm a library author and I have a new web component that I want to get out there and get used and I want to set up a tutorial for it. Maybe it's a complicated one. It's a calendaring web component that builds an entire calendar into your browser. Where do I start? What do I do? So you can probably just yellow it and run. Just yellow it? Yeah.

I mean, try to, without reading the manual, you can run npm create tutorial. So basically, if you didn't know anything, like how to create tutorial, that's, I think, the most intuitive thing you could guess. That's pretty simple. You don't even need a tutorial on how to build the tutorial. You just npm create it. And I did read some of the docs. It looks like it's pretty well laid out in terms of

you create this outline format that's basically like file structure based, right? Like there's like a tree of files and you figure out your tutorial. Maybe there's three parts and, you know, part one has three subsections which have two things inside of them, some sort of tree, like an outline. And then you just like create files and folders in the style of that outline, right? Is that as easy as it is? Precisely.

Precisely. That's why I said YOLO it. That's how I like to do it. I like to first try, bump against maybe some issues, and then go back to documentation, which Tutorial Kit has a really great and up-to-date documentation, which is not always the case with some of the stuff that we've been experimenting with in the past.

the past. Yeah, it's the open source world. Documentation varies. Yeah, but what you said about folder structure, we approach it from developer experience point of view with that being the first class citizen. So we also, I was building tutorial all the time while we were developing the library. So

We had hit a lot of these issues fairly early on and ironed it out before making it public. So for example, okay, let's start from the content you've created, NPM create

tutorial. It installed everything, you have the file structure scaffolded, you can go to VS Code and start editing. There is a source folder in that you have content and first chapter, first lesson and things like that. Right. Every lesson description is a markdown file. You can also use MDX if you want to have some custom components.

So that's that left pane when you look at any tutorial. And then on the right you have the codec environment. So there is a code editor, file tree and interactive preview.

and to display anything in there, in the lesson folder you have a files subfolder and whatever you put in files will appear in the interactive part of the tutorial, in the file tree and the editor. So that sounds like, okay, the way to go, right? But once you start developing that tutorial and building more and more lessons

you will quickly have a lot of boilerplate to copy between each lesson.

So imagine you have a vid project, so you have some vid configuration files, some additional things, package.json, that's pretty much constant. Probably the only thing that the student cares about is something from the source folder. So for that we have also a special templates folder.

And in the template, you put that reusable code that is applied to every lesson. You can also have several templates and use them on different lessons, different chapters and things like that. Yeah, that's really nice because we've all felt the pain of having... I think copy and paste is fine when you're just getting started and you have a handful of steps or sections, right?

We've all felt the pain of getting down the road and then realizing we want to change something general about the entire tutorial. And then it's that global find and replace moment where it's like, do you want to update 27 files? And it's like, yes, but I also want to tweak it and see what it looks like. I mean, just this is bad developer experience. So having built in templating is

is a huge win. I'm glad you guys did that to get started for folks. Yeah. And so I mentioned that you can have several templates. So now the question is, OK, how does Tutorial Kit know which template to use? So of course, we entered the realm of configuration.

And that's another interesting DX question, right? Yeah, for sure. So for the configuration, you can actually configure on every lesson. There's, at this point, I think like 15 things you can configure as in like,

Do you want to show the preview even, maybe your tutorial is like CLI only for a CLI only tool. So you don't need that preview aspect or maybe for a specific lesson, just like an introduction, intro page, and you don't even need the editor. So you'd want to turn on or off several things.

The other popular setting is if you display like five files because they're relevant, but the most important file is the file number three on that list, like app.js, and you don't necessarily want to show the index HTML every time. You can define which files should be open by default in the editor. Okay.

And again, if you imagine that in a bigger tutorial with like 30 or 40 lessons,

having setting that one file probably that might be like one or three files in distributed in different lessons would be tedious so you can define almost every configuration variable on a lesson chapter and tutorial level so you can define it just once for the whole tutorial and you don't have to set this so it's kind of like inheriting of the of the configuration

Yeah, this is a situation where inheritance, even if it's just conceptual inheritance, maybe cascading is a way we can think about it, makes a ton of sense and is very useful, especially in tree, anything that's tree structured. It makes a ton of sense to just drill it down to all your children. Then let's say, okay, I got my thing done and maybe I just NPM created it and then I...

Followed the rabbit trail to all these different Markdown files and I'm done. I got my tutorial ready to go.

And now I want to share it with the world. Yeah, sure. You won't be sending the local host URL, of course. Just expose a port on my laptop and send it out there. Yes. So that's the other piece of the technology. One being, the first being the engine, which is Web Container. The other cool thing, and I think good news for everyone, for every listener that is into JS ecosystem, it's built on top of Astro.

So that kind of answers a lot of questions if you've ever heard about Astro. But if you haven't, you run npm run build command and that creates a static Astro folder. So it's basically a static site right now since now and you can put it on any hosting provider. You can...

configure a CI to build it, of course, and things like that. So wherever you can host Astro, wherever you can host an index HTML file, you can host your tutorial kit project. So again, you don't have to put it on stackbits.com by any means. This can be a part of your documentation site. That's actually the best scenario. That's what we recommend. So you're inspired by Svelte and SvelteKit, but you're built with Astro.

Yeah, true, true. Curious. Good point. Yeah, I think we were mostly focused on having a very simple code structure and focus on specific like Markdown files. So when we looked at what Astro does with projects like Starlight, where like this file routing for Markdown and MDX files is like a commonplace thing.

Plus they have a lot of built-in components that are pretty close to what Tutorokit does, like documenting code specifically. This all comes with Astro, so that was kind of our main reasoning behind this. So once you have your Astro build, you're ready to distribute static files...

and you put it up on any host that hosts static files. Are you done at that point? Is there no server-side requirements at all? There's one thing that you have to set. That's possible on almost every hosting platform. I know GitHub Pages doesn't have this, so that's one exclusion. But for like Verso, Cloudflare, Netlify, you have to set...

app specific headers. So these headers are required for web containers to work. And we have this documented both in web containers documentation, like main stack documentation and on Tutorokit.dev. So there is even specific configuration for each of the common hosting providers. But that's the only thing really. Cool.

Well, there's no shortage of helpful AI tools out there. But using these AI tools means you got to switch back and forth, back and forth between yet one more tool. So instead of simplifying your workflow, it just gets more complicated. But

but that's not how it works when you're using Notion. Notion combines your notes, your docs, your projects, and it puts it all in one space that's simple and beautiful and easy to use. And the new Notion AI has the capabilities of multiple AI tools built into one single tool, which means you can search, you can generate, you can analyze, you can summarize, you can chat, all inside Notion. One thing I really enjoy about Notion is being able to summarize pages automatically.

I feel like personally, summarization is the killer AI feature and Notion AI is connected to multiple knowledge sources. It uses AI knowledge from GPT-4 and Claw to chat with you about any topic.

It can search across thousands of Notion docs in seconds to quickly answer that one question you have. And with AI connectors now in beta from Notion, Notion AI can search across Slack discussions, Google Documents, Sheets, and Slides,

and more tools like GitHub and Jira, those are coming soon. These other specialized tools or legacy suites, they have you bouncing between six different applications. And Notion for me is seamless. It's integrated, infinitely flexible, and beautifully easy to use. So you're empowered to do your most meaningful work all in one single tool,

with Notion AI built right in. And Teams is where it's at for Notion. Teams that use Notion send less emails, they cancel more meetings, they save more time searching for their work, and they reduce their spending on all these different tools, which helps everyone stay on the same page. So try Notion for free when you go to notion.com slash jsparty. That's all lowercase letters,

Notion.com slash JSParty to try the powerful, easy to use Notion AI today. And when you use our link, you're supporting our show, JSParty. I know you love it. Again, Notion.com slash JSParty. Another thing I noticed, which I thought was neat, worth highlighting, is that you have available components, React components to use today.

that you use to build Tutorial Kit, but they are the different subcomponents of Tutorial Kit. And so if people want just, for instance, the file browser or the editor window or like different sections, the different panes to build into something else that's not a tutorial or whatever,

you can grab and go with those, right? Yes, because, so obviously we've built stacklist.com. In stacklist.com, we've built like the file tree, the folks browser and things like that. Then when we started doing Tutorial Kit, we've built it again from scratch and we realized there's a lot of people that are doing this

And it will be useful for other folks as well. If you want to build a lightweight editor in your project, in your library, why not use something that we've already... TutorialKit is also open source, so it made sense to make the parts of it more easy to consume if you want to rearrange and build your own stuff.

Well, it looks really cool. It almost looks feature complete. Is this thing baked, or are you still cooking it up? Are there more parts to Tutorial Kit coming? It never will be baked. There is so many-- no, no, no. But joking aside, we have a roadmap to Wine 1.0, which is close. I think within this--

this month, whatever month this comes. - October, the month of October? - Probably October. - There you go. - Yeah, I think within October we should be on 1.0, but even after that, we have quite a lot of ideas/requests from the early users to add here. But you can certainly build like a Svelte kit-like tutorial right now. Oh, and one additional thing,

If you want to start doing a building tutorial kit, it's best to do it in VS Code with a dedicated tutorial kit extension. That's something that we've also added based on our initial experiences. What does that afford you?

All right, so when we started working on our first tutorials, we realized that even traversing that file structure, the folder structure for lessons and everything, even though it's as minimal as possible, it's still quite a lot of jumping around. So the first thing that Tutorial Kit gives you is an outline in

It displays your tutorial outline in the side panel and when you click it, you jump directly to the markdown description of file of a given lesson plus the specific part of the file tree is also activated, focused, so you don't have to look for a specific

folders, change the folders and things like that. So traversing is the first thing, then creating a lesson. Again, for each lesson, even if it's like we use the templates, we use the configuration on the top level, you still for every lesson have to create a

Content.md file and the files folder every time. So why not just, you know, right click, add new lesson, name the lesson. So lesson creation, removing lessons. In the future, we want also like a drag and drop to rearrange the lesson order if you want to do so. And finally, last but not least is I mentioned there's like over a dozen of configuration options.

And these options are set in the front matter of your Markdown file. And if you've worked with front matter, you probably know that it's not like TypeScript.

To say the least, right? Yeah, you can just typo something and silently fail. Yes, yes. So not anymore. Thanks to the extension, we've implemented language service something. I didn't do it. Language service protocol? Yes, yes. I was only a consumer for this one. But yeah, thanks to this, you have auto-completion errors quickly if the types or whatever are wrong. So yeah.

Yeah, that's the big one. There you are, doing developer experience again. Yeah, exactly. But actually, just to give additional props, in parallel, Astro team worked out a very similar solution. So I don't know if this is specifically, I don't remember if this is specifically for Starlight or generally for Astro. I think it might be...

for astro collections so if you have astro collections the their extension also can do this as well so we're kind of coming out of the dark ages of front matter so are you all using this inside of stackblitz are you scratching an itch are you just providing something for the community what's the motivation i know that rich harris asked about it but that's not usually the

good enough for most people to go and dedicate a bunch of resources to some software. It's a pretty good reason. Yeah, it's a mix of a lot of these things, actually. I think there is, funnily enough, for a company that moves this fast and we have a lot of high priority things that are... Actually, there are some secrets that will be announced this...

on this VidConv. So that would be after this podcast goes live. Coming up soon, VidConv, okay. And it's something entirely different than Tutorial Kit. But there is, I think, a big need in us. Like first five people in StackBlitz

if I remember correctly, were all educators. So we all started by doing this and the initial idea behind StyleBlitz was to give people a tool so they don't have to set up all these things locally and can just start learning the freaking React, right?

And so there is a sense of mission behind it. But now that we have it, we also scratch our reach. So there is a tutorial on using Web Container API on using StackBlitz SDK. I do a lot of general browser...

CSS tips a lot on Twitter and such. So I've built some CSS tutorials as well. Yeah, but it's also, I think, a very cool showcase of what Web Containers is capable of. So yeah, once we got the idea, we just couldn't not do it.

Love it. Well, there is a demo tutorial out there, speaking of CSS, which walks you through some of the basic functionality of Tutorial Kit as you style up some forms. So...

I went through that one this morning and just got a lay of the land. Very familiar. I'm not sure if I've gone through specifically these felts tutorial, but I like that there's becoming kind of this pattern or trend of how these things flow. And honestly, now that tutorial kit exists, it's

It may have the bootstrap effect. The bootstrap effect was a downside because we want to have unique and different experiences on our websites. But you go to our websites and they all look like a bootstrap site with a different color scheme applied and a different logo. And that's not great when you're trying to stand out from the crowd. But when you're trying to make a tutorial that's familiar for folks, actually having it uniform in the way it presents, and of course you can theme and style these.

It's actually a big win because I immediately understood, here's the text on the left, here's the interactive part on the right, and the lower right is the terminal. Here's your output. It was all very CodePen-ish. I don't know who started this trend. Maybe it was Svelte. But it feels like a CodePen or a JSFiddle with additional instruction. And I like that. I like how...

It's uniform. And I think as more people build these out, it's going to be a win for the cognitive load. I mean, we already got to learn so much stuff, right? There's so much to learn. Don't make me learn how to use your tutorial. Yeah, fair point. But yeah, that's a great point. One like metaphor or like mental model that I have for this is

is Storybook also. If you think about it, before Storybook, usually you would build some workbench privately to work on a component faster, but it usually wouldn't get published. And once Storybook came to stay seen, now every component library has a Storybook project. And they look the same pretty much, plus minus some plugins.

yeah speaking of we also have a quite extensive steaming capabilities so you can change things around but like in the same structure which i think right yeah as you said it's a good thing that is a good thing well the website is tutorialkit.dev check it out open source free to use there's really no reason not to give it a try if you have to build a tutorial for whatever your use case whether you're

at work trying to help your your fellow colleagues understand the thing that you built for them or you're trying to educate the next the next group of awesome web devs out there to make anything else that we didn't cover on this topic before we call it a show i can mention maybe some implementations of some people have already built tutorials with that oh yeah for sure

So one of our engineers that is building tutorial kit, he's currently leading the effort, the open source part of it. His name is Ari Perke. He built a vid plugin tutorial.

So, if you've used Vite, you've probably used some plugin and you might have wondered how to build plugins. So now you can do a tutorial and actually learn that. So there is a tutorial-vite-plugin.pages.dev. So it's on Cloudflare, so pages.dev, tutorial-vite-plugin.

And I think the biggest one, because as I think you've mentioned before, like, yeah, coming up with the actual content is now the only remaining challenge. Yeah, it's still the hard part, but it's the only hard part. Exactly. So it's interesting now because it's unlike most of other, I think, tools in that space. We've introduced Tutorial Kit first recently.

like two months ago and there are still not so many like baked tutorials because people are still working on the content so I'm always looking for like the biggest one the most developed one so and I think the one that I've seen is learn.remult r-e-m-u-l-t.dev

So yeah, it's quite extensive one, but there's several in progress as well. There's next-patterns.dev. That's looking promising, especially considering how big Next is.

So, yeah. Also, if you're interested in what tutorial does or do not do, visit our GitHub repository. We have both issues and discussions are quite dynamic. So you can ask questions, you can share your projects and we will showcase it on StackBlitz as well. Yeah.

Yeah, that is awesome. It'd be cool to get together a list. I'm sure you're going to be collecting them. Send me the links to all those things for the show notes so people can click through easily to those existing tutorials and to our listener. If you create a tutorial using Tutorial Kit,

Let Tomek and the team know about it. They would love to know about it. Looks like you have a pretty active GitHub, six open poll requests, 39 issues. So people are participating and talking about it, even though you're not at 1.0 quite yet. So it's new, it's ready for it to be used and they're continuing to advance it. So,

That's all good stuff. That's all good stuff. Well, thanks so much for coming on the show, telling all of us about this very awesome tool you all built. And hopefully people get out there and figure out their content, get some tutorials posted. Yeah, there's one last reason not to write. That's right, one last reason. Unfortunately, now we have no more excuses as to why we haven't finished that stinking tutorial yet, except for...

It's hard to write words down. All right. Well, on behalf of Tomasz Olkowski and the StackBlitz team, the tutorial kit team, I'm Jared. This is JS Party. And we'll talk to you all on the next one.

September's gone, and your shot at free changelog stickers went with it. However, we will be attending All Things Open at the end of October. If you are too, find us there. I'm sure we'll have a bunch of JS Party stickers with us.

If you'd like to go but don't have a ticket yet, we have a few free ones to give away to our community. Sign up at changelog.com slash community and introduce yourself in our new Zulip chat and we'll hook you up. We also have a 20% discount code if you'd prefer to go that route.

The code is MediaChangeLog20. Use that at registration. I don't know if it's case sensitive, but if it is, that's capital M-E-D-I-A, capital C-H-A-N-G-E-L-O-G-2-0. No spaces. Thanks again to our partners at Fly.io, to our Beat Freak, The Goat, Freakmaster Cylinder, and of course, to our longtime partners at...

at Sentry. Use code changelog. Save $100 on the Sentry team plan. Next up on the pod, K-Ball and I discuss the news. Vue creator Evan Yu's newly announced company, the WordPress mess continues, and more. Stay tuned right here. We'll have that episode ready for you next week.