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 form...
For further actions, you may consider blocking this person and/or reporting abuse
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...