Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News The Three Key Dimensions of Front-End Frameworks - Evan You at JS Conf Asia 2019

The Three Key Dimensions of Front-End Frameworks - Evan You at JS Conf Asia 2019


Evan You, Vue.js front-end framework creator, recently talked at JS Conf Asia 2019 about seeking balance in framework design. According to You, frameworks should be distinguished by the design tradeoffs they offer on scope, render mechanism, and state mechanism, rather than on popularity- and community-based metrics. Rather than a binary (good vs. bad) framework evaluation, frameworks are best graduated on a continuous tradeoff axis.

The abundance of front-end frameworks has given birth to a number of comparison studies, aiming at helping developers and architects pick the most appropriate framework for the needs of their projects. While a large set of criteria can be used for the comparison, popularity- and community-based metrics (GitHub stars, npm downloads, stackoverflow questions) are not, according to You, the most decisive factors which should drive a framework adoption. You contends that the tradeoffs originating from the framework design are most enlightening. You groups the key tradeoffs on the three dimensions of scope, rendering and state management.

Scope refers to what the framework tries to do for its users.

Large-scope frameworks such as Angular or Aurelia favor a top-down design, in which most of the conceivable issues developers will run into have already been factored into the framework design. Features like validation, animation, internationalization, or accessibility are baked into the framework, so developers do not have to implement and integrate their own solution.

On the other end of the scope dimension are highly focused frameworks. Such frameworks are organically built bottom-up by the community around a highly focused core. React for instance sees itself as focusing on the view layer of front-end applications, with other specialized libraries coming together to handle additional concerns such as data fetching (relay), or side-effects (redux-saga).

You places the Vue.js framework somewhat in the middle (Progressive framework). On the one hand, Vue largely focuses on the view layer. On the other hand, Vue’s layered design allows for opt-in, official, documented solutions for common problems.

Developers need understand the pros and cons to each approach.

Frameworks which encompass a large scope may be productive in the short-term with their optimized, built-in abstractions covering most common problems. The associated ecosystem of user-defined libraries may as a result be more consistent and coherent. On the down side, that ecosystem may be smaller. The built-in abstractions may require additional learning and training.

Highly focused frameworks have fewer concepts to get started with. The larger flexibility allows for a large ecosystem from which user can build arbitrarily complex systems. For the framework team, the smaller maintenance surface means they can more easily explore new ideas (React introducing Hooks) and optimizing their area of focus (React Concurrent Mode). However, users may need to spend time picking up and integrating a sometimes large set of extra libraries with largely varying levels of maintenance and documentation.

The Progressive approach takes pros and cons from both sides. Developers for instance often celebrate how easy it is to get started with Vue, and the documentation of officially supported libraries. However, Progressive frameworks share the same maintenance burden as frameworks with a large scope, while not being able to exhibit an ecosystem as rich as highly focused frameworks.

The second dimension of analysis is the view rendering mechanism. This involves how the UI structure is expressed, and how the UI is rendered.

On the one hand, in frameworks using JSX, or its TypeScript version TSX (such as React, or Stencil), developers can use the full power of the Turing-complete underlying language to express arbitrarily complex logic. Those frameworks usually see the view as data (virtual DOM), with large customization opportunities in user land, including using view data for rendering to alternative targets (rendering into a terminal, or to pdf). On the negative side, the fully dynamic nature of render functions makes it hard to optimize for by default. Such frameworks, like React, may include escape hatches to enable developers to optimize rendering themselves (React’s shouldComponentUpdate and useMemo). Optimizing rendering in those frameworks involves a significant learning phase, as developers may have to deeply acquaint themselves with implementation details of the framework.

On the other hand, template-based frameworks such as Vue or Svelte, bound the expressiveness of the rendering function to the capability of the template language. Templates are harder to customize out of the possibilities already considered in the template language. The rigid structure however enables optimized-by-default rendering of the UI. In Svelte, for instance, the following template <h1> Hello {name} </h1> will result in running the following compiled code when name changes, updating chirurgically only the part of the DOM which needs to be changed:

