> I think the end game is doing SSR of web content inside the RDBMS

OR just embed the RDBMS into your application!

SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack.

https://www.sqlite.org/appfunc.html

It's also very easy to do in Rust.

https://github.com/rusqlite/rusqlite/blob/master/examples/lo...

Does writing HTML into database entries count? Because certain large entertainment companies are ahead of the curve if so.

This is just compiling and caching right?

No, this is hand-writing HTML into SQL database rows for conditional rendering. I think it stems from a culture of remarkable IP protectiveness. Take your guesses at which company I am referencing.

I am struggling with why the practice of storing HTML partials in SQL is necessarily bad.

If anything, this is arguably one of the more structured ways you could go about attacking the problem of a complex web product.

Because you shouldn't repeat yourself. If you're going to store your content that way, it should be as agnostic as possible, so that when the inevitable redesign comes around, you're not stuck rewriting every single line of that database, like I was.

Plain HTML and plain CSS (well, maybe with SASS) are pretty great.

Plain JS loses much to plain Typescript though, to my mind.

It's not too difficult to use the TypeScript type checker on JS files, so it's possible to reap most of those benefits without having to introduce a compilation step.

In my experience, most of the benefits of Typescript come from type-checking across call boundaries, the point where type-related bugs are most likely to be introduced due to each side of the call often being in different locations and contexts. And you can't get those benefits without explicitly typing function parameters.

If you really don't want the compilation step; you can use JSDoc and get almost the best of both worlds (not everything in TS is supported by JSDoc but most essentials are)

Is there a way to use typescript without pulling in all of npm? That’s the deal breaker for me, maybe others as well.

Yes. E.g. bun [1] consumes typescript directly.

The current canonical TS compiler and language server are both written in JS/TS and run on Node (even though there's an ongoing effort for rewriting things in Go). They are relatively compact though; IIRC installing the Rust compiler or the Haskell compiler takes more space.

[1]: https://bun.sh/

The odds that that person will also understand or care about normalization, let alone the performance characteristics of their RDBMS and how their schema decisions affect it, are close to zero.

I’ve spent enough time watching devs have access to the DB that I know it’s a dead end. For a group that loves to talk about DSA, you’d think a B+tree would be second nature, and yet…

Full Stack is a lie, as is DevOps. We need to return to highly specialized roles. You want a new view? Submit your proposal to the DB team. They shot you down with a list of reasons why? Go learn everything they complained about; next time, the list won’t be so long.

> When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS.

A million times yes!

> I think the end game is doing SSR of web content inside the RDBMS

That feels like one step too far for me. I think things like authorization and HTML rendering belong in a separate layer.

But I do believe that more than 90% of today's "server side code" actually belongs in the RDBMS, and I blame the weakness of SQL as the reason no one wants to do this.

> I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX)

At my workplace our IT department uses APEX a lot for all kind of internal LOB apps. It works great as long as it supports what you need.

Ah yes. That is brilliant until it isn't. For any reasonably complex business problem you will run into:

* Performance issues: table scans, high memory usage for joins, crazy sql execution plans, lock contention

* Security problems: especially around authorisation. Who can see what data. You'll start to need rules engines written as stored procedure or some shit.

* Business logic: can a SQL work out the country city, state and federal tax for the address? Maybe it can. Maybe that query will grind the system to a halt. Maybe you'll slap redis and 1000 sql replications. Maybe you are no longer just doing SQL!

Yeah fortunately for all of us shit is complicated and needs bespoke thinking to solve each problem.

There are problems where your ideas work well (typically consumer facing startup types who can rewrite when they raise a bit more money).

If that is how you do things I know the conversations you'll be having next year already. And that is from just ORM abuse not even front end SQL.

I tried to use Firebase in earnest which is the ultimate in that approach and it is awful. You hit a bunch of new and worse problems because you don't want anything to do with an EC2.