The Folly of Front-End Frameworks

An Analogy

⊕A folly in the style of a Tuscan temple.

Geni, CC BY-SA 4.0, via Wikimedia Commons

In architecture, a folly is a building constructed primarily for decoration, but suggesting through its appearance some other purpose, or of such extravagant appearance that it transcends the range of usual garden buildings.

Some JavaScript frameworks, like React or Vue, require a significant amount of work to maintain an application. I'm not saying that these frameworks are bad; I am saying that they are overkill for many use cases. They are extravagant.

The First Browser

⊕The first HTML/HTTP only supported GET.

HTTP started as a way to share static text documents that contain hyperlinks to other text documents. The protocol originally had support for one method: GET. With only one method, a session consists of connecting to an HTTP server, issuing a GET and displaying the returned HTML.If the HTML contains images, GETs are performed for each image, and the returned images are included in the displayed document. If the HTML contains a hyperlink, clicking on the link repeats the GET/display cycle.

This simple use case: sharing text documents that contain hyperlinks to other text documents was the original goal of HTTP. No forms. No authentication. No REST. No fancy frameworks. A read-only web of publicly available documents.

Adding Some Interaction

⊕HTTP quickly added support for HEAD and POST as well as adding HTTP headers to the request process.

When HTML returns POST data from a FORM it sends each of the FORM's INPUT fields in a url-encoded shape that looks something like:

first_name=Bob&last_name=Chase...

HTTP 1.0 added support for a status line (and status codes, eg. 200, 404, 500, etc), headers (and the HEAD method) as well as POST. The POST method allows the browser to send data to the HTTP serverAnd just like that, the read only web was gone. instead of just getting data. HTML evolved to support forms which can POST data back to the server.

Code in the Browser

⊕Both Java and JavaScript appeared as solutions to adding logic to the browser, making the client programmable. JavaScript (including Microsoft's TypeScript). prevailed as the language of choice in the browser, with Java eventually dropping support for Applets.

Meanwhile, HTTP continued to gain more methods and to add features like pipelining and chunked encoding.

Scripting was added as a way to allow code to be loaded and run in the browser. The code is able to manipulate the HTML and initiate network calls that aren't necessarily tied to a FORM element or a hyperlink.

The Script and the Document

⊕A JavaScript framework manages the construction of the HTML document to be displayed. Some frameworks manipulate a copy of the document—called a virtual DOM—which then is used to update the actual document that the browser displays. There are good reasons for all of this indirection, but none of it comes for free.

Having code in the browser allowed for the development of JavaScript Frameworks, some of which run the entire browser experience with code. Instead of receiving a complete HTML document from the HTTP server, the browser uses code to construct (or manipulate) a document on-the-fly. This sounds cool—and it is—but it adds significant complexity to the creation of a front-end application.

JSON Over the Wire

⊕A JSON API server on the right and a view/controller on the left.

This pattern is another in a long line of RPC implementations—seemingly emerging by accident as JSON over REST over HTTP (over TCP over IP).

If the browser and the server aren't exchanging HTML documents and POST data, what are they exchanging? The answer is almost always structured data in the form of JSON—a serialized JavaScript object.

In concept this is fantastic: the HTTP server is now a data service which is concerned with exchanging semantically relevant data that is devoid of display information—devoid of HTML. The code in the browser takes the data and figures out how to display it based on needs of the application. This allows the server's endpoints to be reused by different applications or different versions of the same application.

This is a beautiful separation of concerns.

What Really Happens

⊕The separation between the API and the browser-based view code becomes blurred.

It is common to find that the HTTP server and the JavaScript in the browser are surprisingly interdependent. In other words: it is not a beautiful separation of concerns. Things are entangled.

Why is this common?

As is often the case, the cause is not technological but human. Software is developed in iterations.Agile methodologies are an explicit expression of this, but even a big-bang approach to software delivery will eventually be fixed or improved upon with follow-on (iterative) releases. Each iteration is focused on a small part of the application; hence, the iteration produces a solution that solves the immediate problem while focusing less on the big picture. This is natural and hard to avoid, and it encourages small independent changes to the API that are explicitly tied to logic in the front-end. This increases entanglement.

If the data API and the JavaScript front-end are not really separate—or not inclined to remain separate—why force them?

What's the Alternative?

First, let me say that an alternative is not necessary—many shops can defend their choice of technologies based on their own circumstances. Good for them.

If you've chosen a JavaScript framework simply because that's the only thing you know, or because all the cool kids are doing it, or because some company that is operating at global scale mentioned it on their blog, then you may want to reconsider.

⊕HTML and css can cover a lot of UI/UX cases. JavaScript can be sprinkled around the page to handle special cases. Maybe the whole build-the-html-in-the browser approach is too much? I think so.

Why not send fully-formed HTML from the server? If your goal is to build a specific application to handle a specific set of features, why do you want to build a generic API? If the front-end is writing an HTML document, what's the harm of simply writing it on the back-end and being done with it? Is there really a need for extravagance?

←