Comment by taylornotswift | Hacker News Reader

Comment by taylornotswift | Hacker News Reader

Parent Full thread

I really like SST compared to SLS because it is by far more featured and actually supports multi-cloud. This kind of cements that as you can deploy nearly anything with it now.

But, if I was going to start a new project today, I would probably reach for SLS, because it is simpler and faster to get set up. I think SST sometimes gets in its own way with complex IaaC config; if I wanted to do all this then I would reach for Terraform, and part of the appeal of serverless is the low lift to getting to "deployed."

So I think it's really cool that SST is adding all these things and exploring areas outside trad serverless to expand and grow new user bases. I also think this kinda sucks for people who have been with SST for a while and waiting for improvements to the DX for serverless (the functionality is there, the DX is not). I'm sure lots of thought went into this decision, but I still think it would be profoundly "worth it" for SST to tackle DX again, or for someone to build a wrapper around it.

In a sense the simplicity of SLS is a trap: immediately when you need to move past the synchronous lambda invocations via API GW use case (caching, service integrations, step function workflows etc) you need to either fall back to plain CloudFormation or rely on third party plug-ins with possible problems with maintenance, quality and feature-completeness. This makes it a difficult choice to recommend beyond simple use cases.

Yeah this is one area it really struggles. I built a harness (using SST, actually!) for things like step functions, background jobs, cron-ed tasks that I'll try to open source once I clean it up a bunch.

I kind of see that as an unforced error on SLS's side as well; AWS EventBridge is pretty simple and would make those types of workflows possible, but the integration with SLS is really rough.

can you share more about what DX is missing?

v3 i think has parity with v2 minus wide support for non-js runtimes

I think it's mostly simplicity; with SLS I can have an endpoint for a random function in minutes, so when I want to build e.g. "return AI generated image" I reach for SLS. Then as that project grows, I stay on SLS because it's just there.

But if I could get that set up with SST in similar time, I would reach for that instead. I think SST is very feature-ful and I often find myself putting good thought into what I am architecting when I'm using it; but it isn't very often that I want to put good thought into what I am architecting when I am just starting a project.

To give an example I am using SLS in most of my contracted work; I am using SST for a project that builds other projects. If you solve the "why are they reaching for SLS at all" problem I think SST would be the very easy choice in every scenario, if for nothing other than the sheer number of providers that are supported instead of just AWS.

I'm sure some of this is a compromise that's tough to design around, so maybe the solution here is a service built on top of SST. I don't necessarily mean Vercel (am familiar with your thoughts on that company), but maybe an easy graphical tool or even a form that spits out my sst.config.ts for me :)

Reply on news.ycombinator.com