Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What web development stack do you prefer in 2024?
31 points by jadler999 10 months ago | hide | past | favorite | 47 comments
Curious to hear what those starting new projects/startups are choosing for web application tooling and frameworks. This is meant to be an informal survey of the HN community for their web development preferences.

On the front end side of things, I feel that React is not the default framework as Svelte and HTMX are everywhere (or maybe I am reading too much Twitter). On the backend side, I think it is a bit more open and has to vary from project to project based on specific needs but would love to hear what you are using and why anyway.

For many, I realize the answer may be to use the tools you are most comfortable with but wanted to ask just to see.




Yes it’s the echo chamber of the promotion funnels that makes it appear as if everyone were jumping ship every few days.

In my bubble, Angular and React are the primary frontend frameworks, with Vue sometimes being ahead and sometimes behind either. Virtually no one uses Svelte in my circles., but most folks have heard of it or have applied it in their side projects. HTMX is even more niche, still up for discovery for most folks, don’t know it well enough to comment. I prefer Vue and Angular DX but I favor React component libraries, it’s complicated. My absolute favorite is PureScript with React.

In most cases, backend is Spring on Java for well-defined or rather systematically approached applications, and Python or TypeScript for something that can run on AWS Lambdas and a junior dev might become responsible for. I think .NET is a no less decent choice for that matter. Go for rather small applications that need to touch on layers beneath the application layer, not the best choice to express complex business logic. I personally just pick the JVM stack with Kotlin and Spring, and deploy to AWS.

Rust is too unstable for long-term maintenance but deserves to be respected, I try to push Rust (though I’ve spent most of my time in C++) for smoother collaboration and simpler code review—there’s little I ever need to check after the Rust compiler—mostly the business logic and some axioms, in addition this raises the bar for quality contributions. Having to deal with low-key merges after the fact, sometimes even circumventing CI, is not pleasant at all.

Therefore, having the source of QA truth in the compiler is a boon to my productivity, hope it manages to obviate even more test suites, lifting more of the business logic into the type system, the way you can do it in Haskell or, even more powerful, Idris, but that’s a bit off-topic. Yet that’s what I choose if I need correctness.


I doubt many advocates for htmx (or Hotwire) believe React is being abandoned right now. However, they do represent a serious challenge, because they’re not just marginally faster or more ergonomic like, say, Preact or Svelte - they represent a complete paradigm shift from how we’ve been building Web apps for the past ~decade. Being able to have over 80% of the interactivity you can get with React while expending perhaps 20% of the effort (no build step, no client-side data modeling and routing, no client-side state, easier for server-side oriented devs, use a language you’re already proficient in, reduced cognitive load, etc.) is huge.

Many pioneering technologies are initially met with skepticism. A decade or so ago, jQuery was the clearly dominant client-side library. Very early adopters of React and its siblings were swimming against the tide, but eventually they made jQuery much less relevant.

I’m not saying htmx will definitely become what React is today, but the belief that a dominant technology or paradigm is safe from disruption has been repeatedly proven wrong.


Great take. My project's tech stack is React on the frontend (without Next) and C# on the backend. For me this strikes the right balance of simplicity, performance, productivity and longevity.


I’m gonna be a hipster by saying I was using Htmx (and its predecessor intercooler) before it was cool. I really wouldn’t think of specifically using Htmx to build your app. You use server side template rendering and then you sprinkle htmx on top to make it a bit nicer.

My preferred stack is server rendered go. I’ve traditionally used pongo2 for templates since they are nicer than standard go templates imo. But I’ll be trying out templ on my next project.

But whether you use go, Django, rails, laravel, whatever, if you’re doing traditional server rendering rather than the SPA or modern “full stack” framework, you’ll have a better time. And this is coming from someone who actually likes using SPA frameworks for interactivity. But managing client and server side state is so much more complex.


I am currently learning golang and HTMX. Do you have maybe some good example projects that a newbie like me can take a look at, which implements best practices?

Any advice for potential pitfalls?


I’m building out my server-side with Django while reading up on htmx. I haven’t started with actual UI interactions, but htmx is what I plan to use.

For more context, I’m essentially revisiting an app I built from 2015-2017, before I became employed in the industry. I built it with Django and Ember. Long story short, Django upgrades nicely, while anything requiring Node that was built that long ago is “lost in time, like tears in rain…”

Yes, I’m resentful. And yes, I hope I never have to touch Node/NPM again.

Some other great options are Elixir/Phoenix/LiveView (I used it at my most recent job, and loved it) and Ruby/Rails/Hotwire. Hotwire is not coupled tightly with Rails, but using it with Rails would be the path of least resistance.

