ASP.NET (C#) has migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/m...

> For example having database migrations built in etc.

I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate

Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).

It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

So in my case, I can have:

  * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
  * a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more
  * a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server

Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!

Yeah exactly. All that boilerplate stuff is such a pain to write or maintain long term.

Migrations are easy to do in literally every framework in any language