What's new with StackBlitz with Tomek SuĊ‚kowski === [00:00:00] Paul: Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul, and joined with us, we have Tomek Sikorski. He's the founding engineer over at StackBlitz. And he's also tackling DevRel over there. And he's back with us again. We've had Tomek on before. And we're going to poke into what's new in StackBlitz in 2023. Welcome to the show. Tomek: Oh, thank you. And hello everyone. Hello again. Super happy to be here. Paul: Oh, we're super happy to have you. It's really awesome to have somebody that's in that first phase of engineering of a product, because you really get to tap into the ethos of what you're trying to build the whole time that we're talking about stuff. So yeah, I know recently you guys had. Some new releases getting announced and they're exciting because they get into different areas. Maybe it's before [00:01:00] designers for the actual engineers, it's StackBlitz tackling a bunch of different professions and in the different releases you guys are coming out with. Could you give us a quick intro into what StackBlitz is just in case somebody listening hasn't heard of it before? Tomek: Sure. Many call us like online IDs or sometimes cloud IDs. I like to say browser ID, which seems like very similar, but the thing is that. Yeah, it's an integrated development environment that works in the browser. The distinction is that online is actually not necessarily required in our case. So this is pretty cool But the whole idea is that Stuckbeats basically started from the need to make sure people don't have to go through like many hoops of setting up the environment, you have to install node, git your code editor and stuff like that. Instead, you can just now you can just open a tab, go to stuckbeats. com and just [00:02:00] start coding with like your framework of choice. So basically that's what we focus on. Paul: Now, last year, you were talking about CodeFlow, which was new at that time. And it's been evolving a little bit. So CodeFlow, you just mentioning it, but it's essentially this development environment sort of thing, right? Where you can click on a button. Tomek: Yes. So the last two years ago, actually, we've released something we called web containers and , you can think of this as like small, like lightweight OS right in the browser. So it's not something that works on like remote VM or something, but it actually like spins up inside of your browser tab. And because now we have this, Oss, we can really run like a lot of apps like programs that you would normally know from like local environments. So , that enabled us to [00:03:00] run the code editor from the open source version of Visual Studio Code. Directly , in that on web containers. So CodeFlow is basically web containers that run that code editor with additional UX improvements and workflow improve improvements that we're building on top of it. Hence the name CodeFlow. It's it's supposed to point you to the fact that you jump into code, you jump out of it, but you want to stay in the flow, so you want to get rid of all distractions and just prepare you the coding environment. Paul: That makes sense. Flow, it's something we all strive for. Since last year, when CodeFlow kind of came out, are there any notable differences that you feel particularly excited about that you want to highlight? Tomek: the... Uh, One that sounds least [00:04:00] exciting, but in the long term is super, super exciting is actually the stability improvements that we done around that like last year, it was still like development phase and we did a lot of. Just to research around that. But the biggest like functionality wise improvement that we've added just recently is on top of , full Git support, it's support for environment variables, which again might not sound like such a huge deal unless you're a developer, because, like you use the DS for everything really. So if you want to use like a deployment CLI with Vercel, Netlify, you can use some like private keys and to authenticate the same goes with databases and things like that. So since. VidCon actually announcement in October. So this month we allowed to define environment variables [00:05:00] that are not stored, of course, on your GitHub project, but are stored securely on the Staglit site. So this is huge because it basically unlocks work production use cases. Paul: Absolutely. You can have secure connections and you said those environment variables are stored within the stack blitz stack. Tomek: Yes, so yeah, specifically you define like a bucket of variables per project. So it's also pretty secure because each project it's own container so to speak. Yeah it's way actually more secure than what you would have in the local where, The file system Paul: Oh, yeah. Tomek: realm and I won't say Paul: I wonder how many times each one of us has used an online paste a bit or something like this to share your end file. Oh, yeah. Tomek: I won't say for myself, but Yeah, I wonder that's the same too Paul: When looking at [00:06:00] a feature is something that's abstract, like this web containers thing, you can run an OS and it's it can do a lot of things that OS can do, which is a big blanket way to say okay, we have a mini operating system. What. I find useful for figuring out what something can do versus can't do is focusing on what it can't do something. I would be like, Hey, you can do this. And somebody is hold up, there's this thing. And that thing, and that kind of helps paint the outline about what space we're working in. So what's something that something maybe a contributor, somebody has commented to, to, I'm like, I'm going to say, Hey, I want to do this. And it's CodeFlow doesn't reach down to that layer yet. Or it doesn't do that yet in relation to the OS and the environment that it's creating Tomek: it's I think in the context of the of the environment itself, we're Pretty much most of the way there. So nothing really sticks out the biggest gap and like what you could want to do comes from like the architecture itself. So the fact that it [00:07:00] runs really locally in the, your browser tab means that it's even. More guarded than your typical, local host thing. So that was always when we go into a web dev, I remember I run my first like local host server and I wanted to send that thing to someone and see what I'm working on, but it's like local host. It's local, right? You can, of course, get around it, some, in some ways, using additional tools, but in our case, it's even more secure, so that's a good thing, but it's also a limitation. If you want to have a socket connection between different things it's not directly possible, so this is The big thing we're not solving. So basically we need to provide proxies for this type of actions. But this is actually one of the big ones. Besides that, like if you're in more [00:08:00] isolated use case, there's not much that's missing. I, I, nothing comes to mind really, honestly. Paul: I'm going to play devil's advocate and just ask one question for myself here. What if I was making an app where I was calling FFmpeg to smush together a bunch of images and spit out a video for me? Is there a limit to the IO there on how stacklets might be running it? Tomek: I think the limit might be probably like memory related because it, it needs to be like kept in that. But that's the only one I think. And of course that, that relies on the fact that if fmmpeg provides like a awesome version to run in, in web containers. Spot. But that's really, I think the only limitation Paul: Yeah, you're subject to memory anyways, it's not like a unique limitation. It's just, that's just computing. Tomek: True. Yeah that's right. Paul: Let's move on to some more exciting news about. What's happening over at stack. What's this year in 2023, you [00:09:00] guys added some notable people to the team, people that, we've seen over here at log rocket like you have Anthony food coming over, right? You guys are really excited to have him. What was his involvement that decided that had you guys decided to have him join the team? Tomek: So we've been fans of Vite like from very early days both because of speed and like your speed is a Staglit's name really. So that's one thing. But. I think more importantly about because of how Open the community is and how many ideas like new ideas come from it so In case of anthony, it wasn't Really like one specific thing and not even something that was directly In line with what we are specifically doing, it's more about like how prolific creator he is and how [00:10:00] many cool like browser based things he's doing. And so we like, honestly, we just want to support that kind of activity. So that was it. really that's like I've been fan of his work. Like I remember like slide dev when I first saw slide dev, I was like, oh, we need to add this to stack leads. And now we have stuck leads slide dev starter. But directly, that's pretty much the only connection besides that. It's just like feed custom is awesome and we were just looking for like people who make the big difference there and how we can support them. Paul: Gotcha. Just seeding the community with power to make a synergetic relationship between you guys. That's Tomek: Yeah, absolutely. Now like almost every open source like JavaScript related project runs on Vite. So when it runs on Stagglitz, it's [00:11:00] also like fast. So it's also in our best interests to make sure the projects are fast. So we support Vite so they are right. Paul: love to move into some of the uh, integration or connection sort of announcements that you guys put out. Thinking about Figma, Figma is always fun. It's fun to integrate with Figma and see how we can like bridge the teams and their skills. Right before we do that, I'm just going to remind our listeners that this podcast is brought to you by LogRocket. And LogRocket, like StackBlitz, it's made for building web applications, it's for the browser. You can debug your application faster, you can find errors that you might not have known about, use data driven metrics to surface all sorts of stuff so you can spend less time in that console, less time debugging. And more time just getting telemetry and data about your application, about the events bubbling up, heat maps. So you can build a better app, spend less time debugging and more time building. Head over to [00:12:00] logrocket. com today and you can try it for free. Hopping back into the topic of building anyways, so Figma is one of those things that as a engineer person, myself, you dabble, you look at it and then the, usually you're working with a designer or design team. They come up with a change. They need to talk to you. Then you can go implement the change. And there's a lot of different ceremonies that are baked into company culture. You guys have put out some new announcements that kind of flip it on its head a little bit in my understanding. And I'm no expert. I'd love to hear you delve into how you guys hope to reduce team friction. And make apps faster with your new Figma integrations and storybook. Of course, I can't forget storybooks in that picture too. Tomek: Yeah. Thanks for that question. I'm super excited about that. I was actually one of the people building that. Yeah, Figma allows for like very interesting stuff by other like plugging ecosystem and they're like, great plugins available. , we're still like just dipping the toe in the water and seeing what's possible. I'm [00:13:00] actually talking with them and how we can make our integrations like even more powerful and less friction. So the idea in our case is that. When you have, sometimes like you have a long running project and there are these designs and so it's basically a documentation of the different screens, different elements UI elements in Figma sometimes for like months or even years and imagine that like you have a new developer, maybe a coming on to that project and there is a, like a, Linear issue or something that the designs for this was changed or there was a typo in the design or like we changed the title in the designs and now we need to implement it. So developer goes to Figma document and then, okay. I know what the change is now. I know the live site looks like this. The Figma looks like this. I need to bridge that gap, right?[00:14:00] Whether this is like a new developer in the project or like someone who was working on it like months ago, you need to probably, clone the repository because it's no longer on your local drive. You need to find the right file and so on. Uh, so. What our integration does instead is that you can define like a special link. On a Figma layer and by clicking on this link, you open that repository in a very like specific place like a specific file and soon you'll be also even able to target even a specific line. So basically, if you want to change something, you just click a link and you just code. That's all you need to do. And because like we have first class Git integration, once you stop, like you're done with your code, you can just click a button and you have a commit, [00:15:00] you create a PR and that's it. All your workflow was really limited to two browser tabs, right? No setup, no, downloading, finding, finding different things and so on. . So if you want to set this up in the Figma plugin, you basically just Point at the GitHub repository and at a specific file and that stays on that Figma document like forever, right? So once you set it up, it's just like removes all the friction for future you or other developers to just make these changes Paul: Do you find that this is going to save more time on the designer side or more time on the developer side, because. Needle is being moved in the industry right now about how much a UI UX person actually needs to do. What does UI UX really entail? So I'm curious if you've seen any usage of this in your beta testing or how [00:16:00] people have been consuming this feature. Tomek: That's a great question. So we mostly focus on the developers but Also on a like use case of just design systems. So in design systems, it's it's more about, you're thinking about the whole team and the longterm maintenance costs, right? Because it's, it requires a lot of skill to put together an initial version of the design system. But what's often overlooked is how much work it is to keep maintaining it. In the long run, I think it will primarily be used by developers who use that who open the Figma document to. Go and implement these changes. It's for a reason that part of Figma is called like a dev mode because that's a plugin for dev mode Figma. But I think also because of how little [00:17:00] meaning like zero setup it provides. It can ultimately be also used by a designer, right because I myself we have like at least one project in stagnant still that is so complex that it has to run locally Namely like it relies on the rails and we don't support rails now And i'm like i'm so scared if I want to like if I need to touch something in there, because I would have to install some, jams and something might break during installation, so on. So I'm slightly less technical now. But if I if I imagine myself in the role of designer who probably like in Web focused team, they know CSS and maybe even like more, some like JavaScript with like easy relatively easy frameworks like view and stuff like that. If you need to just make one change, they can just click them, the link themselves. And without [00:18:00] no setup, they can just change the source, right? And commit the thing. So yeah, long long answer, but I think it's both really. Paul: That long answer very well justified because it's a complicated thing to think about. UI UX designers doing more and more as time goes on in their organization. Tomek: And some designer, I know designers that are just like they sketch Layout. And especially if there's a lot of dynamic things happening, like some animations, they actually prefer to jump into the actual, the real code and adjust these so they're like really perfect because you can never define that specifically in Figma, right? So they do code. Paul: Now, moving on Tomek, I wanted to ask about the web container API and specifically like Python, Pythonic stuff, powering web code, really eager to pick your brain about what could come of that. Cause it's been a rift in the [00:19:00] development community for forever. You got there are honestly two different schools of study about the types of folks who use Python as their main language versus JavaScript. You have two different like sets of packages and ecosystems. So yeah, what is the web container API? What are your hopes and dreams for the next few months? And then we can move into some more questions about specifics with Python. Tomek: Sure. So first of all, the web container itself is, as I said, is just is an OS. So that provides the possibility to have the file system and network layer and so on. The API itself is. You can think of it as a, like a library for using web containers. So if you are building an app that requires like a heavily, like a heavy lifting in terms of imagine if your website needed an OS for something, right?[00:20:00] A good example of that is building like tutorials. So like SvelteKit, for example, tutorial uses that when they Just pretending right like it's running Svelte is not enough because in a way like you can have your own like a lightweight environment in browser to evaluate Svelte for example, and that's faster that works great, but with let's felt kid. For example, you need you need a network layer. You need to file system access. And in that case, they needed to use web container API to have that basically add the OS for their to, to their website. So that's what web container API really provides. Paul: that's great. It's an interface to the web container. It's an interface to your OS as an app. There's a lot you could do with that. One of the things that is stimulating my thoughts thinking about [00:21:00] what could come of this is the Python thing. Yes, we could use Python to power web applications and immediately my mind hops into wow, we got, we're going to get all the NumPy guys over here and the and the PyTorch people, like this is going to be wild and weird. What are you thinking about Tomek and what is integrating Python into the web stack mean to you? Tomek: Oh, so first of all, that's again, that's like a deep not so humble, but like, our feet in the door of other ecosystems and other languages. It's the first time that. We can run really something except, for javascript natively in stack blitz python itself is super exciting because I think that was one of my first languages to learn to like a lot of people just use it to as an intro to, to programming. And nowadays it's like it has its own thing going with the AI. So even more people are interested in [00:22:00] knowing and learning like what's the deal with Python and how you actually program with it. Right now it's our like very early days of Python support. So for example, we don't have like pip doesn't, isn't yet implemented. But you can already write Python scripts and for many cases that's great enough. So you. You just, head over to stack bridge, start coding, start running this without any cost of the like remote computes stuff. So I think it will just grow like Python really is also for us to showcase what's possible with web containers, because we can run Python. That means that we can run other languages too. Soon on the horizon will be probably like Ruby thinning and other things like that. So I think that helps with the barrier of entry for just languages. And I think one of the [00:23:00] biggest things like you want to learn the thing the Python, for example or Ruby or something else. But first you need to solve this puzzle, how they get it running on my local machine. But yeah even for example the code flow supports extensions, right? Like the VS code extensions, we can run these kinds of extensions and there is a huge amount of extensions that actually needs Python to run too. Most of them rely on node and these we support out of the box. For now we were just limited to, to node, but Python will open like another set of doors for us. Yeah, and I think that that's most, that and the AI relying so much on, on Python are the more, most exciting. Things to me personally, Paul: Do you see Jupyter Notebook as like a competitor to what you're trying to [00:24:00] accomplish here? Because they do something similar running Python in a browser based environment. And I'm actually curious if you happen to know Atomic, do they use a similar technology under the hood? Tomek: I'm not, I actually, I'm not sure to us, Python was fairly recent thing. So I'm personally, I'm only started playing with it. Getting back into that space. So I'm not sure for us, like it's, I don't think it's necessarily a competitor but we're new in that Python space. So it will be interesting to see what's possible even. Paul: And my last question about web containers in general. And your ability to now run Python scripts, you're going to look into other languages to support. Do you see these as features to developers who want to make websites? Or do you see this as a paradigm shift in how we think about development as a whole? Where in that spectrum does this lie for you? Tomek: Wow that, [00:25:00] that's an interesting question. So I think in a way, what is interesting is that for web developers, at least for like where I'm standing and how I see like other developers working with different tools actually building web stuff is the only thing that requires your local setup. So like we're using Google Docs, we're using Figma, everything is online and always there. And you're not, don't even have to like think about losing your work because it's. It's there, right? Paul: Yeah, Tomek: When have you last saved your Google doc document, right? I think they even scream at you like, you don't have to save it. But, something like this. It was almost like an irony that we [00:26:00] as web developers have to use browsers outside of tools, outside of the browsers to, to develop. So in a, in that way, I think it'll be a paradigm shift. I think one additional thing that's connected to or maybe could change the mental model of how you think about developing apps is also when you bring up the environment to a browser, you feel. More close to the Git as a source of truth. And it's not as much as like, Oh, I'm sending my local changes somewhere in the cloud. It's more Oh, I'm just committing it. So it's almost like safe. So I think it's , like a set of very small changes, but that switch from local to the browser where everything else really happens in the browser already. Yeah it's like, when you have a rockstar and they're like on the stage somewhere, but sometimes they go to the crowd and it's like [00:27:00] totally different energy. I don't know if that analogy works, but like , you'd feel like just. This much closer to your production environment to your Git repository and things like that. Paul: So I'm hearing more of a paradigm shift. I'm hearing this Tomek: Yes. Paul: and Tomek: to your question. Yes. Paul: yeah. And maybe TBD to be determined on what flavors and what colors that kind of like changes for us in our workflows. But. It is fundamentally different and it's going to change the way that we're working. Tomek: In that way, like the whole code flow thing, we're actually the jury's out about the name of. Of this being the product but like we really like the philosophy it stands for like you have this The logo that is like the infinity symbol like you get here you and you return Paul: It's very nice. Tomek: yeah, thank you and There shouldn't be like really any barriers to make a change in your code and what I [00:28:00] loved from the like first site about just web development was that you can just like open, open the dev tools and just, you have the environment right there. You, you didn't have to do anything and. The next step is really us enabling you to do that with your sites. We do it, for example, with documentation sites. We have this editor called Web Publisher that when you click a link on your dogs instead of going to like github markdown editor, you can go to a publisher and it, you had still have the markdown, but you also have the running live site in the dev server. So you make the changes, you see the changes, right? So again very close to the production, to the living app. Yeah, that's the idea. Paul: We're coming up on time here Tomek. I feel like we've had a good round around round and preview. But some of the new stuff that [00:29:00] was announced in the 2023 stack blitz announcement. If people wanted to find out more about either web containers or code flow. What is the address or domain website docs that people should visit? Tomek: So you can go to developers do stack.com. But I think right now, if you want to have a best overview of what's new, what's possible RF, VidCon keynote might be the best thing to, to look for. So I don't have a short U r L for it, but we can link this, I guess in the Show notes. Yes. . And that also includes one huge thing that I forgot to mention, but it's a big one. So historically we've been focusing more on a sandboxing environment for like single player use and so on, but like a lot of people who use this kind of thinking in work [00:30:00] also wanted to have. The ability to, work in a safe team environment. So we have also introduced stack visits for teams and stack visits enterprise, which allows you to install stack. It's like even very securely on premise and things like that. So that's super cool. Because we already have first customers who are working on this and yeah, the keynote. Paul: Awesome. And just to close us out, Tomek, if people wanted to find anything by you because you are in the devrel side of StackBlitz as well, do you post privately or on the StackBlitz blog? Or anywhere else. Tomek: Both. So on, on StackBlitz, I focused mostly around browsers in general. It's not just StackBlitz content. So I sometimes post like interesting trivias about browsers, about DevTools and so on. So StackBlitz Twitter account is pretty active. I try to maintain activity on my private ones especially around just like [00:31:00] general tooling. So sometimes it's not even browser related but some other like productivity dev productivity stuff. So StackBlitz is the StackBlitz account. And as for me, it's solc, S U L C. Oh yeah, and I'm happy to meet everyone there. Paul: Awesome. Tomek. It's been a pleasure. I'm excited to check out some of the new features in 2023 and I hope some of the listeners are going to be urged to as well to preview, if not already expand on their usage of this new way of development that's exciting and Tomek: Yeah. Oh, if I can add one more special tip. We haven't... Advertised it much, but it's a really cool showcase of what stacklist can do. If you go to stacklist. com slash tilde, just like tilde, like you have the user You basically get like a very fresh, empty. Environment, but it's [00:32:00] already like a VS code Git and no, and just see how fast, everything is set up for you. So you can run, you know, NPX create something or the gate something and kick off like. Any set up you want, but it's just insane how fast it loads. And on the second view, of course, it loads even faster. So it's crazy. I have my own link for this very thing. Whenever I see something cool presented by something for framework, I visit that. And I'm just like playing with it. And then I just close the tab and I'm done, or I can, come into Git and, continue the project. But yeah, stackbiz. com slash Tilda is free. Awesome. Paul: That's a great thing to end on. stackblitz. com slash tilde. Try it out today. All right, Tomek. Thank you so much. Tomek: Likewise. That was awesome.