ES6为JavaScript开发人员提供了更多的处理方式。但这并不总是一件好事。

最新推荐文章于 2024-11-13 17:24:18 发布

cumian8165

最新推荐文章于 2024-11-13 17:24:18 发布

阅读量516

点赞数

文章标签： python 人工智能 java 大数据编程语言

原文链接：https://www.freecodecamp.org/news/is-es6-destroying-javascript-drowning-in-options-7fc02d25d81c/

版权

by Sam Williams

通过山姆·威廉姆斯

ES6为JavaScript开发人员提供了更多的处理方式。但这并不总是一件好事。 (ES6 gives JavaScript developers more ways to do things. But that isn’t always a good thing.)

I recently wrote an article on ES6 Tips and Tricks which has over 17,000 views and 4,600 claps. One comment was from Bob Munck who said that:

我最近写了一篇有关ES6技巧和窍门的文章，该文章有17,000多次观看和4,600拍手。鲍勃·蒙克 ( Bob Munck )的一则评论是：

This article makes a very strong argument for avoiding JavaScript like the plague in any usage where you want long-term reliability, maintainability, and modifiability.

本文提出了一个非常有力的论据，即在需要长期可靠性，可维护性和可修改性的任何用法中都避免使用像瘟疫之类JavaScript 。

His opinion seems to be that if the language is changing as much as it is, it’s signing its own death sentence.

他的意见似乎是，如果语言的变化尽可能大，它就在签署自己的死刑判决。

ES6、7和8在JavaScript中添加了什么 (What ES6, 7, and 8 are adding to JavaScript)

The newest specifications add a lot of new features to the language. Destructuring, concise object assignment, and symbols to name a few. There are some good things coming through, but this article aims to highlight the problems.

最新的规范为该语言添加了许多新功能。解构，简洁的对象分配和符号仅举几例。经历了一些美好的事情，但是本文旨在突出这些问题。

为什么这是个问题？ (Why is this a problem?)

You want to create a function to receive an object and do some logic upon it. Simple right? But which way are you going to do it?

您想要创建一个函数来接收对象并对其进行一些逻辑处理。简单吧？但是，您打算采用哪种方式？

var data = { a: "print me" };

function method1(data) {    var a = data.a;    console.log(a);}

function method2(data) {    console.log(data.a);}

function method3({ a: info }) {    console.log(info);}

function method4({ a }) {    console.log(a);}

All these methods give you exactly the same result. This is a very trivial example but it holds true for far more complex functions.

所有这些方法给您完全相同的结果。这是一个非常琐碎的示例，但对于更复杂的功能仍然适用。

如何决定使用什么？ (How to decide what to use?)

There are 3 main methods for deciding which way to do this:

有3种主要方法来决定采用哪种方法：

Evaluate and compare the available options.
评估并比较可用选项。
Just use whatever you want to.
只需使用您想要的任何东西。
Have a policy about which to use where.
制定有关在哪里使用的政策。

Each of these has its own advantages and disadvantages.

这些中的每一个都有其自身的优点和缺点。

评估并比较可用选项 (Evaluate and compare the available options)

This seems like an obvious choice, but is it the best one? Doing this every time means that you have to assess the advantages and disadvantages of each method EVERY TIME you write a function. That’s a lot of thinking power that could be used on the problem you’re trying to solve.

这似乎是一个显而易见的选择，但这是最佳选择吗？每次执行此操作意味着您每次编写函数时都必须评估每种方法的优缺点。在您要解决的问题上有很多思考能力。

You and everyone you work with need to know the advantages, disadvantages, and nuances of each method. This doesn’t seem too bad, there are only 4, but then what about dealing with async behavior? Do you use callbacks, Promises, Generators, or Async/Await or a combination of them?

您和与您一起工作的每个人都需要了解每种方法的优点，缺点和细微差别。这看起来似乎还不错，只有4个，但是如何处理异步行为呢？您是否使用回调，Promises，Generators或Async / Await或它们的组合？

This means that everyone you work with needs to understand every bit of the language. I’m guessing by the number of views on my ES6 article that lots of people are still learning some of the more basic language syntax. This means there are very few who understand the complexities of async behavior (which I’m currently trying to understand well myself).

这意味着，与您一起工作的每个人都需要理解所有语言。根据我对ES6文章的看法，我猜很多人还在学习一些更基本的语言语法。这意味着很少有人了解异步行为的复杂性(我目前正在试图自己很好地理解这一点)。

随便使用 (Just use whatever you want)

This is the most common approach, for individuals and in companies. This can be great as it means that you don’t waste time and effort calculating the best choice.

