图片来源：Flickr用户Tsutomu Takasu拍摄作品
纵观整个计算机发展史，1995是疯狂的一年：这一年Java语言诞生，紧跟其后的是JavaScript。后者虽然含有java二字，实际和java并不沾亲带故。Java属于静态编程语言，需要编译；而JavaScript只是一个简单的解释性脚本语言，属于动态语言。
如果经历过早期java发展，我们不难忘记它曾经的空前巅峰：铺天盖地的推广，超大规模的JavaOne会议。很多人都认定，这种新型的编程语言必将不惜一切代价称霸计算机领域。然后这一预测最终证实只是部分准确。而今，安卓应用、企业级服务器应用程序和类似蓝光光盘的嵌入式空间中，java仍然保持着统治地位。 纵使java有着极为广泛的实现领域，但桌面应用程序和浏览器编程却始终是它的弱点。Java创立的基于html的小应用程序，还有基于java的开发工具，都是开发人员极力推崇的。但复杂的场景或实际需求，往往会打破这种固有的组合。值得庆幸的是，早期服务器端开发成为了java扬眉吐气的领域。
同时，先前被很多程序员误解为Java好姐妹的JavaScript也开始在自己擅长的领域一展雄风。不得不承认，曾有一段时期，HTML和Web大张旗鼓发展的时候，JavaScript像一个小博格人一样，随波逐流。但AJAX的出现，彻底改变了这一现状。
接着，Node.js的横空出世，吸引了业内众多开发者的追捧。与Java或其他编程语言相比，基于JavaScript的Node.js平台在服务器端的表现更为出色——快！更快！Web端动态化发展，对数据请求次数和响应速度的要求，Node.js均可以满足。
放在20年前，这些都是不可想象的。如今等待这对双J兄弟的是一场硬战，输赢将决定谁会坐上编程界头把交椅。一方是在工程应用和体系结构领域根基牢固的静态编程语言；另一方是更加轻量级简易化的动态编程语言。老派编译性语言Java会坚守住自己的阵地吗？高速灵活的Node.js会为JS清除霸权道路上的一切障碍吗？
Java的优势：坚如磐石的应用基础
提到这点，我放佛都听到了开发者魔性的笑声。是的，Java自身存在着一些小的缺陷和bug，但相对而言，它绝对是编程界的直布罗陀巨岩(haha，乃们能听出我对其顶礼膜拜的夸赞吧)。Node.js如要达到这个境界，估计还要再努力上几年。不仅如此，事实上，当初Sun开发java虚拟机所做的回归测试数量级，JavaScript预达到这个水准，没个几十年根本做不到。 如果你启动了一个java虚拟机，那么恭喜你，您获得了一个掌控企业版服务器的资深管理者20年的经验值！如果你毅然决定要是用JavaScript，这将意味着，您可能遇到了一个脾气坏难相处的工作伙伴：这家伙时而能与你友善相处；时而又要拿出自己那套做人准则(JS标准)bibi，向你发起被动侵犯性的攻击。
Node的优势：无处不在的可应用性
正是由于Node.js的出现，JS终于在网络服务平台找到自己的归属位置。Node采用异步编程达到处理并发事件的效果。虽然它的可靠性还有待提高，但其在业内表现已经堪称不俗。传统的web编程，Java实现后台服务，JS完成前端功能；而Node.js可以让JS一人轻松搞定客服端和服务器，特别是当我们想把逻辑层从服务器移植到浏览器层面时，Node简直就是熠熠生辉。或者矫情的老板又想让我们把逻辑层移回服务端，反反复复，不管怎么个玩法，总之Node.js让代码移植更加简化。
Java能赢在何处：更优秀的IDE
Eclipse,NetBeans和IntelliJ，集调试、编译和服务为一体，这是Java开发人员公认的三大顶尖IDE。他们发展至今，潜心专注用户体验，拥有坚实的相关配套插件。而node.js开发人员可以在命令行下编写代码，或者使用文本编辑器。也有一部分人会选择Eclipse和Visual Studio，这二者也是支持node开发的。Node.js在全球范围内掀起的热浪，势必会孕育出一些新的工具和资源。比如IBM团队开发的Node-Red，它允许用户通过组合各部件来编写应用程序。然而，这种新的开源IDE，若要达到Eclipse的水准，尚有一大段距离。再比如前端开发神器WebStorm，这是jetbrains公司旗下一款JS开发工具，可支持多命令行开发。
当然，仅从代码的编辑和简单开发功能出发，这些新型的轻量级工具绰绰有余。但，如果你希望在执行源代码时，IDE可以给开发者更多的指引(好比一场开胸手术中，手握手术刀的大夫希望得到更多的协助)，强悍的java开发平台可以直接秒杀那些虾兵虾将——无处不在的java！
Node能赢在何处：简化进程
诸如Ant和Maven此类复杂的软件构建工具，对java编程带来的改变意义非凡。然后，始终存在一个问题。比如，开发者在xml中写出的代码，其规范和语法在其他编译环境下得不到支持。的确，可以使用嵌套标签来展示分支，但java与xml之间恼人的互转问题，仍不好解决。
Java：远程调试
能够远程监控服务器集群性能，一直是java引以为豪的。JVM本身的一些特点，加之性能测试工具的辅助，使得程序可以轻松探测出服务端瓶颈和失败。Java堆栈企业版上可以运行极为复杂尖端的服务器，而使用这些服务器的公司可以在遥测过程中获得最好的用户体验。上述提到的监测调试功能，发展至今已相当成熟，我们在部署服务时会深受其益。
Node.JS：直访数据库
类似CouchDB这种新型数据库，可以通过编写JS脚本直接对其进行访问。Node.js和CouchDB语句可以混合使用，不存在互转问题，头疼的语法差异也可以抛在脑后。
同样的情况，许多java程序开发人员在工作中也需要写一些sql语句，此时就要使用java编写的数据库(比如Derby)，到这一步你以为就万事大吉，那么只能说：你想多了！开发人员写好的sql语句，需要进一步经过Derby解析，方可加载在java程序中编译执行。所以，java确实是一门不错的语言，但其语法无法与sql互转，导致开发团队需要明确分工：你来写java，我来写sql。
Java：丰富的资源库
javat提供了一套庞大的工具包集合，这些资源在日常开发中发挥着极为重要的作用。例如，全文检索引擎Lucene和计算机视觉库OpenCV，是最典型的两个开源项目，他们在一些重要的基础工程中扮演着中流砥柱的角色。目前也有用javaScript开发的一些开源共享工具库，其中也有让人眼前一亮的函数和方法，但与Java这套成熟的资源库相比，这一环节java胜出。
Node：JSON
当数据库反馈出结果后，java程序将其转换为一个个java对象。这一环节，开发人员会采用POLP或者Hibernate等映射框架来处理数据，期间的配置和转化耗时是非常大的。最终，java程序才会接受这些java对象。
其实大部分web服务端和数据库，返回的数据类型是以JSON形式封装的(这是JS自带的一种数据交换格式)。这种数据格式被广泛应用于Java开发中，那么问题显而易见喽，开发者需要使用众多JSON解析器或库函数来进行数据的再处理。而JSON是JavaScript原生格式，这意味着在JS中处理JSON数据不需要任何特殊的API或工具包，用户可以简单粗暴直接使用。
Java：坚固的引擎
究竟有多少复杂组件基础开发包是基于java强大的数学函数库，一百个，一万个，这个已经很难去量化了。当初Sun为研发java这套实用工具类，也是消耗了大量的时间和人力。现在被广泛使用的有大数处理BigIntegre，精细复杂的IO库，基于Gregorian和Julian的开源时间/时间库。
在处理简单任务方面，JavaScript的表现还算差强人意，但其实现机理却混乱不堪。一个最常见的例子，JavaScript中定义的函数方法当返回结果是“无”时，可以有三种表现方式：undefined, NaN,以及 null。那么哪一种结果是正确的？其实这三者都是JS语言的数据类型，作用是为了保证程序的严谨性和逻辑性。乍一看，这种怪异的语法在程序运行中一般是不会出错，但与java那些个高大上的库函数一比，又被秒成渣。
Node.JS：速度
node.js速度棒棒嗒，用过的人多说好。数据一来一往，就像闪电一般。它不会作死去盲目设置带有死锁风险的单线程；也不存在内部自检环节，因为这有可能会降低执行速度。总而言之，手起键落，node已然在执行你的代码了。
当然，这种优势下暗藏隐患。代码尽量要写的简单，这样Node.js可以保你事事顺利。一旦某段复杂的代码死锁，整个服务会挂掉。可以这样理解，操作系统开发人员抓耳挠腮费死劲建立起来的系统自保机制，是可以容忍部分程序错误的。但Node.js完全瞧不上这套保护网。这也是node活该的地方。
Java：多线程
执行速度快，固然好。但健壮优良的代码，会更胜一筹。这一轮，java赢得无可置疑。
Java框架开发的web服务器是多线程的。纵使多线程会占用大量时间和内存，但这种内耗是值得的。因为，一个线程死锁，至少还有其他线程扛着；即便一个线程需要长时间占用cpu，至少其他线程不会饥饿等待。
以上情形放到Node.js下，结局惨不忍睹：一个线程慢下来，所有一切慢下来。所以，Node.js仅适用于单线程。
无数程序猿挥洒汗与泪，花费几十年心血，致力于建立一个处理并发事件的智能操作系统。Node在此点上却无法与时具进，玩起了倒退到上个世纪60年代的单线程。
Node：续航能力
祖辈对我们耳提面命：节俭是美德，要做不浪费不索取的好孩子。看着硅谷那帮傻缺用自己的行为在诠释“创新”和“颠覆”，我们确实痛心疾首。但回头静心一想，去其糟粕才是一件意义非凡的啊。Java仍可宝刀未老，先辈们撰写的骨灰级Java老代码无处不在。诚然，Java也在孜孜不倦提供着新的IO接口，但那些已与时代脱轨的老接口将何去何从？小型应用程序和基础实用类也将面临这种抉择。
双赢的局面？混合编程
服务器姓J还是姓JS，这个讨论还会持续很长时间。有一种中庸的方法，可以避开这些喋喋不休的争论—Java和JS的混合编程，将Java类转换为与浏览器兼容的JS。GWT框架把这事做的就很漂亮，很多知名网站就采用了此方法。
嘿嘿，其实还有另外一条小路可以走：像Rhino这种使用Java语言编写的JS的开源实现，程序猿可以直接把Java代码植入其中。如果你够牛逼，还可以在当前比较火的googleV8引擎上捣鼓这个事情。
总之，不要打打杀杀，和谐共处是王道！
