Is each generation of technology trying to solve the problems created by the previous one?
Consider a (somewhat dramatized) progression of front end technologies from circa 1999 to 2020:
What they said: “Web apps will save us”
What they meant: Native desktops apps are getting harder and harder to develop and deploy on thousands of different machines running several different operating systems. HTML and JavaScript based apps served from the cloud will solve this.
What they said: “jQuery will save us”
What they meant: JavaScript standards have not yet been uniformly adopted by all mainstream browsers. The jQuery library currently handles those browser quirks in a manner that is transparent to developers.
What they said: “Angular/Ember will save us”
What they meant: Writing large apps in jQuery has resulted in unmanageable code bases consisting of large numbers of unstructured jQuery functions. These new frameworks provide an MVC architecture for web front ends, along with their own client-side templating engines.
What they said: “React will save us”
What they meant: Frameworks like Angular and Ember have grown very large and complex. Their client-side templating engines too, tax the browser. React is a simple view library that tries to do one thing: efficient, component-based client-side view rendering. React also solves the “two-way data binding problem”, which is something that badly affected the Facebook developers, but not necessarily other development teams.
What they said: “Flux will save us”
What they meant: React has not specified an overall application architecture. As a result, code bases relying purely on React suffer from maintainability problems analogous to old jQuery apps. Flux is Facebook’s recommended architecture for building front end apps with React. It promises to prevent difficult-to-trace cause-effect loops in front ends.
What they said: “Redux will save us”
What they meant: The initial enthusiasm with Flux architecture resulted in a large number of competing Flux libraries and frameworks. Redux emerged as the most practical and well thought-out of these frameworks.
What they said: “Server-side rendering will save us”
What they meant: The large JS bundles created by React, Redux and Node modules are putting a strain on browsers during initial load-up. Since moving some of the processing to the server again requires significant re-architecture, we can solve this problem by running the same FE render code in the backend (sort of like PHP/JSP). This is also meant for applications that need to perform SEO.
Now also consider a (similarly dramatized) progression of back end technologies during those same twenty years:
What they said: “3-tier architecture will save us”
What they meant: Monolithic apps that connect directly to the database have resulted in very large, unmaintainable code bases. By separating code into three tiers — presentation, application and data, we can maintain the application better.
What they said: “Web services will save us”
What they meant: With the presentation tier being a thin layer, much of the complexity has moved to large, monolithic back end applications. Web services split such backends up into multiple, smaller “services”.
What they said: “REST APIs will save us”
What they meant: The previous generation of web services based on XML, WSDL, SOAP have become highly complex — code complexity has been replaced by integration complexity. REST APIs aim to solve this by using a much simpler model where all APIs are modeled using resources and actions, mapped to HTTP URLs and methods, and using the simpler JSON format over XML.
What they said: “Microservices will save us”
What they meant: Large teams now have difficulties making application changes as they need to coordinate with multiple other teams who own different dependent APIs. Code & integration complexity has now been replaced by change control complexity. Microservices will address this by making the services self-contained, with an independent API and own data stores.
What they said: “Docker will save us”
What they meant: With each microservice comes its own dependencies (platform version, libraries etc). With independent teams developing each microservice, these dependencies and their versions may clash. Containerization allows the packaging of all of a microservice’s dependencies into a single image which can be run on infrastructure without each microservice requiring its own dedicated VM.
What they said: “Kubernetes will save us”
What they meant: As large scale applications turned into collections of many containerized microservices, deploying and orchestrating containers, and managing container infrastructure became a need. Kubernetes helps developers and cloud engineers perform these tasks.
What they said: “Serverless will save us”
What they meant: Managing the infrastructure for large numbers of containerized microservices can be time consuming. “Serverless” attempts to solve this by having cloud service providers hide the management overhead of infrastructure (CPU, memory, disk, OS etc) from the developer and instead providing them with managed services. Developers can use these services without worrying about the underlying hardware resources or the operating system.
Now consider this: each generation of technologies seem to create the problems that the next one solves. Does the state-of-the-art in 2020 represent the logical conclusion of this trend, or can we expect the trend to continue? Will will see a new class of technology that solves the problems serverless services create? Will something come along to make server-side rendering easier?
