> no separation between backend and frontend folks in the company.

This is the biggest gain available anywhere.

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. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML).

I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.

> 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.

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea.

When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.

I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.

Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.

Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.

I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.

Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.

I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all.

In a way, it is exactly the example opposite of what you mention.

> The BE / FE split has been a really bad experiment.

What do you mean - "full stack" is very popular and frankly produces some of this weird unmaintainable code. Hiring backend-y type people and making them develop UI (with state especially) is where half these companies realize "crap we need a front end developer"..

I’m sure you can find horrible code bases in any arrangement. I will say that a good team will tend to be better for more projects than two good teams (fe/be). There certainly are cases where a split will make sense and be much better, but I have seen it become the default when one team should be.

This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity

Delete the API, render your html on the server, problem solved.

If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.

I think you mean exacerbated

I get really exacerbated when people make this mistake.

It's not an experiment though. The divide is clear, you have a client application, and then server applications that the client talks to. This is even more true if you want a lot of interactivity. This line isn't going away anytime soon. There will always be an application that runs on the edge device or machine, and it needs to talk to some other application to store and retrieve data.

The secret is to make the thing that runs on the backend the application, and the thing that runs on the edge device the user interface.

It just depends on the use case. The "interface" could be complicated enough that it needs a full blown application with state. I would say that's the typical expectation today from users.

No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.

You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.

I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!

Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.

Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.

Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).

This was true in the lodash and jquery as essential days, but hasn't been the case for years.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> hasn't been the case for years

For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago.

- https://en.wikipedia.org/wiki/ECMAScript_version_history#6th...

It truly did improve the JS landscape by an order of magnitude.

For those unfamiliar with the extensive features this brought to JS, here is a good list:

- https://rse.github.io/es6-features/

ES6 modules make it straightforward to reform great piles of unstructured JS hackery into hierarchical dependency-controlled units for which you can actually reliably draw a block diagram. Hmm, or maybe get Claude to draw it for you ...

Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.

Yeah, those were two big sticking points.

There's also Object.groupBy() now which was another thing I always missed from the standard library.

Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals

Worth noting that those features were indeed added after the creation of e.g. React, but both have been widely available for ~10 years now.

No regular frontend needs any of that. Serde support, that's a ridiculous requirement for painting some web boxes on a display.

Plus, as the other comment noted, the basic JS types go a long way now.

You don't need javascript at all to render.

Oh for a version of the WWW that never allowed javascript at all.... money destroys absolutely everything it touches.

Alright, I've been in the industry a very long time but moved to backend when it got complex. I am wondering why you need a decent hash map or set implementation. This is supposed to be done on the backend. The frontend is for presentation. Your backend should not give you elements with duplicates (why you don't need set). "Decent hash map" sounds like you just don't like the hash map implementation because you are trying to do something complex with the Map implementation, in which case it belongs on the backend.

Yea people should just learn Elixir/Phoenix and forget about all their npm js issues...

It's amazing what CSS can do these days.

I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.

So you're just jumping on the backend treadmill.

Yeah, agreed - but I do think using vue, react, whatever on certain pages really has its benefits. Sometimes a UI really is improved by using features that Vue makes really easy to implement.

Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?

I agree 100%, but "JavaScript only when needed" is a loaded phrase. Especially when you don't have an engineering-centric culture.

Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.