I guess my question is in the sea of options of today, what do you use, what actually save you time and complexity on your project?
I guess my question is in the sea of options of today, what do you use, what actually save you time and complexity on your project?
9 comments
LAMP, Django, RoR, ExpressJS are all good choices.
Just use what you already know.
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.
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.