2020 year Github Before the stars 20 name JavaScript frame

Recently, when browsing the web, I realized that the front end has not appeared a good one in the past two years JavaScript The framework . In this extraordinary 2020 Before the end of the year , Let's see 2020 Performance comparison between popular script libraries in .

what Javascript Frames are the most popular ?  Here it is Github Star Series ranking 20 Of JavaScript Frame comparison , use JS Framework Benchmark Compare them .

Statement : This comparison is interesting throughout the process , It could also be educational . As usual , Every library here is efficient enough for most things . If there's anything to emphasize, it's , Performance can come from a variety of different technologies . Although it can be used as a reference , But the performance of each use case should be verified independently . The latest official results can be found here . It is hereby declared that , The comparison is only objective , The actual development process needs to be combined with the team level 、 Collaboration 、 Efficiency, etc .


Use the latest Google browser Chrome 87 The key result is JS Framework Benchmark. They are Fedora 33 Under the Core i7 Razor Blade 15 Up operation , And close the release .

Filtering out all problematic implementations , And then I got Github Before the number of stars 20 Script library for . For libraries with multiple versions , They don't use third-party libraries to get their latest versions and the most high-performance variants . Here is Github Top stars 20 Script library information and star status .

  1. Vue (177k)
  2. React (161k)
  3. Angular (68.9k)
  4. Svelte (40.5k)
  5. Preact (27.9k)
  6. Ember (21.7k)
  7. HyperApp(18.2k)
  8. Inferno (14.6k)
  9. Riot (14.4k)
  10. Yew (14.2k)
  11. Mithril (12.5k)
  12. Alpine (12.4k)
  13. Knockout (9.9k)
  14. Marko (9.9k)
  15. lit-html (6.9k)
  16. Rax (7k)
  17. Elm (6.2k)
  18. Ractive (5.8k)
  19. Solid (4.7k)
  20. Imba (4.1k)

Be careful : I will put LitElement Implement as lit-html Example , Because the standard example has been marked as a problem . The cost should be minimal , Because it's packaged in a single Web The original in the component lit-html.

This is the present. Web Developing a pretty good part of the ecosystem . Even though Github Stars Not all , But there are 100 Multiple libraries , So we need to choose the relatively popular .

Each library will be in 3 Compare the two categories :

  • DOM performance
  • Start indicators
  • Memory usage

Besides , Divide the framework into 4 Group , To best compare them with their original performance peers . however , Script libraries will be ranked in all three areas .

In each group , There will be references Vanilla JavaScript entry . Using all the best technology , This implementation has been optimized , For optimal performance . It will be the benchmark for all comparisons .

The first 4 Group - Standard performance

This is the largest group , It's made up of some of the most popular script Libraries . And a lot more from Facebook、Google、eBay And companies supported by companies like Alibaba . These script libraries are either not very performance oriented in some way , Or highlight the performance of a certain field , And it's not doing well in other ways .

There's a lot of red and orange , But remember , These libraries, on average, are only more painful than the hand-made imperative we use here Vanilla JavaScript The example is about 2 times . 400ms And 200ms What's the difference? ?

In terms of raw performance ,React Is the leader of the group . Considering the differences in Architecture , Even though it never stops , but React、Marko、Angular and Ember The overall gap is not big . Still React, This is a React Hooks The implementation of the , Here is the leader . For anyone who points to extra functions and insists on using classes , Performance parameters are not with you .React Hooks It's using React The most efficient way to .

Most of the libraries here are either naive list sorting, which leads to poor performance of swapping rows , Or it's expensive to create .Ember It's an extreme case of this , Because its update performance is much better than other members of the group , But in some of the worst cases, it's the creation process .

The slowest Library (Knockout,Ractive and Alpine) They are fine-grained reaction libraries with similar architectures .Knockout and Ractive( Also by Svelte The author of Rich Harris writing ) come from 2010 Beginning of the year VDOM Before Ku led . I doubt it Alpine Whether it is expected to be used JavaScript Method to render 1 Line ten thousand . After comparison , We won't see another pure fine-grained reactive Library .

Next , We will compare the startup metrics of categories mainly based on the size of the library package .

The list changes a lot here . stay Alpine The worst part , We can see that it has the smallest bundle Size and fastest startup time .Marko( come from eBay) Followed by , The second is Rax( From Alibaba ). All three libraries are built for server-side rendering , It is mainly realized through easier client interaction . That's why they are in the second place in terms of performance 4 Group , But here's why it's ahead of the start-up .

The second half of the table is the largest package we have in the benchmark , With Ember ending , More than twice as much as any other implementation . I don't know why it takes more than half a megabyte to render this table . But it does damage startup performance .

