My current side project is using python aiohttp and htmx. The main plus of Python is that it has a lot of machine learning functionality but the truth is almost all of that is used in batch jobs and if I did anything computationally intensive serving a page I would have to farm the work out to another process. I have no trouble maintaining Python I write but it seems to always fall apart like Jenna blocks when I hand it off to somebody else.
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.
Rails. It's all about developer comfort. ruby as a language is a delight to work with. Rails as a framework has all the features I need and then some more. Postgres as the database of course!
This depends on your goal: Are you trying to build + finish a project, or learn a new skill? I like to separate these goals, or otherwise try to scope projects very narrowly.
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.
It would depend whether the web app is a "dynamic website" or a "super interactive app that happens to run in a browser".
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.
I might be the only one in here with an answer like this, but PowerShell and the Pode framework. I am super productive with it, as much so as in any other language, and it plays nice with the rest of my stack (Tailwind, HTMX, SQLite.) I can leverage the .NET framework and C# libraries when I need to and can iterate quickly. All of this runs on the latest version of Ubuntu LTS. Obviously, this won’t work for everyone but for my purposes I haven’t been able to beat it and it makes me happy.
I wish, but right now it is all internal company stuff. I'd like to build something publicly accessible with it someday though so maybe I'll do a Show HN if I have something worth releasing.
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 surprised that Java and modern C++ are not more popular. I know for large web applications, Java is popular in "enterprise" environments.
Java scales both up (Spring Boot, with it's many integrations) and down (Dropwizard, a bunch of popular packages, nice for simpler projects) pretty well, has a great runtime and the language itself is okay.
Also there's .NET, where everything seems to revolve more around ASP.NET and EF, but as a consequence feels less fragmented than things on the Java side. Performance is also nice (especially on Linux with Kestrel) and the tooling is nice.
Honestly, both seem a viable option for something with more typing and language guarantees, as well as on average having a bit better performance than some of the highly dynamic languages (at the expense of iteration speed early on in development).
That said, Go is probably also worth a look, the deployment situation there is way simpler.
It's been a hot minute since I was looking for PHP developers, but when I did, I saw a ton of folks with Wordpress experience. And not many others who had experience with traditional three tier applications, how to write a database query, separation of concerns and general software development.
Maybe I was looking in the wrong places.
Do you find that software engineers who work in PHP are prevalent?
I recently attended Longhorn PHP and found plenty of PHP software engineers (in the true sense of that word) so maybe I was looking in the wrong places previously?
Elixir/Phoenix + Postgresql. Maximum comfort, minimum chore.
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
Just had been thinking about this today, the current state of web development is making me seriously depressed.
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.
The discussion is making me scared from another perspective.
I have experience with a pretty wide variety of development. I've worked with embedded microcontrollers (minimalistic RTOS), embedded applications (on top of a proper Linux), desktop applications in Java and in C#, some C++ work, gamedev and more. But to this day I haven't touched Web apps. I have not written a line of JS and the closest I've done to modern web is a tiny API in Go that sends a JSON response and renders a static HTML page.
With my total lack of Web experience (and self-confessed hate of webapps as a user), I have no opinions on React, Rails, Node.js, Vue and whatever people are naming here. But I'm taken aback at the variety - there's 20-odd replies all giving different answers.
Does Web development in 2023 not have 2-3 tech stacks that dominate? Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems? Is there a high rate of change because things keep improving? If so, where is that improvement for me as a user, when webapps still feel inferior to late 90s native programs?
I'm in the same situation as you, but have what I think be an incredibly unpopular theory on why all those competing technologies exist: Everyone is trying to unsuccessfully patch JavaScript.
Every few years, a group thinks they're the ones with the one true ring, and try again.
Each new shiny seems to promote even poorer practices than the last, lowering both the bar and the barrier of entry further.
I don't think that is an unpopular view. Though I think it is more fair to say people are trying to patch the browser runtime environment and its APIs. JavaScript the language is "fine", it is that doing things the way the browser wants you to do them is often quite verbose, so people build layers of abstraction on top.
Unfortunately these abstraction layers end up being just as, if not more complex than what it is building on top of.
People creating frameworks can work a lot faster than the browser development teams. The modern browser stack is actually getting pretty good, but still some things like creating web components are awkward compared to many of the popular frameworks. And when people find something awkward to do, especially in as flexible a setup as JS, they will make their own abstractions.
My suggestion for anyone feeling overwhelmed by the JS ecosystem is to just work with plain ol' vanilla JS for a while. It'll give you a much better understanding of what is actually going on and you'll likely realize the problems you're trying to solve are pretty straightforward. But you'll also see that things can end up quite verbose (though the comprehensibility will likely be quite high). You'll find that there are some areas that are kind of annoying and this is where when you go back to one of the frameworks you'll see its value (but also likely where it is totally overkill). At the end of the day if you can keep your mindset focused on the browser runtime rather than the specific framework you happen to be using, you'll have a much better time. At least that is my experience.
I was in the same situation as you, and then I tried it a few years ago.
I realized that front end software is actually pretty shallow.
Design is important, deep, and requires talking to users, but once you have a design it is pretty straightforward to get the pixels into your favorite JavaScript/React/Vue/CSS/etc code base. Importantly, design is not about the code. Designers work in tools like Figma, not react.
Web frontend applications will then need to call into a backend. If you are doing anything computationally heavy or complex you are back in the world of normal software development.
I think this is why you see more full stack than frontend engineers.
If you are worried about it, I’d suggest trying a project. If it looks like crap, you probably need to get help from a designer or learn design, not figure out which web stack to use.
My 2 cents: keep working with Go. Learn just enough about templates to start, JSON to struct mapping and URL routing. It's not a great backend, but the client is what you really need to learn. For the client look through browser tools F12. For the basics of HTML, CSS and JavaScript skim through https://www.w3schools.com/ [People HATE this site but it has very limited info, making it a quick read.] For actual documentation use MDN https://developer.mozilla.org/ and skip any framework/library until you have the basics.
> Does Web development in 2023 not have 2-3 tech stacks that dominate?
no
> Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems?
The existing frameworks are fine. Most languages have just 1 or 2 frameworks for you to build in that language.
The problem child for all of this is the JavaScript ecosystem. A lot of developers in that space just keep proliferating a bunch of heavy-handed frameworks that do not accomplish anything new, but represent some opinionated take on architecture, tooling, etc., and which obfuscate everything behind layers of magic and indirection.
> Is there a high rate of change because things keep improving?
For the most part, I wouldn't say things are "improving" that much. I mean, React and Vue and Svelte are better for front-end development than what came before, for sure, but, speaking at least re: React, it's become a bit of a monstrosity. Pluses and minuses, I suppose.
Again, the problem is mostly in JS land. They are a little like the stereotype of Java devs, in some ways.
Web dev frameworks are like pizzas: everyone has their favorite toppings and styles, some are more popular than others, and others are sometimes loathed (pineapple), but it generally all comes down to cheese, dough, sauce at the end of the day.
It's the inner child of developers. They feel the need/urge to show the world they can do it better than existing bloated thing. And they show it, and people jump on the shiny new train. Rinse and repeat. The problem is, those that could really make a dent are not present in this space :P.
There is a high rate of change because the big frameworks solve the wrong problems, massage over a catastrophic knowledge/skills gap, and do less than what is needed while imposing an unavoidable, yet unnecessary, tremendous cost/size.
If developers could execute with confidence in the browser understanding the compile target, the DOM, we wouldn’t be in this mess. But, most developers are scared shitless of tree models and/or writing any form of original code. That is not a technology problem. It’s a people problem.
I have just launched a relatively straightforward webapp that required a light touch front end with fairly significant data processing on the backend
- 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
Django + HTMX + SQLite or PostgreSQL
Hosted on a virtual machine.
... 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.
I feel like I want to like htmx, and the concepts sound cool. But json is such a nice generic serialization format. Like my API can be in service of my frontend, but also other applications. While, unless I misunderstand it, htmx seems to philosophically believe the backend is the frontend.
Are there any patterns where you have an API with nice json payloads but also use htmx to push the rendering to backend? What do you do when you have users that just want basic data from the API? Do you add json endpoints, or is it more of a “fuck you learn how to accept html” situation?
You can have both a hypermedia API and a data (JSON) API. Your hypermedia API is a lot more lightweight and flexible as it's tied to your web app. The HTMX authors talk about that topic in their book: https://hypermedia.systems/json-data-apis/
"These two different types of APIs have different strengths and needs, so it makes sense to use both. The hypermedia approach can be used for your web application, allowing you to specialize the API for the “shape” of your application. The Data API approach can be used for other, non-hypermedia clients like mobile, integration partners, etc.
Note that by splitting these two APIs apart, you reduce the pressure to constantly change a general Data API to address application needs. Your Data API can focus on remaining stable and reliable, rather than requiring a new version with every added feature."
Depends on business scope, growth model etc. My default option is Java/Spring Boot/PostgreSQL for BE with HATEOAS API, Typescript/Angular SPA for FE if personalized experience is required. If it’s about just serving some almost static webpages, then some SSG+headless CMS with a bit of vanilla.js.
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.
You mention it's a passion project. If technology is the center of that passion, then pick what you're passionate or curious about!
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.
213 comments
[ 2.3 ms ] story [ 282 ms ] threadIf 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.
Turbo gives regular server rendered pages the snappiness of an SPA with zero dev effort.
The latest Hotwire allows easy replacement or lazy loading of any portion of a page.
All while preserving 10x developer efficiency. There’s simply no other stack with similar productivity.
(Not the original poster but came to this thread with “Rails” as the answer)
Hotwire is backend agnostic. Laravel has adopted it as a front end solution too.
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.
just give me a simple VPS
Most of what you need to get something functional and not totally ugly, not a lot that you don’t.
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.
Probably Laravel with Livewire and Lit for creating interactive widgets. Postgres for the db.
Functional programming, pattern matching, and immutability make life a lot easier.
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.
FreeBSD
Nginx
PostgreSQL
PHP/Python
Or, for something a bit less mainstream and only for certain types of application but more minimalist:
FNRL
FreeBSD
Nginx
Redis
Lua
I'm surprised that Java and modern C++ are not more popular. I know for large web applications, Java is popular in "enterprise" environments.
Java scales both up (Spring Boot, with it's many integrations) and down (Dropwizard, a bunch of popular packages, nice for simpler projects) pretty well, has a great runtime and the language itself is okay.
Also there's .NET, where everything seems to revolve more around ASP.NET and EF, but as a consequence feels less fragmented than things on the Java side. Performance is also nice (especially on Linux with Kestrel) and the tooling is nice.
Honestly, both seem a viable option for something with more typing and language guarantees, as well as on average having a bit better performance than some of the highly dynamic languages (at the expense of iteration speed early on in development).
That said, Go is probably also worth a look, the deployment situation there is way simpler.
It's been a hot minute since I was looking for PHP developers, but when I did, I saw a ton of folks with Wordpress experience. And not many others who had experience with traditional three tier applications, how to write a database query, separation of concerns and general software development.
Maybe I was looking in the wrong places.
Do you find that software engineers who work in PHP are prevalent?
https://longhornphp.com/
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
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.
I have experience with a pretty wide variety of development. I've worked with embedded microcontrollers (minimalistic RTOS), embedded applications (on top of a proper Linux), desktop applications in Java and in C#, some C++ work, gamedev and more. But to this day I haven't touched Web apps. I have not written a line of JS and the closest I've done to modern web is a tiny API in Go that sends a JSON response and renders a static HTML page.
With my total lack of Web experience (and self-confessed hate of webapps as a user), I have no opinions on React, Rails, Node.js, Vue and whatever people are naming here. But I'm taken aback at the variety - there's 20-odd replies all giving different answers.
Does Web development in 2023 not have 2-3 tech stacks that dominate? Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems? Is there a high rate of change because things keep improving? If so, where is that improvement for me as a user, when webapps still feel inferior to late 90s native programs?
Every few years, a group thinks they're the ones with the one true ring, and try again.
Each new shiny seems to promote even poorer practices than the last, lowering both the bar and the barrier of entry further.
Unfortunately these abstraction layers end up being just as, if not more complex than what it is building on top of.
People creating frameworks can work a lot faster than the browser development teams. The modern browser stack is actually getting pretty good, but still some things like creating web components are awkward compared to many of the popular frameworks. And when people find something awkward to do, especially in as flexible a setup as JS, they will make their own abstractions.
My suggestion for anyone feeling overwhelmed by the JS ecosystem is to just work with plain ol' vanilla JS for a while. It'll give you a much better understanding of what is actually going on and you'll likely realize the problems you're trying to solve are pretty straightforward. But you'll also see that things can end up quite verbose (though the comprehensibility will likely be quite high). You'll find that there are some areas that are kind of annoying and this is where when you go back to one of the frameworks you'll see its value (but also likely where it is totally overkill). At the end of the day if you can keep your mindset focused on the browser runtime rather than the specific framework you happen to be using, you'll have a much better time. At least that is my experience.
I realized that front end software is actually pretty shallow.
Design is important, deep, and requires talking to users, but once you have a design it is pretty straightforward to get the pixels into your favorite JavaScript/React/Vue/CSS/etc code base. Importantly, design is not about the code. Designers work in tools like Figma, not react.
Web frontend applications will then need to call into a backend. If you are doing anything computationally heavy or complex you are back in the world of normal software development.
I think this is why you see more full stack than frontend engineers.
If you are worried about it, I’d suggest trying a project. If it looks like crap, you probably need to get help from a designer or learn design, not figure out which web stack to use.
no
> Are the existing frameworks/techs so lacking that new ones keep appearing to address those problems?
The existing frameworks are fine. Most languages have just 1 or 2 frameworks for you to build in that language.
The problem child for all of this is the JavaScript ecosystem. A lot of developers in that space just keep proliferating a bunch of heavy-handed frameworks that do not accomplish anything new, but represent some opinionated take on architecture, tooling, etc., and which obfuscate everything behind layers of magic and indirection.
> Is there a high rate of change because things keep improving?
For the most part, I wouldn't say things are "improving" that much. I mean, React and Vue and Svelte are better for front-end development than what came before, for sure, but, speaking at least re: React, it's become a bit of a monstrosity. Pluses and minuses, I suppose.
Again, the problem is mostly in JS land. They are a little like the stereotype of Java devs, in some ways.
If developers could execute with confidence in the browser understanding the compile target, the DOM, we wouldn’t be in this mess. But, most developers are scared shitless of tree models and/or writing any form of original code. That is not a technology problem. It’s a people problem.
Those are things people do not need unless at an appropriate scale, or appropriate use-case, etc.
- 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
... 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.
Are there any patterns where you have an API with nice json payloads but also use htmx to push the rendering to backend? What do you do when you have users that just want basic data from the API? Do you add json endpoints, or is it more of a “fuck you learn how to accept html” situation?
"These two different types of APIs have different strengths and needs, so it makes sense to use both. The hypermedia approach can be used for your web application, allowing you to specialize the API for the “shape” of your application. The Data API approach can be used for other, non-hypermedia clients like mobile, integration partners, etc.
Note that by splitting these two APIs apart, you reduce the pressure to constantly change a general Data API to address application needs. Your Data API can focus on remaining stable and reliable, rather than requiring a new version with every added feature."
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.
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.
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'd probably start with Render for rails hosting these days. Seems to be the best heroku descendant.