我是前Sun公司Java SE团队的一名成员，在工作了10多年之后——2009年1月——也就是在甲骨文收购Sun公司之前，我离开了公司，然后迷上了Node.js.
我对Node.js的痴迷到了怎样的程度？自2010年以来，我撰写了大量有关Node.js编程的文章，出版了四本与Node.js开发有关的书籍，以及与Node.js编程有关的其他书籍和众多教程。
在Sun公司工作期间，我相信Java就是一切。我在JavaONE上发表演讲，共同开发了java.awt.Robot类，组织Mustang回归竞赛（Java 1.6版本的漏洞发现竞赛），协助推出了“Java发行许可”，这在后来的OpenJDK项目启动过程中起到了一定的作用。我在java.net（这个网站现已解散）上每周写一到两篇博文，讨论Java生态系统中所发生的主要事件，并坚持了6年。这些博文的主要主题是关于“保卫”Java，因为总有人在预言Java的“死期”。
在这篇文章中，我将会解释我这个Java死忠是如何变成一个Node.js和JavaScript死忠的。
但其实我并没有完全脱离Java。在过去的三年中，我编写了大量Java/Spring/Hibernate代码。但两年的Spring编码经历让我明白了一个道理：隐藏复杂性并不会带来简单性，它只会产生更多的复杂性。
Java已成为一种负担，Node.js编程却充满了乐趣有些工具是设计师花费数年磨砺和精炼的结果。他们尝试不同的想法，去掉不必要的属性，最终得到一个只带有恰到好处属性的工具。这些工具的简洁性甚至达到让人感到惊艳的程度，但Java显然不属于这一类。
Spring是一个非常流行的用于开发Java Web应用程序的框架。Spring（特别是Spring Boot）的核心目的是成为一个易于使用的预配置的Java EE栈。Spring程序员不需要直接接触Servlet、数据持久化、应用程序服务器就可以获得一个完整的系统。Spring框架负责处理所有这些细节，你只需要把精力放在业务编码上。例如，JPA Repository类为“findUserByFirstName”方法合成数据库查询——你不需要编写任何查询代码，只需按照特定方式给方法命名，并添加到Repository中即可，Spring将负责处理其余的部分。
这原本是一个伟大的故事，一种很好的体验，但其实并不然。
当你遇到Hibernate的PersistentObjectException时，你知道是哪里出了问题吗？你可能花了几天时间才找到问题所在，导致这个异常的原因是发给REST端点的JSON消息里带有ID字段。Hibernate想要自己控制ID值，所以抛出了这个令人感到困惑的异常。看，这就是过度简化所带来的恶果。除了这个，还有其他成千上万个同样令人感到困惑的异常。在Spring栈中，一个子系统套着另一个子系统，它们坐等你犯错，然后再抛出应用程序崩溃异常来惩罚你。
然后，你会看到满屏的堆栈跟踪信息，里面满是这样那样的抽象方法。面对这种级别的抽象，显然需要更多的逻辑才能找到你想要的内容。如此多的堆栈跟踪信息不一定是不好的，但它也是在提醒我们：这在内存和性能方面的开销究竟有多大？
而零代码的“findUserByFirstName”方法又是如何被执行的？Spring框架必须解析方法名称，猜测程序员的意图，构造类似抽象语法树的东西，生成一些SQL语句……那么完成这个过程需要多少开销？
在反反复复经历这样的过程之后，在花了大量时间学习你本不该学习的东西之后，你可能会得出相同的结论：隐藏复杂性并不会带来简单性，它只会产生更多的复杂性。
另一面是Node.jsSpring和Java EE非常复杂，而Node.js却是一股清流。首先是Ryan Dahl在核心Node.js平台上所应用的设计美学。他追求别样的东西，花了数年时间磨练和改进了一系列核心的Node.js设计理想，最终得到一个轻量级的单线程系统。它巧妙地利用了JavaScript匿名函数进行异步回调，成为一个实现了异步机制的运行时库。
然后是JavaScript语言本身。JavaScript程序员似乎更喜欢无样板的代码，这样他们的意图才能发挥作用。
我们可以通过实现监听器的例子来说明Java和JavaScript之间的差别。在Java中，监听器需要实现抽象接口，还需要指定很多啰七八嗦的细节。程序员的意图的这些繁琐的样板中渐渐淹没。
而在JavaScript中，可以使用最简单的匿名函数——闭包。你不需要实现什么抽象接口，只需要编写所需的代码，没有多余的样板。
大多数编程语言都试图掩盖程序员的意图，这让理解代码变得更加困难。
但在Node.js中有一点需要注意：回调地狱。
没有完美的解决方案