[00:00:00] Introduction
Eric: we spent a lot of time really exploring the problem space of like.
How do you run like development tool chains in a browser? Because there, there was really not any meaningful prior art on that before, before we came around. Um, and even today, like, like we've got the most domain knowledge on this stuff, I think probably compared to anyone else on the planet, simply because it's, it's what we're in the business of.
And, um, so we, you know, it took us two years of that R and D where we had this kind of aha moment where we're like, Oh, it actually. Should be possible for us to punch in a layer lower here than at this, the higher level kind of bundler runtime level. We can actually punch in more in an OS level, run Node
[00:00:44] Guest Introduction and Background
Andrew: Hello, welcome to DevTools. FM. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin.
Justin: hey Everyone, uh, we're really excited to have Eric Simmons on today. So Eric is the CEO of StackBlitz, uh, have really admired StackBlitz for a long time. Y'all do some really, really cool stuff. So Eric, it's just an absolute pleasure for us to have you on. Before we start talking about your past and some of what you're doing at StackBlitz, could you tell us a little bit more about yourself?
Eric: Yeah, totally. Yeah. Thanks for having me on. Um, big fan of, of your guys podcast and, um, yeah, a little background on me. So I'm, I'm the co founder and CEO of StackBlitz. Um, it's an instant web based IDE, uh, for front end development teams. And you might've seen it if you've ever browsed like doc sites for, uh, you know, Angular or React, Material UI, things like that, where it says like run live example.
Like that's a lot of those use StackBlitz for those sorts of things. And I started this company with actually one of my childhood best friends. He and I have been Uh, building software together for the past decade and a half. So, like, when we were 13, we learned how to how to write web applications and just we've been building stuff ever since then.
So stack puts is kind of it's it's, you know, the, uh, we started stack was like 6, 7 years ago now, I think, and just as a side project really blew up into this, uh. You know, the larger thing than it is today, but Auburn, I've always kind of viewed. It's a, it's a thing that we wish we had when we were 13 learning how to code, you know, I'm not going to set up our local environments.
It's such a pain. Um, but anyways, yeah, so that's kind of a quick background on me.
Andrew: Yeah.
[00:02:13] Ad
Justin: We'd like to thank Raycast for sponsoring this week's episode. Raycast is an app for Mac that's like spotlight, but with superpowers. Besides just quickly opening files, URLs, or apps, it provides clipboard history, window management, schedule a review and more, uh, it's got a clean react based API and an extension store to distribute your own custom extensions.
I've been using the Extension API to make a teal draw extension. So I can quickly. Create and save TLDraw canvases, for ideation or planning. I've also used Raycast deep linking feature to create a link in my obsidian set up to quickly open some of my TLDraw boards. So with custom keyboard shortcuts and extension store. Deep links. Quicklinks all of the features I provide. It's a really flexible tool. That's indispensable in my workflow.
Raycast has also has a teams feature where you can share extensions, snippets, and quick links with your teammates.
You should also check out rake house pro with pro you can take advantage of Ray cast, AI to summarize text. In any app and translate texts on the fly. , it also gives you access to their cloud sync features to keep your settings synchronized across max.
To learn more. You can visit Ray cast.com or check out episode 38, where we talked to Thomas, the CEO about Raycast and how they built it.
[00:03:27] The AOL Story: Living in AOL's Headquarters
Andrew: Before, before we get into the stack blitz stuff, the, the way I was alerted to your existence was you were trending on Twitter because, of kind of a crazy event in your past. So, uh, why were you at AOL for so long?
Eric: yeah, so for, for those, um, who, I imagine a lot of people may not have heard the story, but so back, like. 10 years ago, it was like, I think in 2012, um, there was this kind of, uh, headline that was like going around the world on, you know, front page of newspapers and whatever have you about this, this, you know, teenager that, that illegally like lived in AOL's headquarters, bootstrapping his startup.
And that, that guy was me. So I was, I think I was like 19 at the time. And, uh, so I, I guess there's a little bit of a call back here. So like I'd mentioned, you know, my, my co founder Albert and I, like we had met, um, you know, we were, you know, 13 learn how to code together and right out of high school, um, he and I decided to go and do startups.
And we grew up in the suburb of Chicago. And, uh, at least back then, there was really nothing as far as software and startups in Chicago, um, at least nothing like the Bay area. So we were, we were pretty dead set on coming out here, but we, uh, you know, we were like broke, uh, you know. 18 year olds. And, um, the reason we ended up at AOL actually was because we went through, uh, this program called Imagine K 12, which was, uh, a Y Combinator offshoot for K 12 education companies.
So Albert and I were working on this, like, K 12 software collaboration platform. And 12 has actually been pulled back into Y Combinator itself now, but anyways, they were actually renting office space out of AOL because at that time, AOL was like trying to reinvigorate the company, um, and kind of turn things around and so that they wanted to get like entrepreneurial people and like, you know, uh, really great software people just in the same offices as their employees to, to, you know, kind of have.
This kind of cross pollination and so I ended up with an access card to AOL as a result of that, because our incubator was kind of based out of there and you could use that to get it a time of the day or night their offices were pretty sweet as you as an 18 year old and quality of living bar.
Pretty much non existent, uh, you know, they have tons of couches. They had a gym, which had showers and a laundromat. Like there was like, you know, food that you could eat and stuff. So, I mean, I, I think that, um, it's been a long time now, but I mean, I'm pretty sure. I think, I think the, the, the, I lived on a dollar a month when I was there and I ended up being there for, I think like four months or something like that.
It was just like ridiculous. And, um, so anyway, so, so that was that. And I ended up bootstrapping that, you're kind of bootstrapping our way through that period. And then we were able to raise like a little bit of money and, and, you know, continue our company. But it was that the, the, the, the story kind of broke and it was like this global headline, et cetera.
But yeah, it was, that's like, um, These days I've, I've, you know, back then it was like, that was the only thing I was known for. And today it's like, it's kind of funny because people are like, Oh, I've heard of StackBlitz. I didn't know you were that guy from 10 years ago. It's like, yeah, it's, it's not something I'm trying to advertise.
Right. But, um, yeah, it's, it's kinda, it's kinda fun. Like that's, that's not what I want in my tombstone. I was like, this is like the kid that lived in AOL, blah, blah, blah, you know? So, um, but anyways, yeah, so it's kind of fun story.
Andrew: Yeah, it's uh, it's fun when you are like part of tech history memes. Like, uh, at the old company I worked at Intuit, one of the VPs was Brent Rambo, the kid who does the This like the thumbs up at a computer and just like I would love to have that as a part of my history When did it start to break down like when did people notice like who is this kid?
Like what what team does he work on? Why is he here?
Eric: you know, I don't know. And like, cause, you know, I got away with it for so long because, um, you know, they had like two or three different shifts of guards. And so like the, the, the morning folks were like, you know, just seeing me there grinding, like, yeah, this, this, this guy works hard. And then the evening people are You know, wow, this guy looks hard, you know, works hard the overnight people were like, wow, this guy really works.
But so it took, it took a while for, I think, for the dots to connect with, like, do you see this guy a lot, you know, around here? I still don't know exactly what happened with that. Like, how exactly they. They kind of lasered him, but it was pretty clear. Like the day that they kicked me out, it was like, I had been like coding until two or three in the morning.
And because at that time I was literally just, you know, um, writing like, you know, 16 hours a day worth of coders. It's just something like ridiculous, if not more. I wish I don't know where I had the energy. It's like now I'm like 32. I'm like, I, there's no way I could do that at this point. But back then just infinite energy as an 18 or 19 year old.
And, um, but I, I've been coding until like three. Three or four in the morning or something like that. And, um, I heard, I was like in this room with like a couch in it and, um, I heard these footsteps just coming down the hallway and it was like, it just came straight, like, cause there was no one in the office.
Like, it echoed through the entire floor and it just came, this guy came straight to. The room I was in and opened the door and started yelling at me and then like threw me out of the building. And so it was pretty clear that like, he knew I was in there. Like it's, I don't know, I don't know how it came to be, but like he, he, he knew exactly where to go to find me and came in and just threw me out.
Andrew: Um, but, um, but yeah, anyway, so I don't know. It's still a mystery to me to this day, Yeah, I'd love to hear the other side of that story. I can literally imagine like a, uh, um, a Seth Rogen style movie where you have like a Paul Blart mall cop type, he gets this like intuition that something's going on in the building. I can see the movie now. You should option off the rights. I think you got something there.
Eric: no, it was, it was pretty, so I think it was, you know, the, the security team was not happy about it, obviously. Cause I think it just, you know, Probably it didn't look maybe good on them or something like that, even though it was like, you know, it wasn't, you know, I don't think there was a lot of fault on it, but, but the executive team of AOL was legendary because the way that they were, because I mean, at that time when the, when the story broke, there were, there was some concern around the legality of what had happened and like, you know, everything from like, are they going to, you know, press charges on trespassing or something?
Are they going to like, You know, try and claim IP ownership of the code you were writing. They're like all, there's all these questions that came up. Right. And, um, and, but they were actually just in, like, the response was, uh, incredible. Like I, the, the quote is when some, like what they gave to the press, the quote that they ran with for the story was, you know, we.
Our intention was always to like facilitate entrepreneurship at our Palo Alto office. We just never expected it to work so well. Just like such a, like such a great response, you know, from, um, from, from the, the, you know, the marketing PR team there. Um, and, and it was, it was like a bullet dodge, uh, you know, for me at that time.
But, uh, but yeah, they, they were actually pretty cool. I actually ended up meeting the, like a, within a week of that, they called me into the office and I met the guy who actually provided the quote. Uh, I think his name is David Temkin and he, um, super nice guy. I think he was running a mail or something at AOL at that time.
But, um, you know, I, I sat down with him and he, he was like very, you know, he's like, I, you know, you've got. Uh, you, you got Moxie, like, it sounds like you're doing good stuff. Um, but you know, don't, don't do this again. Like don't, don't, don't come back but they are super nice to
degree that, you know, uh, that, that, you know, we all left on good terms or whatever.
Justin: That's, that's such a wild story.
[00:10:49] Journey from K-12 Education Software to Developer Tools
Justin: So I, I'm also curious about like what you were working on during time. Like how did that product go? Like. Did you have investors where they're like people that you're like at AOL, like during the day and like at night and then you like go meet your investors somewhere.
Like, are they asking about your living conditions? I don't know. I'm so fascinated.
Eric: yeah, yeah. I mean, so it's, it's. It's, um, at that time we, we had only like gotten like back then it was the original kind of YC deal where they gave you like 20 K and you, you know, and you, you burn through that and like through your funds, right? Which we did. And then that's, that's how I ended up at AOL.
So I was like, dang, we need some more time. And so the, the, the software, we were pretty passionate about the education space. And so at that time we were working on this thing called class connect that basically was like, it's like, get up for teachers were effectively like every teacher was like. Writing their own lesson plans and they just, and no one was sharing this stuff and it just made, it makes no sense even to this day.
Right? And so we ended up kind of creating this thing that solved that problem and, um, you know, kind of the, you know, as we were going through the programming, when you go through one of these incubators, I mean, and just in investments in general, you're, um, You're a number on a spreadsheet, typically. I mean, like they're going to not saying that, that they don't provide you with great high quality advice, et cetera, et cetera, et cetera.
But it's, it's really kind of like, you know, they're, it's, it's, it's very unusual, I guess, to have people that are really, really staying on top of like, Hey, does Eric have a home, you know, to that degree, right? Like that's, you know, I don't know. No one was really, they're just, you know, like he's, he's, he's somehow around, I guess, you know, he's, he's kind of giving updates and whatever, you know, but, um, but yeah, so that, that product was actually.
If you want to like get brutalized in entrepreneurship, you go and start a K 12 company, anything in K 12. It's like, it is the absolute worst market. And people have told me this going into it, but I was like 18 and just, you know, extremely naive and whatever. And, um. So basically, like where we decided to stop going after K 12 was, um, you know, we needed to generate revenue.
And so that, that means like selling to schools and that sort of thing. Right. We had a lot of teachers that were like pretty, um, you know, avid users of our platform or whatever. But, um, you know, if you're going to do sales, you, it's kind of K 12 sales looks very similar to enterprise sales, except. Way more insane, like, and way more expensive for the reasons that that'll be obvious after I tell like this, this quick story, but basically we got one of the top sales guys for Blackboard, which I believe they're like a public company, one of the biggest K 12 or, you know, et cetera, software things.
And you might've used it if you ever, you know, in high school or college or something like that. Terrible software. It's ugly, just. We're software ever they have, they have the well oiled sales machine like that is blackboard is a sales company, not a software company and the, so we were going to poach one of the top sales guys there and he's like, and we're like, okay, how does this, what would this like look like, you know, um, to do this and he's like, great.
So we're gonna have to out party blackboard really. Okay. I mean, what does that mean? Like, what does that mean? Like, what does it mean now? Part of it? He's like, okay, well, the way that Blackboard does sales every year is they invite, and this is like kind of a direct quote. It's like, I'm going to use the exact phrasing that this guy said to us at that time.
He said, you know, every year Blackboard invites all the top superintendents. Across the country and to an aircraft carrier that we ran from the U. S. Navy and we threw a giant party with booze and babes over a weekend. These are superintendents come with a blank check and they leave without a check. And that's how these schools decide to use blackboard.
And we were like. What? Like that's, you know, our, our software is better. Like, you know, that's, they should, you know, it's like, it's more cost effective, right? Like that's, this is like, it's better for the kids. It's better for the teachers. You know, it just, it didn't matter. It doesn't, it does not matter. So if you ever wonder why, like, you know, your school software like sucks, it's like, you know, as with many things in many types of systems in life, it's like the further the, Yeah.
The, the, the, the per, the person making the, the actual purchasing decision is from the person actually like using the thing that's being purchased the experience of that thing is going, it tends to be worse, how proportionally to the number of layers between you and them and the purchase maker. Right.
And in K 12, it is a lot of fricking layers. Right. So, um, so anyway, so that's, we were like, all right, K 12 ain't it? Like how, what did we do here? And so this is actually kind of ties into how we started StackBlitz because we ended up pivoting. Into, uh, developer education because this is back in 2012, 2013.
So this is AngularJS, uh, what's coming on the scene. This is like a year or two before react kind of started becoming a thing. And, uh, so we ended up creating this, like, it was, it started, it was just like a blog and it called thingster. io. Um, and we ended up having like the tutorial on AngularJS, um, and all things Angular.
we added react as well. And so we were running that from 20. 12 or 2013 through, uh, 2017, 18, I think, and it became rather popular, had a couple of hundred thousand people using it. And we're kind of similar model to like egga. io or like Linda or plural site where you come, like we had a whole bunch of free content, but then you could also pay a monthly subscription to access, you know, all this content on, you know, building basically the cutting edge of web applications.
Um, and the biggest problem we started running into was that. During that transition, uh, back in the, you know, mid 20, uh, 2010s of going from like, you know, when it was AngularJS, you were just putting like script tags and stuff, but then things started shifting where you needed to use a build tool like Webpack and et cetera, et cetera.
And the problem is that if you're going to teach that stuff, you can't use CodePen anymore. Because CodePen is just an HTML file, a JavaScript CSS file. That's it. Like you, you can't, there's no NPM, there's no whatever, right? Maybe, maybe they've kind of added some stuff now, but even now it's like you really can't do a lot of the things that you need to do.
And um, that, it kind of hit us. We were like, Oh, you know, if we want to have these live examples, like, it should be possible to actually run like a little mini version of webpack and a little mini version of npm in a browser tab, like, not running on some server, right? Because like all these cloud IDs in the past, it's like every person that comes, like, if you open a cloud nine or get a code spaces link. It's your browser is not really doing anything. You have to have to go and provision a VM in the cloud. Usually that means putting in a credit card or it's like super slow or like, you know, if it's free, usually they give you like 128 megs of RAM, which they can't really do much with, um, we're like, it would be very interesting if you could actually just run it in the browser tab, though, using the user CPU and memory because there's no cost on our side of it would be super fast, et cetera.
And so we looked around. No one had done this. And, um, Albert, and I always been suckers for a good challenge. We spent six months Building the first prototype and we launched it and it kind of from day one, took off like a rocket. Um, and so that, that was, that was actually the impetus of StackBlitz kind of in this, this long story here is, uh, we, we built it because people are, you know, people on thinkster were, were just couldn't even learn react.
Cause they're like, Hey, my react says I'm out of file watchers. We're like, that's like not a react thing, you know? Um, and, um, and then, and anyway, so that's, that's kind of the, the, the, the origin of, of where StackBlitz came from. And so to kind of wrap that part of the story is, you know. Stack was started growing really quickly and Albert and I were like, Oh, crap, like we ended up running two companies at the same time.
It was just him and I, you know, like, thanks for this thing. We have bootstrapped and stack. What's this thing that we're bootstrapping as well. And so we ended up selling things to her off to that. We could focus on stack was full time. And that's, that's kind of where we've been since 2018. So that's kind of the.
The long story long how this came to be.
[00:18:38] The Evolution of StackBlitz and Web Containers
Andrew: No, that's a, an interesting journey. Uh, so I know like today we have like web containers and like, we'll get to that. And those are cool, interesting technology, but like in the timeframe you described, like sounds like it was before web containers. So did that initial version of stack blitz, like do something else to get all that stuff running in browser?
Eric: Yeah, it did. And because we hadn't, um, it was to be kind of punched in at a higher level than because web container punches in at a really at the almost the operating system level. Um, to run this stuff in the browser. So like when you go to stack, what's today, you can actually like run commands in a terminal and like run, get the, get CLI and like, you know, type node and, you know, actually get into the node wrapper, install NPM package.
So you had like a full programmable CLI. Whereas, but we, the first version of was, really just like a very hacked up version of like, to be very specific, StackBlitz we took system JS, which was like an in browser. Bundler bundler runtime thing, and we hacked it basically to, to work with web pack loaders, kinda, um, and, uh, and then we basically did to get NPM working.
We wrote a whole bunch of things that it was kind of similar to like unpkg but we basically kind of bolted it into the system JS. Slash, you know, webpack loader bundler thing. It was just basically this, this like custom welded thing that just allowed you to emulate, uh, how create react app or the angular CLI, or these things would work, but it wasn't that like, it was not create react app or the angular CLI or these things under the hood.
It just mimicked the exact. Heuristics of how those things would work, which it was very fast because it's custom welded. It was an extremely fast solution from a performance perspective. But the problem that we were running into is that people were often trying to do these like advanced things where they're trying to like, Eject out of create react app, or like they're trying to use some loader that we didn't have supported.
And, um, and then also there's this trend that, that is, you know, even more in full swing now towards kind of full stack SSR SSG sort of stuff, right? Like next JS or Astro or whatever. And, and that's kind of where. You know, we had learned a ton. So, for the, from 2017, we launched through 2019. So, like, I guess, like, 2 years, you know, we spent a lot of time really exploring the problem space of like.
How do you run like development tool chains in a browser? Because there, there was really not any meaningful prior art on that before, before we came around. Um, and even today, like, like we've got the most domain knowledge on this stuff, I think probably compared to anyone else on the planet, simply because it's, it's what we're in the business of.
And, um, so we, you know, it took us two years of that R and D where we had this kind of aha moment where we're like, Oh, it actually. Should be possible for us to punch in a layer lower here than at this, the higher level kind of bundler runtime level. We can actually punch in more in an OS level, run Node.
js on top of that, and you just run native package managers on top, run your native tool chains on top of that, et cetera, et cetera, et cetera. Um, and, uh, it was. We had a lot of conviction in that because it was actually a story we had seen happen before, like, back when we were in the, you know, first came to the valley back 2012, 2013, um, we had ran into Dylan Field, one of the co founders of Figma, and that was kind of effectively their thesis back then was like, You know, the demo, they went and raised some money on the initial money was like, they had a web GL demo with like a ball falling into water.
Like, it was not a design tools. Like, here's a demo that web GL WebAssembly is a pretty big deal. Right? Right? At that time, it was like ASMJS or whatever. Like, this is, here's a demo of why this is a pretty big deal. Why it can be used to build a design tool, like why this is going to allow design to come to the browser when it has never been able to do so before. Give us money to go do R and D for a year or two on this technology so we can ship this thing. And that's, and so that's really where, where Figma started was this, this deep technology bet on, uh, WebGL and WebAssembly. Once they really perfected that technology, they actually added the productivity collaboration aspects kind of around.
The ability to do rendering like that in a browser engine. And that's kind of what we saw with, with web container. We were like, Oh, shiz, like this is, this is the first time, really almost like the first millisecond of time where you could actually even begin kind of talking about. Building something like that realistically, just because of the advent of very specific browser APIs that hadn't been there before.
Um, and so we ended up taking, you know, 2019, uh, we brought on Dominic Elm, um, and, uh, he was the first, uh, the first hire to work on web container. He, and he was, he, he built that project and, you know, really founded that thing and then ended up hiring on a couple other folks. Um, and then through 2021, which is when we launched it publicly and, um, and since then it's been in like publicly available, people are using it, et cetera, but, um, anyways, yes, that's kind of like the, the evolutionary story of kind of, of how, uh, how WebCanary came to be and kind of really, I mean, in a sense, the existential bet, um, of that StackBlitz made, uh, you know, as a company that, that it had ended up handing out.
And I mean, that story is continuing to unfold.
Andrew: Yeah, the previous strategy must have been a whole lot of work and there's like obviously a ceiling there of complexity that you're going to hit where it's like, well, it's just like, there's a lot of things you can do. We can't really support all of those, but, uh, like with web containers, where you basically able to go, okay, just kind of delete all that.
And it's just web containers now.
Eric: Yeah, and that's exactly it. And it was like, it was extremely unclear if it would work too, right? So, like, it was like, because it was very clear to us if we, if we couldn't make web container work there, what we felt was really compelling and really interesting here, um, you know. About what we were doing versus kind of what everyone else has ever done in the cloud or web IDE sort of space.
Um, it had to work for this to make sense to be a business meaningful to be a startup. Like something had high growth potential. It could like actually change how we do things right? And, um, yeah, back when we first raised our seed around 2019. Um, and we had extremely smart people that work on browser engines that were like, I don't think that I get it.
I don't know if you're gonna be able to do it. And, um, and just because it was, I mean, it was, it's one of these things where you can, you can kind of look at a mountain from afar and like. Analyze it and kind of get the right gear. They think you're going to need to, you know, to climb it. And, but ultimately it's like the question of can, can you climb it?
You only, you only get to know the real answer by, by, you know, strapping on and, and doing it when we were the other, and so that's kind of, that's kind of where we ended up, um, with web containers, like we just, we just. You know, we just, uh, you kind of got to a point where we had extremely high conviction, um, you know, raise some money from investors that were, that took a, you know, a pretty, uh, yeah, a pretty non consensus bet.
I would say on, on certainly at that time on what we were up to, um, ended up panning out. Um, I completely forgot the question you asked me though. I went on a tangent to add some color and now I've forgotten.
Andrew: It's fine. I resonate with your words. I work at a company called Descript and we're making a very similar bet on WebCodecs. Like we are like at the forefront of that technology and like literally like awaiting releases from Apple. So it's a it's a fun space to be in. One thing I wanted to note before we move on to more questions is.
Uh, I, when I would look at your guys's pricing page, I was like kind of surprised. It feels like very low to me. And, uh, I think that low price comes from like the local nature of the product. Right.
Eric: Yeah, effectively. I mean, I, I think, um, yeah, that's, that's one of the, like the, the great things about our model is, is that, um, you know, we don't have to charge you by the minute and we're able to leverage your local hardware. So, like, we can charge us more like a SAS subscription for. That you would, that you would expect from, I don't know, like something like, like Figma or something like that, right?
Like, or Google docs, you can kind of, the cost model is, is the same, you know, so we can actually kind of leverage that, um, to, to give a very transparent, like, uh, pricing model, like, what, what are the things that, um, you know, from a marketing side that we've been kind of kicking around is like, You kind of think of it like when you're buying a stacklet subscription, you're buying, you know, unlimited compute minutes effectively, right?
Whereas, you know, when you kind of look at these other things, it's like they give you. You're either getting like buying like, you know, 50 bucks worth of X number of minutes, or it's you're paying by the minute. And it's just, um, it doesn't make sense either. Because this is 1 of the things too, that we, you know, again, a couple of years ago, back in 20, I mean, even, even until 2020, 2021, there was not a lot of belief that Moore's law was going to keep up.
Um, because like x86 architectures, we're just kind of struggling. And so a lot of, I don't think it's, I don't think it's controversial to say that the consensus take at that time was that. Workloads were going to need to move to the cloud and you saw this with things like Mighty and Stadia and blah, blah, blah, blah, blah, where they kind of gave up on your end device compute becoming faster in any meaningful way.
And they're like, okay, everything's going to go to the cloud and be rendered there, even like your browser and gaming and whatever. But what happened is, I mean, Apple, uh, handedly kind of proved like, nope, like, We can ship ridiculously fast stuff, you know, to end clients. And that's, that's, you know, and it's smoking the stuff that's sitting in data centers.
Today, so, so there's kind of this interesting situation going on where, like, you buy a MacBook, right? It's got, you know, state of the art arm based chip sets that's way faster than what's going to be in, you know, you can connect, connect to an AWS or whatever, uh, for the same price point, at least. And, um, so if you're, if you're like a company, it's like, wait, we're buying a 2000 dollar MacBook.
That's crazy fast. Why are we going to pay by the minute for like. X86 things that are slower, you know, than what you can get local. So, so I think I think there's kind of this transition back to okay. Wait a 2nd, like, client side client side. That is actually. Uh, you know, that, that, the, the, the consensus view that, that, you know, clients that compute was going to go away as it seems to be reversing at least in, in the kind of immediate term by me.
I think it's, it's incredible. I mean, the, the, the yearly releases Apple's doing in particular, just the, where's it at? You know, like, how, how much more, how many more years are we going to see that? You know? So I think, I think the answer is like, uh, quite a few more. It's, I don't think this is a temporary.
Uh, state of affairs we're in. So anyways, blah, blah, blah. But like, that's, you know, I think that was another important part here of like, um, something that's actually changing right now. Like, this is, this has now become like the consensus view, but like, for us, this is like, this is kind of what we had felt, you know, was, was likely to, to be the case back 4 or 5 years ago.
[00:29:28] The Magic of WebContainer
Eric: It's likely that you also benefit from the fact that like a lot of customers using StackBlitz are probably developers or like, you know, have beefier machines. Likely. Uh, I mean, just giving a tech product, product, even if it's like educational in nature or, you know, sort of can facilitate that use case.
Justin: I'm, I'm sure that you're, you're, you kind of benefit from some better client support there.
Um, one
of the things that I wanted to. Talk about is just like feature coverage a little bit. So I had contributed to code sandbox back in the day. Um, it's been a while, but I think I like added like pug support or something.
I don't remember exactly what it was, but, uh, I remember the interesting thing about code sandbox is it was probably like somewhat similar to your pre. Uh, pre web container model and that like, they just had loaders running in web workers. And that was sort of like, they just distributed a bunch of stuff in web workers.
And, you know, you just, you had to write a lot of manual glue code and like rewrite a lot of loaders and do this stuff. So it like supported the language. Uh, so it was never as simple as just like, Oh, this new thing came out and now we support it. As you know, the front end world in particular moves so fast that there's like always something new coming out, like always a new compile to language or, you know, build tooling or whatever else.
So I'm curious in the new world where you're using web containers is the, the sort of notion of language support. Is that even something that you're. Really thinking of like as a first class thing, or do you just like, does that just come by the nature of just like having web containers or like how much extra work do you have to do in that?
Eric: Yeah, great question. And so, so, um, specifically, like, language support for us is largely a, uh, a question of, like, our how well do these languages that the compilers or run times of these languages compile to WebAssembly? Right? And so the answer for that just continues to get. Better year over year. So like back when we were, you know, back two years ago, the answer was not a lot.
Um, today the answer is like, we've got the first ecosystems coming online now, um, for other languages. So, uh, one, you know, probably the, the, the most. Fully featured example of this would be PHP and WordPress like when we first saw WordPress come online, we were like WordPress like that, you know, what, you know, but it's, um, you know, WordPress, WordPress power is, I think, you know, like 40 percent of the internet or something.
It's just kind of, it's ridiculous. Like, you know, and it's been around for, you know, what, like out to two decades, something like that, you know, like 15, 20 years, something. So this is not like a Greenfield thing. Like, this is something with a lot of history and. Yeah. Uh, backwards compatibility, et cetera.
And they've got their entire thing running in, you know, in WebAssembly and StackBlitz web containers now. And, um, and that's huge. Cause now like people that are building WordPress plugins and sites or whatever have you, I mean, like you can do that whole thing in StackBlitz, right? Um, another, you know, a couple of, uh, uh, like a month ago, um, we announced, uh, uh, support for the WebAssembly system interface, which is effectively.
Allows native languages to, you know, have the system interfaces you need to run, like file system access, networking, et cetera. Um, and so we've actually got like early previews of like Python and some other things running in stock. Let's. And so I think that, like. You know, you fast forward, you know, 2345 years, um, I think, you know, most of the world software, I think is going to be compiling the WebAssembly natively just because, uh, I mean, the performance continues to get better.
The compatibility thing is huge, where it's just not having to have all these different build targets and stuff. Um, you know, so, so that's, that's like the, you know, in a nutshell, um, you know, our bet on WebAssembly. Uh, is kind of is the enabler of these other things starting to, you know, come online and kind of fit into this crazy new world, so to speak.
Andrew: So for like you to fit these like new languages and other tools into a web container, is it like first required to go to WebAssembly so it can run in a web container? I'm not really sure on how like those two technologies mix.
Eric: Yeah, totally. Yeah. So basically, um, and so this is the nice thing about the WebAssembly system interface is like, is like a standardized thing through the bytecode alliance, which we're a part of, but, um, it's, it's, it's not, it's like an open specification. So, like, there's a lot of tools that you can run WASI.
Stuff in a cloud floor worker on, like, your local machine or in stock splits and so the only requirement is basically just have a, you know, a dot wasm file that. Exposes the WASI interface to the host to actually kind of plug in and run. Um, and so really the, as a language, if I let, let's say, um, you know, we're like, we want to have rust work, you know, the rust compiler work and stacklets.
Right. Really the only question is like, can we get the rust compiler compiled to a web assembly binary that uses the web assembly system interface to, you know, do its thing. Um, In some cases, that's, that's today can be easier said than done, and it really depends a lot on the nature of the language and how that compiler works, the runtime if it works.
Um, so there's like specific stuff like, uh, the WebAssembly garbage collection proposal that I think that stuff's actually in Chrome behind a feature flag, or maybe it's even been unflagged. I can't remember. Um, there's like multiple memories, which is pretty important for things that are, you know, more sophisticated.
So there's kind of these like. Proposals in the WebAssembly world that are going to be pretty important to get a lot of these language compilers and runtimes to be able to work properly, but, um, but this is kind of the nature of the web. Like, I think it's just the thing with like, the thing with browser APIs, like browser technology is that, um, it's, it's something where you.
You have the security is actually the number 1 thing that has to be right from day 1 and that usually usually the trade off here is like, something's going to be more secure is going to have. Uh, robustness and performance degradations as a result, right? And so, but if you're given enough time, those things actually get resolved reaction up with this, you know, kind of secure by default design that actually runs at native speeds.
And this is what we've seen with JavaScript engines, you know, if you kind of rewind back to the 2000s, um, when JavaScript was first invented, I mean, it really took 10 years. 15 years for, for, you know, V8 to absolutely slam through the, the, you know, the majority of the wins performance wise, you can do to make JavaScript ridiculously fast.
We're, we're maybe halfway, 2 3rds away through the story on WebAssembly, I'd say, so I think it's, I would not be surprised to see, you know, by the end of the decade, like, any, any performance or robustness issues with WebAssembly effectively being gone. At that, um, adoption, I think, you know, it's, it's, it's going to, you know, even, even with those things, it's like more and more things are going to be able to compile.
Andrew: And it's really more of a question. How do you get 100 percent coverage of all the languages out there? That's more of like a by 2030 thing. But I think every year throughout, it just, it continues to grow. Yeah, there, there really seems to be a groundswell of support behind the technology like, uh, the web is special because it's like, it's the one place where everybody has to go no matter their language and put a website site up. And I think that's why, like, awesome has the same kind of like excitement behind it because it's like, oh, we're really now welcoming all of those other communities and like a first class way, even though it might not be the fastest right now, we can work towards that.
Eric: totally, totally. And yeah, and it's also like a very like running an entire compiler or like runtime. Is a pretty heavy duty use case, like, like that. Um, there's a guy I talked to a long time ago. I can't remember, um, who that was, but, um, he had said, like, uh, you know, a good measure of, like, how powerful a platform is.
There's really two types of applications that, uh, that are the most intensive to run for any type of platform. One is video games, simply because the number of, you know, CPU cycles and computation that's happening there is just incredible, right? The other one is IDEs. Because it's not like it's it's if you're running a compiled application, that's kind of one thing, right?
But then when you're actually running entire environment, that's running all of these tools that are being used to develop an application is going to be compiled. It's actually, you know, an ordered magnitude. Harder and like in more competition intensive, typically, uh, to actually do that. And, um, and so I think in the case of WebAssembly today, it's like, you know, if you can write like our, our web container stuff is written with, uh, you know, is written with Rust compiled to WebAssembly and it's like crazy fast, extremely optimized, right?
But like that, the 10 X harder problem there is like making the Rust compiler, you know, work at that same sort of crazy speed or whatever as a web assembly file. Right. But it's, but it's a challenge worth doing for the same reason that, you know, that going to the moon yielded, uh, just, you know, a crop of technologies that, that, you know, changed everything just for everyday, you know, humans like duct tape.
What a fantastic invention. We needed it to get to land people on the move. Right? So, um, so I think it's like, in kind of the browser world, the browser technology world, it's like these sorts of, um, you know, these sorts of like, crazy stress tests are really are really important actually for us to. Kind of aim towards and make sure they're running well.
Cause it's, it's, it's the rising tide that lifts all boats, so to speak.
Justin: I'm curious about what the support story was for just like getting node running. Cause I mean, that was a huge accomplishment in itself. And I'm not, it wasn't clear to me, like how much of that was like the community was working towards, you know, the features and functionality like gave you the leverage to, you know, connect the dots.
Or if it was like, y'all had to invest a lot of like R and D time and to like making that happen. So could you tell us a little bit more about like, you know, how you got to that point?
Eric: Yeah. Yeah. It was, yeah, it was, um, I mean, the, the, the Node. js core contributors are like incredible. I mean, like Node. js in general is like an amazing project. Um, making it work in a browser was, was largely. Um, it was largely left on our end because it, because, you know, for us, um, you know, we were, we've been very focused on like front end development kind of as the main, the main starting use case.
And so obviously node is the primary tool that's, you know, used to run these tool chains or whatever have you. So it was like, that was the ecosystem that we, that we had really lasered in on and, um. It, it was, it was extremely hard, uh, I mean, the bulk of our work was just figuring out how to, like, how to make, like, the native parts of Node, you know, work in a browser, whether via Wasm or JavaScript.
And, um, yeah, that it was, it was, um, so, you know, our folks, like Dom and then the other. Folks that worked on the stuff, um, you know, are, I mean, just extremely familiar with pretty much every part of node JS and we've ended up upstreaming, you know, a handful of different things to note over the years as a result.
But, um, but yeah, like that, that is, that was and continues to be actually 1 of the biggest. You know, uh, parts of our work today on WebContainer
Andrew: Yeah. One really cool feature you guys have there is that you can just pop a debugger statement in a node program and it pauses the browser debugger without any other setup that the DX there is just amazing. Like I, I personally never debug my node applications cause I, I don't want to go look up how to do it.
I'm just console log.
Eric: totally. Yeah. And that was like, and it's funny too, cause we didn't really realize that that was going to be one of the like magical, you know, side effects of this thing. Cause, you know, it was actually, as we were building WebContainer, it kind of started to work. Um, you know, we kept running, you know, the earlier builds of this stuff, you can imagine a lot of stuff was breaking and, um, and so we were like running these different, you know, tool chains with those next JS or whatever, and something would break.
And, um. And we put a debugger there and we're like, Oh, right. Like this, because you're running the backend in the front end, essentially you, you can put a debugger, whether it's, you know, it's kind of cool. Cause you can actually have debuggers that are running both in your running web application, but also that in your node application, and you're actually stepping through them linearly, right.
In Chrome dev tools, um, which is really an experience that maybe there's, maybe there is something on local that kind of lets you do that, but like it's the way it, I mean, you know. Having that just where you're already going to do debugging in Chrome DevTools and like having it just, just work across the board is pretty magical.
Um, it's that, you know, that was kind of a funny one cause it was just, I don't think it was really on any of our radars how amazing a feature that was until we actually went to launch the thing. We're like, this is like one of the best features ever. Cause we, we've been using it the whole development time, basically like this is crazy.
Like this is, you know, as you're having to build full stack apps, um, having full stack debugging is, uh, You know, it's key. Um, but yeah, that's, that is a very valuable, very interesting one.
[00:42:41] StackBlitz Success and Adoption
Justin: Where have you seen StackBlitz get the most success? Where has the product really found its home?
Eric: Good question. Yeah, I think, um, so for like individual developers, I mean, in the open source realm, it's had a lot of, a lot of pickup in. Documentation or for libraries, often it's the pain of being like a design system or like library maintainer and 1 that's used by a lot of people, especially is that you get all these bug reports and often.
They don't provide a reproducible example. And if they did give, do give you one, it's like in a GitHub repo, which means you have to like clone that thing down. You've installed dependencies. It's just a whole process. Right? So often people are like, Hey, provide a stack list link with every reproduction.
And then it just cuts down the amount of time to actually review bugs. Cause a lot of times people will file a bug. It's like not actually a bug. They're just like confused. And it's like, Oh, I clicked this thing. Okay. You're just confused. Here's a, another stack was like showing you how it works. Right. Um, so that's pretty popular one.
And, um, So we ended up kind of, uh, building, we didn't really realize what, how, you know, what we were building that, you know, at the time, but like stack was a very classic, uh, product led growth sort of motion. Like that's kind of the term or community driven sales funnel, but basically like, you know, a lot of, you know, two and a half, 3 million developers a month use stack was.
com. And, uh, and they find us through open source stuff or they're prototyping their own applications. And then out of those folks that are just using it for their own personal purposes or whatever. Um, well, people just raising their hand going, hey, I could use this at my company. Right? And, um, where we've actually found the, the most success has been in the fortune 500, like companies that are pretty security conscious and, um, et cetera, because the, the compute model.
That stacklets uses is like I was saying before about browsers, right? They have to be extremely secure. Because when you open any arbitrary, uh, you know, web page, you're downloading 3rd party code and executing it on your local machine. And so. For that reason, browsers have arguably the best sandboxing technology available in the world, certainly the most well tested.
And, uh, so when you go and look at enterprise companies, security matters a lot because of supply chain attacks, because of, you know, nation states that are trying to attack Western infrastructure. And this is actually a huge, a huge upgrade. Uh, cause when you open a stack, it's like, even if it has some exploit in it, it can't.
You know, root out and, you know, break out of the browser security sandbox. Like this is actually a much better security model than running stuff in your own local machine. And, um, but it also gives you all the productivity benefits, uh, you know, that a web based thing would like, you know, the same sort of benefits that Figma or Google docs like does to, you know, supercharge collaboration.
So it's kind of a unique point in time where like, because this browser technology has matured so much over the past decade or two, you actually have like way better productivity as a result. Um, but also way better security. So for that reason, um, you know, fortune, you know, the fortune 500, 1000, whatever.
Um, they, they tend to really like our stuff, uh, because it, it kind of ticks all the boxes across the board. Whereas when you look at a lot of other solutions, it's like, if it's increasing productivity, it means there's less security. If there's more security, there's less productivity, et cetera. Right. Um, but it's all honestly really thanks to like the decades of and billions of dollars of work that Google and Apple and Mozilla put into.
You know, they can browse their engine super fast and super secure.
Andrew: Yeah. It's, it's, it's hard not to bet on web.
[00:46:14] The Future of WebAssembly and the Web
Andrew: Like all of this, I like, I hear about Wasm. It just makes me think that like, Oh. What we've done so far might become the past one day. Cause it just seems like a superior model. Like you, you have, you compile it once to this one universal thing. It can run anywhere.
It has better security. Like I, I I'm very excited to see where Wasm in the web goes in the next 10 to 20 years.
Eric: Yeah, me too. It seems, it seems like we're, you know. It seems like we're, we're on this, like, kind of cutting edge of the new era here that's happening. Um, and, uh, you know, I think every, every decade we've kind of seen a new one of these happening, you know, for the web. And this one is definitely is definitely crazy.
Interesting. Cause it's, I mean, and the other thing too is like, what, what, um. You know, what's going on with PWAs, uh, you know, where you can install these things as effectively desktop apps. And that stuff just continues to get better and better where, I mean, I think realistically, I mean, you know, again, today you can do this with stack.
That's where it, you know, it removes the URL of our, it looks like a desktop app. It's indistinguishable from like local VS code or whatever. That's where we are today. Uh, I, it just, it, it seems to, it seems to make a lot of sense that I think a lot of stuff is going to. Is going to start getting a lot of softwares and you start getting distributed that way where it's just it's just it's a web app that, uh, you know, is being packaged and installable via your browser or whatever, you know, but, um, yeah, it's, it's, it's, it's extremely cool times.
It's been fun to watch this over the past half decade or so, um, you know, from our side of the fence. And it's, you know, it's, it's fun to see it. Hitting hitting like maybe the early signs of like maturity. Um, this is gonna be a crazy decade. I think for, for the web.
Justin: It always, like, I'm always a little bit amused to think back that, like, this is what Oracle was trying to do, I guess, with, like, Java and joblets and, you know, like their vision for the JVM having the, the kind of coverage that like wasm has. And it's, it's really interesting to see. He's like, okay, that definitely didn't work.
There were similar ideas, but definitely different. Uh, and you know, to see all we've learned and especially how we've learned, you know, as you rightly pointed out, like there's a lot of sandboxing knowledge that's been. Honed over the years of like doing browser development. And now I feel like wasm is this like.
I don't know. It's, it is like really good target. And so I'm really, I'm really fascinated about, uh, you know, programs that you compile them and you run them anywhere. So they're like running locally in your browser. And then it's like, Oh, we got to do a lot of stuff. Now we're just gonna like push it up to the cloud, like very seamlessly and you don't like see it.
It's just like, it just happens or vice versa. It's like, you were going to run this thing in the cloud. I was like, Oh no, this is fine to run in the browser. And it just like pushes it down to you. I like. Without you really thinking about it, you know, that, that model of sort of universal compute is really exciting.
Eric: Yeah, definitely.
Andrew: Yeah, I, I often wonder what the world would look like if Steve Jobs didn't realize he could make money off an app store because the, the vision of the iPhone one, I feel like we'd be in a better world if we had stuck with that.
Eric: Yeah,
too, where, you know, it, you know, it makes sense. It's been in their interest to, to not let other browsers right on, on the app store and stuff. But, uh, I mean, I think it was just like yesterday or the day before they, they, you know, it.
I believe there's been a formal announcement that sideloading is, has to be done in the EU. And once I would suspect that's once that genie is out of the bottle, it's just that it's, that's, you know, it's only a matter of time before that happens in the U. S. and everywhere else. Um, but that, I think it's, I think that's gonna be, I think that's, it's gonna be great for the web.
I think it's gonna be really great for the web. We've worked a lot on making. Web container work in Safari, which we actually got a working road this year, but I mean, even there, it's just like the. There's some strange decisions that, um, that are made on the Safari side. And it's just, it's very weird. I don't have a lot of direct insight, but like every release there's, it's kind of like, uh, you know, 1 step forward, 2 steps backwards in some areas where, like, there's just new things that are broken.
It's just, it's, it's just this whack a mole thing. Um, and, uh, so I, I, I am personally excited to see. You know, Chromium and, uh, you know, Firefox, et cetera on iOS devices because it's, you know, I think it's, I think it's just going to, it's going to make, you know, it's going to make the, the power of the web, I think, finally permeated hit on phones, maybe a little bit more than it has for what you were mentioning, right?
Where they've really been trying to hold this thing back. It feels like the floodgates are about to open here. So, um, yeah. You only took what, you know, 15 years, something.
Andrew: after just a few years.
Eric: so yeah, you've, y'all have done so much work and, you know, having. Andrew and I both have been doing web development front end stuff for a while. So we've had the joy of watching a lot of these tools mature and like stack blitz, uh, stack blitz really feels like magic now.
Justin: Like, I mean, it's really hard to, to state how crazy this sort of experience is and how much that y'all have been able to accomplish so. Having done all of this stuff to get to this point, what's next?
[00:51:43] The Future of StackBlitz
Justin: What's your next magic trick? Where are y'all taking it from here?
Eric: Yeah. I think, um, you know, I think a lot of it, if you, I guess like where, where I think we'd see ourselves five years from now is, is, um, I mean, similar to what Figma has done for design today, where it's, it just seems extremely kind of backwards that you would do design in some desktop tool that you can't share with URL.
Right. Um, And I think when you think about web development. At a minimum web development. I mean, it seems kind of weird that you can't, like, use a web browser to build web applications today. Like, you would kind of think that, like, maybe that's, that's one of the first things you ought to be able to do inside of web browser.
Right? And, um, because the benefits to that would be pretty immense. Like, I mean, a lot of the stuff we've talked about with, like, kind of full stack debugging, et cetera, but also the collaborative aspects where you can just send a link to someone and they're in this kind of live. workspace to be commenting on things, you know, making tweaks or seeing the changes live, et cetera.
Um, so I think, I think for us, it's, it's, uh, you know, we've got some really interesting plans around how you can do collaboration, um, around web development in real time and that sort of thing. Um, and I, and, and some stuff where, I mean, it's very interesting too, what's going on with AI, where you can have, it's like having.
An infinite number of, you know, developer partners that you can kind of kick work out to and kind of get these things back and which fits really well with, um, you know, the sort of like browser based model that we're up to. So I think those are the things that we're particularly interested in from a technology standpoint.
Certainly, like. WebAssembly, there's like lots of interesting stuff happening there with like more languages, et cetera. Um, so I think at a high level, it's those things. And then, you know, uh, more than ever, you know, it's, uh, a lot of companies are picking our stuff up. And so, like, I think that's, you know, we've kind of gone from this R and D experiment in a sense, like, will this work?
Question mark. It's and it's like, yes, it does. Um, and now it's like going and helping, you know. Uh, companies around the world build better app, uh, web applications faster. And, um, so that's, you know, I think that's, you know, a big thing is, uh, you know, our enterprise offering that you can like run behind your own firewall, et cetera.
Um, and, uh, so, so I think that that's kind of a mosh mosh posh, but I think the things that we're, we're pretty excited about and like what, what we're thinking about.
Andrew: sounds like you guys have built a good foundation, built a good base of support and are moving just more into teams and enterprise and that expansion.
Eric: Yeah, exactly.
[00:54:10] Spicy Dev Take
Andrew: yeah. One, one question we like to ask, uh, before we move on to tool tips is, uh, what is your spiciest dev take?
Eric: I, I think if I, if I had one, like I did the spiciest one I probably had for a while was like, you know, anyone that's not adopting VEET is probably, I guess that's, that's maybe still true is like anyone that's that is holding out on adopting VEET as like the bundler for their framework or whatever.
Is has an extremely high likelihood of getting smoked over the, over the next two, three years. And I like that. I would have said that 2 years ago. I think it's worth it. Most most folks are using it today, but that, uh, that might be a spicy take. I mean, there's now actually a lot of just download numbers kind of backing that up.
It's the advantages that are pretty are pretty obvious at this point. So maybe it's less spicy. That would have been, but it's maybe still like a load of medium spice. Yep.
Andrew: Yeah, you guys are pretty bullish on Vite, right? You
Eric: Yep.
Andrew: ViteConf?
Eric: Yep. Yeah. And it was like back, uh, I think it was like 2 years ago now when I, when we first kind of ran across me, maybe a little over 2 years ago, but, um, back then they were doing 100, 000 downloads a week. I mean, it was, it was like, it was pretty small. It was pretty niche. Like there is, there's a little bit of a community, but I mean, it was, it was.
But we had a lot of conviction on like the design decision that they used. Um, you know, using like the world plugin API. And I, I actually wrote a blog post about this on our side of when we became the biggest backer, uh, in November of 21. But, um, I mean, since then it's grown like 10, 000%, right? So it's like, it's actually been, you know, one of these like calls, um, that, uh, You know, ended up being really just, you know, we ended up being kind of dead on about, uh, you know, what we thought would, you know, was really interesting and valuable about what V was doing and, uh, and the V community has been just fantastic.
And so we have brought on Matias, the, you know, one of the core maintainers, and we run Vconf every year. Um, but yeah, I mean, it's, it's, it's really cool to see it grow and evolve and people building all these cool frameworks and tools around it. But, um, but yeah, so it's, we've been kind of, we've been part of it, maybe not from the exact beginning of the journey, but like.
When it was very nascent, it was, it was, it was a non consensus bet at the time that this, that this was going to be anything.
Andrew: Yeah, that's cool. I've used the tool myself and it is quite fast. It's hard to go back to other things. It really pushed the whole industry to go, oh man, we need to make everything fast now.
Eric: pretty
much.
Yeah.
Justin: I really love just the, the framework convergence to
Eric: Yeah. I think that's 1 of the
biggest things.
Justin: the framework convergence. Everybody moving to the same tooling is
highly valuable.
Eric: Yeah, and it's just like, all the working together, right? I think that was actually 1 of the, there's like, 5 reasons or something that we were that we wrote. We were bullshitting. That was actually 1 of them, which is like. It encouraged all the framework authors to work together versus inventing all of their own things would just have been happening.
And I think that, you know, it's kind of a flywheel effect. Once that starts happening, things are moving at such a fast rate. If you're continuing to just be off on your own island, you're, you're having to rewrite the world, basically, um, a kind of an impossible challenge. Um, and that's like the flywheel effect is very much in full swing at this point.
Um, so, yes, that's why it's like, I think it's probably not, it's not, uh, I don't have to be very brave, I guess, to say that, you know, it's probably a good idea for folks to switch to beat at this point. But, um, you know, it's, I think there, there's, there's, you know, that's about as spicy as I've got, I think on me,
Andrew: Yeah, it was a nice lukewarm take.
Eric: love it.
[00:57:42] Tooltips
Andrew: Okay. And with that, let's move on to tool tips. My first tool tip of the week is a plugin for webpack. Oddly enough, a great segue. Uh, so what this plugin is, is a replacement for HTML webpack plugin that does one very key thing. So like in normal webpack, it doesn't care about HTML. You have entries that are JavaScript and to get HTML there's a plugin that does things to connect the things and it's kind of hard to understand and just kind of magic in the end.
What this plugin aims to do is be a lot more like Vite and have, uh, enable you to define your entry points as HTML. So you can do the same kind of development workflow where you have like, uh, maybe a multi page app with like five different index HTML is that all import different, uh, JavaScript files.
And what this plugin does is it helps you stitch those all together and create different outputs for each one. I literally was just trying to do this in Webpack today and I ended up configuring our Webpack to do this for us, but it's a lot more work and I have to know about chunk names and stuff. So if you want something like the V experience, but not, you can't quite use V yet, I would, uh, check out this plugin.
It's called, uh, HTML It's a terrible name for a plugin. It's very hard to find on Google, but it, it looks like it has some cool features.
Justin: so y'all were still using
webpack
Andrew: yeah, we are still using Webpack. Uh, we. We got a lot of stuff going on. There's a lot of different files. We load a lot of different things we do with those files. I think we might move to RS pack, but, uh, it's still a little bit early in that project. And, uh, I hit some hurdles when I tried to move us towards that.
Justin: Were y'all using module federation
and
production?
Andrew: Um, no, I really want to just like for our electron application, like a big problem we have at Descript is we send a lot of updates and for people to update their electron app, they have to hit a button. So, if we ship an update every day, they get annoyed by having to hit the button every day. So, a nice thing we could do with module federation is just like ship a shell app and then the actual app is a federated module that we just update in the background and they never know about.
So, I still want to do that, but I haven't gotten around to it.
Justin: Yeah. So, uh, my tool tip today is it's more of a theme that I'm calling out. So, uh, I think. You know, we've seen these, what I am going to classify as like meta cloud services, things like Netlify, uh, things like Dino deploy, um, who are building a lot of times building on preexisting infrastructure and providing sort of like cloud services to, to do things.
Um, and these are just two of many examples of vercel probably fall in this category. Something that's really interesting that I'm seeing now is they're Leveraging, uh, their platforms to provide these sort of richer services like S3, like, you know, blob storage or KV stores, or, you know, queuing services, you know, just all these things you can think of for AWS, but they're providing them in a way that's like.
That feels pretty integrated and seamless in the platform. So I've, you know, picked, I picked, uh, Dino queues as a tool tip in a previous episode. So Netlify just launched their blob store. And then just like the other day, uh, Steve Krause from VowTown who've had on the past also mentioned like VowTown supporting blob store. But the, the, the thing about all of these. Platforms as they're doing. So in a way that it's like, it just feels like an API call, you know, like, like simple, not, you're not, you don't have to set up a big library. It's just like import one thing, call a function. And it's, and they're just leveraging, you know, the fact that they have a lot of more contextual information about the application you're running on their platform, uh, which lets them skip a lot of like the configuration nuance and like dealing with a lot of infrastructural stuff.
So I think this trend. Of richer cloud integrations with like smaller amounts of configuration is going to continue to grow and the meta platforms that are building on the bigger cloud platform providers. This is one of their sort of like strategic advantages because they're a little bit more contextual in nature.
I mean, the cloud providers can can obviously leverage this same sort of thing too, but, um. I don't know. Interesting to see these two launch and I'm like pretty fascinated to watch the whole industry go in this, this direction. And I think in particular, I said it before, but I'm pretty, uh, bullish on Dino.
Uh, and I think they're, they're having a really, really great approach where they're. Building these things, not only that they're like a native Dino, like standard library kind of thing, but they're also doing it where you can host the infrastructure yourself. That's killer. So anyway, I love to see this trend.
This is awesome. Anything that can make software easier to build. I think this is great. So this is cool.
Andrew: Yeah. I love the simple APIs. Okay. Now, next up a curse technology, Angular. Oh,
Eric: Scroll, this webpage, scroll it like, just like
this thing goes so hard. Like it is, it is, um, I mean, it is pretty wild. Uh, I put a tweet about it because I was like, this is like the best designed homepage. I've seen a Google product in a very long time. You know, it's like angular. dev. Like, that's, that's, that's what it is.
You know, um, they just did a phenomenal job on building this website. And, um. Anyway, so, so yeah, they're actually using WebContainer to power that part right there. I don't know if you're using Safari or Firefox or
something.
I can't remember what the deal is with the latest Safari.
They're doing something wacky, but anyways. Um, and Chrome, it's actually really cool. I mean, it's got the, uh, you know, the running live dev server and stuff. And they took a cue from what Rich Harris did with learn. svelte. dev. But, um, this is, this is probably the, the most beautiful. Doc site, I think I've ever seen, um, the way they leave it out is very cool with like interactive tutorial.
So I just want to just point that out because it's like kind of ridiculous. Um, how, how well done the, that that website is. Um, but, um, so angular. dev, I think that's like the new homepage for angular or whatever have you.
Justin: I really need to check into what they've been doing. Angular, it feels like such a moat. It's like they have a lot of loyal developers, but they. Have like a, I don't know, a pretty dedicated community and they don't cross pollinate as much. So, so I feel like when I'm, you know, talking to people that do like Svelte or react or, you know, even like quick and like a bunch of the new stuff, they're all kind of like in the same arena sometimes, but like Angular folks are just like over here, like doing their thing, shipping
software,
Andrew: 17 major versions deep.
Eric: Yeah, well, it's, it's incredible. I mean, after the whole angular, just angular to switch thing, they haven't had like really breaking changes in any of this stuff as far as I'm aware. Like it's, it's been a, you know, and so a lot of enterprise companies use angular, you know, for this reason, cause it's just consistent.
Um, like they're very, very consistent. So, um, yeah, it's super interesting, but it was, it was a cool one. And, um, I think the, uh, uh, the other things I picked were viteconf which is like, I've actually been like playing through the conference, like 12 hours of talks. Um, and, uh, yeah, so it's like, it's, it's quite a gauntlet to sit through in one sitting, which I was not able to do, but I've been actually listening to all the, all the talks now.
And, uh, it's pretty cool. Like, it's the, uh, the replays. Is, uh, uh, pretty well done, like I think at the top is like a link for it or whatever, but it's, it's all broken out and, um, you know, all the live examples are runnable within the site or whatever, uh, from the talks, but, um, yeah, so anyways, been a, been a lot of fun kind of watching, um, you know, watching Vietconf, uh, You know, and kind of rewinding what, uh, you know, what, what folks were saying there.
My next tool tip is, uh, next-video. It's a way to add video to your next JS application. It's built on top of, uh, the technologies that mux puts out. So it does a lot of. Cool things like optimizing the video streaming. It supports like HLS and quick and posters and all the different things that you'd want with a video service.
Andrew: Uh, the cool part about it though, is that it's almost like a pages directory for your videos. So what they suggest that you do is you create a videos directory in your next project. You get ignore that and then like get LFS, uh, the videos so that they don't make your repo bigger. And then. Uh, what they suggest you do is run this script that as you add videos to that, they upload those videos to the platform.
So it's just like, kind of, uh, it feels like you're managing it within your repo, but you really kind of aren't, it's like just integrating with their platform. So, uh, if you're looking to integrate video with your, with your app, uh, you might want to give this a try. I've been hearing a lot of good things about mux and they seem to put out pretty good stuff.
Justin: that's pretty cool. Video is non trivial. It's not easy. So it's awesome.
Andrew: next up we have immich
Justin: on the note of videos and maybe photos, uh, something that I've been talking to some friends about, uh, recently is like, it's, it's like hard to find a good photo and video, like backup. Tool for, you know, like you're using on your phone. So it's like, if you're on Apple, you can use iCloud or, you know, if you're on an Android, you can use Google photos or something, but maybe that's not what you want to do.
Maybe you want to self host something. Uh, so image is just this project that I found on GitHub, uh, which is yeah, doing that they're just like making a self hosted photo and video backup tool. Uh, and it's, it seems pretty cool. It's like, looks pretty high quality, uh, open source. So, I mean, you can play with it.
Uh, yeah, I don't know. It's just like, I feel like definitely we push a lot of our data up to the cloud. And like, sometimes it's nice to have, you know, actual physical copies of these things and, and hopefully still have a good, like user experience around it. And these have apps that come with them and they, the apps look pretty good too.
So if you need a solution for that
check it
Andrew: out
Yeah, I run a similar thing on my NAS, I think. I don't use it very much, but it exists there.
Andrew 2: Last up we have remix.
Eric: I don't know what's in the water over at Shopify, but like they, these guys are on fire. I mean, like they, they are like, this is remix is really a, it seems like it's really turning into like a very serious react framework. Um, I mean, Shopify is, you know, apparently using it, right.
And, you know, they're, they're kind of switching all their stuff over to remix. But, um, and they also just like, uh, you know, they've done this like kind of rewrite of they have their own kind of custom compiler thing and they've, you know, they're, they're migrating over to V, which is pretty cool because it's, it makes adopting remix something you do like very incrementally, if you're on like.
React router or something like that. And, um, that's pretty big deal. Cause I mean, like we've got stuff, it's that puts on like react router or whatever, and then we'd lots of things over the years. Um, and so people that are like create react app or on like VEED or like some, you know, custom web pack plus react router thing.
I mean, this is going to be, I think it's gonna be a pretty big deal. I mean, like a incremental path where you can just, you know, add it to your VEED config and you know, suddenly you've got SSR stuff, you know, um, they're doing a really good job. So I wanted to give a. A shout out there. So I've had a lot of fun playing around with remix.
Andrew 2: Yeah, Shopify made a bet on, uh, Ryan and Michael, and I don't think that was a, a very risky bet. Uh, it's been cool to see what they've been able to do with like a company backing before, like, uh, they were just kind of just some guys teaching React and like doing re, uh, nice React libraries in their side time.
Now that it's their main focus, it's really exciting to see the progress that they've made.
Eric: Yeah, I think you hit the nail on the head. I mean, I think them going to Shopify with like ended up being, I mean, it appears it has been a very great decision. I mean, on both parties, um, cause having it be not tied to like having to be monetized or something like that. I mean, it's just really allowed them to focus on building something that's great, you know, and, um, that's great to use at any type of company and that's cool.
So I'm excited to see where remix goes. I think, I think they're a pretty serious contender. Um, at this point in my view for, uh, you know, if you're building react application. So, um, I'm excited to play around more with, uh, the stuff remixes putting out.
Justin: yeah Dockside we have a bunch of remix apps for all of our internal stuff and our public facing site and then The like web UI on the oxide racks is like a remix like spa, but they're actually coming out with a single page app mode for remix soon. So when they come out with that, we'll probably just switch over entirely.
So really excited about
that. That'd be cool.
Eric: Wow. I didn't even know that that's going to be, yeah, that's going to be a big deal. I think that'll be a game changer.
Andrew 2: Well, that's it for tool tips this week. Uh, it was a lot of fun having you on Eric talking about, uh, your crazy pass at AOL and all the crazy stuff you guys are doing with Wasm and web containers today was a lot of fun. Uh, so thanks for coming on.
Eric: Yeah. Thanks for having me. It was great chatting with you all.
Justin: Yeah, so good to have you, Eric. Uh, and also like StatBlitz is an absolute treasure. I mean, it's like, it's, I love anytime I go to the documentation page and I like see live examples that I can play with. So, uh, appreciate all the work that you do and yeah, just wish
all luck.
Eric: Awesome. Yeah. Thanks. Thanks for having me on. This has been a lot of fun. Really appreciate it. This is good stuff.