Personally, I went back to Django for reasons including:

- Data modeling and migrations with Django’s ORM are top-notch.

- Auth and admin which come out of the box are key for getting to an MVP quickly.

- I find Django’s template language more intuitive and more elegant than erb and EEx/HEEx.

- Python is still king in the data world, so it’s easy to integrate with mature DS/ML/AI libraries.

- If I need to find talent, Python devs are everywhere.


What made your old Node code not work? I've picked up old node projects from up to 10 years ago and they all still work just fine, so I'm unclear what pain you encountered?


If you use the same Node version and NPM dependencies it could work, but trying to get the project upgraded to use a modern version of Node and mitigate vulnerabilities was a nightmare and I just abandoned the effort.

I get emails from Github with long lists of vulnerabilities on old toy projects where literally __zero__ dependencies are listed in package.json. It’s not so much the vulnerabilities that bother me, but the dependency conflicts, and in general a massive amount of infrastructure I have to buy into without even knowing it.


Anything serious or has actual customers should use established technologies imo.

Who cares if it’s not the latest some hipster is pushing on Twitter? Most of the time these people aren’t even serious (in what they’re doing).

Focus on solving your customers problems.

For hobbies it’s free for all. Do whatever you like. It’s fine to be emotionally tied to some library or obscure thing. It’s for fun after all.

For anything serious, it’s good to be serious.

Maybe the trendiest thing will become that some day but don’t tank your own business in the process. Remember that Meta invested heavily in react not for fun but because they are a serious multi billion dollar business (key word).


https://jstreb.hgreer.com is my lastest fun project, and it's seriously just javascript. Originally it depended on math.js for matrix operations but I ripped out that dependency and wrote my own linear algebra code for about a 20x performance boost.

For actual work, I've got one in sqlite / flask / htmx, and another in tensorflowjs + react + tanstack + firebase. I'm having opinions about the latter- a recent meeting started with me putting the url for the home page into a browser and then counting out loud until enough of the serverless stuff spun up for the interface to load. I got to 24, which was past "making my point" into "awkward"


For the last three years I have used only Go with vanilla HTML (templates/html from the standard library), CSS and JS.

For a database, I have been using PostgreSQL.


Nice! I love the simplicity. Going to build some side projects this year with this stack.


Are you able to share the types of applications you've built?


I have built three SaaS products using this stack. The services are mainly B2B, but one of them has a fairly large B2C-ish user base (recruiting teams). Everything I've built has been profitable and cost of running is very low.


That's awesome, thanks for sharing. I'd love to work on projects like yours, they are hard to find!


After test drive countless of frameworks...I've settled for a very boring stack

Ruby on rails is the only framework I use for SaaS applications.

Plain ES6 for a lot of things that are not as big as a SaaS. React when I need frontend stuff.

Python lives mostly in notebooks for all my thinkering.


I can provide somewhat unorthodox answer for 2024.

I am currently working on a solo project and EXTRA prioritizing for time to MVP. In the past I already delivered one project with React and I found it very unpleasant to debug with my backend even if surprisingly useful for handling complex dynamic behavior in UI. I decided that MVP might as well be as vanilla at it can get considering that I am building very much backend-data driven application.

Python + Flask for backend. vanilla HTML + vanilla Javascript for little of the dynamic behavior that I need now on frontend. after MVP I'll most likely transfer to React because there's a limit where it will become pointless to write JS scripts by hand.


I don't understand the downvotes to this comment.


Vanilla HTML, CSS, JS (no need to compile/transpile/etc.)

Golang (I only need to upload a binary to my server and done)

Postgres/MySQL/SQlite

Docker and/or binaries.


I think Next.js with Node.js for backend will be the go to stack for 2024 in Web Development.


Have you played around with Bun at all?


Most my personal and side-business projects have very spiky load or just low load in general. Because of that I love using AWS Lambda as my backend since it scales to 0 and scales to whatever you have your limits set at.

I use SST [0] for my backend with NodeJS (TypeScript) and Vue (Quasar) for my frontend. For my database I use either Postgres or DynamoDB if the fit is right (Single Table Design is really neat). For Postgres I like Neon [1] though their recent pricing changes make it less appealing.

[0] https://sst.dev

[1] https://neon.tech


How do you feel about $0 vs $20 for e.g. a VPS that just sits idle? Is the complexity of AWS worth it for $20/mo?


> Is the complexity of AWS worth it for $20/mo?

For some of my projects it is, for others it wouldn't matter but I like keeping my AWS skills sharp since I use them professionally as well. There have been many times that I've had a solution at my fingertips for my job because I had previously played around with something on AWS for a personal project. I see it as a sort of "continuing education".

