JavaScript疲劳已成为当今前端开发人员世界中的常用短语。 似乎每天都有新的大肆宣传的框架，体系结构，命令行工具或SaaS开发人员服务。 新事物的不断波动最终可能使开发人员感到厌烦而不是兴奋。
为避免这种情况，建立扎实的本能很重要，以便将值得花费时间的技术和产品与在名声结束15分钟后将逐渐消失的技术和产品分开，他们有关TechCrunch的精选文章已逐渐淡出档案库，或他们的“ Show HN”最后一次被动的激进评论早已被人们遗忘。
我作为程序员的旅程始于大约30年前，当时我有了第一台计算机：一台二手的Commodore 64，它会以闪烁的光标向我打招呼，作为“ Basic V2”的条目。
从那时起，发展世界上唯一不变的就是变化，而不断学习和发现的需求。 这里有一些关于我如何能够保持最新发展而不沉迷于不断变化的想法。
了解您的历史
这可能是一篇有关领先于变革步伐的文章中令人惊讶的建议，但是要了解和评估当代技术，您必须了解该领域的历史。
在一个经常变化的空间中，很容易想到发布流确实是新的。 但是技术往往具有令人惊讶的周期性。 表面上看起来很新的东西往往在下面具有深厚的历史根源。
当Ruby on Rails在2004年问世时，它的发展几乎是翻天覆地的，并对行业产生了巨大的影响。 同时，它所基于的模型视图控制器（MVC）模式的大多数思想，以及来自Ruby的基础面向对象的模式，都从70年代后期一直追溯到Small Talk编程环境。
对于当时精通主流Web平台（PHP，Java，ASP）的开发人员，Ruby on Rails不仅引入了具有新语法的全新语言，还引入了新概念和元编程的主要新范例。 但是，对于跟随SmallTalk及其兴起的语言和平台的兴起和衰落的开发人员而言，Ruby on Rails充满了熟悉的概念（带有一些新的语法，并从Small Talk应用程序的世界中进行了一些适应到网络上）。 他们需要学习的只是Ruby和Small Talk之间的（重要但不是很大的）区别，以及Web的MVC和Small Talk应用程序的MVC之间的概念区别。
以类似的方式，当React出现时，它似乎立即席卷了整个JavaScript框架。 其中大多数尝试将受Rails启发的MVC模型转移到浏览器。 对于许多开发人员而言，这似乎与依赖于带有双向数据绑定的模板的单页应用程序框架以及与jQuery之类的简单库都大相径庭。 但是从本质上来说，React受到了功能编程语言（尤其是OCAML）的启发，这些思想一直可以追溯到计算的早期。
React的创建者Jordan Walke最近描述了自己的历史之旅如何为他提供了构建React所需的背景：
- 在最长的时间里，我只是假设“ Welp，我想我只是一个奇怪的程序员”。 然后，我最后学习了一门有关编程语言基础知识的课程（在大部分课程中都使用ML（SML）），最后我有了一些基本术语来描述我想如何构建应用程序。 我还了解到，我偏爱的编程风格既不奇怪，也不新颖，实际上更接近于一些最古老的编程语言哲学—从来没有成为主流的哲学—该行业已经使用了二十多年的哲学。破坏（我认为对他们不利）。
- https://www.reactiflux.com/transcripts/jordan-walke/
对于许多前端开发人员而言，使用类似Redux之类的“助焊剂”架构（可能与Immutable.js结合使用）进入React更加成熟的全状态管理世界的旅程会感到不知所措。 但是对于具有坚实历史基础的开发人员，他们一直在追随函数式编程的重新出现-其周围的概念可以追溯到1958年创建LISP-React反映了熟悉的概念和思想。
即使积极尝试学习新技术，历史也可以成为很有帮助的老师。 当Rails第一次发布时，除了一些在线文档，教程和源代码本身（稍后会更多关于源代码）之外，很难获得有关它的材料。 但是，有关通过Small Talk到目标C进行MVC演变的文章很多，并且从在Small Talk世界中基于消息传递的元编程和OOP的工作中学到了很多教训。
这可以是更快学习新技术的好工具：与其阅读最新的教程和新兴文档，不如了解他们的灵感来源，他们所汲取的经验和基础。 有关那些较旧的技术，思想和方法的材料很可能会更加成熟，并且您会发现很多经验教训，这些经验教训很可能适用于该领域的新方法。
扎实的历史意识为您提供了一个很好的工具集，可以提出以下问题：这次有什么不同？ 这个问题的答案（或没有答案！）通常会决定一项新技术的成败。
人，文化和社区事务
容易想到工具和技术只是在不断发展。 例如，面向对象编程成为功能编程，文本编辑器发展为成熟的IDE，而动态语言则转换为静态类型的语言。 但是，新技术和框架不仅会自己走进化的道路。 它们是由人类，组织和社区发明，构建和传播的。
当出现新工具或技术时，重要的是要质疑技术基础（有什么不同？它建立在什么基础模式上？）和动力（为什么有人选择现在就建立它？是谁？这项技术为组织解决了什么问题？）。
我最喜欢的一篇论文中，为什么某些工具会赢而其他工具会淡出，是理查德·P·加布里埃尔（Richard P. Gabriel）于1989年提出的“更糟的崛起”。它描述了Unix和C取代基于LISP的技术的可能原因-与这两种解决方案的固有特性无关。
Gabriel在论文中描述了一种“更糟的是更好”的方法，与MIT / Stanford设计学院相反，新泽西设计学院认为实现的简单性高于最终用户界面的简单性或正确性。 这种关注使C和Unix在市场上击败了LISP。 C编译器比LISP编译器更易于实现，移植和优化，这使Unix实施者更快地将软件交付用户。 这导致更快的采用速度，最终意味着将有更多的人（和公司）投入到发展和改善C / Unix生态系统中。
在查看新技术时，不仅要了解他们的目标，技术实现方式，而且要了解它们将如何传播以及如何发展社区。 对于主流编程社区来说，最重要的技术往往是那些对后来的问题有最佳答案的技术，即使在看起来似乎是纯粹基于纯技术基础的退步的情况下。
但这是真正的把戏：有时技术领先的工具注定永远不会被广泛采用（我愿意打赌，我们不会在任何时候都以Idris语言编写网络应用程序不久）。 LISP从未成为主流，但是今天的许多主流框架，语言，库和技术都因其发明和探索的思想而背负了巨大的债务，即使今天学习LISP仍可以为未来的技术带来很多见识。
如果您可以发现存在于此交叉点中的工具，那么学习这些工具可能会带给您下一个开发人员超能力。
始终 了解“为什么”
回到我开始开发时，最接近StackOverflow的是带有源代码的计算机杂志，您可以手动在终端中键入以使程序运行。
我是一个草率的打字机，一路走来，我永远无法在没有错误的情况下输入完整的程序。 实际上，这是计算机程序打印输出相对于可复制和粘贴的Stack Overflow代码片段的优势之一（绝对很少！）：要使其正常工作，您需要真正理解代码。
作为开发人员，我们始终在迫在眉睫的最后期限上工作，并面临着尽快将新功能，特性和错误修复移交给用户的压力。 我见过一些开发人员非常专注于将某些东西付诸实践，他们将库和代码段放在一起，却没有花时间去理解它为什么起作用。 或者，他们会看到某些东西已损坏，可以尝试各种不同的潜在解决方案，而无需先花时间了解为什么系统首先出现故障。
不要成为那个开发者。 在您花时间了解为什么该解决方案可行之前，切勿使用Stack Overflow或其他地方的解决方案为自己的一条规则。 挑战自己，再进一步一步，弄清楚自己想出哪种解决方案。
有时，您会发现一个问题，只需进行很小的更改（例如将一个库更改为另一个库，调用所使用的函数的变体等）即可解决一个错误，但实际上您并不知道为什么。 此时不要安顿下来。 深入研究并建立一个思维模型，可以使您确切地了解一个解决方案失败而另一个解决方案起作用的原因。 通常，这将导致更深入的学习，并且您会发现可能揭示隐藏在系统其他部分中的未发现错误的模式。
也以这种方式采用新技术。 不要专注于表面学习。 学习一些不同框架或语言的语法并不会给您带来太多帮助，但是学习那些技术基础之下的决策过程将从根本上使您成为更好的开发人员。
总而言之，最重要的不是学习什么 （哪种框架，哪种工具，哪种语言），而是从中学到的东西 。
将这些课程付诸实践
选择合适的工具并不总是那么容易或显而易见，即使对于最熟练的程序员而言。 在坚持使用众所周知的，值得信赖的和可靠的工具而又很少有惊喜之间，以及采用能够以新的更好的方式帮助解决问题的全新技术之间，始终存在一个折衷的选择。 但是，做一些前期工作可以使成功选择和实施新工具成为开发实践的一部分。 确实，这是一种实践，并且一直在不断发展。 这里有几种方法可以应用本文中的建议。
了解您的历史
历史意识提供了一个扎实的工具集，可以问：“这次有什么不同？”答案（或没有答案）通常决定着一项新技术的成败。 新东西很酷。 新东西很有趣。 但是，如果您对这一切的速度感到不知所措，并且偶尔会出现JavaScript疲劳的爆发，请放慢脚步，并记住这是一个漫长的游戏，遵循大趋势比持续努力重写所有应用程序更重要。最新的框架。 彼得·诺维格（Peter Norvig）在他的论文“十年内自学编程”中指出了这一点。
人，文化和社区事务
得益于GitHub，Stack Overflow和NPM的迅猛发展，尽早了解社区如何扩展以及开发人员如何响应其雄心壮志要容易得多。 尽管贡献者和明星可以向您介绍很多已经成功的项目，但它们并不总是成功的早期指标。 但是，您可以使用相同的逻辑来帮助确定社区是否很可能拥护您正在使用的项目，就像您可能已经用来构建自己的软件一样，还是选择您想为之工作的公司：
- 是否有明确的愿景？
- 是否有明确的用户需求？
- 是否有合适的人员，资源和文档来进行扩展？
- 它可以扩展吗？ 即，它可以扩展或适应以服务新兴技术或用户类型吗？
- 也许，谁在背后？
始终了解技术背后的“原因”
不要专注于表面，而要关注下面的电流。 学习几种不同框架或语言的语法可以帮助您，但是学习这些技术的决策过程将从根本上使您成为更好的开发人员。
迈克尔·费瑟斯（Michael Feathers）列出了“每个开发人员都应该阅读的10篇论文”。 所有这些都是关于语言，体系结构和文化的基础思想，并为理解当今众多趋势下的思想奠定了良好的基线，这些趋势仍在当今的编程中引起轰动。
继续研究所有新事物！ 但是，请以合理的速度进行操作。 这样的步调可让您有时间建立正确的基础。 最终，您可以更快地采用新技术，更深入地了解它们，并更全面地评估其持久力。