The last category we're going to look at is memory consumption .

Memory tends to reflect the patterns we've seen , Because it has a big impact on performance , Larger libraries tend to use more memory .Alpine,Marko and React lead . The aging fine-grained reaction library is the most used one Ember.Ember It's huge . Render only on the page 6 After a button , It has been used more than Vanilla More memory used throughout the suite .

The first 4 Group results

Usually , The group is in GitHub On behalf of 30 Ten thousand stars , May be NPM The largest part of the download , but Marko and Alpine The average ranking in this group is the highest . In terms of performance ,React Rank third , Second only to them .

The first 3 Group - Performance awareness

In these frameworks , You can see that performance has been considered . They realize that scale , And there's a balance between creation and renewal costs . We see all kinds of ways .Yew One of them Web Assembly frame ( use Rust To write ),LitElement One of them Web Components .
This matter should not be delayed , Let's see how they work .

The score has improved a little , We see an even bigger gap .Preact It's the highest performance in the group , Just added LitElement.Vue 3 and Riot Tied together , Both libraries are in the middle , Their history includes reactivity and VDOM.Mithril It was the first to put performance first VDOM One of the Libraries ,Yew Is the only one. WASM At the end of the library .

In terms of performance , All of these libraries are similar . There is no pure reaction pool in this reactor . They all use top-down rendering , Whether it's VDOM It's still simple Tag Template Literal diff. Compared to the previous group , Their reconciliation lists are smarter ( See line break performance ). however , Most still have some of the slowest line selection performance .

Yew It's an exception , But in other ways it's slower . Let's see if the rest of the tests help .

Things have changed , But in terms of starting indicators ,Preact Still in the lead .Yew It's the only really large Script Library in this pile .WASM Ku does tend to the bigger side .

Again , We see a result pairing .Vue It's second only to Yew The second largest Script Library of .Preact and Riot Very compact .Mithril and LitElement In the middle

Preact yes React Of 4kb succedaneum , Absolutely the smallest library we've seen so far . But the smallest library continues . For all that , No libraries in this range should pay too much attention to their package size .

Yew I won this time . In all the tested frameworks , It has minimal memory footprint .WASM Ku is also very good at this . The others are very close .Mithril and Preact It's the worst , But the gap is not big .

There's nothing to talk about from here . You might think LitElement Examples may be better than other non yew The library is lighter , Because it doesn't use virtualization like other libraries DOM. But as we'll see later ,VDOM It doesn't mean more memory .

The first 3 Group results

Riot and Preact The average ranking is the best , The second is LitElement, Rank third .Riot Despite the poor performance , But there is no weakness in this group , In the end, I won in the comparison . however , I won't be disappointed with any of these frameworks . adopt WASM and Web Components , They represent what many people think Web The future of .

The second group - Performance champion

This group's script libraries are highly competitive . We have most of the libraries called compiler languages . Each has its own characteristics . We have the same structure Elm, suffer Ruby Enlightening Imba and “ Vanished ” Svelte.

Be careful : Not everyone is familiar with Svelte Former “ The disappearing frame ” nickname . It describes the ability to basically self compile from output .

Strangely enough HyperApp, It's the exact opposite of other applications . No compiler . No template . just h One function and one minimal Virtual DOM

ok , The smallest virtual DOM Win . Contrary to recent statements , It turns out that virtual DOM It's not just the secret of poor performance , And compiling doesn't help other libraries .

In the compiled Library , We actually see 3 There are two different ways to render all of them with about the same average performance .

  • Imba Use DOM Coordinate ( Closer to what we saw before LitElement)
  • Elm Use virtual DOM
  • the last one Svelte Using component response systems

You should pay attention to , fictitious DOM The selection row of the library is the worst , Because that's their extra work . But these libraries also have faster initial rendering . If you look closely at the results so far , You should notice that compared to responsive Libraries , fictitious DOM Sharing between Libraries . But beyond that , The performance is still very strict .

therefore , Let's move on . How our compiler adjusts the startup time / Bag size ?

ok , As you can see , This little virtual DOM Libraries not only have better performance , And smaller than the others . actually ,HyperApp Is the smallest implementation of all our libraries . Compilers don't make it .

It and Svelte It's better than ours Vanilla JavaScript Reference build small . How could it be ? Write less code to write abstractions in a more reusable way .Vanilla JS The implementation is optimized for performance rather than size .

Elm Still on a competitive scale in this group . However ,Imba Begin to enter group 4 The scope of some libraries in .

