Reading luca mezzalira‘s articles about frontend architectures sparked some thoughts on the evolution of software architecture as I observed it during my career.
That frontends can indeed be architected (from a software engineering perspective) wasn’t widely accepted until a few years ago.
IMHO these have been the key contributing factors:
- the advent of mobile apps and consequent acceleration towards headless backends and microservices;
- the end of programming language restrictions dictating the architecture patterns;
- democratisation of software engineering;
The first factor is easy to grasp. Early web applications consisted of a user interface tightly integrated with its engine, what we call the backend. Building a UI was more a job of learning some bits of HTML for a graphic designer. When CSS and JS came along things didn’t shift yet towards software engineering — fortunately?
The first attempt to engineer the frontend that many of us are aware of, was the MacroMedia Flash Player (then acquired by Adobe). Beside bells and whistles you could take out of a Flash application, when ActionScript 2.0 was released, concepts of namespaces, objects and programming patterns had to be learned by the frontend community eager to build “Rich Internet Applications” (RIAs). I myself “converted” some graphic designers to AS 2.0 programmers by teaching them software engineering concepts and design patterns and I was pleased to see diagrams on the whiteboard before people jumped on their keyboards — wasteful trial and error anyone?
If anything, since then we learned to decouple the frontend and build endpoints and services, although still part of big monoliths.
Then came web 2.0 and finally HTML5 and the ECMA standards freed up creativity and a whole new category of proper software developers (as opposed to hypertext mark-uppers), the frontend developers.
Here comes the second factor.
the end of programming language restrictions dictating the architecture patterns
Just as part of programming efforts shift toward the frontend and different languages are used for different purposes, it’s been the end of the dictatorship of C, C++, Java as the only reputable programming languages worth talking about. Software design patterns could only be taught and explained with them. In the long gone days, you could be considered a software engineer only when you could pepper your conversations with citations from Donald Knut’s well worn books or could give an opinion on the design of the TCP-IP stack as laid out in Tanenbaum’s literature. Asking for help meant writing a news post in a newsgroup (search for NNTP if you are too young to know) only to be scolded for not knowing. Nobody escaped this initiation by part of the “elite”.
democratisation of software engineering;
Frontend engineers now have to cope with complexity and a whole set of technologies that are required to at least earn a job. This is why the FE engineer is not a second class citizen any longer — since the early 2010s and HTML5, ECMA6 and Node, I believe.
This is why FE engineers are massively accelerating the growth of software architecture in general with their contribution and specific patterns unknown to the seasoned backenders.
And now that EdTech and IoT are bringing in fresh air by breaking old taboos (if you learned OO programming, it’s blasphemy going back to procedural, for instance) the old “elite” had to give in and accept that software is everywhere, there’s no way you’ll master the ever expanding domain and the one size fits all approach was dead a decade ago at the very least.
As white haired software engineer, I really welcome this convergence and the shift to maturity it brings to IT.