Web development didn't change much. If you can get http requests and then generate responses easily, you're ready to make money.

LAMP, Django, RoR, ExpressJS are all good choices.

Just use what you already know.

I have started to use lambda for serving an API backend and VueJS for the frontend.

Although there's a lack of nice frameworks, Lambda is great, being incredibly cheap and almost no scaling worries.

However for me developing a SPA front end is far more complex and problematic than in the Django days.

The question is why are you building it? - If you care about getting project off the ground, then you can use this link: (https://mcfunley.com/choose-boring-technology-slides) - If you care about learning new framework or language or keeping up with industry, there are plenty of articles around. Just yesterday I watched a video called "My Bleeding Edge Tech Stack for 2025" from Fireship. Might be a good start if you are in to frontend

Stick to what you know, unless you have some very specific requirements that means it would be impossible not to.

Django has the Django Rest Framework that makes the API setup fairly easy to work with.

Django is still good and simple.

Second this

Cloudflare workers and Durable Objects for backend. Svelte for frontend.

What is missing from Django that you feel it didn’t evolve much?

If you prefer code that is backend-first, self-hosted and keeps JS in the frontend to a minimum, I'd recommend something like Laravel + Alpine.js, especially in MVP-like scenarios. This approach is still somewhat scalable.

Laravel is just a popular choice with an easy learning curve and comprehensive features. Of course, there are plenty of alternatives.

More modular, more enterprisy, still PHP: Symfony

If you don't like Alpine and are comfortable writing Vanilla JS, you could also write your JS without any framework whatsoever, or use different libraries.

You would probably still bundle your frontend code. Laravel provides a nice simplified abstraction on top of Webpack called "Laravel Mix", which makes this extra easy.

If you prefer a JS-first approach, I'd recommend next.js. The complexity might be overwhelming at first if you're not comfortable with full-stack JS.

It might also be overkill for some types of pages (no interactivity without page-reload, no or few external services involved).

Using next.js would mean to use a Node-based frontend web server, except when you limit yourself to Static Site Generation.

It also means that stuff like routing lives in JS code.

This does not mean you can't self-host and use an SQL database. But it means that the code that talks to your database, serves your internal API, generates server-rendered HTML etc is written in Node and/or in JS.

Then there's the fuzzy "JAM-Stack" term. In contrast to next.js (there's certainly some overlap) this means that your backend code mostly lives in external services.

For example, you would use an external "headless CMS" to serve content via an API and a separate frontend server serving the HTML, JS and CSS.

The frontend code could be fully static (with the client JS rendering HTML based on API responses), or it could be a Node server pre-rendering pages based on server-side requests to the API.

The latter version is again something that frameworks like next.js provide.

The contrast between SSG, server-rendered dynamic content and client-side rendering is not black-and-white, it's a spectrum and the approaches can mix on one user-facing page.

Next.js makes it relatively easy to combine all these forms of content rendering in one page.

If you'd like to focus on the backend but still don't want to use PHP or Python, you should probably look at stuff by Microsoft, but I don't have any experience there.

Blazor might be a great fit for enterprise web-apps in a NET setting.