It's definitely not easy by any definition. And also not happening accidentally. Almost all frameworks/libraries mention about how small they are in overhead.

* declaring JSON (or similar format, but why reinvent the wheel) variables

* rendering the values of these variables

* interacting with the variables with controls (inputs, check boxes, selects, etc)

* conditional rendering based on those variables

* iteration over them

* submitting a form as a JSON object

* saving a JSON response from the server into a variable

* re-rendering the effects of a variable change without a full page reload

I think a major reason for why we ended up here[2] is because browsers did not add these features to HTML and thus devs resorted to AJAX and small JS snippets at first and then kept expanding the use of JS.

[1] as a Java dev who used to do front-end before the ascendance of client side SPA frameworks I'm thinking of JSP, JSF, Thymeleaf, etc. Maybe the client side stuff used nowadays is similar, I'm just not familiar with it.

[2] being forced to run a turing-complete programming language just to display a fully static document, leaving one exposed to security risks (yes, the browser guys are doing a much better job sandboxing than Flash, Java Applets, etc) and tracking.

Split the Web? On the server side? Or the client side?

Splitting the server seems unnecessary - since servers already let you serve as simple a site as you like. If you want to make simple sites with no javascript you are welcome to do that.

So split the client? Have one app to read some sites and another to read some other sites? That sounds contrarian to literally every program evolution in history. Because all client software strives to read all relevant formats (think Word loading WordPerfect files.) why would a user choose 2 separate apps when 1 would do?

It seems to me that the author misses the point that sites are javascript heavy not because they have to be, but because their makers want them to be (largely so they can make money)

Integration points: Everyone sends their version to Person A, and they integrate it, filter it, postprocess it, extracts parts into another sheet, etc.

Caching: Everyone has their own version of the excel sheet in their local inbox.

Redundant: There's typically plenty of shared directories on which you can find the same excel sheet in different versions.

The overarching concept of No Code/ Low Code is that "code" is the hard part of building software, ergo if we can make it so "normal" people don't have to code the problem is solved. Of course we all know that code isn't the hard part of the job- if code was the issue software developers would all be using No Code/ Low Code solutions already (as it's been pointed out, they've been around forever).

No Code/ Low Code is about selling accessibility to the wantrepreneur crowd... the same people that have an "app idea" that they want you to build. It's a huge market, but it isn't going to have an impact on software development any more than model rockets would have on the aerospace industry.

If the No Code/ Low Code tools were any good software developers would already be using them.

(When I am talking about No Code/ Low code, I am not talking about things like Webflow / Dreamweaver NOT solutions like Serverless.)