对于个人和公司，这是最常见的方法。这可能很棒，因为它意味着您不会浪费时间和精力来计算最佳选择。

The problems could arise when someone else comes to read, or fix, your code. You may be a JavaScript wiz kid and know all of the newest methods for everything. But the next person who comes to read or alter your work may not have a clue what you’ve done.

当其他人来阅读或修复您的代码时，可能会出现问题。您可能是一个JavaScript的智者，并且知道所有事物的所有最新方法。但是下一位来阅读或更改您的作品的人可能不知道您做了什么。

This also encourages huge style differences between companies and coworkers. It can also mean differences between yourself and a future you, when you learn a new syntax. This isn’t great and makes reading code written by multiple developers much harder.

这也鼓励了公司与同事之间巨大的风格差异。当您学习一种新的语法时，这也可能意味着您自己与未来您之间的差异。这不是很好，并且使读取多个开发人员编写的代码变得更加困难。

政策 (Policy)

Whether it’s company policy or personal policy this eliminates a lot of the problems with the first two approaches. It doesn’t require thinking and it promotes consistency across a code base. Unfortunately, it still has a few problems.

无论是公司政策还是个人政策，这都消除了前两种方法的许多问题。它不需要思考，并且可以促进整个代码库的一致性。不幸的是，它仍然存在一些问题。

With new versions of the ECMAScript specifications regularly coming out, there comes a dilemma. Should the company change its policy to be in keeping with the newest releases? Or write a policy and never change it — missing out on the new features? Or should it be somewhere in between?

随着新版ECMAScript规范的不断发布，出现了一个难题。公司是否应该更改其政策以与最新版本保持一致？还是写一个策略并且永不更改—错过了新功能？还是应该介于两者之间？

New hires have to learn the policy and know how to use it. Yes, you could have a booklet on the policies, but it might take longer to find the spec than to write the line of code. Even if they do find the policy on async behavior, they then need to be able to use it. This could end up suppressing junior devs to simple coding as they don’t want to break the policy, massively restricting their growth.

新员工必须学习该政策并知道如何使用它。是的，您可能有一本关于策略的小册子，但是查找规范可能要比编写代码行花费更长的时间。即使他们确实找到了有关异步行为的策略，也需要能够使用它。这最终可能会抑制初级开发人员使用简单的编码，因为他们不想破坏策略 ，从而极大地限制了他们的增长。

ES6 +真正提供了什么？ (What does ES6+ really provide?)

What is the real difference between the examples I gave above? Are the new syntax easier to read or do they provide any extra functionality?

我上面给出的示例之间的真正区别是什么？新语法是否更易于阅读或提供其他功能？

their suggestions have to {do} with reducing keystrokes and adding tricks that are “neat”.

他们的建议必须{减少}击键并增加“整洁”的技巧。

I really can’t see much, if any, benefit to using destructuring or concise object syntax apart from saving keystrokes. There may be performance benefits or some special magic that I don’t know or understand but:

除了保存击键之外，我真的看不到有什么好处(如果有的话)使用解构或简洁的对象语法。可能会有性能上的好处，或者某些我不知道或不了解的特殊魔术，但是：

None of this performance difference matters, at all! — YDKJS

这些性能差异都无关紧要！ — YDKJS

This quote is kind of taken out of context so I’ll explain. Suppose method X runs 1,000,000 operations/second and method Y runs 500,000 operations/second. That means that X is twice as fast as Y. But the difference in run time is only 1 microsecond. This is 100,000 times slower than what the human eye can perceive. So none of the performance difference matters at all!

该引用是出于上下文，因此我将进行解释。假设方法X运行1,000,000次操作/秒，方法Y运行500,000次操作/秒。这意味着X的速度是Y的两倍。但是运行时间的差异仅为1微秒。这比人眼感知的速度慢100,000倍。因此，性能差异根本不重要！

The savings made by using different methods are probably going to be so tiny that it doesn’t matter. If you’re trying to write the fastest code possible, why are you writing it in JavaScript?

通过使用不同的方法节省的费用可能很小，以至于没有关系。如果您试图编写最快的代码，为什么要用JavaScript编写呢？

ES6还提供了什么 (What ES6 also provides)

Confusion, Complexity, and Options.

混乱，复杂性和选项。

Later on in the discussion with Bob, he said this about JavaScript:

稍后在与Bob的讨论中，他谈到了JavaScript：

You have to decode it to understand what it’s doing. The syntax and semantics of the language are complex, intricate, convoluted. The programmers who debug, maintain, enhance, and revise your code the next day or a decade later will have trouble understanding it. They’ll find themselves wondering if something you did was incredibly clever or incredibly stupid.

