1 the introduction

Think deeply about why front-end frameworks are needed, and can Web Components replace front-end frameworks?

Original address, it is recommended to read the original text first, or read an overview.

2 an overview

There are a lot of front-end frameworks out there, so if we had to answer the question “Why do we use a front-end framework?” what do you think are the following reasons?

  • Componentization.
  • Has a strong open source community.
  • Having a large number of third-party libraries solves most of the problems.
  • There are plenty of third-party components already in place.
  • Has browser extensions/tools to help fast debug.
  • Friendly support for single page applications.

No, none of that is the root cause. It’s more a marketing ploy for the front-end framework. The fundamental reason given by the author is as follows:

Solve the UI and state synchronization problem.

The author assumes a project without a front-end framework, like in the Jquery era, where we need to manually synchronize state and UI. Like the following code:

addAddress(address) {
  // state logic
  const id = String(Dat.now())
  this.state = this.state.concat({ address, id })

  // UI logic
  this.updateHelp()

  const li = document.createElement('li')
  const span = document.createElement('span')
  const del = document.createElement('a')
  span.innerText = address
  del.innerText = 'delete'
  del.setAttribute('data-delete-id', id)

  this.ul.appendChild(li)
  li.appendChild(del)
  li.appendChild(span)
  this.items[id] = li
}
Copy the code

First, update efficiency is a problem, and the biggest problem is synchronization. Imagine interacting with the server multiple times and missing a step in the synchronization process, resulting in the subsequent UI becoming disconnected from the state.

Because we can only synchronize the state and UI step by step, we can’t guarantee that the UI and the state are completely synchronized at every moment, and any oversight can lead to a disconnect between the UI and the state, and there’s nothing we can do but constantly check that the UI and the data correspond.

So the most important help of modern frameworks is to keep the UI in sync with the state.

How to do

There are two ideas:

  1. Component-level re-rendering: For example, React, when the state changes, maps the changed virtual DOM and finally changes the real DOM mapped by the current component. This process is called reconciliation.
  2. Listen for changes: Such as Angluar and vue.js, state changes directly trigger changes in the value of the corresponding DOM node.

React renders as a whole, but it’s no less efficient than an Observable under the virtual DOM. Observables also need to rerender more extensively when their values don’t fully map the UI. In addition, vue.js and Angluar have already adopted the virtual DOM.

These three frameworks have been integrated, and the two ideas mentioned by the author are now a hybrid technology.

What about Web Components?

React, Angluar, vue.js are often compared to Web Components, but the biggest problem with Web Components is that it doesn’t address UI and state synchronization.

Web Components only provide template syntax, custom tags solve HTML problems, and do not provide a way to synchronize state with the UI.

So even with Web Components, we might need a framework for UI synchronization, such as vue.js or Stenciljs.

The authors also provide a short example of UI state synchronization, which is skipped here.

Finally, four conclusions are given:

  • Modern JS frameworks mainly address the problem of UI and state synchronization.
  • It is difficult to write complex, efficient, and easy to maintain UI code using native JS alone.
  • Web Components does not address this major problem.
  • While it’s easy to build a framework for solving problems using a virtual DOM library, it’s not recommended that you actually do it!

3 intensive reading

The author’s core point is that modern front-end frameworks primarily address the issue of UI and state synchronization, which is unquestionable, and also mentions that web Components still don’t address this issue.

This is probably the most central question of Web development.

Initial developer efforts focused on front-end standardization, resulting in a number of libraries that address standardization issues, most notably jquery. After the current react era, we can see that the effort has shifted from solving standardization to solving the conflict between web specification and practice, which is exactly the problem mentioned by the author.

The front three musketeers

The problem lies in the separation of HTML, JS and CSS.

HTML, CSS, JS are a set of independent systems, but JS can control HTML and CSS at the same time, that in order to solve the synchronization problem, it is best to give all the control to JS.

This makes the problem of Web Components easy to understand. Web Components solve HTML problems and are destined to have nothing to do with JS.

In order to solve the problems of the current front-end framework, HTML must be completely taken over by JS, which is almost JSX, or HTML that supports the template syntax. But this is against the original web design idea.

HTML stands on its own and can even run without JS, which naturally leads to the problem of UI and state synchronization.

Why do we have to use JS

HTML non-JS designs may be out of step with the front end, and maybe JSX or Template is the future.

Sure, HTML is now designed to run on browsers that don’t support JS, but more recently, all modern browsers have supported service workers, which are JS scripts that override the timing of HTML execution and can even intercept HTML requests. A browser that does not support JS may not support service workers, and the insistence on disabling JS may be a matter of security.

In fact, modern web pages use JS to completely dominate web rendering, so this has risen from a technical problem to a social problem. How many pages can be accessed normally in browsers that disable JS? With the exception of some very large sites that have special optimisations for disabling JS, few front-end projects now consider disabling JS because we don’t assume the React, Angluar, vue.js framework code won’t work.

So why not merge HTML and JS?

Given the fact that UI is already tied to JS, why doesn’t the W3C include JSX or Template as a standard? Perhaps the specification never takes this step forward for compatibility.

Fortunately, this has not prevented the proliferation of modern front-end frameworks, and it is unstoppable.

4 summarizes

Perhaps the biggest drag on the front end is the issue of UI and state synchronization, which has been addressed by modern frameworks, but the W3C standards have been unable to move in this direction, making it difficult for standards specifications to drive the next evolution of the Web. Much of the rapid development of the front end is due to the development of norms, and now we are entering an industrial-led era where norms are likely never to catch up, and with it, the industrial community will struggle to make further breakthroughs.

The front end is not just the Web, or maybe the next breakthrough is not the Web, but AR/VR or the next hCI scenario. Similarly, the Web is not only the front end of the three swordmen, if the React, Angluar, vue.js brought by the industrial specification is the new specification, the front end will have the impetus to develop backward, such as a new framework based on virtual DOM, new language.

So the author deduced that the essence of modern front-end development is to change the js/HTML parallelism into JS/HTML inclusion. As mentioned above, this may be a departure from the w3c’s original intention, but it is the trend now.

Finally, to sum up my views:

  1. Modern JS frameworks mainly address the problem of UI and state synchronization.
  2. The traditional front three musketeers are facing a crisis of further lack of development.
  3. Modern front-end frameworks are telling us about the new triumvirate: JS (virtual DOM, virtual CSS).

5 More Discussions

The discussion address is: intensive reading: The root reason why modern JS frameworks exist · Issue #84 · dT-fe /weekly

If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays.