Ask HN: What web stack would you use for startup, and why? | Hacker News Reader

Ask HN: What web stack would you use for startup, and why?

15 pointscapl44 comments

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)

The goal is to bring the user a good experience, but use the least time developing since it's a side project. What do you reach for? Django + React? Laravel + Livewire? ASP.NET + Blazor? Next.js + Prisma?

View on HN

Rails (front and back)

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.

Came here to say this. Rails is by far the best option for a startup. For starters you can focus on business-level design rather than building a bunch of plumbing.

Also, the framework lends itself to small teams extremely well. A single developer on Rails can outperform entire teams on other technologies.

Full .NET stack.

- 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.

Yeah I've been looking at Blazor for some time, and the .NET 8 updates are great, but I just don't know if I like the .razor DSL and the fact that things are either SignalR (latency) or .NET runtime in the shape of WASM (huge bundle, literally the kitchen sink).

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.

Blazor Server isn't inherently latency riddled. Blazor Wasm isn't necessarily slow to initial load with .NET 8. IIRC the compiler is also really good at trimming the Wasm bundle when publishing in Release mode.

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.

Hey again. Tested .NET 8 and blazor again, and it wins… I mean it wins by so much that I now default to using .NET and C# for any task web related. Having components be SSR’d by default and then using SignalR later on by interactivity demand fixed by biggest criticism which was initial load overhead.

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.

I just want to note how much time would be lost to confusion on my team, if we had to differentiate between "Server Side Rendering" and "Server mode"...

.NET is such a cluster of poor naming choices

I ended up moving things to the standalone WASM app just for this same reason. This confusion gets worst if you have different layouts for different aspects of your app, and who knows where things should be placed appropriately. All of a sudden some of the components won't become responsive at all...only to realize that it's pre-rendered.

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.

I feel like Microsoft's naming division has a mandate to cause as much name collision as possible, so that "out of date" requirements at very big very slow enterprises suddenly and magically target the latest hotness.

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.

I've started using what I've dubbed the HAG (HTMX, AlpineJS, Go) stack for my "startup". It's really simple and easy to get into. I do try to minimize the use of third party packages/modules to reduce my attack surface.

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).

Cool! I haven't heard of Turso until now but it looks great. Why choose it over Planetscale, though?

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

To be honest, while I have heard of Planetscale I never really looked into it. It does seem really interesting, but as you can probably gather from my answer I'm really into simplicity and ease of use. And since Turso is powered by LibSQL (SQLite fork) it is dead simple to use. Their pricing is also very predictable which and with a generous free tier.

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.

Fair enough! I'll try out Go + HTMX this weekend if I get the time

Supabase + Next.js is what I'm using.

To 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.

I would go for something similar.

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 ;)

If you are building a blog or something content Astro is a great choice!

The portfolio looks great, congrats! I hope she will find a job soon, and good for you for building & promoting it ;D

While I haven't quite tried it yet. I think it is possible to also use astro with functions/lambda's to do a full blown app.

I personally really like their approach to templating and components as well as server vs client side JavaScript.

Seems very interesting. What would recommend for followings:

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 ?

1. Depends on what you need, how long it runs, etc etc. If you just need cron/triggers, Supabase can get you quite far. If you need proper processing you might need some other service or host something yourself. We use modal.com, but there are many options.

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.

Qless is a good language-agnostic queue system; its essentially a bunch of Lua that runs within your redis server(s), and then you have a client library in your language of choice (i know of at least ruby, python, nodejs and php libs for it) that calls to the Lua.

https://github.com/seomoz/qless Is the original project.

Cool! Seems very productive. Only thing I'm thinking of is reliability and the lack of control since you aren't hosting it yourself.

You could self host as it's all open source, but that would be a lot more work..

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.

Self-hosting Supabase is pretty hard when you consider mail set up, and all the config like setting your own domain/secrets/config without the full dashboard Supabase managed service provides, doesn't it? Aka you can't just get-up-and-go fill in a nice UI/form on an EC2 instance AMI template for Supabase...

I would assume so. Never tried it, and I hope I never have to, I use Supabase to have less work not more haha.

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.

Use what you know, what you are efficient with, what you like to use.

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.

"Use what you know" is, in my opinion, the best answer. If you're starting a startup, why would you hinder yourself with the struggle of learning new a new stack (and, worse, a new language!) with all the other things you have to do to get traction and product market fit?

if you want to get up and running quickly, choose what you're familiar with.

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.

Depends on which programming language you’re most familiar with. For python I would go with Django and htmx, Ruby, rails plus Hotwire, Php, Laravel with livewire or inertia, Elixir, Phoenix with liveview, C sharp, asp.net razor pages and htmx, Java, spring boot and htmx, JavaScript, express or sailsjs and htmx

Do you really use Htmx in production ? Do you have examples to show ?

I would use Elixir (Phoenix + liveView), to me its the most productive stack for web apps at the moment.

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.

Whatever you're comfortable writing and think you can build a fast MVP in. You can always, and will likely, need to come back and rebuild portions of the software if your startup takes off, so don't worry too much about making all the "right" choices out the gate. That's my philosophy, anyway.

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.

Flour, sugar, salt, baking powder, eggs, milk, and butter

The pancake stack

Never neglect the importance of a healthy breakfast for the startup grindset

Good point. And it's easy to pivot to crepes.

PropelAuth + Next.js + Prisma + Supabase, unless I need socket communication or integrating services like Slack.

I will use Java for backend and vue.js plus tailwind css for develop web pages.

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

Golang + SSE + Vue + Postgres

No cloud vendor lock-in. Small image sizes. Easy on-boarding. Simple and productive.

This is all buzzword soup.

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

Do you need React or could you get away with server side rendering plus a bit of interaction on your pages (htmx)?

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.

- HTMX for the front end

- Flask or Phoenix (Phoenix Live View if websockets are very important)

- Amazon Dynamo for (DB)

- Elastic Beanstalk

I haven't used it yet, but for my next full stack project I want to try Laravel with Livewire.

I love Svelte for client side stuff but in truth 80-90% of UIs can be solved with HTML over the wire.

I have finally a disconnect between investor expectations and the reality of shipping prototypes with php that I wonder if anyone else has seen?

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?

PHP has a really bad reputation in the tech world, unfortunately.

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.

Indeed. Every time I do work on a recent javascript framework I find myself crying into my coffee because of all the (what feels like) needless complexities. Svelte is pretty good though. Still love me some python, go, rust and laravel though.

Not sure if most would consider it a web stack, but it can do the web. Not likely to be popular but dart/flutter for me.

Reply on news.ycombinator.com