To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, 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.
OR just embed the RDBMS into your application!
https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
If anything, this is arguably one of the more structured ways you could go about attacking the problem of a complex web product.
Plain JS loses much to plain Typescript though, to my mind.
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/
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.
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.
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.
* 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.
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.
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.
In a way, it is exactly the example opposite of what you mention.
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 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.
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.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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
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:
Plus, as the other comment noted, the basic JS types go a long way now.
Oh for a version of the WWW that never allowed javascript at all.... money destroys absolutely everything it touches.
Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?