I also just dislike managing servers, call me whatever you want for feeling that way but I'd rather spend my time writing code and not worrying as much about patching/upgrading my servers. I know there are downsides to using Lambda, I've hit almost all of them, but I still prefer it over managing a server.


Next.js - https://nextjs.org/

React framework - 20 million NPM downloads a month ()

https://moiva.io/?npm=next


Working with various data, ML, and researcher-type engineers there's a bit benefit to using Python. Especially if you want to be at the forefront of what's being built.

I've been building with Python FastAPI and a React/Nextjs app. I've gone back and forth on whether we should have used Django, but we've been full steam ahead with what we have.

If I wasn't building in the AI space I think I probably would have used Node <-> React with tRPC to make the typed full stack monorepo experience seamless.

Oh and Postgres - I'm irrationally loyal to Postgres


Astro SSR with React components when in need (rarely). A joy to iterate upon since you don't have to worry about coordination between the frontend and backend. Easy to dockerize and deploy wherever you want (I'm looking at you Next!). Never been more productive in my life. https://astro.build/


> I feel that React is not the default framework

It doesn't really matter from a technical standpoint, you can build the same UI with any framework (or none). React is still a good default choice if you want to rely on the ecosystem or if you are planning on working with other people. There are lots of devs using react daily at work. Svelte may have twitter-appeal, but not very many big companies are using it.


Core vitals:

Vanilla JS

CSS

HTML

--------

Frameworks:

HTMX[0]

Tailwind CSS[1]

Cash[2]

--------

Backend:

PHP

NodeJS

--------

For quick mockups & landing pages:

Webflow[3]

Carrd[4]

--------

Also some no-code SaaS solutions for dealing with tricky stuff like forms

[0] https://htmx.org/

[1] https://tailwindcss.com/

[2] https://kenwheeler.github.io/cash/

[3] https://webflow.com/

[4] https://carrd.co/


Recently I re-wrote my personal homepage (which was previously written in Vue.js) and the homepage for my discord bot in PHP (w/ smarty, and some CSS copied from Bootstrap).

For one of my other projects, my discord bot dashboard (which uses MongoDB and lots of boilerplate stuff for interacting with MongoDB), I'm using ASP.NET Core and Boostrap. It does the job, and it does it quite well.


Django + HTMX + old-fashioned CSS (no framework - sometimes SASS, sometimes not). Hosted on Heroku if I don't want to faff about.

For a couple of projects where it seems justified, Svelte (with a Django backend).

Plenty of experience over the last decade has me very wary of too many JS dependencies (revisiting anything older than a couple of years has invariably been a nightmare).


For front-end vanilla HTML, CSS and JavaScript. HTML is SSR, unless an AJAX call would obviously improve UX. For back-end I don't really care as long as it's not one of those CMS frameworks that caters to the non-developer.


At work I use vanilla HTML, CSS and Javascript for the frontend. For the backend I use node.

For personal projects I sometimes use the same stack, however in some occasions I have used Sveltekit.


I'm planning two side project apps this year using Dart/Flutter with an SQLite DB for local storage/backend. I like the ability for this to run on any platform.


Frontend: Whatever I'm using at work. Backend: Rust with Sqlite. It's simple, but with the amenities of a higher-level language, it's performant and the compiler has my back.


PHP (Symfony) on the backend. I just can't get used to Node and I don't like Python for web development.

I don't do frontend anymore but when I do it's pure JS and Bootstrap/Tailwind.


Java + Spring Boot + MySQL in the backend. With OpenAPI to define the API structure and generate as much code as possible.

TypeScript + React in the frontend.


In the process of establishing HTMX, Alpine, Tailwind at work since the 6 year old React SPA is impossible to upgrade.


It doesn't matter because all tech stacks do the same thing. The only difference is how they organize code.


ASP.NET Core + HotChocolate GraphQL for backend, blazor for internal tools frontend, and react for web frontend


I use vanilla js with tailwind for the frontend. Currently building on top of Cloudflare Pages and MySQL.


Varies, but most commonly:

Django, Postgres, React, Docker, Heroku, AWS S3 for static frontend deployment.


front end? preact if it's complicated enough to need it, vanilla js otherwise.

Actually, a few months back I started doing something in react, then i asked myself why, then I replaced it with .net/aspx and no javascript.


Rails and Turbo - the lazy dev’s path to success.


Whatever we use @ work, I don't code on personal time


React and Node here.


Honestly, I'm tired of big sites. I like simple, clean HTML + CSS websites. And I write them myself. JAMstack.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: