为什么前端精通Node.Js的人这么少？
按投票排序
前端为什么要精通nodejs？是指nodejs的拼写么？
我也算用nodejs的渣渣了，说说个人觉的难精通的原因吧：1.nodejs比较新，09年才发布距今不到10年，跟JAVA、C++这些老前辈没法比；2.更新比较频繁, 因为新所以要经常改，改动有多频繁？看人家更新日志感受下（），因而对应的第三方模块改动也大，用过expres3.X跟4.X的同学都懂的。3.战线比较长，战斗力自然分散，就像html5的
hybrid app 三端通吃，结果每一端都被原生碾压。前后端通吃的人，精力自然分散；哪能像单攻一端那么强？4.nodejs目前定位比较尴尬，高不成低不就，大项目稳定性、安全性被质疑，小项目还是没人家PHP 各种CMS来得快。随着更新完善，这点以后必定会有所好转。5.同行的嘲讽；我们行业总有那么一群人，对新、旧技术（c# html5 nodejs）了解皮毛后，发现其缺点然后无限放大在各种社区发帖黑之。虽然无法理解 这种 损人不利己的行为，但其对技术的发展阻碍作用还是很明显的。PS：第4、5点导致nodejs开发领域，进来的新人多不了，自然就鲜少精通的牛人。 6.nodejs在技术层面上精通有一定难度，一方面前面有知友说了 nodejs后台需要有后端思维才能玩的转，另一方面nodejs后台一些高阶实现就是调用C++代码模块，对于大部分没后台开发经验的前端同仁要精通又得多一道坎。（nodejs底层实现，最近看朴灵大神的《深入浅出nodejs》，其对这方面有比较多的讲述）最后， 安利下，nodejs作为前端开发新技术可谓是另辟蹊径，对前端的意义还是很大的，作为一个上进的前端不了解、不使用谈何进步？
因为Node.js属于后端。
事实上node开发web系统，还是有后端思维的才玩得转。前端也要看什么前端，只能写写几十行jQuery插件，还一堆bug那种，后端绝对玩不转。node也不行。最少要能封装出功能良好，扩展性方便的jQuery插件，这样的前端去玩后端才行。在知乎上看过一篇文章，答的是程序员的能力。有一条就是全局临时记忆能力。差的前端，只能记得一页的结构，而后端需要对整个系统大体记得，对某个业务前因后果记得非常清楚，这样开发时才不会丢头弃尾。少有前端能锻炼出这些能力，有的也是前后端通杀的高手。
很多人并没学node，而是学了expressJS。
前端工程师很少会去研究后端，工作上没这个要求。因为后端工程师是必备的，后端工程师兼职做前端的很多；工作多了分化之后就需要专门招前端了，后端安心做后端的事情了，这样的前段没必要懂后端也能好好工作。而后端工程师就不局限在js上了，还是php, ror, java, django等等各种更专业的后端平台用得更多。既然工作上没这个要求，那么凭兴趣呢？不行，前端工程师凭兴趣要去折腾Node.js还是很难的。后端的linux命令，mysql, nginx, 各种配置，每一样都是完全陌生的领域，而且没人请教----跟自己配合的后端工程师不搞Node.js啊，还不如请教他们熟悉的后端呢。有兴趣的时候，还不如专研各种前端框架呢，前端的世界好大呀。
精通NodeJS，必须有后端开发的基础和相关项目经验，必须对算法和数据结构有较深刻的认识，否则别谈“精通”这个词。而这些属性往往是一般的前端所不具备，更不必说从设计转过来的‘前端设计师’了。。。所以，前端很少是真正精通nodejs的，更多是知道些皮毛而已，往深层次应用发展很难。找擅长nodejs的人才，往做后端的人里面物色吧，如果发现js不错的后端，那就说服他转行做nodejs吧。
前端精通前端的都不多，为什么要精通后端
因为能正确拼写 Node.js 的人就不多，谈何精通。Node.js，而非 Node.Js！
精通这事，
如果他都不敢说精通，国内又有谁说精通呢？？既要精通 C++ 又要精通 V8 又要搞过前端，这三个条件下去都几乎找不到人了
想了想，决定占个坑，然后讲讲挖坑经历。---------------------------华丽的分割线---------------------------补充。为什么前端精通node.js的这么少？那我们来梳理问题啊，前端通常做什么，后端要做什么？不对不对，应该这么问：前端和后端分别要掌握哪些知识点以及分别要求有哪些认识？## 一个页面仔的日常&!DOCTYPE html&
&title&Example&/title&
&tr class="caption"&
&td&name&/td&
&td&age&/td&
&td&sex&/td&
&tr class="item"&
&td&a&/td&
&td&1&/td&
&td&1&/td&
&tr class="item"&
&td&b&/td&
&td&2&/td&
&td&1&/td&
&tr class="item"&
&td&c&/td&
&td&3&/td&
&td&1&/td&
&div class="result"&
&script type="text/javascript" src="/jquery/2.1.4/jquery.js"&&/script&
&script type="text/javascript"&
$(document).ready(function(){
$('.item').click(function(e){
var _items = $(this).children('td');
var _id = _items[0].innerHTML;
//alert(_items[0].innerHTML);
getData(_id);
function getData(id){
$.post("/data/post/",{id:id},function(response,status){
if(data && response.code === 200){
console.log(data);
$(".result").html(response.data);
console.log('err');
上面这玩意的效果大概是当用户点击表格中的某一行的时候，从后台查询数据，然后添加到页面里。（随手写给后端的东西，请不要纠结细节~），### 基础知识：html中table、tbody、tr、td使用，以及标签的class设置js中选择器的使用，jquery中ajax的post提交，标签内容的获取与修改### 错误处理：ajax提交数据后返回status，data，status通常是网络正常与否之类的东东，但是还有服务器返回数据的错误呢？所以这边定义了一个response对象，结构大概是{code:200/500(int),data:{}}，然后对应了服务器内部查询的错误处理。这些都比较简单，我这里只是举了一个特别简单的例子。不过事实上呢，通常情况下，前端主要做的大概就是这个了~（动画啊，特效啊，什么的，那也是！但是和nodejs这边关系不大，用expressjs加载几个页面什么の，乃不是精通！请不要跟我撕逼，谢谢。）---------------------------华丽的分割线---------------------------补充。## nodejs实例前面是给后端哥哥写了一段便于他查询数据的简单代码，我们现在具体到实际开发喽，具体是一个“微信公众号“开发的小例子（只是粗略的写一写~）。代理：nginx语言：nodejs框架：expressjs存储：redis微信公众号jssdk的接入，需要验证签名，获取token，接着拿到jsTicket,并最终生成签名。### 基础知识#### Nginx对于一个独立开发者，服务器的管理是必然的，况且，一个vps上面，你肯定要放很多蛋疼的小玩意，我们这边是nodejs来做基础环境，为了不影响其他服务的正常使用，最好是通过nginx前端代理，把请求转发到nodejs得web程序上面去，配置参考下面链接。（这里还有一堆进程守护什么的东西，随便听听就好了~）#### ExpressJs不管你是用nodejs的http/https直接创建web程序，还是用expressjs框架，其实都是差不多的，对req,res的处理都一定要有所了解，有兴趣就去查官方api吧~#### redis为什么要这个呢？如果你看过微信的官方文档，应该知道签名相关的那些接口是有调用次数限制的，过期时间是7200s（2h），所以吧，肯定是要存在你服务器的，cookie、session之类的存储也不是不可以，我这里用redis来做缓存的。### 具体实现暂定前面的那些你都搞定了或者你都用不到，我们直接进入实现的流程。#### 关于结构、配置、部署等等一个web服务器，路由肯定要有的，我这里是expressjs的，那么就是涉及到一个代码组织的问题，我一开始是使用expressjs生成的那种结构，大概是类似传统的mvc模式（不知道的自行搜索），但是问题来了，当你目录的层级到一定深度的时候，require()使用起来就蛋碎的一笔~前一段时间爬了好久angular的坑（之所以说坑是因为1.3.x和2.x已经不是一个东西~），所以组织代码的方式变成了现在的这样样子，主要代码全部放在了app目录，资源文件放在public目录，conf那边就是调试和运行的一些配置文件了，app下面除了common那边以外是以功能来组织代码。.
├── README.md
├── app
├── api
├── blog
├── common
├── doc
├── index
├── mood
├── route.js
└── user
├── app.js
├── bin
├── autoload.js
└── gulpfile.js
├── bower.json
├── conf
├── api_develop.json
├── api_product.json
├── app_develop.json
└── pm2_develop.json
├── node_modules
├── package.json
├── public
├── css
├── css-gulp
├── favicon.ico
├── html
├── images
├── js-spm
└── vendors
└── static
也许有人觉得随便怎么放都行，是我事太多（好像我真的是个事b...），可是我发现啊，我改了好多次结构以后，现在用起来很方便，一目了然，给别人解释起来也比较方便（哼，咱目标可是架构，怎能实现功能就行？笑~），所以嘛，配置啊，模块啊，代码组织啊，运行啊，编译什么的，都要考虑嘛~，再说了，你要做nodejs啊，你是后端啊！你不考虑？不考虑部署？不考虑结构？不考虑配置？——行行行，你什么都不考虑，但是总得考虑这玩意公开以后别人能不能看得懂吧？#### 其实写代码是最好做的那一部分~先把所有请求全转到router那边来处理吧~```
// ------------- ROUTERS -------------
require('./app/route')(app, passport);
# router.js
= require('./api/api');
app.use('/api',api);
var apiApi = require('../api/apiModule').A
router.route('/wechat/signature')
.get(apiApi.wechat().checkSignature);
router.route('/wechat/signature/gen')
.get(apiApi.wechat().genSignature);
router.route('/wechat/token/get')
.get(apiApi.wechat().getToken);
然后我们就来写代码吧~
var obj = {};
// 签名检查
obj.checkSignature = function (req,res){
var WECHAT_CONFIG = CONFIG_APP.
var signature = req.query.
var timestamp = req.query.
var nonce = req.query.
var echostr = req.query.
var shasum = crypto.createHash('sha1');
var arr = [WECHAT_CONFIG.token, timestamp, nonce].sort();
shasum.update(arr.join(''));
if(shasum.digest('hex') === signature){
res.send(echostr);
res.send('err');
=====未完待续。让我静静，后面的那些不忍心贴了，太长....未补充的那部分实际上是错误处理与一些逻辑关系的东西，让我回头整理一下思路。。。贴个地址：
因为前端主要工作主要还是写前端应用，所以用大多数前端用Node.js主要还是用来写一些前端构建打包脚本，又或者做一些一些 isomorphic 应用，又或者如果后端是用 Node.js 做成 RESTful 的话，前端也有可能会去改一下请求或者响应的格式来满足产品需求。所以从工作职责上来看，并不需要专门去研究 Node.js(libuv/v8) 本身。
之前解决问题的不同造成思考方式的不同
前端如果只用jquery的选择器 其余用native javascript就好多了很多前端迷于框架和jquery的方便 其实不真懂javascript不通javascript何谈搞定nodejsjavascript是钻石 别不用jquery是好东西 有选择地用bootstrap这种偏css的框架也是不错 选择之当库去用少用angular这种js框架 多是屎 让你远离本质和钻石
提问者居然提了一个 “前端为什么精通后端的人少” 的问题。。。针对 @萧强 的答案，有所 反对 / 质疑 / 赞同 。为什么前端精通 Node.js 的人这么少？这不是理所当然的事情么。为什么前端精通
Java 的人这么少？为什么前端精通 PHP 的人这么少？为什么前端精通
Python 的人这么少？为什么前端精通
Ruby 的人这么少？为什么前端精通
Go 的人这么少？这不都是理所当然的事情么。（一般情况下，名称叫 Node ；只有语境有所混淆的情况下，才叫 Node.js 以和 node/“节点” 区别。这和 Go 一样，一般叫 Go ，有表达不清楚的情况，才叫 Golang 以和 go/“去吧” 区别。以下文中均称 Node .）反对 “1. Node 比较新”：就因为它比较新就精通的人少吗？它在 09 年发布，同年诞生的还有 AngularJS ；AngularJS 也比较新啊，为什么同样“比较新”而前端精通 Node 的人少、前端精通 AngularJS 的人多呢？质疑 “2.更新比较频繁”：更新频繁就精通的人少吗？同期诞生的 AngularJS 更新貌似更频繁吧？我不是前端的，不了解，谁懂谁来补充。赞同 “3.战线比较长，战斗力自然分散”：做 前端/客户端 的人，去研究 后端/ 服务器端，精力分散，思维需要切换，身为前端去搞 Node 这样的后端，当然一般不会精通。这点我赞同。强烈反对 “4. Node 目前定位比较尴尬，高不成低不就，大项目稳定性、安全性被质疑，小项目还是没人家PHP 各种CMS来得快”：这句话放在 09 、10年还可以，放在现在已经不适用。定位：Node 的定位一直很明确：“高性能的 Web 服务器”，事件驱动、非阻塞I/O 是它的特点。大项目中：Node 已经作为大项目的部分被相当大范围地使用了：淘宝、天猫的 Web 版，已经使用了 Java - Node 的架构，你能看到的很多页面都是在Node 服务器 上渲染的，而不是原来的在
Java 服务器 上渲染、更不是到现在还问题多多的 前端渲染；UCloud ，已经使用 Node 构建分布式集群；国外的 Paypal、Linkedin 就更不用说了，部分业务在使用。Node 在大项目中并不是去取代谁，而是接手它擅长的部分，去和其他后端语言共存。小项目中：现在初创公司的纯移动应用，首选后端语言是 Node . 比如：决战喵星、知乎日报、爱范儿、丁香客。一是因为开发起来快，比 PHP 还要快；二是因为对他们来说够用、需要的功能通过 Node 都能又快又好地实现。至于 Node“没人家 PHP 各种 CMS 来得快”，Language 和 CMS 比谁快，不在一个层级上，没有可比性。另外，各大 PaaS/BaaS 提供商均对 Node runtime 实现了支持：Parse 只支持 Node ；LeanCloud 首先支持 Node 、最近刚刚增加了对
Python 的支持；BAE 支持 Node、Python、Java、PHP （这四个可以合称后端四大天王。。）；阿里云 ACE 也支持这四大天王（其中Node、Python 最近推出，尚未体验版）。PaaS/BaaS 提供商之所以要支持 Node runtime ，因为做应用的客户们有使用 Node 的需求。不明白 “5.同行的嘲讽” 跟精通一门后端开发平台有何关系：再次强调：这是门后端开发平台，不是前端的新技术。你们愿意学后端开发是可以的、但不是必要的，学会使用那些 Node 编写的前端开发辅助工具就可以了，比如学会使用 Gulp .不太认同 “6. Node 在技术层面上精通有一定难度”:对前端开发者来说，不止是 Node ，精通 Node、Python、Java、PHP、Ruby、Go 等后端开发平台均有一定难度。但是对后端开发者来说，精通 Node、Python、Java、PHP、Ruby、Go 的难度差不多。稍有不同的可能就是 动态类型语言 和 静态类型语言 语言上的差异，但基本的服务器 API 、构建服务器程序的方式、与数据库的交互，都是一样的原理。所以我建议普通前端们不要再想着精通一门后端了，除非是学有余力的全端大牛。
玩过一点node的前前端程序员，虽然语言特性和JS很相似，但确实需要有后台的编程思想，所以有点难上手。还有，什么叫精通呢，像朴灵那样的吗……
学了一两月，因之前做过后端开发，所以感觉也算入门了。先不管nodejs是如何实现的，它具有完善的语言功能(Ruby,python...),完全可以作为后台开发所用。个人觉得对于做前端的开发者来说学习nodejs是很有必要的，首先nodejs使用的是原生的js语法，降低了前端开发者的学习成本；再者通过学习nodejs可以培养后端思维，这样可以更好的与后端开发者合作；还有就是如今的前端环境还比较混乱，比较知名的框架有(angular,react,,underscore,ionic,meoter等)，基本上每一个都有自己的知识体系，学习量太大，而且针对移动端的后两个框架都是与nodejs集成。所以学习node有必要，但精通，何为精通？
为啥我觉得比较多…
因为发现还是PHP简单，学node不如学PHP来得方便快捷
前端的把node.js玩熟的不会去提这样问题的公司。是什么让Node.js比Java更快？
　　每隔几个星期，就有人发表Java和Node比较的性能评测，像PayPal&或者&Joey&Whelan 发表的帖子.作为Node很多公共管理模块核心的维护者和贡献者之一,Strong Loop 很高兴看到Node的获胜。每个人都知道，评测是一个特殊的衡量方式，其实并不适用于所有的情况。有时候Java要快一些，有时候Node要快一些。当然，用什么和怎么衡量才是最重要的。
　　高并发性问题
　　但是，有一件事我们都认同：在高并发性（成千上万的连接）的情况下，你的服务器需要达到异步非阻塞的...。我将用IO来完成那种情况。但问题是，如果你的服务器代码的任何部分阻塞你需要的一个线程。在这种级别的并发下,你不能去为每个连接创建线程。所以整个代码路径需要异步非阻塞式的, 不仅在输入输出层。这就是Node擅长的地方。
　　尽管Java或Node或其他技术可能赢得一个评测，到现在为止还没有形成服务器端Node.js 完整的非阻塞生态系统。所有写在异步方式的模块超过50&k,就可以使用Node.js了。无数散落在网页的代码示例，课程和教程都使用这种异步方式。调试器、显示器、记录器、集群管理、测试框架甚至更多其他都期待你的所有代码是非阻塞异步形式。
　　直到Java或另一种语言生态系统到达这种支持异步模式的程度(在Node中达到的水平因为浏览器中的异步JavaScript),它不管原始的NIO性能是否比节点或其他任何评测结果表现的更好:需要大并发的项目会选择Node(并且忍受他的缺点),因为它是完成他们项目的最好方式。
　　大公司, 供应商和社区
　　我们要帮助让Node和其系统工具和库保持成熟。其他人也在做着同样的事情,从LinkedIn，雅虎与Groupon这样的大用户到像微软,MuleSoft&Appcelerator这样的供应商和个人开发者每年贡献成千上万个有用的模块。Node将变得会越来越好,我们会帮助修复缺点或完全删除它们,异步的时代将会带我们进入数以百万计的连接设备的乐土。
　　使用StrongOps 监控节点应用程序
　　准备好开始监视事件循环,管理节点集群并找出内存泄漏了吗？我们很容易地用一个简单的npm安装从本地或你最喜欢的云开始StrongOps。
　　接下来是什么？
　　在即将到来的版本里有什么?大的性能优化,阅读博客了解更多信息。
　　看伯Bert&Belder的综合视频介绍v0.12所有新添加的特性。
　　准备用Node.js开发应用程序接口API并让他们连接到您的数据吗?我们已经让这变得很容易，用一个简单的npm安装就可以在本地或你最喜欢的云上开始开发。
顶一下(0) 踩一下(0)
热门标签：前后端分离的思考与实践（一） - 博客 - 伯乐在线
& 前后端分离的思考与实践（一）
也谈基于NodeJS的全栈式开发（基于NodeJS的前后端分离）
为了解决传统Web开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的NodeJS，试图探索一条全新的前后端分离模式。
随着不同终端(Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，我们往往需要针对不同的终端开发定制的版本。为了提升开发效率，前后端分离的需求越来越被重视，后端负责业务/数据接口，前端负责展现/交互逻辑，同一份数据接口，我们可以定制开发多个版本。
这个话题最近被讨论得比较多，阿里有些BU也在进行一些尝试。讨论了很久之后，我们团队决定探索一套基于NodeJS的前后端分离方案，过程中有一些不断变化的认识以及思考，记录在这里，也希望看到的同学参与讨论，帮我们完善。
一、什么是前后端分离？
最开始组内讨论的过程中我发现，每个人对前后端分离的理解不一样，为了保证能在同一个频道讨论，先就什么是”前后端分离”达成一致。
大家一致认同的前后端分离的例子就是SPA(Single-page application)，所有用到的展现数据都是后端通过异步接口(AJAX/JSONP)的方式提供的，前端只管展现。
从某种意义上来说，SPA确实做到了前后端分离，但这种方式存在两个问题：
WEB服务中，SPA类占的比例很少。很多场景下还有同步/同步+异步混合的模式，SPA不能作为一种通用的解决方案。
现阶段的SPA开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一些展现逻辑，这就意味着后端还是涉足了View层的工作，不是真正的前后端分离。
SPA式的前后端分离，是从物理层做区分（认为只要是客户端的就是前端，服务器端的就是后端），这种分法已经无法满足我们前后端分离的需求，我们认为从职责上划分才能满足目前我们的使用场景：
前端：负责View和Controller层。
后端：只负责Model层，业务处理/数据等。
为什么去做这种职责的划分，后面会继续探讨。
二、为什么要前后端分离？
关于这个问题，玉伯的文章中解释得非常全面，我们再大概理一下：
2.1 现有开发模式的适用场景
玉伯提到的几种开发模式，各有各的适用场景，没有哪一种完全取代另外一种。
比如后端为主的MVC，做一些同步展现的业务效率很高，但是遇到同步异步结合的页面，与后端开发沟通起来就会比较麻烦。
Ajax为主SPA型开发模式，比较适合开发APP类型的场景，但是只适合做APP，因为SEO等问题不好解决，对于很多类型的系统，这种开发方式也过重。
2.2 前后端职责不清
在业务逻辑复杂的系统里，我们最怕维护前后端混杂在一起的代码，因为没有约束，M-V-C每一层都可能出现别的层的代码，日积月累，完全没有维护性可言。
虽然前后端分离没办法完全解决这种问题，但是可以大大缓解。因为从物理层次上保证了你不可能这么做。
2.3 开发效率问题
淘宝的Web基本上都是基于MVC框架webx，架构决定了前端只能依赖后端。
所以我们的开发模式依然是，前端写好静态demo，后端翻译成VM模版，这种模式的问题就不说了，被吐槽了很久。
直接基于后端环境开发也很痛苦，配置安装使用都很麻烦。为了解决这个问题，我们发明了各种工具，比如，但是前端还是要写VM，而且依赖后端数据，效率依然不高。
另外，后端也没法摆脱对展现的强关注，从而专心于业务逻辑层的开发。
2.4 对前端发挥的局限
性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。
为了解决以上提到的一些问题，我们进行了很多尝试，开发了各种工具，但始终没有太多起色，主要是因为我们只能在后端给我们划分的那一小块空间去发挥。只有真正做到前后端分离，我们才能彻底解决以上问题。
三、怎么做前后端分离？
怎么做前后端分离，其实第一节中已经有了答案：
前端：负责View和Controller层。
后端：负责Model层，业务处理/数据等。
试想一下，如果前端掌握了Controller，我们可以做url design，我们可以根据场景决定在服务端同步渲染，还是根据view层数据输出json数据，我们还可以根据表现层需求很容易的做Bigpipe,Comet,Socket等等，完全是需求决定使用方式。
3.1 基于NodeJS“全栈”式开发
如果想实现上图的分层，就必然需要一种web服务帮我们实现以前后端做的事情，于是就有了标题提到的“基于NodeJS的全栈式开发”
这张图看起来简单而且很好理解，但没尝试过，会有很多疑问。
SPA模式中，后端已供了所需的数据接口，view前端已经可以控制，为什么要多加NodeJS这一层？
多加一层，性能怎么样？
多加一层，前端的工作量是不是增加了？
多加一层就多一层风险，怎么破？
NodeJS什么都能做，为什么还要JAVA？
这些问题要说清楚不容易，下面说下我的认识过程。
3.2 为什么要增加一层NodeJS？
现阶段我们主要以后端MVC的模式进行开发，这种模式严重阻碍了前端开发效率，也让后端不能专注于业务开发。
解决方案是让前端能控制Controller层，但是如果在现有技术体系下很难做到，因为不可能让所有前端都学java，安装后端的开发环境，写VM。
NodeJS就能很好的解决这个问题，我们无需学习一门新的语言，就能做到以前开发帮我们做的事情，一切都显得那么自然。
3.3 性能问题
分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高开发效率。分层带来的损失，一定能在其他方面的收益弥补回来。
另外，一旦决定分层，我们可以通过优化通讯方式、通讯协议，尽可能把损耗降到最低。
举个例子：
淘宝宝贝详情页静态化之后，还是有不少需要实时获取的信息，比如物流、促销等等，因为这些信息在不同业务系统中，所以需要前端发送5，6个异步请求来回填这些内容。
有了NodeJS之后，前端可以在NodeJS中去代理这5个异步请求，还能很容易的做Bigpipe,这块的优化能让整个渲染效率提升很多。
可能在PC上你觉得发5,6个异步请求也没什么，但是在无线端，在客户手机上建立一个HTTP请求开销很大，有了这个优化，性能一下提升好几倍。
淘宝详情基于NodeJS的优化我们正在进行中，上线之后我会分享一下优化的过程。
3.4 前端的工作量是否增加了？
相对于只切页面/做demo，肯定是增加了一点，但是当前模式下有联调、沟通环节，这个过程非常花时间，也容易出bug，还很难维护。
所以，虽然工作量会增加一点，但是总体开发效率会提升很多。
另外，测试成本可以节省很多。以前开发的接口都是针对表现层的，很难写测试用例。如果做了前后端分离，甚至测试都可以分开，一拨人专门测试接口，一拨人专注测试UI（这部分工作甚至可以用工具代替）。
3.5 增加Node层带来的风险怎么控制？
随着Node大规模使用，系统/运维/安全部门的同学也一定会加入到基础建设中，他们会帮助我们去完善各个环节可能出现的问题，保障系的稳定性。
3.6 Node什么都能做，为什么还要JAVA？
我们的初衷是做前后端分离，如果考虑这个问题就有点违背我们的初衷了。即使用Node替代Java，我们也没办法保证不出现今天遇到的种种问题，比如职责不清。我们的目的是分层开发，专业的人，专注做专业的事。基于JAVA的基础架构已经非常强大而且稳定，而且更适合做现在架构的事情。
四、淘宝基于Node的前后端分离
上图是我理解的淘宝基于Node的前后端分离分层，以及Node的职责范围。简单解释下：
最上端是服务端，就是我们常说的后端。后端对于我们来说，就是一个接口的集合，服务端提供各种各样的接口供我们使用。因为有Node层，也不用局限是什么形式的服务。对于后端开发来说，他们只用关心业务代码的接口实现。
服务端下面是Node应用。
Node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式，封装一些view层需要的Model。
Node层还能轻松实现原来vmcommon,tms（引用淘宝内容管理系统）等需求。
Node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合，xTemplate能做到前后端公用。
怎么用Node大家自己决定，但是令人兴奋的是，我们终于可以使用Node轻松实现我们想要的输出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步，想怎么整就怎么整，完全根据你的场景决定。
浏览器层在我们这个架构中没有变化，也不希望因为引入Node改变你以前在浏览器中开发的认知。
引入Node，只是把本该就前端控制的部分交由前端掌控。
这种模式我们已经有两个项目在开发中，虽然还没上线，但是无论是在开发效率，还是在性能优化方面，我们都已经尝到了甜头。
五、我们还需要要做什么？
把Node的开发流程集成到淘宝现有的SCM流程中。
基础设施建设，比如session,logger等通用模块。
最佳开发实践
线上成功案例
大家对Node前后端分离概念的认识
技术上不会有太多需要去创新和研究的，已经有非常多现成的积累。其实关键是一些流程的打通和通用解决方案的积累，相信随着更多的项目实践，这块慢慢会变成一个稳定的流程。
六、“中途岛”
虽然“基于NodeJS的全栈式开发”模式很让人兴奋，但是把基于Node的全栈开发变成一个稳定，让大家都能接受的东西还有很多路要走，我们正在进行的“中途岛”项目就是为了解决这个问题。虽然我们起步不久，但是离目标已经越来越近！！
可能感兴趣的话题
o 108 回复
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线博客团队正试图以我们微薄的力量，把优秀的原创/译文分享给读者，做一个小而精的精选博客，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2015 伯乐在线
赞助云主机