SST v2
So Dax, SST two is officially out. It's officially out. Right?
Dax:Yeah. It's officially out, finally. I've been in a hole for, I think, six months of not releasing anything and is rewriting every single line. And it's finally out as of last week. We haven't made too much noise about it because we haven't updated our docs, but, yeah, people have been using it and it's going well so far, I think.
Adam:Yeah. That's that's why I asked if it was officially because I I couldn't remember seeing, like, a big tweet, but I've been using, like, the snapshot and then the whatever the other version was, the release candidate. Before we get into, like, what all is in SSD two and just talking about SSD more generally, first question I have when you said that made me think, you've been in a hole for six months. Did did you ever feel like that your your SSD counterparts, your co founders, is that the word, I guess, Did you ever feel like they were doubting you or wondering is this ever gonna actually happen? Like, when you go six months, like, did you ever worry about the perception of what they might say?
Adam:Or they've been seeing
Dax:it all along the way. Yeah. Well, here's the thing. Right? I wanted to do this the moment I joined the team, which was two years ago.
Dax:But I had to build up credibility over Yeah. The last two years before I was like, hey, I'm gonna do this and I think it's gonna work. So I think the team was pretty bought in that it it would work out. None of us like it. And if you look at our so we review our numbers every week, every every Sunday.
Dax:And if you look at our numbers for the past six months, they have not been really good. Like, the growth has been pretty like, there's, like, always, like, a decent amount of growth. There's been no, like, jumps or nothing exciting. Right?
Adam:When you say none of us like it, like what? None of you like SST two o? We don't
Dax:like having to, like, just do a big rewrite where we're not releasing new stuff. Because we effectively release nothing new over the past six months, and we're used to releasing new stuff, like, every two weeks or every month, whatever it is. And that really drives our growth and gets people excited. So the past six months, we've been operating without that motivation, without that feedback. So we didn't like having to do this.
Dax:We knew we had to because it enables a bunch of really interesting things. And now that it's out, we're looking at our numbers and like, yeah, we're back to seeing like these huge jumps from everyone trying it out and and people getting excited about it. So I don't think they doubted me. I probably doubted myself a little bit because it was there's just a there's just a lot to to figure out. But we got to a place where there's like a working demo of it and the working demo was pretty exciting.
Dax:We got to that pretty early on. So it wasn't terrible.
Adam:So but I just realized we haven't said what SSD is and it's like not everyone knows. So maybe could you give like the could you give the elevator pitch? You really need to have a pitch
Dax:Oh, man.
Adam:For SST. Could you give the pitch? What is it? Just get it at a high level.
Dax:I'll try it. So SST is a framework that helps you ship applications to AWS. AWS is a big complicated beast. We all know this. There's maybe 3% of it that you need to use to build 95% applications, and we try to focus on that 3% and make the best experience we possibly can and let you bring other complimentary modern tools like all these cool front end frameworks that come out.
Adam:Yeah. And you would say do you guys label yourselves as an infrastructure as code framework? You're kind of like going beyond that now, I feel like. But is that is that how you would classify the likes of the CDK or serverless framework?
Dax:Yeah. That's definitely where we started. And for a long time, I saw ourselves as a infrastructure as code. But more lately, I'm seeing that more as just something that we have to do to let you do everything else. We wanna help you build an application and deploy to AWS.
Dax:Of course, part of that is gonna be spinning up infrastructure. But if you're if you're like someone that's trying to do a bunch of infrastructure work and you want a tool for that, it's probably not gonna be SSD because we're more focused on application developers that don't really wanna spend a bunch of time doing infrastructure work because their infrastructure is not very bespoke. It's kind of the standard APIs, front ends, databases, queues, things like that.
Adam:And that's what I love about SST as somebody who's come from, like, the other traditional infrastructures code frameworks like the CDK or just CloudFormation even. Like, SST actually focuses on the application authoring. Like, what you go past the infrastructure and you actually help with the writing actual code for your project. Like, it feels like a modern web framework, but it's doing all your infrastructure as well. And none of the others really feel like that.
Adam:It's like it's cool. It's like Mac versus PC
Dax:or whatever you do, Linux.
Adam:I don't know. And it's so TypeScript friendly. It's just very modern.
Dax:Yeah. And I think it's because, you know, people that work on SST, we have a weird mix that I don't like, our background's kind of a weird mix that you don't often see. We all have done a lot of front end, but we've also done a lot of infrastructure. So these other frameworks, I don't think are I know written by people that are very, very good infrastructure that are a lot better than us at infrastructure. But you don't often see the combination of front end plus infrastructure, and I think our framework reflects that because we're trying to help you build, you know, like a full application.
Dax:And I think that's why our position's a little unique. Most people either are pure front end engineers and never wanna look at infrastructure, or you you kinda don't really often run into infrastructure engineers that like to do front end. So I think because we have that combination, SSD reflects that.
Adam:Yeah. So I want I wanna, like, dive into what is new in SSD two versus like, for people who actually know what SSD is, I feel like that's worthwhile doing. But I also just kinda wanna, like, share my experiences with SSD and some of the things that get me really excited, which makes sense to go first.
Dax:Yeah. I'll do, like, a quick explanation of what it is so people have have context in why I did all of this. So SSD up until two point o, so all of zero point o and and one point o, it was it was the same code base from the beginning. And, you know, when you're a startup, you don't really know what you're gonna become. No one knew what ST was gonna become at the beginning.
Dax:And it was also started at a time where TypeScript wasn't as obvious as a choice it is now. So large portions of the ST code base were written in just JavaScript, not even TypeScript. And as you guys all know, I love TypeScript, so it was a pain for me to just go into that code base all the time. So that was a real limiter. We had some really old code optimized for certain things that we don't really focus on anymore just because our startup has has shifted and our framework has shifted.
Dax:And then the second side of it is we never really cared about performance. When we were building stuff, we just wanted to get stuff out. We weren't thinking about, okay, this adds a hundred milliseconds or this adds two hundred milliseconds. And we did that, you know, over the course of several years and you eventually end up with stuff that just is very slow. So one, I wanted to rewrite everything in TypeScript.
Dax:And two, during this rewrite, I wanted to make sure that any little thing we add, we understand the performance cost, and we really optimize the heck out of whatever we can find. So the experience with two point o is as a user, it definitely feels faster. And I think everyone's, like, noted it's, like, it's not just we did well on benchmarks, people can feel it. And then for us, as people maintain the project, we're able to ship way more, way fewer bugs. We fixed, like, we fixed, like, a thousand little bugs or, like, weird ergonomic issues with s t two.
Dax:With one point o, people could use it, but I wasn't really excited for people to try it, and I wasn't really excited for the experience for it. With two point o, I'm definitely more excited with, okay, people are gonna use this and have a decent experience. Of course, I still don't feel like it's where I wanted it to be, but definitely, you know, order of magnitude better than where it was.
Adam:Just go head down for another six months. I'm sure you'll get there.
Dax:Oh, I can't can't do that again.
Adam:I wanna speak to my experience with SSD, but it's not really like I think all my experiences with SSD two. I don't think I played with it much before you had like a snapshot release that I could play with. I think, like, there's a recent example on Twitter and and I'm more speaking to web developers, I think. I'm not like people who've used the CDK or people who've used CloudFormation and they want something new. If you're just a web developer so Rox, who streams on Twitch, he is building this thing and he needed to do uploads.
Adam:Like, ideally, multi part uploads. It's like huge video files. He's trying to make this app where people can upload their video files. And he wanted to use s three. He heard that'd be better than what he was doing, which was like people posting straight to his railway server or something.
Adam:He he his sentiment on Twitter and I've talked with Rox about this a lot. I'm not like talking behind his back. His sentiment on Twitter was like, why can't there just be an easy thing? Just give me, like, a a library that'll just do this for me. And there's really not a way to do that traditionally, like, to have a library that goes to that extent because it's like back end stuff, it's infrastructure stuff, and then you've got the front end piece.
Adam:It's gonna be multiple things you're stringing together to make uploads to s three work. But SST actually makes it this I I see this future where you could have, like, an SST construct or, like, a third party library somehow that builds with SST, and it encapsulates all of that from, like, your front end, which SST helps with deploying your front end, whether it's ASTRO or Solid Start, these, like, exotic new things or it's Next. Js. You've got these constructs where it's like you're acknowledging the whole stack within your application. And you've got this opinionated folder structure.
Adam:So you create an SSD app and you have this place to put infrastructure stuff, like functions that need to run, APIs, databases, storage, whatever, like s three buckets. But then you've got, like, the ability to drop your front end there and and interact with those back end components natively, like, very easily without managing all the environment variables and all the plumbing and all that stuff. So I can imagine a world where you could have these kind of higher level application components that make something like multi part uploads to s three way more feasible. And then Rox could have his wish of like, somebody just point me to a thing that I can just install and then it'll just work. Right now, like, multi part uploads are a huge pain.
Adam:Even just normal uploads to s three, there's like a several steps involved there and you don't just have like a node library that you can install and suddenly have all that work. So that's my take, like and I built out a multi part upload thing using SSD. It just feels really good. It just it feels like a modern web framework, like I said, but it actually takes you into your AWS account and deploys infrastructure and does all these more, like, bespoke things you need to do when you're building things that aren't trivial. Is that accurate?
Dax:Yeah. And I think that fits with the way I've been thinking about things lately. I have this idea where whenever we're building features, I try to think of it as I don't wanna make the user leave their editor. I don't want them to make them leave their language. So if if you build, like, the best let's say we all know AWS Console sucks.
Dax:But let's say you built like, you're the best designer in the world, the best front end engineers in the world, you built the absolute best AWS console there is, it's still not the correct experience because if you are in your editor, you're writing application code, and you need to create a bucket to upload stuff, the context switch of having to switch to some UI tool to do that Yep. Is it doesn't matter how good you've made that UI tool. You've already lost the developer experience because they had to do a context switch. So for us, we know most people are using TypeScript. They have to be using it if they're on the front end.
Dax:So they're likely gonna use it on the back end, and we wanna make sure you can do everything through TypeScript. And if that's the case, you're never doing a context switch. Like, doing quote unquote infrastructure work just feels like the rest of your code, And the type safety we've provided across infrastructure front end and back end makes it all feel like one one thing. So we're kinda hoping we get to a place where it feels like I'm just writing an application. I'm not doing these discreetly different tasks.
Adam:Yeah. As somebody who does all the parts of the stack, it's very refreshing to me. But I'm like a kind of a weird maybe use case of, like, I work alone a lot and all that. You've got a lot of startups using SSE. I've been in your Discord.
Dax:Mhmm.
Adam:That it doesn't seem like there's any has there been a drop in activity in in the Discord for those six months? Because it feels very active. They don't seem to have slowed down a bit. Your like, who's building on SSE?
Dax:Yeah. We're still growing really well and, you know, with two point o, we've seen a huge jump. Our focus is definitely still startups. We believe in helping people build, like, you know, they're trying to build sustainable companies, sustainable product to, you know, to work on. And, obviously, that needs to be easy at the beginning, but it can't be this thing where they hit a point where they just hate our tooling and need to eject out of it really hardcore.
Dax:So we intentionally accept that our stuff is never gonna be the easiest to start with because you need to trade something off to get there. You need to trade off longevity. So most of our users are startups or companies or teams that are working together. We do have, like, really large enterprise companies as well, and we like to support them as much the best as we can. But our focus really is, I'm sorry.
Dax:I'm trying to start a company. It's just me and my cofounder. And then within a year, then there might be a team around this. And there's, like, a very narrow set of things those people need. So it's very easy to optimize for that experience.
Adam:Yeah. And you're very like practical, I would say is the word. You you thought you've thought through the whole authoring experience in the light of like future maintenance. Like, not a lot of frameworks seem to care as much about how easy is it to keep building on your thing, you you say, like, in year two and year three. That stands out as well as I work with it.
Adam:Like, the domain driven design stuff, I mean, just stuff that like in the serverless community especially has sort of been abandoned, it feels like. And SST is kind of bringing it back to those principles.
Dax:Yeah. And these are all just really old ideas which is what's funny about it. Just stuff that's been around forever and has worked forever. And it's always fun to, like, deviate away to see if things are different now. But the stuff we have in there is old time tested stuff that the most maintainable apps apps have.
Dax:But we try to keep it light. Like, we don't want you to, like we never want someone to feel like I'm studying the theory of something. And I think that was a lot of what even serverless was like for a while. Right? Like, I'm gonna become a serverless developer and have these, like, grand theories about serverless architecture and infrastructure.
Dax:This is how we think, and this is how what we believe in. And it becomes like a whole philosophy. And that's kinda why I was saying the other day, like, front end world has a much better relationship with serverless. Most front end engineers are really serverless native. Like, everything they do is they don't even expect anything different.
Dax:They just expect it to be serverless. But they don't think twice about it. It's just a natural and instinctual way for them to do things. Whereas I think the back end world has been it's always been like this very intentional large step Yeah. To doing serverless as opposed to feeling like, oh, this is just normal.
Dax:This is what building applications is like.
Adam:Yeah. You mentioned earlier ejecting too. I I thought I should point out, I think in my examples, things I've built with SST, I've had to use something there's something I need to deploy outside of that 3% on AWS. Like, I needed some kind of infrastructure. And you could just drop CDK components directly into an SST stack.
Adam:Like, these are just CloudFormation stacks or just CDK stacks at the end of the day. Right? Is that accurate?
Dax:Yeah. Exactly. And that's as much as I struggle with the constraints of CDK, because it's not my project, it's AWS' project, and, you know, sometimes I want them to do things differently. The reason we're still on it is for that long term maintainability, sustainability thing. We are never gonna be able to cover a 100% of people's use cases.
Dax:They're always gonna need to do some weird thing that's different. And it might it's it's not even that it's misguided or anything. It's just people have different requirements. And being able to drop down into something lower level that still feels pretty similar. Like, when using a CDK construct, yeah, it's a little bit different, and some of the stuff doesn't work as nicely as it does with SST, but it's not like you're dropping down to writing YAML all of a sudden.
Dax:Right. Something that you, like, never seen.
Adam:Or doing something in the console.
Dax:Yeah. Exactly. So I think that's a lot of the reason we've seen we're able to see especially for mean, we're not we're still, like, a new project, and for something as important as your infrastructure, it's a big decision for people. And I think a lot of the reasons we've been able to see a good amount of growth is everyone knows that there's an escape hatch of fail safe if if they don't like something, they can they have the underlying layer they can drop to. So we don't take that lightly.
Dax:We know it's a big reason why people are willing to try it out.
Adam:And you've got the OpenNext. So you deploy Next. Js sites into an AWS account with similar feature sets as Vercel. Right? I mean, there's are there still things you guys haven't built out maybe?
Dax:Yeah. So that's a really interesting project, and I think we're getting some signals over the last week that it's working out the way we were hoping. The idea behind it was, you know, Vercel has this really awesome serverless infrastructure to deploy next JS sites. We don't know the full details of it, but they can do whatever they want. Right?
Dax:Because it's a black box. They can use some of AWS. They can mix in Cloudflare. They can kind of do whatever setup works well for them. And if you wanna self host and you wanna have a similar serverless setup in your own account or whatever it is, it takes the effort of, like, an entire Vercel engineering team to to, like, come up with that architecture and do things correctly.
Dax:And there were several, like, disparate attempts at doing this. You can think about, like, you know, individual open source attempts of, okay. Hey. Like, here's here's, like, a way you could do it in your AWS account. There are other proprietary attempts.
Dax:Right? Like Netlify let you deploy Next. Js to their infrastructure similar to Vercel. Amplify has their own. So it it felt to us like everyone was repeating this work over and over.
Dax:So we try to create, okay, let's create, like, an open attempt at doing this. And we're not irony is no one on the team is an Next JS user. So we're, in a lot of ways, ill suited to do this. Like, understand the infrastructure stuff really well. We understand front end in general and how to deploy front ends in general well.
Dax:But if it comes down to, like, how should this specific Next. Js middleware operate, like, we're not the people that do that. So that's why we really wanted an open effort. We saw enough interest in our community where a lot of people were deploying Next. Js.
Dax:Like, Next. Js experts that, like, knew every little detail of it. And we really wanted them to contribute and, like, find bugs and be opinionated on how it should work. And over the past week, we've been seeing pull requests fixing, like, really obscure things that we would have probably never figured out. So so with something like this, it's always gonna be a little behind Vercel because, like, you know, they're building XJS.
Dax:Their infrastructure is gonna match it, and they're gonna be nice lockstep there. We're always gonna be a little behind, but if we have a decent amount of eyeballs helping us and looking at it and and helping us stay up to speed. We have a really good shot at maintaining parity with a similar Next. Js experience on Vercel. It's never gonna be the same because they mix in other stuff.
Dax:Like, they use Cloudflare for some things. Our ourselves a 100% AWS, and we have the constraints there. But it's at this point, it's comparable. And I think for most use cases, it works effectively the same.
Adam:I wish the whole Next. Js thing being so complicated to deploy didn't taint my like, I it's hard for me to wanna use Next now just because it's so complicated to deploy. And I know I'm, like, probably unique there. Everyone's still probably using Next. Js in mass and deploying to Vercel and I'm sure it's not hurting them any.
Adam:But for me, as somebody who's really into, like, running stuff in my own AWS account and building out my own APIs and those things, yeah, the whole, like, complicated nature of Next. Js. Because you guys have other constructs for, like, these other frameworks and they're super simple. Right? Like deploying an ASTRO site Yeah.
Adam:Super simple. The Next. Js, not super simple. You have to have a whole open source, like, movement to try and keep up with what all the that they're doing there. I guess it's good.
Adam:I mean, I guess the features that they provide are cool. I just wish it wasn't so complicated.
Dax:Yeah. Exactly. Like, if you look at the code for our other contracts so right now, we have an ASTRO contract. We have a REMIX contract. We have solid start contract, and we have more coming.
Dax:The other three are almost exactly identical and there's almost they're like share, like, 90% of the infrastructure and there's like very little nuances between them. But these other frameworks were built to be very neutral from day one. Right? They like in their repos, they have adapters for for Cloudflare, for Netlify, for running in a container. I'm interested to see how these evolve because that is a constraint that they're adopting.
Dax:They're saying we're gonna build in a neutral vendor neutral way. And maybe for front end, that doesn't matter too much. But at the end of the day, Next. Js will always provide features that are very difficult for some of these other providers to other frameworks to do. And I'm starting to see them kind of break that little.
Dax:Like, ASTRO has their image component, which, you know, only works like, it doesn't work in Cloudflare. It only works in, like, AWS type environments. So as an example of these frameworks having to draw some lines and be a little bit opinionated, they're all really good in complete filling frameworks.
Adam:Is it is it just about the runtime? Like they wanna use something that's node specific or something and then it has to be deployed to node servers?
Dax:That that's what they that's one one constraint. But things like Next. Js has a bunch of like interesting stuff. Right? Like their middleware it's like, your middleware can run an edge it can, like, decide things before it hits your regional function.
Dax:Those are, like, architectural features that, you know, for coming from, like, like, whoever's working on ASTRO, their only ability is to say you have a single function and the functor's gonna execute. They can't, like, do complex routing stuff at the at the, like, the infrastructure level. I don't know how important all that is. Again, I I don't use Next. Js, so I don't know how, like, oh, this is a really awesome feature or this is just like a cool thing they use once in a while.
Dax:So, yeah, I think these frameworks won't be able to do that type of stuff, but as a user of these frameworks, it doesn't feel like it's mattered too much. I can do everything I need in Astro and Solid Start and all these frameworks. I haven't felt limited yet by them.
Adam:And whatever framework you're using, you can use SST to deploy it into your own AWS account. Super cool stuff. I'm a big fan. I've become a big fan. I think those six months, I needed to see you put in the effort, Dax.
Adam:And once you did that, I felt solid moving forward with SST. I'm just kidding.
Dax:I mean, that's kinda what I was hoping, so
Adam:Like it would bring on the the people that are slow adopters like me. Well, it's been, I don't know, two and a half months since we've done this. Is that right?
Dax:Yeah. It's flown by. It has flown We like went to hibernation for the winter.
Adam:Yeah. Was just a holiday break. I like to take long long holiday breaks from everything and that's what this was.
Dax:All the way up to President's Day?
Adam:Yeah. Exactly. When is that? When when's Labor Day? Is that like June or something?
Dax:Never keep track. Like we because if we both are kinda independent, like we don't have the the company calendar to remind us of these things. Exactly. Just don't know.
Adam:Okay. I don't remember how we ended. Did we ever have a way we ended a podcast episode or was it always just
Dax:kind of
Adam:like awkward goodbyes?
Dax:I think we were all just like, alright. See you, Adam.
Adam:Alright. See you next.
