I've been a software engineer for a very long time (pre-JavaScript existing).
I highly doubt it. I am working on a greenfield project and we are on Angular 17 for the front-end and C# for the REST APIs, backed by a relational SQL database. It is smooth sailing.
I am not familiar with those frameworks outside of what Next.js is doing with React (combining server and client code).
I don't like it, at all. I've spent decades working with what is now being called "SSR", but that's literally how everything was done.
So many developers got into software engineering knowing only JavaScript and usually a bit about a framework, generally React. Then we got Node.js so we could have JavaScript on the server, then Express.js so JavaScript can serve JavaScript, then NoSQL so you can store JavaScript objects in a database (essentially a KV store) without needing to learn SQL.
Now we have JavaScript that mixes front-end and back-end together.
I have 22 years of C# development. It works, it's easy, and it's fast. The "split" between front-end and back-end is perfectly fine to me.
I've used C# for decades at this point, but only every had a day job that used it once. I don't know why so many startups drive right past the dotnet ecosystem for some cthulian JavaScript thing.
I sure wish I could return to dotnet professionally!
I don't think so. I just think right now Vercel is very good at marketing and lots of new programmers and hopping on the NextJS train. There are tons of materials out there for building apps quickly and it's very appealing for newer developers, particularly the bits where getting a site deployed is as easy as running a couple commands w/ the Vercel CLI.
For larger applications, I don't see meta-frameworks eating up a significant chunk of the world since they're very expensive to run in certain situations. Especially so if you use the default deployment options and rely entirely on serverless functions for your infrastructure or a database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale, just in the same way that people carve up their Rails applications of yore.
I generally think that the meta-framework obsession will also help propel backend SSR + HTMX, since thinking in server-side components is easier to translate to traditional backend SSR than SPA -> backend.
> database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale
(Supabase maintainer) Supabase is just postgres, so it’s actually designed like this. You can start using all the “auto generated” tooling, then evolve into a pure Postgres + middleware solution if you need/want to
> they're very expensive to run in certain situations.
In terms of pricing, it’s ~equivalent to RDS, at least the database component
Aren't some people also - at least trying - to move in the opposite with pure javascript, Petite Vue, Alpine etc. because of framework and tooling fatigue?
The thing that will kill JS frameworks is a vast contraction of software jobs from all these layoffs. Frameworks are desirable when developers are either rare or challenging to identify, but once that’s gone people who cannot develop without frameworks are less valuable than those who can develop in any environment.
Developers are a cost center. What matters is what costs less to build, deploy, maintain, and hire for the employer.
The larger the framework, and the more abstractions it attempts to cover, the more likely you will hit a wall where the framework makes it difficult or even impossible to solve the task at hand. The further I have gone into my career, the more I prefer a minimal framework + internal libraries which solve the needs of the company/team/project etc.
Im no good at predictions but an obvious question for me is how many applications based on these networks are in the wild and successful?
Basically, how well have these frameworks scaled?
Ruby on Rails is a highly successful framework but successful applications based on it would usually be rewritten after reaching a certain size because of scaling/performance/cost issues.
Why are these considered meta frameworks instead of just frameworks? These are just webservers, we had them for years and Rails is a framework, not a meta framework.
By logic, a meta framework should be used to write frameworks and not applicative code
I highly doubt it. I am working on a greenfield project and we are on Angular 17 for the front-end and C# for the REST APIs, backed by a relational SQL database. It is smooth sailing.
I am not familiar with those frameworks outside of what Next.js is doing with React (combining server and client code).
I don't like it, at all. I've spent decades working with what is now being called "SSR", but that's literally how everything was done.
So many developers got into software engineering knowing only JavaScript and usually a bit about a framework, generally React. Then we got Node.js so we could have JavaScript on the server, then Express.js so JavaScript can serve JavaScript, then NoSQL so you can store JavaScript objects in a database (essentially a KV store) without needing to learn SQL.
Now we have JavaScript that mixes front-end and back-end together.
I have 22 years of C# development. It works, it's easy, and it's fast. The "split" between front-end and back-end is perfectly fine to me.