The One where it all began

Preface

After long procrastination, here I am. Content consumption is hard, especially in the era of AI, LLMs and MCPs. I feel I am consuming more content than ever before. So here I am writing my first blog post. Im gonna try building this as reference notes that helps me keep track of my knowledge base and not explode my brain with information overload. To do this, I need to start at the very beginning…

Part 1 - Let there be light

I like building solutions. As a computer science engineer, one chooses their comfort in the level of abstraction they wish to work in. Over the last few years in my undergraduate and post graduate degrees, I have discovered domains from networking, cybersecurity, data science/engineering to low level embedded programming, compiler design and the like. I have come to realize that as a software developer my level of the wheelhouse is as a software developer. As a jack of all trades, master of none, I wish to focus my time on a particular domain first and then branch out to the rest as the opportunity presents itself. So lets’ begin at the outermost layer.

What is an application?
Wikipedia defines an application as a computer program that is intended for the end-user. As simple as that. This implicitly defines a few things for us.

1. Having an end user interaction requires an interface
2. Having UI requires systems to be designed in a way that can deal with dynamic interactions
3. Dynamic interactions are actions done by users at runtime which inherently is not guaranteed to happen in any order

In order to deal with such problems we came up with the request-response model. In distributed systems lingo, this grew to be known as the master slave paradigm. Although, in modern times it’s often referred to as client-server architecture.
The client is an entity that contains this user interface and propagates communication to a server entity. This server entity has 1 job, and that is to fulfill the clients needs. This may be data or hypermedia in any form.
Over the years we have come to defile multiple entities as part of the “client” umbrella. From desktop or mobiles apps, LLM chat interfaces to web browsers. I, being a web developer, am mainly focused on this last one. The browser.

Part 2 - The journey through time

The network was a magical invention. More so the process of communicating over the network allowed infinite possibilities in the world of web technology. Over the years we have had big entities that have enabled and standardized many paradigms giving us structure and obedient formats that can be used to build software in this domain in the form of specs. From the W3C to the WHATWG have all worked immensely hard to push the web forward in a unified way. The advancements in each level of the OSI models has taken place for us developers to work on the last layer to provide a meaningful experience to our users. From IP to SSL to HTTP to HTML. Each layer, produces a crucial part of hypermedia processing that allows us to inherently work with data and provide meaningful application of our interface - hence the name “Apps”.

Over the past few decades, we have made certain discoveries. We have come up with patterns that are repeated in many technologies from time to time. As developers, building meaningful user interfaces is a complex task. We approach our problem from multiple angles, engineering a solution to best fulfill our task, users needs and the technical constraints presented to us. Through this journey we have realized it is a good design to implement our application structure in the form of a hierarchy in a declarative manner. This gave us the implementation of markup languages that help define HTML, XML, and the like. From Java Swing(AWT based) to JavaFX, XAML and MAUI from the Microsoft world, to the web DOM. Many domains across the many fields have narrowed down on this approach to maintain a structural hierarchy of the interface as a static entity to be defined with which the user can interact upon.
This idea of the interface arranged as a hierarchy of nodes is achieved with markup as it allows us to define the entities in a tree-like way providing clear relationships. This potentially unlocks the core essence of the computer science by providing Modularity as well. However in order to improve on this model and not deal with a chaotic hierarchy, we have had further enhancements providing us with semantic meaning to these entities.

However there is a cost. Hierarchy does not necessarily always define the design. UI Design and experience (UX) almost always drives a direct impact on the interactivity of the software. Having an hierarchy solves the problem of composition of interface in terms of engineering design by declaratively building it; however it does not solve the look-and-feel of the software. That is the reason UX as a branch of such is very psychological in nature providing solutions to scenarios that depend on user interaction and the philosophy behind it. To solve this problem we have realized a way to express our design opinions and link it to the markup entities providing a direct relation between them. This lead to the development of CSS. A DSL for the browser that not only helps apply styles to the interface but also cascades based on its hierarchy further binding the two together. This composition pattern of CSS linking to HTML provides a system that allows us to declaratively build the interface and style them as required. In modern times CSS supports complex styling requirements for UX design like animations, view transitions and mathematical computations.

The last clutch is that of interactivity. The web and hypermedia in general, although began as static newspapers and magazines has now progressed to advanced complex applications. In order to support such complex interactions we need an imperative way of enabling our markup to support dynamic events. This lead to languages like JS (that although was scrapped together in 10 days) that has driven the web forward in building complex interactive experiences. Across other domains, like AWT/XAML etc the core logic of such interactions are imperatively programmed to allow us to handle them in a controlled way. Now enabled with an interactive interface we can finally do things with our experience (apart from just reading beautified content). But where would that be?