您必须对其进行解码以了解其功能。该语言的语法和语义复杂，复杂，复杂。在第二天或十年后调试，维护，增强和修改您的代码的程序员将很难理解它。他们会发现自己想知道您所做的事情是多么的聪明或愚蠢。

This rung so true with me. I’ve found myself looking over code I’ve written, puzzling to figure out what I did and why I did it. While you can write complex and confusing code in any language, JavaScript gives you many opportunities to catch yourself out.

这对我来说真是如此。我发现自己正在查看我编写的代码，困惑地弄清楚我做了什么以及为什么要这样做。尽管您可以使用任何语言编写复杂而令人困惑的代码，但JavaScript却为您提供了许多让自己脱颖而出的机会。

I did this to myself in the ES6 article. In the 4,000 people who read the whole article, only 5 managed to find my error before I corrected it. Which one of these is correct?

我在ES6文章中对自己做了这个。在4,000位阅读整篇文章的人中，只有5个人在纠正错误之前就找到了我的错误。以下哪一项是正确的？

let person = {     name: "John",     age: 36,     job: { company: "Tesco", role: "Store Assistant"}}

function methodA({ name: driverName, age, job.company: company}){ ... }

function methodB({ name: driverName, age, job: { company }){ ... }

I used the wrong one and most people didn’t notice. Only the few that tried it out managed to find the error.

我用错了，大多数人没有注意到。只有少数尝试过的人设法找到了错误。

What do these two methods really provide to justify the extra confusion and complexity? Many people could read, write and understand a function like this:

这两种方法真正提供了什么来证明额外的困惑和复杂性？许多人可以阅读，编写和理解如下功能：

function methodC(person){    var driverName = person.name,        age = person.age,        company = person.job.company;    ...}

Yes I had to write 32 extra characters, but since most of programming is thinking, not typing, are we saving time typing only to spend more of it thinking?

是的，我不得不多写32个字符，但是由于大多数编程都在思考而不是打字，我们是否在节省打字时间只是花了更多时间思考呢？

It’s not just the extra time that the author spends thinking about it, it’s every person that reads that code after that point (often the author again). Complicated code has the “thinking tax” every time it’s read and we, as humans, only have a limited supply of thinking power each day.

这不仅是作者花在思考上的额外时间，而且是每个人在此之后(通常又是作者)阅读该代码的时间。每次阅读时，复杂的代码都会产生“思维税”，而我们作为人类，每天的思维能力有限。

并非一切都不好 (Not all is bad)

While this article seems to be slating ES6, there are some things that increase readability and maintainability. Promises, async functions and async/await all help to abstract the complexities of asynchronous behavior, making code more logical and easier to read. This is what I believe should be focused on, not keystroke saving tricks.

尽管本文似乎将ES6纳入标准，但有些事情可以提高可读性和可维护性。承诺，异步功能和异步/等待都有助于抽象化异步行为的复杂性，从而使代码更具逻辑性且更易于阅读。我认为这应该是重点，而不是按键保存技巧。

长期影响 (Long-Term Effects)

While this probably won’t make any difference to you as a developer, companies with lots of developers may feel the impact. Having to first understand what the syntax is doing before understanding what the code is doing results in unreliable and un-maintainable code.

虽然这对您作为开发人员可能不会有任何影响，但是拥有很多开发人员的公司可能会感受到这种影响。在理解代码在做什么之前必须先了解语法在做什么，这会导致代码不可靠且无法维护。

This could result in JavaScript losing favor for anything that is large, complex, critical, or evolving. This would be a massive market for JavaScript to lose out on.

这可能会导致JavaScript失去对任何大型，复杂，关键或不断发展的事物的青睐。这将是JavaScript失去的巨大市场。

摘要 (Summary)

ES6 gives us even more ways to do the same task.
ES6为我们提供了更多完成同一任务的方法。
You can calculate what is best, do what you want, or have a policy on it.
您可以计算什么是最好的，做自己想做的事情或制定政策。
ES6 gives us new tricks to save some keystrokes.
ES6为我们提供了一些节省按键的新技巧。
These new tricks increase complexity and chances of error while reducing readability.
这些新技巧增加了复杂性和错误机会，同时降低了可读性。
There are some good bits of ES6, increasing readability.
ES6有一些不错的功能，可以提高可读性。
Could the increased complexity and reduced readability make companies less likely to use it in complex, critical, or constantly evolving solutions?
复杂性的增加和可读性的降低是否会使公司减少在复杂，关键或不断发展的解决方案中使用它的可能性？