追逐神迹
One of the very first projects I ever worked on as a professional was a relatively large site with tons of legacy code. Legacy code brings many headaches. My favorite example was opening a few pages to find that these pages used not one, not two, but three different JavaScript frameworks!
我曾经作为专业人员从事的最早的项目之一是一个相对较大的站点，其中包含大量的旧代码。 旧版代码带来许多麻烦。 我最喜欢的示例是打开一些页面，发现这些页面使用的不是一个，不是两个，而是三个不同JavaScript框架！
The developers were overworked and the site had never gotten enough budget to give it the rebuild it needed. Granted, they could have stuck with the original framework included but the problem was that as each of the frameworks faded and gave way to the next one, the ecosystem and community around them online dried up and shriveled.
开发人员工作过度，该站点从未获得足够的预算来对其进行重建。 当然，它们本可以保留原来的框架，但是问题是，随着每个框架逐渐淡化并让位于下一个框架，在线周围的生态系统和社区干dried了。
There’s a happy ending to this story. Eventually, jQuery was used and all the other frameworks were removed (talk about a big performance win!). jQuery never suffered from the same fate as the other frameworks the team had tried to use—its ecosystem only continued to grow and flourish as time went on.
这个故事有个幸福的结局。 最终，使用了jQuery，并删除了所有其他框架(谈论巨大的性能胜利！)。 jQuery从未遭受与团队尝试使用的其他框架相同的命运–随着时间的流逝，其生态系统仅持续增长和繁荣。
Of course, the snarky side of me would be happy to point out that had they used good old fashioned JavaScript, the problem would have never manifested in the first place.
当然，我傻乎乎的一面会很高兴地指出，如果他们使用的是老式JavaScript，那么问题就不会在一开始就显现出来。
That isn’t entirely fair though, is it? There’s a reason people build these tools. Tools exist because somewhere someone thought one would be helpful in some way. So they created it and they shared it. And frankly, that’s pretty darn awesome.
但这并不完全公平，是吗？ 人们构建这些工具是有原因的。 之所以存在工具，是因为有人认为有人会以某种方式提供帮助。 因此，他们创建了它并共享了它。 坦率地说，这真是太棒了。
So maybe that’s why some people were a little upset when they read the post going around that pokes a little fun at the current state of learning JavaScript. The post was intended to be humorous (I laughed), but to some it felt like a critique of the ecosystem and those contributing to it.
因此，也许这就是为什么某些人在阅读有关该文章的文章时有些不高兴的原因，这使人们对学习JavaScript的当前状态有些兴趣 。 该帖子原本是幽默的(我笑了)，但对某些人来说，它就像是对生态系统及其贡献者的批评。
To be clear, I don’t think that was the point of the article. The thing is, it’s not the ecosystem that’s the problem. It’s great that we have a plethora of options available to us. It beats the alternative. No, the problem is the way we’ve chased after each new tool that comes along and even more concerning to me, the way we teach.
需要明确的是，我认为这不是本文的重点。 问题是，不是生态系统成为问题。 非常高兴我们有很多可用的选择。 它胜过其他选择。 不，问题在于我们追赶出现的每个新工具的方式，对我而言，更令人关注的是我们的教学方式。
Our industry loves tools, and not without reason. Tools help us to be more productive. They can help to automate low-hanging fruit that is critical to the success of a project. They can help to obfuscate tricky browser compatibility issues. The can free us up to focus on the bigger, more interesting challenges presented. Tools are generally a “Good Thing”.
我们的行业喜欢工具，并非没有道理。 工具可以帮助我们提高生产力。 它们可以帮助实现对项目成功至关重要的低垂成果。 它们可以帮助消除棘手的浏览器兼容性问题。 这样可以使我们解放出来，专注于提出的更大，更有趣的挑战。 工具通常是一件好事。
Unfortunately our love of tools has lead to an unhealthy mentality where we constantly feel the need to seek out the next great tool to be released.
不幸的是，我们对工具的热爱导致了一种不健康的心态，我们不断感到需要寻找下一个要发布的优秀工具。
Build scripts are a fun example. Grunt came out and was really instrumental in getting the front-end community as a whole to give more serious consideration to having a formal build process. Just as people started to adopt it more frequently, the early adopters were already starting to promote Gulp as a superior option. As some developers tried to make the shift, still others jumped on Broccoli. For many, it seemed that just as they started to understand how to use what had been the new best option, an even newer best option would become available.
构建脚本是一个有趣的示例。 Grunt出现了，并且确实在使整个前端社区成为一个整体方面更加认真地考虑了正式的构建过程。 就像人们开始更频繁地采用它一样，早期采用者已经开始将Gulp推广为更好的选择。 当一些开发人员试图做出改变时，其他开发人员跳上了Broccoli 。 对于许多人来说，它似乎就像他们开始了解如何使用什么一直是新的最佳选择，一个更新最好的选择将变得可用。
Mostly, I think the evolution is healthy. We should be iterating and improving on what we know. And each build tool does things a little differently and different people will find one or the other fits their workflow a bit better. The problem is if we blindly race after the next great thing without stopping to consider the underlying problem that actually needs solving.
通常，我认为进化是健康的。 我们应该对我们所知道的进行迭代和改进。 每个构建工具在做事上都有一些不同，不同的人会发现一个或另一个适合他们的工作流程。 问题是，如果我们盲目地追赶下一件伟大的事情，而又不停地考虑实际上需要解决的根本问题。
I don’t know exactly what fosters this mentality, but certainly the way we approach teaching JavaScript (and web technology as a whole) doesn’t help.
我不知道是什么导致了这种心态，但是，肯定的是，我们讲授JavaScript(以及整个Web技术)的方法无济于事。
If you’ve ever tried to find resources about how to use vanilla JavaScript to solve a given issue, you’ll know what I’m talking about. It’s rare to find a post or talk that doesn’t throw a tool at the problem. A common critique you could hear early in the days of jQuery really taking off was that too many posts assumed the use of jQuery. You’ve likely heard similar critiques of using Sass to demo something where you could’ve demoed it using regular old CSS. When the fictional character in the previously mentioned post responds to a simple question with “you should learn React”, it may be a little contrived but it isn’t uncommon.
如果您曾经尝试找到有关如何使用普通JavaScript解决特定问题的资源，那么您会知道我在说什么。 很少找到没有引发问题的工具的帖子或谈话。 在jQuery诞生初期，您经常听到的一种常见批评是，太多的帖子都假定使用jQuery。 您可能听说过类似的批评，即使用Sass演示某些可以使用常规旧CSS演示的内容。 当前面提到的帖子中的虚构人物用“您应该学习React”回答一个简单的问题时，可能有些人为的作法，但这并不少见。
Just as each additional tool adds complexity to our development environment, each additional tool we mention when teaching someone about how to build for the web introduces complexity to the learning environment. That, I think, was the point of the post going around. Not that the ecosystem is flawed, not that the diversity of options is a bad thing, but that when someone wants to find an answer to a problem, the response they get frequently starts with “use this tool, then set this up”.
就像每个其他工具都会给我们的开发环境增加复杂性一样，我们在教某人如何构建Web时提到的每个其他工具也会给学习环境带来复杂性。 我认为这就是帖子的重点。 并不是说生态系统存在缺陷，不是说选择的多样性是一件坏事，而是当某人想找到问题的答案时，他们经常会从“使用此工具，然后进行设置”开始做出回应。
It’s ok—good even—to teach new tools that may be helpful. But when we do so, we need to be careful to present why these tools may be helpful as well as when they may not be. We need to be careful to separate the underlying issue from the tool itself, so that the two do not become conflated. Let people learn what’s going on under the hood first. Then they can make a determination themselves as to the necessity of the tool.
教可能有用的新工具也可以，甚至可以。 但是，当我们这样做时，我们需要小心地说明为什么这些工具可能有用，以及什么时候可能没有帮助。 我们需要谨慎地将潜在问题与工具本身分开，以免两者混为一谈。 让人们首先了解引擎盖下发生的事情。 然后他们可以自己确定该工具的必要性。
I’ve said it before, but the most valuable development skill to develop is not to learn Node.js. Or React. Or Angular. Or Gulp. Or Babel. The most valuable thing you can do is take the time to learn the core technologies of the web: the network stack, HTML, CSS and JavaScript. The core understanding of the web serves as your foundation when making decisions about tooling.
我已经说过了之前 ，但最有价值的开发技巧，开发不是学习Node.js的 或React。 或角形。 或大吃一惊。 或通天塔。 您可以做的最有价值的事情就是花时间学习网络的核心技术：网络堆栈，HTML，CSS和JavaScript。 在做出有关工具的决策时，对Web的核心理解是您的基础。
Those tools are useful in the right context, but you need to be able to understand what that context is. Whenever you come across an issue that needs solving, think about what the underyling problem actually is. Only once you’ve identified that should you consider whether you might want to use a tool to help you address the problem, and which tool that might be.
这些工具在正确的上下文中很有用，但是您需要能够了解该上下文是什么。 每当您遇到需要解决的问题时，请考虑一下潜在问题。 仅在确定了这一点后，您才考虑是否应该使用一种工具来帮助您解决问题，以及应该使用哪种工具。
For the tool itself, there’s a few things you might want to consider. Here’s what I tend to look at:
对于工具本身，您可能需要考虑一些事项。 这是我倾向于看的东西：
Who benefits from the use of this tool and how? Someone has to benefit, or else this tool doesn’t really need to be here, does it? If you can’t articulate who is benefitting and how they’re benefitting, then it’s probably not a tool that needs to be used on this particular project.
谁将从此工具的使用中受益，以及如何受益？ 有人必须受益，否则确实不需要使用此工具，不是吗？ 如果您无法明确指出谁在受益，以及他们如何从中受益，那么这可能不是该特定项目需要使用的工具。
Who suffers and how? There is always a trade-off. Always. Someone is paying for the use of this tool in some way. You could be adding complexity to the development environment or, in the worst case scenario, it could be your users who are paying the price. You need to know the cost so that you can compare it to the benefits and see if its worthwhile.
谁受苦，如何受苦？ 总会有一个权衡。 总是。 有人以某种方式为使用此工具付费。 您可能会增加开发环境的复杂性，或者在最坏的情况下，您的用户可能会为此付出代价。 您需要知道成本，以便可以将其与收益进行比较，看看它是否值得。
How does it fail? I’m stealing this from the fine folks at Clearleft, but I love the way this frames the discussion. What happens when something goes wrong? Like it or not, the web is a hostile environment. At some point, for someone, something will break.
它怎么会失败？ 我是从Clearleft的好朋友那里偷来的 ，但是我喜欢这种讨论的方式。 出问题了怎么办？ 不管喜欢与否，网络是一个敌对的环境。 在某些时候，对于某人来说，某些东西会破裂。
Does the abstraction feed the core? If it’s a framework or library, does it help to strengthen the underying core technologies in a meaningful way. jQuery to me is a good example of this. jQuery was a much friendlier way to interact with the DOM and some of the work they did ended up influencing what you can use do with JavaScript, and how that should work.
抽象是否养活了核心？ 如果是框架或库，是否有助于以有意义的方式增强底层核心技术。 对我来说，jQuery是一个很好的例子。 jQuery是一种与DOM进行交互的友好得多的方式，并且它们所做的某些工作最终影响了JavaScript可以使用的功能以及它的工作方式。
There may be more questions you want to ask (how active the community is, the number of contributors, etc), but I find this is a really good start to help me begin to think critically about whether or not it is worthwhile to introduce another tool into my current environment.
您可能要问更多的问题(社区的活跃程度，贡献者的数量等)，但是我发现这是一个非常好的开始，可以帮助我开始认真思考是否值得引入另一个问题。我当前环境中的工具。
Very often, the answer is no. Which means that when you’re chatting with some developer friends and they’re talking about using this brand new framework inside of a new code editor released last week, you may have to politely nod your head and admit you haven’t really dug into either yet. That’s nothing to be ashamed of. There is power in boring technology. Boring is good.
很多时候，答案是否定的。 这意味着，当您与一些开发人员朋友聊天时，他们谈论在上周发布的新代码编辑器中使用此全新框架时，您可能不得不礼貌地点头并承认您并没有真正钻研还是。 这没什么可羞耻的。 无聊的技术有力量。 无聊是件好事。
Have you ever watched someone who has been using Vim for years work in it? It’s amazing! Some joke that the reason they’re still in there is because they haven’t learned how to quit yet, but I think they’re onto something. While some of us jump from tool to new tool year after year, they continue to master this “boring” tool that just works—getting more and more efficient as time goes on.
您是否曾经看过使用Vim多年的人？ 太奇妙了！ 有人开玩笑说他们之所以会留在那儿是因为他们还没有学会如何戒烟，但是我认为他们正在努力。 当我们中的一些人年复一年地从工具过渡到新工具时，他们继续精通这种仅适用于工作的“无聊”工具-随着时间的流逝，它变得越来越高效。
We are lucky working on the web. Not only can anyone contribute something they think is helpful, but many do. We benefit constantly from the work and knowledge that others share. While that’s something to be encouraged, that doesn’t mean we need to constantly be playing keep-up. Addy’s advice on this is absolutely spot-on:
我们很幸运在网络上工作。 任何人不仅可以贡献他们认为有帮助的东西，而且许多人也可以 。 我们不断从他人共享的工作和知识中受益。 尽管这值得鼓励，但这并不意味着我们需要不断努力。 艾迪(Addy)对此的建议绝对是当场的 ：
…get the basics right. Slowly become familiar with tools that add value and then use what helps you get and stay effective.
…正确掌握基础知识。 慢慢熟悉增加价值的工具，然后使用有助于您获得并保持效力的工具。
Start with the core and layer with care. A rock-solid approach for building for the web, as well as for learning.
从核心开始，谨慎处理。 建立网络以及学习的坚如磐石的方法。
追逐神迹
扫一扫
286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
