The Document Object Model (DOM) API is provided within browsers to allow developers to read from and dynamically mutate web documents. Upon its initial introduction in 1997, it was very limited in scope but has expanded greatly in the last two decades, allowing us to now have programmatic access to a wide variety of browser functionality.

The DOM itself presents us with a hierarchy of elements that are derived from the parsed HTML of a given page. This hierarchy is made accessible to JavaScript via an API. This API allows us to select elements, traverse trees of elements, and inspect element properties and characteristics. Here is an example of a DOM tree with the corresponding JavaScript used to access it:

The way we access specific DOM nodes has changed over the years but its fundamental tree-like structure has remained the same. Via access to this structure, we can read from the elements, mutate them, or indeed add to the tree of elements ourselves.

Alongside the DOM API is a collection of other natively provided browser APIs that make it possible to do things such as reading cookies, mutating local storage, setting up background tasks (workers), and operating on the CSS Object Model (CSSOM).

As recently as the year 2012, it was quite typical for web developers to only use JavaScript to enhance experiences already manifested in the markup of a page. For example, they might've simply added a rollover state to a button or validation to a form field. Such additions were considered a type of progressive enhancement, where the user could experience the website without JavaScript if they wanted but having JavaScript enabled would enhance their experience in some small way.

Nowadays, however, it is far more common to have the frontend portion of a web application built almost entirely with JavaScript and expressed within a single page. These are often termed SPAs. Instead of having the user naturally navigate around a website, loading up new pages within the browser upon each action, the SPA will instead rewrite the current page's content and the current browser address. SPAs are therefore dependent upon the user's browser supporting JavaScript and potentially other APIs too. SPAs typically do not gracefully degrade, although it is best practice (and good sense!) to provide a series of fallbacks so that the entire audience can receive functionality.

The proliferation of the SPA can be attributed to both developer experience and user experience boosts:

• Architecture (DX): There is a nicer separation of concerns between the frontend client and the backend API layer. This can lead to a cleaner architecture that helpfully delineates business logic from UI. Having one code base that governs both the rendering and dynamic enhancement can vastly simplify things as well.
• State persistence (UX): Users can navigate and execute actions within a web application without having to lose in-page state, such as populated input fields or scroll-position. Additionally, the UX can include multiple different panes, modals, or sections that populate independently and can be persisted regardless of other actions taken.
• Performance (UX): The bulk of HTTP resources can be loaded just once within the user's browser, increasing the performance of any further actions or navigations within the application. That is, after the initial load of the application, any further requests can be optimized to be simple JSON REST responses with no unnecessary boilerplate markup so the browser spends less time re-parsing or re-rendering boilerplate HTML, CSS, and JavaScript.

The growing demands on web applications and the proliferation of the SPA have meant that programmers have come to rely much more on browser APIs, especially the DOM, to create rich and dynamic experiences. The painful truth, however, is that the DOM was never intended to cater to the creation of rich desktop-like experiences. Because of this, there have been many growing pains in bringing the DOM up to scratch with current demands. Additionally, there has been a slow and iterative process of creating frameworks that enable the development of rich experiences atop a platform that was not originally designed for them. 

One of the most obvious ways in which the DOM (and browser APIs generally) does not meet the current demands of SPAs is experienced when trying to bind the DOM to data. We will now explore this topic in more depth.