I consider the article How Browsers Work: Behind the scenes of modern web browsers, from html5rocks, to be pure gold because very few blog posts and articles go out of their way to really explain what the browser does under the hood with all the HTML, CSS and Javascript.
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.
Many frameworks and libraries were both developed and improved in the last five to eight years due to VueJs, React, Redux, Flux, Angular, MeteorJs, etc. to give developers a set of tools to manage these complex problems. But they don’t solve one underlying problem that exists in the JavaScript development community: As more complex tools and problems are developed at a fast pace, most developers still see the browser as a black box in which stuff works. In part, this is happening because many HTML/CSS books and articles are oriented at giving developers a very pragmatic “do this to make this happen” approach, without considering why HTML must we be written in a certain way.
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
