Shortly after Jesse James Garrett invented the term, "AJAX," web pages began to cease to be "pages" and began a slow and painful evolution to becoming "applications." Problems quickly developed on both the "host side," where the HTML and AJAX content was produced and processed, and on the "client side," where [usually ...] JavaScript code was written for the user's web browser. On both sides, there slowly appeared an insidious problem: "bafflling complexity."
Host Side:
On the host side, source-interpreted languages such as Perl, Python, Ruby, and PHP quickly became dominant – but none of them ever displaced the others nor even attempted to do so. Larger organizations sometimes used compiled languages such as Java. Microsoft advanced its "dot-net framework" as a solution.
Source-interpreted languages have proved to be a very interesting (and, costly and intractable ...) problem for a number of reasons. "The programming that is actually being executed" consists of source(!) code, yet "the programming language which is 'doing the executing'" has not remained the same. Almost every subsequent incarnation of the PHP language, in particular, has proved to be – in some very-important way or another – incompatible with prior versions of itself.
This same exact problem is endlessly multiplied by the fact that "the programming that is actually being executed" consists, not only of the programming that the hired programmers have written, but vast amounts of additional, so-called "package" programming that is also constantly changing.
In a "truly compiled" language, the entirety of the source-code that affects the system is, in one step, reduced to a set of pure-binary instructions which is the one and only thing which actually affects the future operation of the system. Therefore, "the system" remains stable, at the chosen "release point," no matter what subsequently happens to the [many layers of ...] underlying source code. However, none of this intrinsic stability exists in any of the present arrangements. "Disrupting influences" can – and certainly do – occur at any time.
Client Side:
On the client side, meanwhile, the problems began innocently enough: Microsoft Internet Explorer (IE). It was introduced as a built-in part of the Windows operating system, and Microsoft pushed very hard to use its enormous market presence to make its web-browser succeed at the expense of all others. It introduced, and patented, a number of features that no other browser had, although many of these were just different ways to do what other browsers were already doing. Soon, five or six incompatible browsers were duking it out, none of them exactly compatible with the others. The IE browser went through several releases, several of them notoriously buggy and once again not fully backward compatible with their own prior versions.
Client-side programmers, quite of necessity, began to write and use JavaScript software libraries to shield themselves from these incessant compatibility issues. The idea was that the author of the library would undertake to figure out how each browser and browser-version did things, and to reliably detect which one the user was running. They would then provide a common set of library calls that would work more-or-less identically on all of them. It was from this innocent and relatively-compact beginning that client-side frameworks took root and grew ... and grew ... and grew and grew and grew and grew and grew. Until it is now quite commonplace for a library to consist of so many megabytes of (compressed) JavaScript source-code, and to have so many features, that a separate "build system" is now used to prepare them for use with a particular project. There are now more than fifty such libraries in use – often, several at the same time on a single site – and of course none of them are compatible with the others.
The "HTML" markup language upon which all web-sites are based also underwent enormous and sometimes incompatible expansion. HTML version 5 introduced, for example, a high-resolution graphics capability with tools for JavaScript-based manipulation. Sound input and output, geo-location, and many other features that one might expect only in a programming language also wound up in the spec. There must be a kitchen sink in there someplace.
As the client-side burden continued to grow larger, web sites also became slower. The JavaScript language has many very-dynamic features that can also make runtime interpretation of the language very sluggish. Intrepid browser designers began to try to counter this with "just-in time compiler" features, where the browser literally constructs a machine-language program to replace a particular segment of JavaScript code, then attempts to determine when it can run that segment instead.
Obviously, "other alternatives exist, and have existed." In fact, Adobe Flash® was one of the very first, and for many years its approach was dominant. Flash consisted of – and still does – a runtime plugin which directly executed binary code that was produced by a separate, true, language compiler. Unfortunately for Adobe, their strategy has since been vilified, although there is actually no particular reason for it. Microsoft's "dot-net" client-side implementation, dubbed Silverlight®, is certainly no different in principle. Neither is another concept called "WASM."
Conclusion: "Where Might We Go From Here?"
The "conclusion" of this particular article is, admittedly, just speculation. But I really do believe that we are approaching a point where we must finally "re-examine first principles." What are we actually attempting to do here, and is this "baffling complexity" actually the best and most cost-effective way to do it? If our final goal is to "sell a product," or "present a catalog," or "accomplish a particular well-defined [external or internal] business task," are we really justified in indulging in this amount of "gratuitous technical complexity," particularly when we have basically exposed ourselves to the consequences of the [arbitrary ...] decisions that might be made by parties who are entirely external to ourselves?
"I don't think so." And I frankly expect my colleagues to begin to return to this realization. Whether we are speaking of "an end-user experience" or the "SOAP and AJAX calls" that [today ...] underlie those experiences, we have today strayed impossibly far from any "plausible realm of business control" that we can reasonably justify to our business stakeholders. We are today expecting them to indulge us in far more business risk than they properly must take, and the symptoms of these failures can today be seen everywhere.