javascript 库
by Sacha Greif
由Sacha Greif
评估任何新JavaScript库时需要考虑的12件事 (The 12 Things You Need to Consider When Evaluating Any New JavaScript Library)
您如何知道一项新技术是否值得投入时间？ (How do you know if a new technology is worth investing time into?)
For this year’s State of JavaScript survey I wanted to dig a little bit deeper, and not only know which tools and libraries people were using, but also why they were using them.
在今年的JavaScript状态调查中，我想更深入地研究，不仅要知道人们在使用哪些工具和库，还要知道他们为什么使用它们。
Which means I had to find a way to translate personal preferences into cold, hard data. After some research, I came up with a 12-point scale that covers the main aspects of picking and working with any technology.
这意味着我必须找到一种将个人偏好转换为冷硬数据的方法。 经过研究，我得出了一个12分制的量表，涵盖了选择和使用任何技术的主要方面。
参加测验！ (Take the Quiz!)
To make it easier for you to apply the scale to any library, I prepared a quick quiz that will take you through all 12 factors and give you a final recommendation:
为了使您更容易将比例尺应用到任何库，我准备了一个快速测验，它将带您了解所有12个因素，并为您提供最终建议：
➡️ 参加12要素测验 (➡️ Take the 12-Factor Quiz)
If you’re not sure what to evaluate, just do it on a library you’re familiar with (React, Vue, jQuery…) and see how well it scores!
如果您不确定要评估什么，只需在您熟悉的库(React，Vue，jQuery…)上进行评估，看看它的得分如何！
Or, you can read on to find out more about each factor, and see how they can be applied.
或者，您可以继续阅读以找到有关每个因素的更多信息，并了解如何应用它们。
注意：关于JavaScript的现状调查 (Note: About The State of JavaScript Survey)
Like I mentioned, I originally developed this scale as a way to get more granular data for the annual State of JavaScript survey.
就像我提到的那样，我最初开发此量表是为了获得年度JavaScript状态调查的更详细的数据。
If you’d like to contribute and help identify the latest trends in the JavaScript ecosystem, go take the survey!
如果您想贡献并帮助确定JavaScript生态系统中的最新趋势， 请参加调查 ！
Now back to the 12-point scale.
现在回到12点刻度。
因素 (The Factors)
Here’s the full list:
这是完整列表：
?️ Features
️功能
? Stability
？ 稳定性
⚡ Performance
表演
? Package Ecosystem
？ 包装生态
? Community
？ 社区
? Learning Curve
？ 学习曲线
? Documentation
？ 文献资料
? Tooling
？ 工装
?️ Track Record
️历史记录
? Team
？ 球队
⚖️ Compatibility
⚖️兼容性
? Momentum
？ 动量
I’ll explain the importance of each factor, and also give you a scoring grid to show you how to evaluate it. Let’s go through the list!
我将解释每个因素的重要性，并为您提供一个评分网格，向您展示如何对其进行评估。 让我们浏览一下清单！
️功能 (?️ Features)
The first reason why you’d pick any technology is likely for what it does.
选择任何技术的第一个原因很可能就是它的作用。
But the key question here is knowing how far to go. React is probably the most popular front-end library out there right now, but a common complaint is that it just doesn’t do enough, leaving things like routing and state management to third-party libraries like React-Router and Redux.
但是这里的关键问题是知道要走多远。 React可能是目前最流行的前端库，但是一个普遍的抱怨是它做不到，将路由和状态管理之类的东西留给了第三方库，如React-Router和Redux。
In fact, this is a big part of the appeal of Vue, React’s biggest competitor. By providing official packages for these common use cases, it’s managed to offer a more well-rounded solution and gain a lot of ground.
实际上，这是React最大竞争对手Vue吸引力的很大一部分。 通过为这些常见用例提供官方程序包，它设法提供了更加完善的解决方案并获得了很多基础。
Then again, take this too far and you might end up with a bloated, complex framework that tries to be everything to everyone.
再说一次，将其推到太远，您可能最终会得到一个肿的，复杂的框架，该框架试图将所有人的所有内容都包含在内。
So sometimes, a minimalist approach is what’s needed. Libraries like Lodash or Ramda let you replace your messy nested for loops with terse functional expressions, and that’s enough to make them invaluable tools.
因此有时需要一种极简主义的方法。 像Lodash或Ramda这样的库使您可以用简洁的函数表达式替换嵌套的for循环，这足以使它们成为无价的工具。
Again, it’s all about finding the right equilibrium!
再次，这都是要找到正确的平衡！
计分系统 (Scoring System)
A: Unlocks things that were just not possible before.
答：解锁以前不可能完成的事情。
B: Lets you do the same things as before, but in a better way.
B：让您做与以前相同的事情，但是做得更好。
C: Does less than current solutions.
C：比目前的解决方案少。
？ 稳定性 (? Stability)
You can have the most elegant, full-featured framework ever, but it won’t amount to much if developers run into errors every two minutes.
您可以拥有有史以来最优雅，功能最全的框架，但是如果开发人员每两分钟遇到一次错误，它的作用将不大。
For that reason, a lot of tools in the current JavaScript ecosystem focus on adding stability and security to the stack. Look no further than TypeScript and Flow’s successes, or even languages like Reason.
因此，当前JavaScript生态系统中的许多工具都致力于增加堆栈的稳定性和安全性。 除了TypeScript和Flow的成功，甚至是诸如Reason之类的语言之外，别无所求。
And on the data layer side, GraphQL’s type system also contributes to making sure everything runs smoothly.
在数据层方面，GraphQL的类型系统还有助于确保一切顺利进行。
计分系统 (Scoring System)
A: Fewer bugs, and issues become easier to debug and solve.
答：错误更少，问题变得更容易调试和解决。
B: Adopting the technology does not have an impact on your software’s stability.
B：采用该技术不会影响软件的稳定性。
C: New bugs and issues arise as a direct consequence of adopting the technology.
C：采用该技术的直接结果是出现了新的错误和问题。
表演 (⚡ Performance)
If you’ve ever trained martial arts, you’ll know that one of the best possible attributes you can have on your side is speed, not strength.
如果您曾经接受过武术训练，那么您会知道，可以拥有的最佳属性之一就是速度 ，而不是力量。
Similarly, all the features in the world are no use if it takes your app 15 seconds to load. By that time, the user has already closed the tab and you’ve lost the fight before it even begun!
同样，如果您的应用需要15秒钟才能加载，世界上的所有功能都将无用。 到那时，用户已经关闭了选项卡，而您甚至在战斗开始之前就已经输了！
In the JavaScript ecosystem, look no further than Preact to see an example of focusing on speed: its API is identical to React, so it’s not trying to compete on feature strength. But by being lighter-weight and faster to load than React, it lets you save precious milliseconds and improve your webapp’s performance.
在JavaScript生态系统中，除了Preact以外，您还可以看到专注于速度的示例：它的API与React相同，因此它并不试图在功能强度上竞争。 但是，与React相比，它重量更轻，加载速度更快，因此可以节省宝贵的毫秒数并提高webapp的性能。
计分系统 (Scoring System)
A: Lighter bundle, faster load times, or other performance improvements.
答：更轻的捆绑包，更快的加载时间或其他性能改进。
B: Adopting the technology does not have an impact on your software’s performance.
B：采用该技术不会对软件的性能产生影响。
C: Adopting the technology slows down your app measurably.
C：采用这项技术会明显降低您的应用速度。
？ 包装生态 (? Package Ecosystem)
Before investing in any new technology, it’s important to look at the ecosystem that has developed around it.
在投资任何新技术之前，重要的是要研究围绕它开发的生态系统。
Not only is a vibrant package ecosystem a huge time-saver since it lets you piggy-back on the work of others, but it’s also a sign that the technology has reached a certain maturity level. For that reason, well-maintained third-party packages are one of the best possible signs that developers have embraced a technology for the long run.
充满活力的软件包生态系统不仅可以节省大量时间，因为它使您可以背负其他人的工作，而且还表明该技术已达到一定的成熟度。 因此，维护良好的第三方程序包是开发人员长期采用这项技术的最好标志之一。
计分系统 (Scoring System)
A: Ecosystem has unambiguous solutions for common concerns; third-party packages are well-maintained and well-documented.
答：生态系统对于共同关注的问题有明确的解决方案； 第三方程序包维护良好且有据可查。
B: Budding package ecosystem with many competing new options.
B：具有许多竞争性新选项的包包生态系统。
C: No package ecosystem to speak of, lots of manual work required.
C：没有软件包生态系统可言，需要大量手工工作。
？ 社区 (? Community)
Another factor to consider is the overall community. A dedicated forum or Slack channel can be a huge help when running into issues.
另一个要考虑的因素是整个社区。 遇到问题时，专用的论坛或Slack频道可以提供巨大帮助。
It’s also helpful to have an existing repository of Stack Overflow answers to look up. And of course, a well-maintained GitHub issues page is a must!
查找现有的Stack Overflow答案存储库也很有帮助。 当然，必须维护良好的GitHub问题页面！
计分系统 (Scoring System)
A: Forum and/or chatroom (Slack/Discord/etc.) with daily activity, GitHub issues addressed within a day. Many answered Stack Overflow questions.
答：具有日常活动的论坛和/或聊天室(Slack / Discord / etc。)，一天之内解决GitHub问题。 许多回答了堆栈溢出问题。
B: Forum and/or chatroom with infrequent activity.
B：不经常活动的论坛和/或聊天室。
C: No community beyond GitHub.
C： GitHub之外没有社区。
？ 学习曲线 (? Learning Curve)
An easy learning curve makes it much more likely that developers will give your framework or library a shot. It’s tempting to think that if a technology is truly disruptive people will push through any obstacle, but it’s often just not true.
简单易学的曲线使开发人员更有可能向您的框架或库提供帮助。 人们很容易想到，如果一项技术真正具有破坏性，人们会克服任何障碍，但事实往往并非如此。
A closely related (yet sometimes opposite) concept is the “adoption” curve. When it first launched, Meteor was extremely easy to use (at least compared to existing alternatives) but it required you to adopt its entire stack at once, making it very hard to implement for existing projects.
一个密切相关的概念(但有时是相反的)是“采用”曲线。 首次启动时， Meteor非常易于使用(至少与现有的替代产品相比)，但它要求您立即采用其整个堆栈，这使得为现有项目实施非常困难。
React is also famous for its rough learning curve: for developers used to separating HTML and JavaScript, having to use JSX can be tough. Vue on the other hand makes it a lot easier to get started without having to rethink the way you think about front-end coding as much.
React还以其粗糙的学习曲线而闻名：对于习惯于分隔HTML和JavaScript的开发人员，不得不使用JSX可能很困难。 另一方面，Vue使上手变得容易得多，而不必重新考虑您对前端编码的思考方式。
计分系统 (Scoring System)
A: Possible to get started in a single day.
答：可以在一天内开始使用。
B: About a week required before becoming productive.
B：大约需要一个星期才能变得富有成效。
C: More than a week required to learn the basics.
C：学习基础知识需要一个多星期。
？ 文献资料 (? Documentation)
A big part of an easy learning curve is having great documentation. This is harder to achieve than it sounds, as the people writing the documentation are usually the ones with the most experience; meaning they’re also furthest removed from the new developer experience.
易于学习的曲线的很大一部分是拥有出色的文档。 这比听起来要难得多，因为编写文档的人员通常是经验最丰富的人员。 意味着它们也距离新的开发人员体验最远。
So writing good documentation requires forgetting what you know for a second and putting yourself in the shoes of someone just discovering your technology.
因此，编写好的文档需要一秒钟忘记您所知道的一切，而将自己置于刚发现您的技术的人的脚下。
It also requires anticipating common issues, understanding the user’s mental model, and most of all keeping everything up to date as your codebase changes! And all of that takes precious time away from actual coding…
它还需要预见常见问题，了解用户的思维模式，并且最重要的是，随着代码库的更改，一切都保持最新！ 所有这些都花费了宝贵的时间，与实际的编码相比……
Given all these factors, you can understand why good documentation is a rare and valuable thing!
考虑到所有这些因素，您可以理解为什么好的文档是一件稀有且有价值的事情！
计分系统 (Scoring System)
A: Dedicated documentation site, screencasts, example projects, tutorials, API documentation, and well-commented code.
答：专用文档站点，截屏视频，示例项目，教程，API文档和注释良好的代码。
B: Basic Read Me and API documentation.
B：基本的自述文件和API文档。
C: Very succinct Read Me, the only way to know how to use the library is to look at its code.
C：非常简洁，请读我，了解如何使用该库的唯一方法是查看其代码。
？ 工装 (? Tooling)
Just like documentation, tooling is one of these things that may seem like a secondary distraction to some maintainers, but is actually vital to the popularity and success of any technology.
就像文档一样，工具是其中的一部分，对于某些维护者而言，这似乎是次要的事，但实际上对于任何技术的普及和成功至关重要。
I believe a big reason behind Redux’ success is its amazing Devtools browser extension, which lets you visualize the Redux store and actions in a very user-friendly way. Similarly, VS Code’s great TypeScript support has done wonders for its adoption.
我相信Redux成功的一个主要原因是其出色的Devtools浏览器扩展，它使您能够以非常用户友好的方式可视化Redux存储和操作。 同样，VS Code对TypeScript的强大支持为其采用提供了奇迹。
计分系统 (Scoring System)
A: Two or more of: browser extensions, text editor extensions, CLI utility, dedicated third-party SaaS services.
答：两个或多个：浏览器扩展，文本编辑器扩展，CLI实用程序，专用的第三方SaaS服务。
B: One of: browser extensions, text editor extensions, CLI utility, dedicated third-party SaaS services.
B：以下之一：浏览器扩展，文本编辑器扩展，CLI实用程序，专用第三方SaaS服务。
C: No external tooling.
C：没有外部工具。
️历史记录 (?️ Track Record)
At the end of the day, even the most elegant, best-documented library out there will be easily dismissed as nothing more than a flash in the pan if it’s only been around for six months.
归根结底，即使只有六个月，即使是最优雅，文档最丰富的图书馆也很容易被淘汰，无非就是一闪而过。
We can all recount stories of adopting the “next big thing”, only to come crawling back to good old Rails/PHP/*insert tried-and-true technology here* when things start to go bad.
我们都可以讲述采用“下一件大事”的故事，只是在事情开始变糟时才回到使用良好的旧Rails / PHP / *在这里插入久经考验的技术*。
For that reason, nothing can beat a solid track record. Express is one of the examples around: it was originally released in 2010, yet is still considered the default Node.js server framework despite the JavaScript ecosystem’s fast-moving pace.
因此，没有什么可以超越可靠的记录了。 Express是其中的一个例子：它最初于2010年发布，尽管JavaScript生态系统发展Swift，但仍被视为默认的Node.js服务器框架。
计分系统 (Scoring System)
A: Has been around for 4+ years, adopted my major companies and well-known tech consultancies.
答：已有4年以上的历史了，采用了我的主要公司和知名的技术咨询公司。
B: Has been around for 1–4 years, used by early adopters and smaller-scale consultancies.
B：已经存在1-4年，被早期采用者和较小规模的咨询公司使用。
C: Has been around for less than a year, no real adoption yet.
C：已经存在不到一年了，还没有真正的采用。
？ 球队 (? Team)
Not all projects have an existing track record. When a library is brand new, how do you judge its potential? One reliable way it to look at who’s behind it.
并非所有项目都有现有的跟踪记录。 当图书馆是全新的时，您如何判断其潜力？ 一种查看背后原因的可靠方法。
When React first came out, the fact that none other than Facebook was behind it was a big argument to at least try it out. Facebook then went on to release Relay and GraphQL, showing that React’s success wasn’t a fluke!
当React刚问世时，除了Facebook之外没有其他事实，这至少是一个尝试的大争论。 然后，Facebook继续发布Relay和GraphQL，表明React的成功不是a幸！
And larger companies also have more resources to invest: Google has been able to continue maintaining the original Angular.js even after releasing newer, incompatible versions.
大型公司也有更多的投资资源：即使发布了不兼容的新版本，Google仍然能够继续维护原始的Angular.js。
Of course this doesn’t mean lone maintainers can’t also create major innovations. This is how Vue.js was born after all, to say nothing of 99% of all open-source software out there.
当然，这并不意味着孤独的维护者也不能创造重大创新。 毕竟，这就是Vue.js的诞生方式，在所有开源软件的99％中，更不用说了。
计分系统 (Scoring System)
A: Maintained by a major company with a dedicated open-source team.
答：由一家大型公司维护，并拥有专门的开源团队。
B: Maintained by a medium-sized team of engineers with solid individual track records.
B：由具有可靠个人记录的中型工程师团队维护。
C: Lone maintainer working independently.
C：单独的维护者独立工作。
⚖️ 兼容性 (⚖️ Compatibility)
The great thing about adopting cutting-edge libraries is that they usually evolve quite fast. Sadly, that can also be a major downside!
采用前沿库的最大好处是它们通常会快速发展。 可悲的是，这也可能是一个重大缺点！
A fast improvement rate can also mean frequent breaking changes as new best practices replace old patterns, leaving early adopters to pay the refactoring costs.
快速的改进速度也意味着随着新的最佳实践替代旧模式而频繁发生重大变化，从而使早期采用者需要支付重构成本。
React Router generated a lot of gripes when they decided to completely change their API between versions 3 and 4. And so did Angular when they made the switch from Angular.js to the new “just Angular”.
当他们决定在版本3和版本4之间完全更改API时，React Router产生了很多困扰。当他们从Angular.js切换到新的“ just Angular”时，Angular也是如此。
Frequent updates are fun and exciting when you’re just starting out a new project, but once your app is up and running in production the last thing you want is having to spend weeks of refactoring and debugging every time a new version of a library comes out.
当您刚开始一个新项目时，频繁的更新既有趣又令人兴奋，但是一旦您的应用启动并在生产中运行，您想要做的最后一件事就是每次使用新版本的库时都要花费数周的重构和调试时间。出来。
计分系统 (Scoring System)
A: Updates are mostly backwards-compatible, deprecations are handled with warnings, and incompatible older versions are maintained for two years or more.
答：更新主要是向后兼容的，弃用将通过警告进行处理，不兼容的较旧版本将保留两年或更长时间。
B: Breaking changes do happen but are well documented and are rolled out gradually.
B：确实发生了重大变化，但有据可查，并逐步推出。
C: Frequent breaking updates requiring major refactoring without the proper guidance.
C：频繁中断的更新需要在没有适当指导的情况下进行重大重构。
？ 动量 (? Momentum)
Last but not least, momentum. In other words, hype.
最后但并非最不重要的一点是动量。 换句话说，炒作。
Hype is often seen as a bad thing (“don’t fall victim to the hype”), as an indicator of style over substance. But it doesn’t always have to be.
炒作通常被视为一件坏事(“不要成为炒作的受害者”)，它是风格超过实质的指标。 但这并不总是必须的。
With enough momentum, a new software project can attract more users and more contributors, which means bugs are found and fixed faster, a package ecosystem can develop, and everybody ultimately ends up better off.
有了足够的动力，一个新的软件项目就可以吸引更多的用户和更多的贡献者，这意味着可以更快地发现并修复错误，可以开发出软件包生态系统，并且最终每个人都会变得更好。
But yes, there’s also the other side of the coin: too much hype too early can expose potential users to an unfinished version riddled with issues, turning them off for good. Like they say, you only get one chance at making a first impression.
但是，是的，还有另外一面：过早的大肆宣传会使潜在用户暴露于未完成的版本，其中充斥着各种问题，因此将其永久关闭。 就像他们说的那样，您只有一次留下第一印象的机会。
计分系统 (Scoring System)
A: Hype Level Over 9000: top of Hacker News, thousands of GitHub stars, talks at major conferences.
答： 9000级炒作：黑客新闻的顶部，数千个GitHub明星在主要会议上进行演讲。
B: Some interest around the initial launch, hundreds of GitHub stars.
B：几百个GitHub明星对首次发布感到有些兴趣。
C: Lone developer toiling away in obscurity. One day I’ll show them! I’ll show them all!!
C：孤独的开发商苦苦挣扎。 有一天我会给他们看！ 我会给他们看的！！
更新：更多因素 (Update: A Few More Factors)
Some of you suggested a few more great factors to look at. Something to consider for a potential version 2.0 of the scale!
你们中的一些人提出了一些值得关注的重要因素。 可能要考虑的规模2.0版！
Scalability: how well does the technology work for large projects.
可伸缩性 ：该技术在大型项目中的运行情况。
Adoption: who else is using the technology currently?
收养 ：目前还有谁在使用这项技术？
Compatibility: how well does the technology work with other existing techs?
兼容性 ：该技术与其他现有技术的融合程度如何？
Decoupling: how easy is it to migrate out of the technology if you want to stop using it?
解耦 ：如果您想停止使用该技术，迁移到该技术有多容易？
案例研究：Apollo客户 (Case Study: Apollo Client)
Let’s put our scoring system to the test by applying it on an actual, real-world library: Apollo Client.
让我们将评分系统应用于实际的真实库中： Apollo Client ，以将其用于测试。
Apollo is a GraphQL client, in other words it’s a library that will query a GraphQL endpoint and load its data on the client for you. It also handles things like caching, making sure data is not duplicated, and sending said data to your front-end library of choice.
Apollo是GraphQL客户端，换句话说，它是一个库，它将查询GraphQL端点并为您在客户端上加载其数据。 它还处理诸如缓存，确保数据不重复以及将所述数据发送到您选择的前端库之类的事情。
Let’s see how it does on our scoring system!
让我们看看它如何在我们的评分系统中发挥作用！
特点：B (?️ Features: B)
Apollo gives you better ways to query data, so it’s more of a gradual improvement over existing tools.
Apollo为您提供了更好的查询数据的方法，因此它是对现有工具的逐步改进。
？ 稳定性：A (? Stability: A)
Adopting Apollo and GraphQL does make it easier to reason about your data and track down issues.
采用Apollo和GraphQL确实使推理数据和查找问题更加容易。
表演：B (⚡ Performance: B)
Apollo does include tools to optimize your data loading, but overall should not have an outsized impact on your app’s performance either way.
Apollo确实包含用于优化数据加载的工具，但无论哪种方式，总体上都不会对应用程序的性能产生太大的影响。
？ 包装生态系统：A (? Package Ecosystem: A)
Apollo supports packages called links in order to enable extra features.
Apollo支持称为链接的软件包，以启用其他功能。
？ 社区：B (? Community: B)
Apollo does have a very active Slack chatroom, but in my experience questions can sometimes go unanswered and it can be hard to get replies from busy core team members.
Apollo确实有一个非常活跃的Slack聊天室，但根据我的经验，问题有时可能无法得到解答，并且很难从繁忙的核心团队成员那里得到答复。
？ 学习曲线：B (? Learning Curve: B)
Learning all the nuances of Apollo can actually be a challenge, especially if you’re learning to use GraphQL at the same time.
学习Apollo的所有细微差别实际上可能是一个挑战，特别是如果您正在学习同时使用GraphQL。
？ 说明文件： (? Documentation: A)
Good, well-maintained documentation provided for multiple front-end frameworks, as well as example codebases.
为多个前端框架以及示例代码库提供了良好，维护良好的文档。
？ 工具：A (? Tooling: A)
Browser extension and a dedicated metrics platform.
浏览器扩展和专用的度量平台 。
️记录：B (?️ Track Record: B)
Apollo itself is still fairly new, but so is the GraphQL space in general.
Apollo本身还很新，但是GraphQL空间也是如此。
？ 队伍：A (? Team: A)
Highly competent and well-funded team with experience launching other open-source projects (Meteor).
高素质，资金雄厚的团队，具有启动其他开源项目( Meteor )的经验。
⚖️稳定性：B (⚖️ Stability: B)
Breaking update from v1 to v2, but overall good stability and backwards compatibility since.
从v1到v2的更新中断，但此后总体上具有良好的稳定性和向后兼容性。
？ 动量：B (? Momentum: B)
Apollo may not be a household name yet, but it’s the dominant player in its niche despite Relay’s head start.
阿波罗可能还不是家喻户晓的名字，但尽管接力先发，但它仍是其利基市场的主导者。
总成绩：A？ (Overall Grade: A ?)
With 29 points out of a maximum of 36, Apollo ends up doing really well! Even if there will always be areas for improvement, it’s easy to see why it’s been adopted in production by many teams who need a reliable way to deal with GraphQL data.
阿波罗(满分36分)满分为29分，成绩斐然！ 即使总有需要改进的地方，也很容易看出为什么许多需要可靠方法来处理GraphQL数据的团队在生产中采用了它。
其他方法 (Other Approaches)
The folks at NPMS have implemented a similar rating system, automated from looking at GitHub and NPM data. This makes their scoring less subjective, but no the other hand it doesn’t cover things like documentation or community.
NPMS的人们已经实施了类似的评级系统 ， 该系统通过查看GitHub和NPM数据而自动实现。 这使他们的得分不太主观，但是另一方面，它也没有涵盖文档或社区等内容。
On the raw data side, you can also get some cool stats with NPM Trends:
在原始数据方面，您还可以通过NPM趋势获得一些很酷的统计信息：
And learn more about which libraries are currently popular on Best of JS:
并了解有关哪些库当前在Best of JS上的更多信息：
And of course, there’s always last year’s State of JS survey results:
当然，总会有去年的JS状况调查结果 ：
What about you, how do you usually evaluate libraries? Leave a comment to let me know!
那您呢，您通常如何评估库？ 发表评论让我知道！
结论 (Conclusion)
This scale is by no means an absolute measure of a library’s worth. After all this will always be mostly subjective, and strongly depends on your project and your needs.
这种规模绝不是衡量图书馆价值的绝对标准。 毕竟，这将始终是主观的，并且在很大程度上取决于您的项目和需求。
Still, we’re hoping it can serve as a useful starting point. If nothing else, it can serve as a checklist to make sure you’re not overlooking anything important before making that big jump into the future!
不过，我们希望它可以作为一个有用的起点。 如果没有别的，它可以用作检查清单，以确保您在迈入未来之前大步向前迈进！
javascript 库
1021
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
