Why frontend development needs to change?

A brief history

I learnt to code my first web page when HTML2 was just new. Those were the days of the <marquee/>. Javascript was just introduced to HTML to make the pages reactive. I was delighted at a button being able to open an alert box and show and hide something on mouse over. I had a page on the free hosting site geocities.com which was made in Microsoft Frontpage. It used to be a WYSIWYG editor for HTML pages. Around that time, Microsoft had introduced COM and ActiveX. I was able to embed an IE activex control into an app and make my first ever desktop webapp for managing books for a library. Although it was a hybrid and the majority of the portions were written in C++. All this time, I thought Javascript was some laughable small toy version of the Java language. But it was when someone took the Javascript engine out of the browser and made a server out of it called Node.JS. After this, there was no looking back for JS. It became a full stack language and exploded in use and adoption, and is still the fastest growing language at its scale. However, at its core, JS has remained the same-an event driven runtime. To extend the capabilities of JS developers around the world have built countless tools, libraries, and frameworks to provide higher levels of abstraction over the core DOM api and event driven engine. These are either npm packages, which are basic libraries, or build systems which extend JS language capabilities by adding compile time processing of JS code, or they are entire languages, such as Flow and Typescript which aim to reduce human errors and improve code maintenance. Consequently, the web apps have become increasingly rich and complex, driving a movement of even highly complex desktop apps to cloud based web apps running in the browser. It has also lead to a fundamental change in software development by introducing agile and rapid delivery and a hyper focus on design and user experience. It has put true power in the hands of designers and engineers to make any abstract imagination come to reality. They are no longer bound by the limitations and constraints of the desktop ecosystem.

What are the challenges?

The majority of this progress has occurred in the last 15 years, resulting in an ever-changing landscape known as JS framework hell. Last 12 years, we have seen the transition from JQuery to Knockout / Backbone to AngularJS to ReactJS and Vue, each followed by their several versions from redux / flow to hooks and now moving to web component based frameworks like Svelte and SolidJS. The key issue is that each of these frameworks has quite many quirks and nuances, which are necessary to write performant code. And as apps have grown bigger and more complex, and devices have become more and more portable, the need for performance has also become greater. You cannot "throw servers" at the problem to solve performance problems in frontend code. This poses a huge mentorship and constant learning challenge for frontend developers. Also, it is very difficult to ensure the right guidelines are followed across a large team and codebase. The number of packages has also exploded, complicating code maintenance in a large repo with multiple versions of libraries running in parallel and hundreds of unknown packages being bundled with incompatible licences and open security vulnerabilities. The build systems have also become increasingly complex and hard to debug.

Secondly, only about 30 to 35% of the frontend code is business logic, while the rest is either boilerplate, presentation, or state and prop management. When a developer starts to build a new frontend, she literally starts by creating a new repo from the command line, either as a blank slate or using a template. But irrespective of how simple it might seem to get started, they are practically unusable unless one understands the internals in sufficient detail. The same is the case with frameworks like React, Vue, etc. The tutorials and getting started guides look deceptively simple, but it takes a nuanced understanding to get the real value out of them. So much code needs to be written to create components and component structures, put conditions and loops in DOM to make it dynamic, pass properties and event handlers down the component heirarchy and connect components that are deep in different hierarchies, bind and manage CSS with the components, fire actions from event handlers and change all affected states and stores, get and store inputs, make elements reactive, etc. Even just the tooling around the repo is incredibly complex. It takes a lot of effort to perfect CI/CD, unit tests, regression tests, linting, prettifying, package and build management like webpack, rollup etc. Every project comes with decisions on how to modularize parts of code, how to write components, how to write APIs, queries, reducers, hooks, etc. The list is endless. Even CSS is prone to overdoing by using industrially large frameworks to create basic boxes. Even very simple web pages are full of bloated JavaScript and CSS, which does nothing but hurt them. Few developers are able to make the optimal choices because everything may look the same at first glance.

Thirdly, user experience has become very complex, and it is generally hard to reproduce designs accurately. There are a lot of ambiguous cases as well, which are impossible to think fully through by designers and developers when building apps. There are many small details to pay attention to when apps behave when resized or zoomed. For example, which dimensions should expand and which should remain static, or should they scroll or wrap or overflow, expand, contract, dissappear or change form, etc. The developers also need to account for browser compatibility across devices and performance of pages under different network speeds and device capabilities. In addition, there is a need for accessibility, internationalisation, color themes, and modes, etc. which are required to call an application "complete". All these permutations across hundreds of elements on a single page of a web app are humanly impossible to fully be done correctly.

What next?

Most of these above-mentioned decisions that a developer takes are largely based upon rules and heuristics that a developer learns with experience. There isn’t any great fundamentally new insight that is applied in a large number of these cases. Furthermore, developers are increasingly finding it difficult to keep up. In the future, there are good reasons to believe that these tasks are getting increasingly complex for humans and can be done better by a machine heuristically and intelligently as compared to a human. But how is it possible? Can the machine infer the intent behind the designs and wireframes, fill in the missing information, and convert it into intuitive and readable code for developers to an extent? This can usher in an era of "co-creation" of applications with the help of machines, resulting in rich, performant, and delightful applications with much less time to go to market and to iterate.