Huh? Nothing about using SSR means designers have to write SQL. I think you have some inaccurate assumptions about what SSR has to look like, or how it can be layered. MVC was a thing for a long time, and still is in various forms.

>Huh? Nothing about using SSR means designers have to write SQL.

I said front end devs, not designers. And that is literally called out as a specific proposed benefit in the article.

The article calls out access to features of SQL data stores — not writing SQL itself. In practice, that means developers need to learn how to use an ORM; most common operations are pretty well abstracted.

Sorry, but I'd rather do front end dev on static HTML and CSS any day than deal with the self-abuse treadmill of frontend JS.

And I don't know what to tell you, absolutely no one is advocating for JSP style SQL-inlined-in-HTML or something.

>Expecting frontend devs to write efficient SQL queries

This just isn't a problem for most modern stacks. You're using an ORM and not writing SQL which isn't any harder than GraphQL or Rest endpoints.

And, for better or worse, there's not that much need to write efficient SQL because servers are so fast these days. The target you need to hit is something like "one of my filter conditions has an index" and things will usually be fine.

Why in the world would I want to split a team in two highly coupled halves that can't deliver any value by themselves? Division of labor? Seriously? Are we back to the 18th century?