There's been a lot of discussion in the web space lately on what a full-stack framework actually is.
On one side there's the "traditional" full-stack frameworks like Laravel (PHP), Ruby on Rails (Ruby) and Django (Python). These frameworks come with batteries included, and an opinionated way to manage your database, render templates with SSR using a built-in templating language and much more. I'd say they started with a focus on the heavy backend stuff, and have had many years to grow and mature.
Then there's the alternative approach, where you use a JS-based framework like NextJS or NuxtJS to build your entire application. These frameworks have started the other way around, with a focus on the UI and then added more and more support for doing serverside work. This includes stuff like API routes and server components, which are basically different ways to run code on the server so you can access your DB and perform other serverside tasks.
This is how I like to think about the different approaches all of these frameworks are coming from:
The SSR frameworks started from the backend and got really good at all of that. Theyβve then later embraced tools like InertiaJS to allow rich client-side interactivity with JavaScript. Frameworks like Next and Remix instead started from the frontend, like how we can build high fidelity web apps with awesome UX first - and then started worrying about solutions to authentication and databases afterward.
Both obviously have their own advantages and disadvantages. Tools like Laravel and Rails are more feature complete, and generally adhere to certain design patterns within the framework. This means that almost every Laravel or Rails app will seem familiar - making it easier for devs to jump between projects. It also makes it easier to build stuff as a single developer because you donβt have to make a lot of decisions on the βboringβ stuff (like setting up authentication and your basic database structure) because the framework has already made those for you.
On the other hand, frameworks like Next or Nuxt or Remix come with fewer βbatteries includedβ. They allow you to run code on the server (making them technically βfull-stackβ), but they donβt have an opinion on which database you choose, how you communicate with it, what you do about authentication or how you send out emails. This can be a good thing, because the developer is free to select the tools that he or she most enjoy working with and that solve their individual problems the best. But it also means thereβs a lot more variety, and two different Next apps can look vastly different.
Being a front-end developer myself, I love how easy it is to build really good UIβs with JavaScript using tools like React and Vue. But I also see a lot of value in starting with something like Rails or Laravel if your goal is to ship a fully functioning product as soon as possible. Because thatβs where the opinionated approach really shines and enable developers to build cool stuff much faster.
I donβt really have a solid conclusion to leave you with, other than that you should absolutely, 100% of the time pick the tool you most prefer and that solve your problems most effectively. Thereβs not a βrightβ or βwrongβ choice in this debate - at least once you understand where both sides are coming from.
Though Iβm personally super excited to see how the JS-based metaframeworks continue to evolve and tackle the remaining set of problems in order to build great full-stack experiences. It does feel like Next, Nuxt, Remix etc. are just getting started, and theyβve obviously had way less time to mature than their Rails or Laravel counterparts. So if youβre coming at it from that side and enjoy these tools, I think the future looks very bright.
And if youβre curious to learn more, this podcast episode features the creators of Laravel and Remix and is a great listen to really understand the nuance and where these different frameworks are coming from: