HOW BROWSERS WORK
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:
Understanding the steps the browser takes to parse the HTML nodes from text character to rendering, then parsing of CSS rules, merging the HTML and CSS into the right DOM nodes etcetera. This gives you a better understanding of how to debug or deal with weird rendering scenarios, such as colors not changing for elements, dynamic element insertions or style mutations that can break a UI.. Because the browser does not throw HTML and CSS exceptions when something is wrong, you don't get you a lot of information about what caused the page to render wrong. This is usually the burden of various frameworks to anticipate these errors, but it's useful to know about these rules and steps yourself. With it, you can quickly develop a stable feature or app even in plain HTML, CSS, JS, or develop a stable feature even faster with a framework's tools by anticipating various side-effects and issues that may arise from a style or state change.
An extensive application may have complex CSS rules that elements in the UI depend on. Understanding how CSS is parsed and rendered, especially when this process is different in Firefox, Chrome, and Safari gives any developer an edge. Knowing the knit and grit of this process could allow a developer to alter the stylings and elements so that it doesn't break existing or future elements.
A web page is a complicated tree structure underneath that very strictly controls its state. Any change(, especially the dynamic ones happening on runtime) to the state, can lead to the UI breaking. This happens because the parent controls its children very tightly; any change to the parent element can lead to changes in the child nodes, grandchild nodes, and so on. Various CSS attribute values for display, size, position etc. change how the browser will interpret that node in its tree, floats and absolutely positioned elements are out of the flow, placed in a different part of the tree, and mapped to the real frame.. This can affect the position, size, and the encapsulated JS logic of a component in some cases.
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