他们已经已经开始较为RealWorld插件-更为重要是”要做”的插件。 一般来说，”巨集事宜”没传递足够多的科学知识和看法来前述构筑前述的插件。译者：闻数舞动
他们再做一场。 这是2020年，除了2019年，2018年和2017年。
具体来说让我已经开始-当然并非您如果为后端优先选择的较为。 它是对四个各方面的较为小而相较单纯的：操控性，大小不一和十分相近的插件的标识符行。
考虑到这一点儿，它是怎样组织工作的：
他们已经已经开始较为RealWorld插件-更为重要是”要做”的插件。 一般来说，”巨集事宜”没传递足够多的科学知识和看法来前述构筑前述的插件。
它以这种形式控制技术标准-两个合乎这类准则的工程项目-有两个规范化。 提供更多后端API，动态记号和式样。
由研究者编写或审核-两个完全一致的，虚拟世界的工程项目，平庸情况下，该控制技术的研究者应创建或审核。
他们已经已经开始较为甚么样库/架构？
在编写责任编辑时，在RealWorld存储库中有24种Conduit同时实现。 与否有大批的拥护者都没亲密关系。 惟一的前提是-它表明在RealWorld增发网页上。
他们看甚么分项？
操控性-此应用领域须要多久就可以表明文本并显得需用？
大小不一-该插件有多大？ 他们将只较为已校对的JavaScript文档的大小不一。 HTML和CSS对大部份变体都是通用的，并且是从CDN（文本交付网络）下载的。 大部份控制技术都可以校对或转换为JavaScript，因此他们仅调整该文档的大小不一。
标识符行-译者须要多少行标识符就可以基于规范化创建RealWorld插件？ 公平地讲，这类插件有很多麻烦，但如果不会产生重大影响。 他们量化的惟一文档夹是每个插件中的src /。 无论它是自动生成的，都没亲密关系-您仍然须要对其进行维护。
分项1：操控性
他们将检查Chrome随附的Lighthouse Audit的操控性得分。 Lighthouse返回的操控性得分在0到100之间。0是最低的得分。 有关更多详细信息，请参阅《灯塔计分指南》。
审核设置
Lighthouse Audit Settings for all tested apps
基本原理
绘画得越早，某人可以做某事的越早，使用该插件的人的体验就越好。
Performance (points 0–100) — higher is better.
备注
注意：由于缺少演示插件，因此跳过了PureScript。
结论
Lighthouse Audit没睡。 您可以在今年看到未维护/未更新的插件跌破90悬崖。 如果您的插件得分> 90，则可能不会有很大的不同。 也就是说，AppRun，Elm和Svelte确实令人印象深刻。
分项2：大小不一
传输大小不一来自Chrome网络标签。 服务器提供更多的GZIPped响应标头以及响应正文。
这取决于架构的大小不一以及所添加的任何其他依赖项。 同样，构筑构筑工具可以很好地消除捆绑软件中未使用的标识符。
基本原理
文档越小，下载速度越快，并且解析的次数也更少。
Transfer size in KB — fewer is better
备注
由于缺少演示插件，因此跳过了PureScript。
Angular + ngrx + nx，请不要怪我Angular + ngrx + nx-检查Chrome开发工具网络标签，如果我算错了，请告诉我。
Rust + Yew + WebAssembly还包括.wasm文档
结论
Svelte和Stencil社区所做的惊人组织工作将其压缩到20KB以下，确实是一项成就。
分项3：标识符行
使用cloc，他们可以计算每个存储库的src文档夹中的标识符行数。 空白行和注释行并非此计算的一部分。 为甚么这有意义？
如果调试是消除软件错误的过程，则编程必须是将其放入其中的过程— Edsger Dijkstra
基本原理
这说明给定库/架构/语言的简洁程度。 根据规范化，您须要多少行标识符就可以同时实现几乎相同的插件（其中一些具有更多的功能）。
备注
由于cloc无法处理.svelte文档，因此Svelte被跳过。
由于cloc无法处理.riot文档，因此跳过了
riotjs-effector-universal-hot。Angular + ngrx：使用/ libs文档夹完成的LoC计算仅包括.ts和.html文档。 如果您认为这是错误的，请告诉我甚么是正确的数字以及怎样计算。
结论
只有具有重新构架的Imba和ClojureScript就可以在1000LoC下实施该插件。 Clojure以异常表达而著称。 Imba第一场出现在这里（去年是cloc，不知道.imba文档格式），看起来好像会保留下来。 如果您关心自己的LoC，那么您就会知道该怎么做。
常问问题
＃1为甚么此较为中不包含架构X，Y和Z？
因为在RealWorld仓库中尚未完成实施。 考虑做出贡献！ 在您喜欢的优先选择的库/架构中实施该解决方案，他们下次将包括它！
＃2您为甚么称其为现实世界？
因为它不只是两个巨集事宜插件。 在RealWorld中，他们并并非要较为薪水，维护，生产力，学习曲线等。除了其他一些调查可以回答其中的一些问题。 他们所说的RealWorld是两个连接到服务器，进行身份验证并允许用户CRUD的插件，就像虚拟世界中的插件一样。
＃3您为甚么不包括我最喜欢的架构？
请参见上面的＃1，但以防万一，这里又来了：因为在RealWorld存储库中该同时实现尚未完成。 我并没完成大部份的同时实现-这是社区的努力。 如果您想在较为中看到您的架构，请考虑做出贡献。
＃4您包括哪个版本的库/架构？
在编写责任编辑时（2020年3月）需用。 该信息来自RealWorld增发。 我确定您可以在GitHub存储库中找到此文本。
＃5为甚么您忘了包含两个比较为流行的架构？
同样，请参阅＃1和＃3。 在RealWorld存储库中，该同时实现尚未完成； 就这么单纯。
如果您喜欢这篇文章，如果在Twitt
摘要
请记住，这并并非苹果之间的较为。 有些同时实现使用标识符拆分，有些则没。 其中有些托管在GitHub上，有些托管在Now上，有些托管在Netlify上。 您与否仍然想知道哪两个最好？ 我把它留给你。
(责任编辑翻译自Jacek Schae的文章《A RealWorld Comparison of Front-End Frameworks 2020》，参考：
https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1)
