First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face.
If we then take your argument and instead just apply it to, say, using JS on the backend.. well, JS is not going anywhere any time soon.
pl/pgsql is absolutely awful and it is a disservice to other programming languages to call it a programming language. Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) is just going to make every single person who has to maintain this in the future hate your guts.
I'm truly glad I don't have to work with anyone who genuinely thinks such a design would be a good idea.
> First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face.
the comment makes sense if one interprets "frontend" as "all the shit in front of the database". which is a reasonable interpretation in the context of something like postgrest, if not perhaps satisfying to you.
> pl/pgsql is absolutely awful
who cares
> Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea)
there are a number of other languages available for writing postgresql procedures, and you can add new ones
How long has Postgres been around? How long has your currently fashionable front-end framework been around?
I avoid triggers but put as much of my applications into stored procedures as I can.