cool hit counter A real-world performance comparison of mainstream front-end frameworks 2017_Intefrankly

A real-world performance comparison of mainstream front-end frameworks 2017


Front-end technologies, especially front-end frameworks, have had an explosive growth in the last few years. Each of them is capable of building great web applications. So how do you as a developer compare and decide which framework to adopt for use in our software projects?

First, we need to make a meaningful comparison, focusing on the following important factors.

1.Real-world operational applications. It can't just be "to do". Often the to-do does not convey the real knowledge and perspective to build real applications.

2.Standardization. Items that meet certain specifications. Hosted on a server that includes backend API, static HTML, CSS & specs.

3.Developed by experts. A consistent, real world project. Ideally, software is built by technologists. This is true, at least most of the time.

So how do we get such a project? The good news is that Mr. Eric Simons has created the real project, which is a medium-sized blog. This project has implemented the same HTML structure, CSS and API specification, but the front-end uses different libraries and frameworks.

I developed a functional implementation in ClojureScript and later did a re-build, I don't consider myself an expert. Thanks to the experts on my team for reviewing my code.

For benchmarking performance, we need to use the following metrics for real-world testing. Includes the following indicators.

1.performance

How long does this app need to be launched available and how long does it take for the content to show up?

2.size

How big is this app installation package and how much space does it take up after installation?

We only compare compiled JavaScript. CSS is the generic variant and is downloaded from the CDN. HTML pages are just as generic, and all technologies are compiled or converted to JavaScript, so only this file needs to be adjusted.

3.Number of lines of code

How many lines of code did the developer use to develop a live specification-based application? Frankly, some applications have a confusing development directory for developers, but it shouldn't have much effect on compilation. My source code only has a src directory.

At the time of writing (as of December 2017), the leading front-end frameworks involved in the review include the following (21CTO note: because we can't add external links to WeChat Public, we've attached them to the software name).

React / Reduc

https://github.com/gothinkster/react-redux-realworld-example-app

Elm

https://github.com/rtfeldman/elm-spa-example

Augular 4+

https://github.com/gothinkster/angular-realworld-example-app

Augular 1.5+

https://github.com/gothinkster/angularjs-realworld-example-app

React / MobX

https://github.com/gothinkster/react-mobx-realworld-example-app

Crizmas MVC

https://github.com/gothinkster/crizmas-mvc-realworld-example-app

CLSJ Keechma

https://github.com/gothinkster/clojurescript-keechma-realworld-example-app

AppRun

https://github.com/gothinkster/apprun-realworld-example-app

Metric 1: Performance

Use Chrome's own LighthouseAudit for rendering tests. The earlier it renders, the better the user experience of using the app. Light is also making the first interaction, which is connected to most applications.

Metric 2: Size

Transfer size is from the Chrome web tag. The GZip compression enhancement response header is returned by the server side along with the body.

The smaller the file, the faster the download and the smaller the parse.

These are dependent on the size of the front-end framework, and all the additional dependencies that are added tell how to make a small bundle using the build tool.

Transfer size (KB) - smaller is better

Metric 3: Number of lines of code

If debugging is the process of removing software bugs, then programming must be the process of adding them in.

- Edsger Dijkstra

We use open source toolscloc to calculate eachrepo warehousessrc in the directory Number of lines of code。 Blanks and comments will not be counted。

What's the point of doing this?

owing to Number of lines of code less the number of, The less likely it is that an error will occur, The lower the code maintenance complexity。

Framework code line ranking - the less the better

summary

About Performance

The above is a comparison of how real frameworks perform in real projects, not using benchmarking tools. These apps are hosted on Github and may have slightly different results than your tests, which is fine.

Several tests are executed for each application and then rounded up to the average.

You can see that most of the libraries and frameworks are in the excellent and good range, and there is no particular difference in performance.

About Size

The size of each app package is actually not very different. We are also comparing similar implementations to see the size of the bundle. Apprun kind of boggles my mind. In terms of lines of code, Elm does an excellent job.

AppRun's package size is only 18.7K

Number of lines of code

This has a bigger impact on us developers。 Number of lines of code more, There will also be more content to maintain, It requires a balance。 Especially when it comes to Strongly typed and dynamic languages。 Strongly typed languages give us more security and overhead, More types need to be declared。

Strongly typed and dynamic languages

strong type:Elm,Angular 4+ together withAppRun

dynamic (science):React| Redux,Angular 1.5 , React | MobX, Crizmas MVC , CLJS Keechma together with CLJS re-frame。

Which ones are better? There is no better or worse, they have their own characteristics between them. Just like TDD (Test Driven Development), some people love it and some people hate it. Choose a software that suits you better and use it to develop great software.

What about frameworks like Vue, Preact, Ember, Svelte, Aurelia, you might ask? It seems they are not on these lists now, you don't have to worry, we will add them to the review later.

To conclude, in a real product run, it is not quite the same as a review. Our world isn't perfect. It has to do with server load, network bandwidth/traffic, and other related factors that cause some differences in the data.

original text:https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-e1cb62fd526c


Recommended>>
1、Tencent cloud server scramble any on board
2、Phishing threat grows as Fortune 500 companies continue to be targeted for payment fraud
3、Taking you inside the Freescale Flashloader4
4、ELK Learning Notes on Elasticsearch Startup Common Errors
5、layerIn the popup layerH5 Player full screen error solvedamp propertiesposter Bottom image filledvideo promotion of the method

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字,当前共

    发送中

    网络异常,请稍后重试

    微信扫一扫
    关注该公众号