Ask HN: What web stack would you use for startup, and why?
If you were to build a startup or a solo side project, what web stack would you use and why? Web stack meaning backend and frontend. To make a more specific use case if that's easier, say you need:
1) Auth (local accounts + OAuth)
2) Simple user dashboard with some live updates (Websockets, SignalR, etc)
3) Blog (simple db read/write)
44 comments
[ 4.7 ms ] story [ 58.2 ms ] threadTo cover your list:
- Auth: Supabase has auth, with oauth support for many services. Also prebuild UI for login forms etc. It's really easy to set up
- Live updates: Supabase has a realtime api to send messages, or subscribe to db changes
- Database: Supabase is basically a Postgres database with a bunch of stuff on top, it generates a REST/GraphQL api from your schema, meaning you don't have to make endpoints.
It's incredibly productive as it covers all the basics. It's open source so you are not locked in, and they have a free plan that will get you quite far.
For the frontend Next.js is my preference, but you could opt for other frameworks if you are more familiar with them. Next.js on Vercel is really easy to set up with preview builds, automatic deployments etc.
Reliability, it depends on your app and requirements. Been using them for about a year and it has been really solid, the few times I did have some issues the support was really quick and helpful. But I do see your point, it might not work for everyone.
I still find it important that the option exists if ever needed, and maybe even more important is the ability to move away from Supabase, which some people have done successfully (see for example https://news.ycombinator.com/item?id=36004925)
Other services like Firebase make that really complicated. I quite like that portability is one of their core principles.
There are some guides and templates on self hosting https://supabase.com/docs/guides/self-hosting but it's obviously a big complicated project with lots of features. It probably also requires a bunch of work to monitor, maintain and update it once you get it running.
1) Background jobs - Something like Sidekiq for Rails.
2) Admin Dashboard - Something admin interface of Django or active-admin for Rails
3) Authorization
4) Is NextJs good for working with Websockets ?
Do you have/know any git repository which implements this stack ?
2. Three options: use the supabase admin panel, build something yourself (or use templates), or use a 3rd party tool - many low code tools can connect to postgres and there are also some specific integrations with supabase.
3. Supabase has auth built in, with RLS you can control data access.
4. Next.js is just React when it's in the browser, so yes, it will work well. If you use the Supabase realtime with their client library it will handle all the socket connection for you.
5. Have a look at https://www.madewithsupabase.com/tag/Open%20Source it's not all next.js but there are quite a few.
https://github.com/seomoz/qless Is the original project.
I would try supabase + Astro.
With astro you can have more choice in frontend framework, vanilla js, alpinejs, react, svelte, vue.
I recently made a portfolio website for my girlfriend and the experience was awesome.
https://zhazira.design/
If anyone's hiring junior designers ;)
The portfolio looks great, congrats! I hope she will find a job soon, and good for you for building & promoting it ;D
I personally really like their approach to templating and components as well as server vs client side JavaScript.
- Self-hosted identity management, "ASP.NET Core Identity", using new scaffolding from .NET 8
- Blazor, using the "Auto" mode from .NET 8: Default to SSR, autopromote to Server mode for live updating components
- EF Core for DB handling
The idea is to focus on keeping things simple and easy for the developer. The most annoying part about the stack is the way Microsoft names things.
Keeping the rendering logic fully server-side lets you use your EF DbContext/entities directly in your components, taking on some (I'd say minor) technical debt to greatly simplify development.
You won't need a fully separate SPA with a dedicated API. Not yet, maybe ever. You can migrate your components to Blazor Wasm piecemeal if/when you reach a stage where using Server mode starts giving you troubles.
The biggest upsides to Blazor is that, as you said, greatly simplify development as you basically have only one code base to think about with Blazor Server, and you save a lot of time not worrying about the backend / frontend bridge. On the other side, there is a demon on my shoulder whispering that the customer doesn't care about developer UX, and they'd go for a native web-app over a latency-riddled or slow initial load web app.
The neat thing about the new stuff in .NET 8 is that you can choose the interactivity at the component level, so if some component really sucks when used with Server interactivity, you can take the extra time to convert it to Wasm w/ some backend API.
You should also ask your shoulder demon much would even be interactive in the first place. SSR'd pages with forms can get you very far.
Also I’ve experimented with azure since it’s of course very well integrated with the .NET environment, and I think I’ll use that too instead of digital ocean which I’ve defaulted to before. I thought azure was too expensive, but re-evaluating now, it is actually very generous by giving free tiers which lets you launch without paying a dime.
.NET is such a cluster of poor naming choices
It is my main gripe with the .NET ecosystem. Don't get me started on Azure..
But once you get over the hump and understand the meaning of the subtle differences, it's possible to make sense of it.
In some cases, even the SSR gets you a quick time to first bite, clicking on a link that takes you to a WASM-rendered page freezes things for a bit while WASM and other files were getting downloaded.
The experience turned into a bit of a mess and I ended up moving things back to WASM and so far a smooth ride since then. There's potential with the Blazor Web App approach, only if Microsoft put some heads into revamping that experience a bit better.
personally, I'd go with Rails + SQLite. skip OAuth unless you absolutely need it.
> Simple user dashboard with some live updates (Websockets, SignalR, etc)
you probably don't need live updates in v0.1. skip it.
> Blog (simple db read/write)
any static site generator + markdown. I use nanoc, but any SSG would do.
Turbo handles live updates
For authentication, I'd use the devise gem, and plan for OAuth later.
I'd use Pundit for authorisation.
I'd use sendgrid for email and stripe for payment.
I'd host on FlyIO; though I'd consider Heroku as 50$ a month would likely cover most needs, and it's super simple.
All up blog would take about an hour.
Then it's about style, and for that I'd go with w3schools css. There are a pile of templates and it's dirt simple to add. IMHO tailwinds is a sledge hammer when most need a ball-peen hammer.
Also, the framework lends itself to small teams extremely well. A single developer on Rails can outperform entire teams on other technologies.
- Flask or Phoenix (Phoenix Live View if websockets are very important)
- Amazon Dynamo for (DB)
- Elastic Beanstalk
No cloud vendor lock-in. Small image sizes. Easy on-boarding. Simple and productive.
I would use Laravel
1) Auth
You can create your Laravel app choosing (Vue + Inertia) or (Livewire) and have auth, 2FA and a profile dashboard in a few minutes, with Laravel Socialite package you can quickly add single sign on with Google Auth, GitHub, Octa, dozens of options. Oauth with Laravel Passport.
2) Simple user dashboard with live updates. I prefer Livewire or you can use View + Inertia these would have been installed in the previous step. You can also use Laravel Nova, or Filament to speed things along building a dashboard.
3) Blog I would run this standalone from the app and use Statamic, Next js or just html + tailwind css depending on the complexity
Laravel Ecosystem
Herd - macOS app that makes setting up your local dev environment instant.
Jetstream - Start a new project with auth and team management.
Telescope - debugging and insight UI
Scout - Lightening fast full text search
Echo - WebSockets
Cashier - Stripe and Paddle Subscriptions
Envoyer - Zero Down Time Deployments
Forge - Server creation and management (EC2)
Vapor - Serverless Creation and management
Horizon - Redis Queue Monitoring
Pennant - feature flags
Sail - Local Docker
Socialite - Social Auth Google, Facebook, GitHub (tons of drivers)
Sanctum - API and mobile auth
Pint - Code style fixer
Dusk - Automated browser testing
Inertia - SPA with server side routing
Livewire - Dynamic server side apps. (Similar to Rails/Hotwire)
And those are just some of the first party packages and tools.
There are well maintained Laravel packages for almost everything else you need.
And working with Laravel is the best developer experience.
I love Svelte for client side stuff but in truth 80-90% of UIs can be solved with HTML over the wire.
One recent raise that I was talking a new entrepreneur through had the investor take a hard pass as soon as they found out he was building with Laravel.
This isn’t the first time but in the past it was suspicion and wasn’t so explicit. They literally passed on giving a term sheet specifically because they were built in laravel… so I finally got someone “on the record.”
I have built startups with PHP and had great success, though I use a lot of platforms now and not as much php anymore, but I wonder if there is any issue with the raise.
I know the technicals (and how dumb it was, the first version gets trashed always anyways) but I wonder if others have seen this?
I had that wrong idea too until very recently. I realized PHP has progressed a lot better in the last 10 years than JS has because they have the luxury of being able to control the runtime. Unlike the JS world that has to use TS as a crutch because browsers are evolving so slowly.
Personally I'd choose the LAMP stack because it's what I'm most familiar with for web development and I know I can rapidly build a performant functional product with it, but for you that might be something else.
Unless you’re building g Facebook or Gmail-like interactivity, server side rendering might be enough. That alone could save you 3-5x the time.
The pancake stack
Never neglect the importance of a healthy breakfast for the startup grindset
You can have SPA like user experience without building a separate frontend & backend. That simplifies things ALOT!
For data persistence, I would consider SQLite otherwise go with Postgres.
Take a step back and think hard about what you need the stack to do.
If you are very proficient in a stack and it will do the task with dependency he’ll or too many junk layers, that is the best one to use.
If you care about what is sexy or popular or cool, you’re doing it wrong
and Use Swift for macOS app and iOS apps
use flutter to make iOS and android apps
My latest is the macOS app that is a window manager
https://wins.cool
For the rest of your questions,
- Auth: Auth0. Simple to get started, and depending on your plan you can enable SSO for business clients.
- Frontend: Plain ol' HTML, CSS, and minimal JS. This is where HTMX and AlpineJS comes into play. Elements can be updated without a whole page reload creating a better user experience.
- Backend: Go. A language I love to use. Fast, simple, and deployed very quickly.
- Database: Turso. Dead simple, easy to use, and with easy replication to different regions.
My app code is all contained in a monolith, which is deployed onto a dedicated web server. I can either update the server resources or using a load balancer I can deploy more servers running the application to increase scale (if necessary).
I've been looking at HTMX + Go for some time but I just don't know if it's worth it over React which I already know. Is it really more productive, or is it simply a ideology/hype thing? I'm also a Go fan because it values simplicity, which I think we should all strive for, so the HTMX + Go combo appeals to me, even though I haven't looked at HTMX as I mentioned. Having to use C# and TypeScript at work, I start to see the real appeal of simplicity more and more... I'm becoming a grug brained dev :O
HTMX + Go is such a great combo for those who don't necessarily enjoy JS/TS. I just want a good user experience and also a good dev experience. And for me, HTMX + Go is that. I can create reactive websites while working in my preferred language. I'm also shipping minimal amount of data to the user so and using as little CPU and memory as I can.