p(changed, ctx){
  if ( {
    set_data (t1,

Such by-default optimizations are difficult to achieve for frameworks which use a virtual DOM and compute the DOM operations to perform in case of updates by keeping track and diffing two versions of a virtual DOM – thus exhibiting a higher memory and CPU usage profile.

You notes that Vue strikes a middle ground by being template-based by default, with by-default rendering optimizations, while still letting developers falling back to full-fledged JavaScript render functions when the need arises.

As a third dimension to evaluate framework on, You mentions the mechanism by which state is managed by the framework, in particular the reactivity and data synchronization abilities offered by the framework.

You, in his presentation, doubts the existence of a universally best framework:

The framework landscape is like a multi-dimensional space with multiple ever-moving entities, each seeking its own balance point.
(…) Where is the perfect balance point? Is a single perfect balance point even optimal for JS devs as a whole?
(…) There isn’t a single Good vs. Bad spectrum for frameworks.

Developers need to understand front-end framework design tradeoffs and how that fits the requirements of their projects.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Great article!!

    by Olmo del Corral,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My two cents: TSX is typescript checked JSX, making React views not only more expressive but more type safe than the template alternatives.

    The article mentions TSX but not what it is. For me being strongly type on the views is the killing feature of React.

  • Incorrect Information

    by Rob Eisenberg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Unfortunately, Evan has completely misunderstood the meanings of the terms "Cathedral" and "Bazaar". I would strongly urge him to read the original white paper. I caught this mistake immediately not only because I have read the original essay, but also because I was deeply involved in the Cathedral/Bazaar conversations with Microsoft in the mid-2000s when we were working so hard to get that company to change its open source approach. If you don't want to read the original essay yourself, you can read this quick summary of the two terms from Wikipedia:

    * The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers.
    * The Bazaar model, in which the code is developed over the Internet in view of the public.

    Now, if you look at the practices of the frameworks that Evan points out, you will see that he's categorized them exactly opposite of what they are. For example, Evan announced Vue 3 in the 4th quarter of 2019, including showing benchmarks and talking about file size. However, almost 9 months later, the Vue 3 source is not open. It is restricted to a small group of individuals. This is the epitome of the Cathedral style. On the other hand, if you look at Angular 2+ and Aurelia vNext, you will see that in both cases, from the earliest development, they were fully open...all design docs, plans, documentation, code, etc. This is the Bazaar approach.

    Cathedral/Bazaar is not about scope. It's about how you run the open source project and involve the community.

    Evan goes on to use this mis-characterization to show his project in a positive light and to somehow spin the fact that Angular and Aurelia have more out of the box features as a bad thing. He completely misunderstands the architecture of these frameworks. For example, Aurelia is one of, if not the most modular and extensible JS framework today. Angular is also highly modular. Taking Aurelia as an example, while it provides many "plugins" out of the box, they are just that: plugins. The community has produced alternate versions in many cases. This is the value of having a pluggable architecture. The abstractions are carefully designed (with the community involved as part of the Bazaar approach), and are not complex. The framework provides a simple implementation ready to be used immediately, and the community creates alternative, specialized implementations as needed. This is the way nearly every major modular framework has been built. Vue isn't built this way though and seems to lack things like DI that provide a standard way to achieve a plugin architecture. So, in Vue, their plugins are typically hacked around globals, global hooks, and other odd things, which pollute the architecture and provide less consistency.

    I could go on, but this response is far too long. This isn't the first time that Evan has made mistakes like this. So, please, in the very least, do some fact checking on anything he says.

  • Re: Incorrect Information

    by Rob Eisenberg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Pardon my typo. It should read "Evan announced Vue 3 in the 4th quarter of 2018"

  • Re: Incorrect Information

    by Olivier Couriol,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comment Bob. I edited the article to remove the Bazaar and Cathedral references to avoid any mischaracterization. I also messaged you on your twitter.

  • Re: Great article!!

    by Olivier Couriol,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks! I edited the article to mention that TSX is the TypeScript version of JSX.

  • Re: Incorrect Information

    by Rob Eisenberg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Bruno, no fault of your own on that. You are just reporting what Evan said. It’s mostly frustrating that he portrayed things that way.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p