3 ms·
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
by moritzwarhier 4y ago
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.