Okay , To compare memory , The compiler's last chance to shine .

Memory is close to , It's almost a draw , however Svelte Finally, the compiler won . To the virtual DOM Some of the sweet revenge of the show that it's smaller than it is , faster .

honestly , All of these libraries have excellent memory profiles . It should be clear by now , The relationship between less memory and better performance .

The first 2 Group results

Don't believe in hype ?

No . More complicated than it seems . Well designed systems , Whether it's run time or compile time , Or whatever technology is used , Can be made into high-performance systems .

HyperApp Is the obvious winner of the group , Followed by Svelte, The second is Elm and Imba. Through this focus on performance , You know that these libraries are available in most cases , And always at the top of the benchmark .

The first group - Performance elite

In a way , This may be called “ Dazzling fast ”, I believe it used to be one of the slogans of these libraries . If you want to follow , Now there is only 2 It's a script library . in fact , There are a few script libraries in this category that are constantly challenging boundaries . But the only thing that's popular is 2 Kind of . They are more primitive than manual optimization Vanilla JS On average, it's less than 20%.

It's worth seeing . Here we have two libraries , If you look at their code , They may be considered brothers , But the method used is totally different .Inferno It's the best performing virtual machine in the world DOM One of the Libraries . you 're right , front 5 In the name 3 One is virtual DOM library .select row The slowdown in testing can be seen as evidence .

On the other hand ,Solid Use fine-grained reactivity , For example 4 The slowest old library in the group . It's strange where this technology reappears , But as we can see ,Solid Solved their weaknesses . Creation time is as fast as update time . And Vanilla JavaScript Of 5% The gap is incredible .

Strangely enough ,Inferno and Solid What we have in common is JSX Templates and React Inspired by API. For all other customizations with optimizations DSL The library of , Maybe you don't expect to find anything at the peak of performance . however , just as HyperApp Shown , Some things have less impact on performance than people think .

Solid take HyperApp and Svelte Join as the third library , Its cubby Vanilla JS Achieve small . however Inferno It's not slack .

It seems that the performance library is small , Sometimes adding more code can improve performance . Better list coordination algorithm , More specific protective measures , More refined updates .

Inferno Maybe larger than some of the libraries in the previous groups , But it is still a 10kb The following Library , Outperforms almost all of .

There? . except Yew And its effect on WASM In addition to the use of , They are the lowest memory consumption frameworks in the competition . Considering their performance , That's not surprising .

This memory consumption figure reflects a very careful consideration of objects , And create closures . A lot of it does come from customization from both libraries JSX transformation .

The improvement of memory performance is very important to Solid Particularly important , because Solid Like most fine-grained reactive Libraries , All will CPU The overhead is replaced by memory consumption . In this comparison , To be able to conquer memory overhead is Solid How to take a technology similar to most of the slowest libraries and make it a big part of the fastest approach .

The first set of results

The sky is the limit .

… Or say Vanilla JavaScript yes . But the performance of our declarative library here is so poor , You'll never know the difference between them . When using DOM when , We should seriously consider the problems we have to face , Many different techniques can render effectively DOM.
We see it here .Solid Won the performance championship with technology that was considered ancient and slow ten years ago , and Inferno It's proven again Virtual DOM Can't do anything effectively .


In the build JavaScript Front end , We have many choices . It's just a quick understanding of the performance overhead of the framework . When it comes to actual performance in an application , User code has a greater impact .

however , What I really want to impress here is , It's important to test your solution and understand performance . Reality is always different from marketing . fictitious DOM It's not guaranteed to be slow . There is no guarantee that the compiler will produce the smallest package . Custom template DSL There's no guarantee that it's the best .

Last , I will provide you with a complete list , Show all libraries together . Just because the library is coming to an end , Doesn't necessarily mean it's slow , But compared with these fierce competitors , It scored worse .

All frames

All frames in a single diagram .


 all JS Frame performance comparison


2020 year Github Before the stars 20 name JavaScript Frame time comparison


Final ranking

All results are added to a list ( The first 1 Name gain 20 branch , Last 1 I got a score ). In the case of a draw , Grade first .

  1. Solid (57)
  2. HyperApp (54)
  3. Inferno (51)
  4. Svelte (51)
  5. Elm (46)
  6. Riot (40)
  7. Preact (39)
  8. Imba (36)
  9. lit-html (36)
  10. Yew (32)
  11. Vue (29)
  12. Mithril (29)
  13. Marko (28)
  14. Alpine (28)
  15. React (19)
  16. Rax (16)
  17. Angular (12)
  18. Knockout (11)
  19. Ractive (8)
  20. Ember (6)