Trying To Fix The Web Dev: Part 1, The Issue.
Some of us remember the "old" days when web development was simple.
PHP, two types of forms, and some jQuery for the magic to happen (AJAX hit like using ChatGPT the first time).
And it was pretty reliable too, despite everybody managing servers themselves (I still do btw, using vim).
React.js Happened.
Angular happened first, but I skipped that.
So, React felt like a new era was coming – now you could write and embed highly interactive mini-apps.
Of course, that was possible before, but React enforced component architecture with props propagation and manageable component state – back then, I (20 y.o., 70% PHP monkey, 30% jQuery enjoyer) could not even think about something like this, and it gave me superpowers.
BTW, I think micro apps with little to no back-end interaction are the perfect use case for front-end frameworks. Perhaps because that was what they were actually designed for, or maybe because I don't fully understand the world.
Nowadays.
Oh boy. I am CTO and co-owner of an international hardware development + production company (DH + EMS).
How I got there – different story. But what’s important: I’ve built many things with my teams.
From an Electron-based manufacturing control & automation system, to light show drone firmware with a custom UDP swarm control protocol (I wrote the core myself in Rust – I [spoiler] was a bad manager), to actual hardware.
I even had my own JDSL, which powered [spoiler] server-driven production operator terminals — so you could deploy new workstations just by describing the execution process in JSON. It was so bad and somehow surprisingly awesome.
BUT every freaking time I had to deal with the web during this career period, it caused me pain.
The Issue.
I don't want to yell about JS and its ecosystem. Everybody’s already doing that.
I think there is something much fundamental:
Business logic has migrated to the browser.
Take a look:
Ok, for real:
It would be ignorant to claim the old approach fits the modern web. Sites built like that often feel outdated, lack features and the UX sucks.
Why is Business Logic In the Browser an Issue?
You probably already felt that something was wrong. Here are my anti-highlights:
#1 Huge Deal: Front-end dictates API access.
The data you need to read or write conditionally depends on business logic, and so it is reflected in the UI flow.
That means you have to reflect the UI flow in API access schemas, which operate in a completely different dimension.
Such a unified control schema cannot exist.
That’s arguable. And I can object to myself here, often, just role-based is good enough. Ok, role-based with some extra configurable properties. Ok, role-based with some properties and runtime conditions. Ok, with a bunch of architectural nightmare code – 100% doable.
For straightforward logic applications, that’s not a big deal.
However, if you’re entering the B2B space with control panels, a bit of business process automation (not to mention ERP), it's going to be rough.
Or follow the vibe™ and don’t care. Rely on Elusive Joe security strategy and expose your whole db.
Boring: 84% reported experiencing at least one API‑related security incident in the past year
#2 Opinion: Thick Client.
This largely depends on your industry and the complexity of your app's functionality.
Building the complex logic of your service on top of a million lines of JS dependencies to be executed in the browser doesn't feel right.
JavaScript is the best language in the world. Or how else do you explain that something made for SCRIPTING now powers the web?
But seriously. It's genius, just the application seems narrower.
I think that too much freedom in approaching deeper-than-surface-level tasks is not good (why I love Rust). JS/TS provides hallucination-level abstraction tooling.
#3 Reality: Teams synchronization and higher button cost.
That depends on the size of your team or company. I worked in small to medium-sized companies, where adding basic functionality is usually a low-cost operation.
However, I’m hearing stories from my corporate friends all the time about how their work and releases are blocked by multi-level endpoint approval processes (reason #1) and teams syncing (everybody has their priorities).
Anyway, with the growth, an increase in feature cost is unavoidable.
But that makes the fact that you need to do the same thing in two different projections (app and API) even more frustrating.
It’s Just Skill Issues.
Maybe. And I am an impostor.
So don’t subscribe and miss Part 2: The Solution (it's going to be technical)
Top comments (13)
Think I got you point (or at least I hope so)...
Imho that tendency, spreading business logic (BL), isn't "only" bound to the web.
| Business logic has migrated to the browser.
Nah... seen this quite often, that some BL is moving into the frontend... in every language.
Or I also remember encountering APEX (or any other DB-bound framework.. never to mind VBA and MSAccess) to create applications, which are tending to smearing the BL all over the different parts of the application, i.e. Database, Front-End and so on...
... and, after some time (or very soon) are hell to maintain.
Due stepping into that same trap, I'm facing the issue, how to identify and seperate the different parts. And also trying to convince developers, not to put everything into one place or the exact opposite.
To avoid that, every now and then, I try to step back from my current projects and inspect, if there's an "all-purpose allrounder" emerging (in german, there's the idiom de.wikipedia.org/wiki/Eierlegende_...).
Long story short... JavaScript Is Not The Issue... damn, you already wrote that :D
It could be I made one) Check out part 3!
Sorry, I'm not understanding what you are saying here. By "reflect the UI flow in the API access schema", what do you mean? That the API should be built with the frontend in mind? I know a lot of REST style APIs like to be frontend agnostic, at least many hope to be. They have a goal of being usable by web, iOS, Android frontends and focus on exposing fundamental data and operations that the clients can use where/how necessary.
Also, you say the problem is "Business logic has migrated to the browser," but it's always been in the browser for us web viewers, it's only a Javascript problem if we choose to build it that way. A complex multi-step UI flow is complex if it's built as a SPA or good-old PHP style. Personally I think the testing/deployment/maintance concerns are better handled in a good-old PHP style backend-heavy approach, but that can only reduce complexity so much.
Finally, questions, thanks!
If your API is not just a database wrapper, it is built with the front-end in mind.
But in either way, API access control must be done with business logic in mind (who and when should be able to read and write what, not "the clients can use where/how necessary").
That's what is behind the BFF trend - API cannot be abstracted anyway, so why bother?
I don't think so. With the "classic" approach, the browser acts just as a human I/O, and the server makes decisions.
Overall, I agree that complex things are... complex. However, technology can either support you along that path or become an obstacle. The old-style implementation of stateful logic carries much more hassle.
I don't understand the issues...
Front end only dictate access to front end views. Authorization for any action is still on the server
Opinion is not an argument....Devices have gotten really powerful so more javascript is not an issue
Organizational problems are still present even if everything is backend oriented
AI has impacted web dev the most, allowing quick iterations and neglecting hardware limitations. And the trade off is usually well worth it. By the time efficiency becomes a problem you already have a somewhat usable product that can finance the devs needed for refactoring.
Great article though!
Views also require authorization. As I stated in the article, that's not a big deal for apps with simple business logic; however, access context can be complicated, and it's common (B2B, BPA systems, control panels, customer portals).
Article titled "javascript is not the issue") However, in general, the argument that devices are now so powerful that we can care less about performance doesn't resonate with me. With better hardware, people should have even better UX.
That's arguable. I think product success, especially in competitive areas, depends highly on quality. If you're low on resources, it's better to have something small that works. Additionally, from my experience, an already good code base can be refactored, while a bad one can only be redesigned, which is costly and often avoided by businesses until it fires and burns.
Thanks for the reading and commenting.
BTW, just a fun story. I recently discovered that the Gmail web app consumes nearly 0.5 GB of RAM. How did we get here? And it's not a record.
Perhaps you are ready for Juris :-)
How does it solve The Issue?
Thank you for your question Alex.
Juris fix the web dev, because, the dev relies interely in Javascript and does not need any other tooling based and NodesJS.
No VDOM, JSX, no hooks, no effects...
Juris is totally fine grained reactive, dependency Injection , battle tested.
It has all the advantage of hyped frameworks without thier complexity.
You only need Notepad on your are done :-)
Joke apart : Look carefully at the official site, examples.
All examples are completed contained in a single HTML page . Look at them it is awesome.
It is a real shift in web development.
I have created the Dev To account, to post mainly about Juris, I really believe in it.
The author of Juris has already build and app for ST MicroElectronics
Regards
Okay, but how does it solve The Issue I stated in the article?
Btw, writing code in Notepad isn't great.
I missed the point then, sorry...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.