I've seen a lot of projects fail/struggle in golang (package ecosystem is still missing a lot of basics imo) or nextjs (very buggy).
.NET has been my secret weapon. It's boring, works really well, has a good ecosystem and asp.net is really well thought through and you can go as "deep" as you want with middleware etc. Plus performance is extremely good, as is the deployment story with docker these days (having to use Windows server with .net Framework a few years ago was a nightmare, enough to put me off, but in .net core Linux is a first class citizen now).
Also the IDEs are great these days, especially rider.
If not: the tried but true Rails + Postgres.
Add more things only when needed. For example Alpine.js if a bit of interaction that's not covered by Rails' Turbo. If the need for background processing arises, bring in the good_job gem, and there may be no need to deploy it separately at first.
For hosting I'm not quite sure these days. Heroku may be on life-support, but its feature-set covers most basis.
I would pick what I'm most comfortable with, a simple monolithic Nest.js application running Fastify, with Postgres or SQLite, Dockerized, hosted on a predictably-priced host like Hetzner, and Ansible to automate everything. I know that stack will give me plenty of headroom until I eventually need to scale differently.
Front-end is still React, which has a massive ecosystem, and I feel like I can do _anything_ with it by just bringing in some dependencies, if it's a passion project then I want to deliver features fast, React allows me that.
I feel like a dinosaur, edge, workers, cloud functions... I'm familiar with none of that magic, there's probably a whole universe of amazing new ways to build for the web I'm sleeping on, but at that point I don't even care really.
For the former, I tend to reach for the tech stack that I've spent years working in and can very quickly spin up projects in. This is heavily specific to your background, but for me:
- Frontend: React, vite, react-router, Chakra UI.
- Backend: Node.js + Express
- Database: PostgreSQL
- Scheduled jobs/ML/data processing: Python
- Deployment/Infrastructure: Docker, docker-compose, AWS EC2 or Lightsail, Digital Ocean droplets, Netlify, Render
For the latter, there are lots of potentially better options, whether that's server-side rendering, serverless functions, etc. (Next.js, fly.io, supabase, are a few examples) and again depends on your industry.
If I had to get more people involved and have it scale I might go to Flask but might also go to a Java-based backend as it really has the best ability to use threads and parallelism.
As for HTMX I like it but I think there could be something similar but a little more feature risk, for instance my app has a lot of tables and tools that make it easy to add client-side sort buttons would be nice. If I had more people working on it I could see using a react-a-like system as well.
The database is arangodb which I love for rapid prototyping but if it had to be really reliable the first thing I would look at is postgres.
For me personally, I've been working on one that's pretty app-y and used Postgres + Deno + React/MobX (built with esbuild)
I'm very comfortable and happy with TypeScript, so I like having it on both ends (especially because I can share types between the two sides of the wire). And Deno and esbuild make the tooling story really simple and no-nonsense on the back and the front respectively, while being less opinionated than a framework like Next (I like Next for other things, just didn't choose it here)
It can easily be maintained by a single developer. Scales well enough for a decent number of users. Huge ecosystem of components. Easy to deploy to literally any web host. Wide variety of front-end systems.
If you need to scale, it can do that. Developers for it are plentiful. But you can always rewrite it in the flavour-of-the-month framework when you hit either scale or money.
I'm building a B2B2C marketplace in my free time and I'm blown away by the practicality of this stack. Due to longevity of Django, every problem I encounter is just a search away. DRF makes it dead simple to add REST APIs. The Admin panel is a golden cherry on top.
... Or the stack you're most efficient/ effective in. A short time-to-market is most important for learning. If you don't reach an audience, your project might bore you soon. Tech rarely is the holy grail to success.
For frontend side, if i can get away with minimal js, i'd go that way. If not, highly depends on team and target interactivity. If it's just me, i'd go with LiveView
There's nothing even close to the productivity we had back in the days of VB6/Delphi to be had on the web, ever. The closest we're going to get is a pale imitation.
I can totally see how a senior fullstack dev would have a completely different approach though.
Vite and TypeScript were new to me. I'd briefly used a older version of Vue for something. I currently deploy to Vercel, but don't have any Vercel dependencies.
I used Phind, ChatGPT, GitHub Copilot extensively in order to understand the "AI pair programming" experience. They were helpful for suggesting solutions and helping understand mistakes. Just to set expectations, the flow was less "problem→solution", and more "problem→try this→iterate→try this→iterate→solution".
Very fast to get going and nice developer experience. Love jamstack style hosting. Scales from simple static site generator that is free to host, to live APIs/dynamic pages, and back again without changing frameworks. Can make beautiful pages that load in 100ms and 30kb.
Currently using tailwind css because it also compiles (like svelte) and only ships what you use to the client.
Hetzner (bare metal) for hosting. Bash script for provisioning a server. Vanilla JavaScript only when necessary. Tailwind for design. nanoc for generating a static site.
If I were to start again, I'd pick the same stack again. It just works and gets out of the way.
Honestly though, the vast majority of webapps I implement are "boring" and the technology behind them needs to be boring and focus on productivity and maintainability. For this I usually select JakarataEE and JSF/Primefaces. Component based frameworks like this are stupid easy to slap together forms and business processes for internal webapps.
Ideally, I'd pick something that has OpenAPI as a first class citizen or code generation, including validation.
For a website, it'd be Go + HTML/CSS (sprinkling JS where needed). Here's why: (1) Code will "just build" years later (2) Deployment is stupidly easy -- just build to a single binary with all resources embedded (3) Everything about the stack is stable and easy to reason about. Though perhaps not exciting.
For a "web app", I feel there are no great options. The half life of the JS ecosystem is about 5 minutes, so whatever you start with will be out of fashion shortly after. React has had some staying power, though isn't without its flaws. I generally feel like most "web apps" could actually be websites though.
Another recent project I did in mostly pure Java, with only a third-party library for SMTP email sending, and a library for using HTML templates.
IDE is VSCode with clangd as linter, and gcc as compiler, and CMake as build system. For Java, I use the RedHat VSCode plugin.
Frontend in pure TypeScript, with an icon library.
Challenges I encountered: - Statically checking data structures between frontend and backend. This needs code generation. And there was a lot of code repetition for shared data structures between front- and backend. - More database abstraction would be good.
Other than that it all runs great.
It’s not the .NET Framework you might remember from the 2000’s.
Backend: AWS Appsync (or AWS API Gateway) integrated with AWS Lambdas written in Golang. Authentication through AWS Cognito. DB: anything serverless from AWS (Dynamodb, Aurora etc.)
This way the app would be 100% serverless, no need for effort to scale it or to maintain the infrastructure (apart from automating the ifrastructure through AWS CDK).
But I believe that, in the early days, Drupal made excellent foundational design choices as a framework, and if you used it's APIs in your custom module development, then, generally speaking, you would have a secure website.
But now, D7 is approaching EOL, and I absolutely don't want to migrate to the latest flavor. D7 has been rock solid for a decade, and I have no desire to chase the latest fad.
I wish that there were a stable, monolithic solution that is simpler to setup (as in including everything, including database, webserver, SSL certs, etc.) that just worked and was extendable and overridable programmatically, in the same way that Drupal was.
Modern web stacks have become a bucket of Lego pieces that seems ok if you are an expert in everything and know how to put everything together exactly. The problem is, most people aren't experts in form handling, login and authentication, media handling, caching, etc.
if the passion is to learn some new tech then well, there are lots of options, i'd pick something that i haven't worked with yet.
if it is something where the passion is in the content, i would use the same old stack that i used for my last few projects. in my case that is aurelia+custom backend which is a reusable object storage and user management platform, where i didn't need to add any project specific features for some time now.
if i could not use that backend, i would pick something that makes it easy to manage objects through a REST API.
if i had to evaluate a new framework then the main thing that i would look for is the ability to minimize or avoid any dependency on build tools.
unfortunately, with the rapid evolution in frontend frameworks there is also a rapid evolution in build tools. that just adds extra effort to maintain a site for more than a few years.
without buildtools getting in the way i can maintain a site with minimal effort, and i know it will still be running in a decade from now.
Functional programming, pattern matching, and immutability make life a lot easier.
It's all built in, you can buy packages that implement most SaaS features out of the box, authentication, 2 factor, all the crap you need is rolled in as packages.
I would stick with something like Orchid for admin type CRUD apps as there is ZERO html/js knowledge required.
for a public app - I would still use Orchid on the backend and then on the frontend use something simple with blade templates and controllers.
PHP is a lot better than it was, Laravel developers are easy to find, the stack is very well understood, and it's flexible enough to build whatever you want.
EDIT: I just wanted to add 99% of "apps" are not retail facing but are internal apps or business to business type apps that solve a specific business niche. For that, I only care about how fast and easy is it to stand up and implement that specific business logic.
It's simplicity has been a fresh of breath air. I love Go and being able to use it for almost the entire web app is amazing. I am excited for the upcoming router enhancements Go has proposed, that will let me move off Chi router. I try to stay as close to the std lib as possible. Though, the `templ` package is amazing and I very much will continue to use it when possible.
For my database I use `libsql` by Turso with server mode.
As for deployment, I just dockerize the app and the database then run them as two separate components in a Docker App.
Makes it a simple and easy to develop and deploy updates.
SvelteKit is the best combination of front-and-backend in terms of performance and developer usability that I've found.
If I was trying to learn something new, I'd experiment with solid.js or htmx.
For anything new, I'd try Phoenix to see what I can achieve with Elixir and a non-React/Vue frontend.
Choice of stack is simple: it may not be the best in class or fancy choice, but it’s close enough, allows simple infrastructure setup, quick start with rapid iterations and easy to go from 1 dev setup to a team. More importantly I have a lot of experience with this stack, so I can focus on business rather than on learning new technology.
Depending on the frontend need, I might go with straight server rendering static pages. So often the big stack of rendering contexts and HOCs and blah blah blah just gets in the way. Rendering a view shouldn’t be difficult, and progressive enhancement is easier starting from strict HTML + well structured CSS.
I love React, I’d be happy to try Svelte… my fear in not doing that would be “when we eventually need it, it’s difficult to opt in progressively” (which is terrible).
Which of those depends on whether the focus of the passion was exploration of new tech to make an impact on my understanding of tech or exploitation of existing tech to make an impact on the world.
If it was the former, today I'd probably learn Rust + whatever webapp stack is popular in that language. Seems to make some pretty interesting guarantees around programming and is blazing fast.
If it was the latter, I'd pick rails. Nothing in my experience beats rails for productivity for a bog standard webapp.
Go backend. Single binary. Big performance. I’d use Go for as many things as possible until I actually had a need for distinct technologies (queues, redis, etc.). Throw embedded db into the mix and you shouldn’t have any problems for a long time.
React UI on cloudflare pages. Free. Easy.
Postgres. Single node goes far. Great plug n play extensions. Same as with Go I can push this pretty far until there is some serious requirement to do something else.
Deploy on either cheap bare metal or an affordable provider like DO.
- Backend: Django (Postgres in production) + Celery to handle async tasks - Frontend: HTML (standard django renderer), CSS, HTMX + occasional jQuery - Deployment: Render
I was already familiar with Python and I feel the language is more than capable to handle the data processing required and with Django I could concentrate on the actual app functionality without diving too much into auth etc
For me it would be:
*Django* for backend with the built-in templates. No frontend backend split.
TailwindCSS for styling.
StimulusJS for sprinkling JS wherever needed, which is not very often.
Postgres as my DB (although if I'm not integrating Stripe, SQLite will suffice).
Maybe Redis for caching and as a broker for background tasks, if needed.
Of course SQLite has limits but it takes a lot of complexity or concurrent users to come close to them.
If it was a big corporate with deep pockets then I'll (or they'll force me to) go with React, Angular etc.
Frontend: Lit and Tailwind (in reality, unocss, a tailwind runtime that doesn't need build)
Database: indexeddb + some CRDT
Backend: no backend, webrtc to sync between devices without a central server
Hosting: Github and cloudflare cache, the app has a functionality to deploy itself, generating a minified tailwind CSS and if needed, a "SSR" version of it (but without hydration, this is the part of the frontend craziness that I don't wanna get close).
I’ve built several projects like this and just started another one and it is by far my favorite stack.
I don’t like spending time fighting frameworks, so I like to keep my stack as minimal as possible. Thankfully the Go ecosystem pretty uniformly shares that ideology.
Seems super simple to get up and running and let's you focus on the product itself rather than the stack.
Alternative answer: Use whatever you're most familiar/comfortable with.
https://github.com/refinedev/refine
It has built-in integrations for UI libraries and data providers. You can select your stack
I keep changing my mind. Part of me wants to use old school tech. But I do like the DX of Next.
NextJS tends to make sites that need JS on the front end. And probably bigger bundles than an old school MVC job. I will take that hit though for some of the positives of working in React and productivity and modernness and community of great work around React.
I think I might use Bootstrap but I'd heavily customize theming.
Probably SvelteKit or Vue for the frontend. Most likely SvelteKit.
SQLite or a flat file database for sure.
I think what I would do is use Tornado to serve SvelteKit pages, if I went with Python.
Definitely a monorepo for front and back end. Probably I'd try to do zero server side templating.
I’m planning to try out HTMX + a backend written either in Rust or Go. Since it’s a passion project it doesn’t necessarily need to be out there for thousands of users, so I’ll go with SQLite.
- HTML
- JS (Ecma Script, not some "framework")
- CSS (not "Typescript" or whatever, standard CSS)
For backend I'd use PHP. Yes, PHP.Edit: The same would apply for $job
(Typescript, tRPC, Tailwinds
Next.js React, Prisma, Zod
Bun)
Client and server in one project and language. All the trendy, still free, easier to use compute instances let you deploy javascript server projects. Many don't support other stacks like Java or Python. Heroku supports python but no longer has a free tier.
Also, this stack is free if using vercel + supabase until you reach an BIG userbase
Backend: ASP.NET Web API (REST). Only calling these APIs from the backend-for-frontend Node code.
Hosting: Everything at one Cloud provider, either Azure or AWS. No SaaS-services.
Database: Postgres
Infra: Terraform or Bicep for infratructure as code, and Docker.
Would prefer go on the backend but language switching when doing frontend at the same time is a bit of a pain.
Backend: Golang standard lib, gorilla/mux for routing Front: htmx + tailwind
If i need a database, i tend to start with redis, then sqlite and ONLY if it scale, postgres!!
Also tried Remix for a few smaller projects - didnt really fly but was quick to develop.
Fastify has been game changer for me.
Flask / HTMX / Pico.css / Postgres or Sqlite
Dockerized so that it's easy to spin up.
Edit: Caddy for webserver.
- infra on AWS via AWS CDK TypeScript
- backend domain plain TypeScript
- frontend plain React, no framework (TSX)
- database RDS Aurora serverless v2 (Postgres)
- monorepo using pnpm
Choosing a stack has always been a balance between "what you are currently productive in" and "the best possible tool for the job."
These days, assuming you have a base level of skill and experience, it's like 2-10x easier to get up to speed in a brand new stack thanks to those AI coding buddies
Your current competencies still matter and always will, but today, IMO we're way more free to choose the "best" tool and assume that we can get up to speed quickly.
Putting that aside, I still think Rails is amazing for "most" webby stuff. Would consider Flask if I needed things from the Python ecosystem. Or I guess Phoenix if I needed that massive concurrency. Would pair them with Postgres and/or Redis as needed.
For frontend... Vue? Or maybe just server-side rendering if I could get away with it.
Most of what you need to get something functional and not totally ugly, not a lot that you don’t.
Accessible Powerful cost Effective
relative to your audience and available resources.
I would pick flutter / istio / booternetes / helm
Probably Laravel with Livewire and Lit for creating interactive widgets. Postgres for the db.
Tomorrow: Who knows.
Frontend: Flutter
If Flutter is not possible or suitable than htmx + bulma (or w3c, pico etc..).
- SSR SvelteKit with Hydration (https://github.com/sveltejs/kit)
- PostgreSQL database server
- Postgres.js - PostgreSQL client for Node.js (https://github.com/porsager/postgres)
- Migration powered by graphile-migrate (https://github.com/graphile/migrate)
- PostgreSQL Row-Level Security (https://www.postgresql.org/docs/16/ddl-rowsecurity.html)
- svelte-headlessui (https://github.com/rgossiaux/svelte-headlessui)
- sveltekit-i18n (https://github.com/sveltekit-i18n/lib)
- TailwindCSS (https://tailwindcss.com/)
- Superforms (https://superforms.rocks/)
- sveltekit-flash-message + svelte-french-toast (https://github.com/ciscoheat/sveltekit-flash-message + https://github.com/kbrgl/svelte-french-toast)
Tooling :
- asdf (https://asdf-vm.com/)
- Docker and Docker Compose
- NodeJS
- pnpm
- Jest for unittest
All deployed on a VM at Scaleway (https://www.scaleway.com/en/) with Bash script (https://github.com/stephane-klein/sveltekit-tendaro-webshell...)
After 3 months of development on this stack, I'm very satisfied. My application is fast, light and requires very little code.
Project skeleton example: https://github.com/stephane-klein/sveltekit-tendaro-webshell...
FE - Typescript, React, Tailwind
DB - Postgres
Cache - Memcached
Server/Routing - Envoy
- Either vanilla js or vue.
In a while, s/node/bun
Go on the server is fine as well.
Plain SQL with Postgres
React