For some time now, web-based client applications have started to become increasingly more complicated because of problems that arise from: state management, performance, advanced UI/UX requirements, implementing a scalable architecture. Thus web pages are less and less about static content served on a page, and more about functionality, reactivity and business logic oriented to tailor a satisfactory experience for anyone using a specific web app as a tool, entertainment, or even just reading content.
The article from html5rocks, tries to explain how these processes work under the hood in the browser. It requires a few reads if you want to get the full general overview of how and why the browser parses HTML and CSS in this particular way and how the rendering engine, which is different from browser to browser usually, deals with running the same code more or less everywhere. It goes into details such as language syntax and design and how parsing characters in a state machine end up being a tree of DOM elements rendered on the page.
For me, the article gave a few interesting insights that I think every developer that works closely with the browser should be aware of:
In a world where web apps are reactive, dynamic, and wait for tens of asynchronous operations that change one or many elements, this little bit of knowledge can save some frustration and time on the developers’ part. By knowingly constructing a UI that does not neglect state changes and various side-effects, the application will scale without breaking bugs that are usually caused by changes that are very subtle and hard to spot.
I can’t say that this article has changed how I write code 180 degrees, but it made me more aware of specific small issues that arise during development. In some way, making my knowledge of existing frameworks a bit more abstract and universal because at its core, React, Vue, and Angular all try to solve the same problems that arise from the browser.
Partly because of the specific way it was designed to read, interpret, mutate and render a UI. After some thorough reads of this article, I started dedicating a lot more time to logically coupling my components. I now do this so that they are always rendered correctly, have few side-effects outside the local scope, and enforce clear communication of state or style changes. Or in short, I write more consistent and easily extendable CSS rules.
Curious about reading the article as well? Click here