p*****2
发帖数: 21240 | 1 node真不是那么容易驾驭的
所以node转go我真不奇怪 |
l*********s
发帖数: 5409 | |
p*****2
发帖数: 21240 | 3 不是看好 傻瓜语言最容易流行 比如java python go
不过跟我都没啥关系 我不在乎语言 我在乎的是生产力
【在 l*********s 的大作中提到】
: 二爷也看好go了啊，all-in了!
|
c******o
发帖数: 1277 | 4 我们的游戏是nodejs的。
网站是ruby的，用户数据平台后端和大数据分析后段都是scala的。
DevOPs是ruby/shell
各有各的应用。 |
p*****2
发帖数: 21240 | 5 赞大牛
我们前端node 后端scala devops ruby
跟你们类似了
【在 c******o 的大作中提到】
: 我们的游戏是nodejs的。
: 网站是ruby的，用户数据平台后端和大数据分析后段都是scala的。
: DevOPs是ruby/shell
: 各有各的应用。
|
l*********s
发帖数: 5409 | 6 ：-）， 流行就是一切了。
【在 p*****2 的大作中提到】
: 不是看好 傻瓜语言最容易流行 比如java python go
: 不过跟我都没啥关系 我不在乎语言 我在乎的是生产力
|
y**********u
发帖数: 6366 | 7 羡慕啊
你们这些都是技术型公司
【在 p*****2 的大作中提到】
: 赞大牛
: 我们前端node 后端scala devops ruby
: 跟你们类似了
|
l**********n
发帖数: 8443 | 8 The problem with node is you can't do any parallel code execution.
NodeJS works pretty well for webapp servers as most of the time is actually
spent on waiting for network or disk (database / sockets) and the logic is
not really CPU intensive.
Anything CPU intensive is problematic for node. |
b***e
发帖数: 1419 | 9 So the question is, in the past 5 year, how many CPU intensive work did you
need to do?
actually
【在 l**********n 的大作中提到】
: The problem with node is you can't do any parallel code execution.
: NodeJS works pretty well for webapp servers as most of the time is actually
: spent on waiting for network or disk (database / sockets) and the logic is
: not really CPU intensive.
: Anything CPU intensive is problematic for node.
|
w**z
发帖数: 8232 | 10 node.js 适合web application 倒是真的。但现在大部分写软件的都在写web app。不
过这在本版好像不符合。
you
【在 b***e 的大作中提到】
: So the question is, in the past 5 year, how many CPU intensive work did you
: need to do?
:
: actually
|
|
|
N*****m
发帖数: 42603 | 11 主要是前后端通吃，这点很重要
【在 p*****2 的大作中提到】
: node真不是那么容易驾驭的
: 所以node转go我真不奇怪
|
d****i
发帖数: 4809 | 12 This is not a problem for Node at all. JavaScript is already super fast now
thanks to V8. For applications where you really need bare-metal performance,
you can use node-fft to call native libraries written in C/C++ easily,
pretty much like what JNI and JNA does for Java.
https://www.npmjs.com/package/node-ffi
actually
【在 l**********n 的大作中提到】
: The problem with node is you can't do any parallel code execution.
: NodeJS works pretty well for webapp servers as most of the time is actually
: spent on waiting for network or disk (database / sockets) and the logic is
: not really CPU intensive.
: Anything CPU intensive is problematic for node.
|
l*********s
发帖数: 5409 | 13 What is the benchmark between node vs go?
now
performance,
【在 d****i 的大作中提到】
: This is not a problem for Node at all. JavaScript is already super fast now
: thanks to V8. For applications where you really need bare-metal performance,
: you can use node-fft to call native libraries written in C/C++ easily,
: pretty much like what JNI and JNA does for Java.
: https://www.npmjs.com/package/node-ffi
:
: actually
|
l**********n
发帖数: 8443 | 14 这不是比快慢。
now
performance,
【在 d****i 的大作中提到】
: This is not a problem for Node at all. JavaScript is already super fast now
: thanks to V8. For applications where you really need bare-metal performance,
: you can use node-fft to call native libraries written in C/C++ easily,
: pretty much like what JNI and JNA does for Java.
: https://www.npmjs.com/package/node-ffi
:
: actually
|
j********x
发帖数: 2330 | 15 js好歹是web前段的统治级语言
有人会小看么
。。。
【在 p*****2 的大作中提到】
: node真不是那么容易驾驭的
: 所以node转go我真不奇怪
|
p*****2
发帖数: 21240 | 16
actually
you can't do any parallel code execution
你怎么能犯这么低级的错误呢？
【在 l**********n 的大作中提到】
: The problem with node is you can't do any parallel code execution.
: NodeJS works pretty well for webapp servers as most of the time is actually
: spent on waiting for network or disk (database / sockets) and the logic is
: not really CPU intensive.
: Anything CPU intensive is problematic for node.
|
l**********n
发帖数: 8443 | 17 async = require('async')
async.parallel([
function(callback){
for (var i = 0; i < 1000000000; i++) /* Do nothing */;
console.log("function: 1")
},
function(callback){
console.log("function: 2")
}
]);
what result you expect?
【在 p*****2 的大作中提到】
:
: actually
: you can't do any parallel code execution
: 你怎么能犯这么低级的错误呢？
|
l**********n
发帖数: 8443 | 18 async = require('async')
request = require('request')
async.parallel([
function(callback){
request("http://google.jp", function(err, response, body) {
if(err) { console.log(err); callback(true); return; }
console.log("function: 1")
callback(false);
});
},
function(callback){
request("http://google.com", function(err, response, body) {
if(err) { console.log(err); callback(true); return; }
console.log("function: 2")
callback(false);
});
}
]);
what would you expect of this? |
L***s
发帖数: 1148 | 19 node做web server是合适的，因为不同用户的请求之间基本相互独立，
单线程异步的模型非常合适。
比如贱厂的web，一个页面大概包含3-6个micro services，每个service在
10-30个VMs上跑，每个VM大概起60-120个node进程，每个进程跑同一个app。
单个进程崩溃、重启、又崩溃、又重启，是家常便饭，不影响整体availability。
跟DB/storage打交道的逻辑，一般不在web server上做，是后台独立的，
跟web server之间用RESTful API隔离。
actually
【在 l**********n 的大作中提到】
: The problem with node is you can't do any parallel code execution.
: NodeJS works pretty well for webapp servers as most of the time is actually
: spent on waiting for network or disk (database / sockets) and the logic is
: not really CPU intensive.
: Anything CPU intensive is problematic for node.
|
p*****2
发帖数: 21240 | 20 从来不用这些
【在 l**********n 的大作中提到】
: async = require('async')
: request = require('request')
: async.parallel([
: function(callback){
: request("http://google.jp", function(err, response, body) {
: if(err) { console.log(err); callback(true); return; }
: console.log("function: 1")
: callback(false);
: });
: },
|
|
|
d****n
发帖数: 1637 | 21 你这个 写法block了， wrap each task in setImmediate and try minimize each
task size
async = require('async')
async.parallel([
function(callback){
setImmediate(function(){
for (var i = 0; i < 1000000000; i++) {;}/* Do nothing */;
console.log("function: 1")
callback();
});
},
function(callback){
setImmediate(function(){
console.log("function: 2");
callback();// you missed callback here,不用谢了 :)
});
}
]);
另外：这个也不是multiple threads, event queue 而已
【在 l**********n 的大作中提到】
: async = require('async')
: request = require('request')
: async.parallel([
: function(callback){
: request("http://google.jp", function(err, response, body) {
: if(err) { console.log(err); callback(true); return; }
: console.log("function: 1")
: callback(false);
: });
: },
|
d****n
发帖数: 1637 | 22 好奇二爷的node都是怎么用的？
【在 p*****2 的大作中提到】
: 从来不用这些
|
b***e
发帖数: 1419 | 23 这个也不行。中间的big loop怎么说也是一个even handling。逃不掉。只能在i++上加
timeout。node.js的确不是用来做cpu intensive的东西的。象他写的这个例子，就像
是京二说的，是应该避免的。
【在 d****n 的大作中提到】
: 你这个 写法block了， wrap each task in setImmediate and try minimize each
: task size
: async = require('async')
: async.parallel([
: function(callback){
: setImmediate(function(){
: for (var i = 0; i < 1000000000; i++) {;}/* Do nothing */;
: console.log("function: 1")
: callback();
: });
|
b***e
发帖数: 1419 | 24 Then just answer the question. Or if you prefer, let's survey it out on the
board.
【在 w**z 的大作中提到】
: node.js 适合web application 倒是真的。但现在大部分写软件的都在写web app。不
: 过这在本版好像不符合。
:
: you
|
p*****2
发帖数: 21240 | 25 裸写monad
【在 d****n 的大作中提到】
: 好奇二爷的node都是怎么用的？
|
b***e
发帖数: 1419 | 26 coffee-monad没有composability，过于玩具化。实际中用得上么？我原来做过一个带
transformer的。有空整理出来。我倒是感兴趣你有没有做出过什么非常规的monad。
【在 p*****2 的大作中提到】
: 裸写monad
|
z****e
发帖数: 54598 | 27 红果果地打那些说前后端一起做的脸
你说的这些，那些前端程序员能看懂么？
像金字塔一样的callback陷阱真是让人无语
都说try catch恶心，callback陷阱没几个前端程序员能绕开的
【在 L***s 的大作中提到】
: node做web server是合适的，因为不同用户的请求之间基本相互独立，
: 单线程异步的模型非常合适。
: 比如贱厂的web，一个页面大概包含3-6个micro services，每个service在
: 10-30个VMs上跑，每个VM大概起60-120个node进程，每个进程跑同一个app。
: 单个进程崩溃、重启、又崩溃、又重启，是家常便饭，不影响整体availability。
: 跟DB/storage打交道的逻辑，一般不在web server上做，是后台独立的，
: 跟web server之间用RESTful API隔离。
:
: actually
|
p*****2
发帖数: 21240 | 28 在某些情况可以利用这个pattern
比如串行执行很多命令 但是其中一个fail了可以继续执行 结束条件则可以自定义
不需要其他library 自己实现monad就可以了
【在 b***e 的大作中提到】
: coffee-monad没有composability，过于玩具化。实际中用得上么？我原来做过一个带
: transformer的。有空整理出来。我倒是感兴趣你有没有做出过什么非常规的monad。
|
L***s
发帖数: 1148 | 29 我现在就做“前端”啊，包括browser端的html/css/js assets，和web server端
的nodejs micro service —— 由于业务逻辑上耦合很紧，都放在一个repo里。
nodejs micro service 主要是服务请求、做页面渲染（由于SEO/SEM的原因，
越来越多的页面放到服务器上去渲染）；browser端js做强交互性的东西。
我们从用户浏览器到DB，大概经过这么几层，每下一层都有一次RESTful call：
1. Browser JS
2. Nodejs micro services (at customer facing web servers)
3. API layer (external; for web, mobile web, mobile apps)
4. Backend services (DB access, indexing, ...)
5. Downstream backend services
由于“前”和“后”是相对的，取决于你的站位，我一般避免这样称呼。
如果实在要说，API layer以上（包括1 & 2）的我们统称“前端”。
有些小公司把2称作“后端”，并且把2和4/5放到同层的web server上，
那是因为他们没有一个API layer把后端服务封装起来。
【在 z****e 的大作中提到】
: 红果果地打那些说前后端一起做的脸
: 你说的这些，那些前端程序员能看懂么？
: 像金字塔一样的callback陷阱真是让人无语
: 都说try catch恶心，callback陷阱没几个前端程序员能绕开的
|
L***s
发帖数: 1148 | 30 二爷的node像是非典型用法，呵呵。他的应用场景，可选的技术很多，
所以可以经常在不同技术栈之间摇摆。我们前端开发选node，
是因为其实没有这么多好的选项。
【在 d****n 的大作中提到】
: 好奇二爷的node都是怎么用的？
|
|
|
s***o
发帖数: 2191 | 31 第一层js是从第二层还是第三层取数据？
【在 L***s 的大作中提到】
: 我现在就做“前端”啊，包括browser端的html/css/js assets，和web server端
: 的nodejs micro service —— 由于业务逻辑上耦合很紧，都放在一个repo里。
: nodejs micro service 主要是服务请求、做页面渲染（由于SEO/SEM的原因，
: 越来越多的页面放到服务器上去渲染）；browser端js做强交互性的东西。
: 我们从用户浏览器到DB，大概经过这么几层，每下一层都有一次RESTful call：
: 1. Browser JS
: 2. Nodejs micro services (at customer facing web servers)
: 3. API layer (external; for web, mobile web, mobile apps)
: 4. Backend services (DB access, indexing, ...)
: 5. Downstream backend services
|
L***s
发帖数: 1148 | 32 第二层。每一层只能跟临近层通信。所以，如果每一层都没有cache，
浏览器要取到DB数据，要经过若干次RESTful API calls。
第二层的nodejs micro service主要是面向 传统桌面web 和 移动端浏览器
上的web（终端设备form factor不一样，但tech stack一样）。
mobile apps (iOS, Adroid, WP, ...) 直接调第三层API。
所以我们把1&2层统称“前端”：桌面web、移动web、移动apps，是三种不同的“前端
”。
【在 s***o 的大作中提到】
: 第一层js是从第二层还是第三层取数据？
|
l**********n
发帖数: 8443 | 33 node handle cpu intensive job 的方法不外乎
cluster
webworker-thread
chunk up the job.
node只有一个worker thread.
netty有thread pool.
【在 L***s 的大作中提到】
: 第二层。每一层只能跟临近层通信。所以，如果每一层都没有cache，
: 浏览器要取到DB数据，要经过若干次RESTful API calls。
: 第二层的nodejs micro service主要是面向 传统桌面web 和 移动端浏览器
: 上的web（终端设备form factor不一样，但tech stack一样）。
: mobile apps (iOS, Adroid, WP, ...) 直接调第三层API。
: 所以我们把1&2层统称“前端”：桌面web、移动web、移动apps，是三种不同的“前端
: ”。
|
l**********n
发帖数: 8443 | 34 my question is
单线程快，还是多线程快。
【在 l**********n 的大作中提到】
: node handle cpu intensive job 的方法不外乎
: cluster
: webworker-thread
: chunk up the job.
: node只有一个worker thread.
: netty有thread pool.
|
s***o
发帖数: 2191 | 35 这个架构跟用nginx做Web Server，用js直接从第三层api取数据相比，有什么好处？
【在 L***s 的大作中提到】
: 第二层。每一层只能跟临近层通信。所以，如果每一层都没有cache，
: 浏览器要取到DB数据，要经过若干次RESTful API calls。
: 第二层的nodejs micro service主要是面向 传统桌面web 和 移动端浏览器
: 上的web（终端设备form factor不一样，但tech stack一样）。
: mobile apps (iOS, Adroid, WP, ...) 直接调第三层API。
: 所以我们把1&2层统称“前端”：桌面web、移动web、移动apps，是三种不同的“前端
: ”。
|
N*****m
发帖数: 42603 | 36 nginx是http server；楼上说的是web service，不单单是一个http server
【在 s***o 的大作中提到】
: 这个架构跟用nginx做Web Server，用js直接从第三层api取数据相比，有什么好处？
|
z****e
发帖数: 54598 | 37 一样的
没啥本质上的区别
多了两个无聊的http methods
这种构架是典型的企业构架
某些公司死守node让人很无语
我见过不只一个公司用其他的http server来做ws
本来restful就用了http
更何况node很多公司就是用来做web server而不是web service server的
还有就是现在很多http server也都能提供异步和web service的功能
【在 N*****m 的大作中提到】
: nginx是http server；楼上说的是web service，不单单是一个http server
|
z****e
发帖数: 54598 | 38 那你们换node.js的障碍就只剩下一个npm了
你们不是没有选择
是你们老板不愿意丢掉sunk cost
一条路走到黑
另外app直接调第三层api这个也没有必要
用node就可以做一个ws server，而不仅仅是web server
做点安全验证啥的在这一层
【在 L***s 的大作中提到】
: 第二层。每一层只能跟临近层通信。所以，如果每一层都没有cache，
: 浏览器要取到DB数据，要经过若干次RESTful API calls。
: 第二层的nodejs micro service主要是面向 传统桌面web 和 移动端浏览器
: 上的web（终端设备form factor不一样，但tech stack一样）。
: mobile apps (iOS, Adroid, WP, ...) 直接调第三层API。
: 所以我们把1&2层统称“前端”：桌面web、移动web、移动apps，是三种不同的“前端
: ”。
|
z****e
发帖数: 54598 | 39 如果我没猜错的话
异步，web service和npm是当时的主要考虑
现在异步已经烂大街了
什么http server都有了，ws也差不多
就剩下npm了，这个其实也不是完全不可替代的
就是轮子造起来麻烦
说到底还是懒
你上次抱怨的那一层层的callback的代码可维护性强么？
看上去简直就是噩梦一般的存在
跟fp的一堆嵌套起来的括号有一拼
【在 L***s 的大作中提到】
: 二爷的node像是非典型用法，呵呵。他的应用场景，可选的技术很多，
: 所以可以经常在不同技术栈之间摇摆。我们前端开发选node，
: 是因为其实没有这么多好的选项。
|
L***s
发帖数: 1148 | 40 nginx是web server，我们用nodejs写的service也是跑在nginx上的。
我上面写的第1层就是前端里的client端，第2层是前端里的server端。
（client-server之间其实还有a cluster of load balancers，
由于属于non-functional需求，我前面略去不提。）
“用js直接从第三层api取数据相比”——你是说第1层client端的js吗？
原因A：client js是你首次访问url时，server返回给你浏览器的，
既然需要server参与，“绕过server直接从client访问api”这种需求就没有意义。
原因B：绝大多数的业务逻辑必须server端实现，因为：1. 业务本身的复杂性
（各种scenarios, internationalization/localization, A/B testing ...）；
2. server-side page rendering for SEO/SEM；3. 商业机密、安全原因；
4. 体积尺寸（我们一个micro service有约40万行coffee代码，编译成js要近百万）；
这些都决定了这些不可能写成client js，只能放在server端。
mobile app是特殊情况，因为你已经在手机上下载了我们的app，于是原因A无效。
其次，我们mobile app能实现的功能是桌面web的一个比较小的子集，
业务逻辑相对简单，所以原因B无效。所以mobile app允许（也只能）直接call API。
【在 s***o 的大作中提到】
: 这个架构跟用nginx做Web Server，用js直接从第三层api取数据相比，有什么好处？
|
|
|
L***s
发帖数: 1148 | 41
debugging callback hell还是比较痛苦的。我觉得困难倒不在于callback本身，
而在于levels of indirection。“Every problem can be solved with
another level of indirection”——于是indirection容易被滥用，
读代码时大脑很容易爆栈。
就js而言，client端可以在runtime用browser来debug（比如chrome你可以开
async mode看call stack），30层callback捉虫起来困难也不是太大。
server端就比较麻烦，我一直没有找到称手的工具，一直是console.log大法。
【在 z****e 的大作中提到】
: 如果我没猜错的话
: 异步，web service和npm是当时的主要考虑
: 现在异步已经烂大街了
: 什么http server都有了，ws也差不多
: 就剩下npm了，这个其实也不是完全不可替代的
: 就是轮子造起来麻烦
: 说到底还是懒
: 你上次抱怨的那一层层的callback的代码可维护性强么？
: 看上去简直就是噩梦一般的存在
: 跟fp的一堆嵌套起来的括号有一拼
|
z****e
发帖数: 54598 | 42 30层还不够痛苦啊？
你真牛逼
java代码多来几层try catch，下面一堆人骂娘
30层估计有人爆发了，呵呵
我一直很佩服你，用chrome来debug
用vi来写代码，这种工作效率其实是不高的
我用dart，基本上就不需要chrome和vi
一个人最近写了上万行代码，都一个人做的
别人维护起来也没啥大问题，debug没有ide帮忙感觉都很痛苦
我做很多项目第一件事就是下ide，呵呵
运行时断点＋看内存的value是ide里面非常常用的一个工具
这个vi就做不了了
【在 L***s 的大作中提到】
:
: debugging callback hell还是比较痛苦的。我觉得困难倒不在于callback本身，
: 而在于levels of indirection。“Every problem can be solved with
: another level of indirection”——于是indirection容易被滥用，
: 读代码时大脑很容易爆栈。
: 就js而言，client端可以在runtime用browser来debug（比如chrome你可以开
: async mode看call stack），30层callback捉虫起来困难也不是太大。
: server端就比较麻烦，我一直没有找到称手的工具，一直是console.log大法。
|
L***s
发帖数: 1148 | 43 动态语言，IDE帮助不大的，js/ruby/python都一样，维护都是grep大法。
【在 z****e 的大作中提到】
: 30层还不够痛苦啊？
: 你真牛逼
: java代码多来几层try catch，下面一堆人骂娘
: 30层估计有人爆发了，呵呵
: 我一直很佩服你，用chrome来debug
: 用vi来写代码，这种工作效率其实是不高的
: 我用dart，基本上就不需要chrome和vi
: 一个人最近写了上万行代码，都一个人做的
: 别人维护起来也没啥大问题，debug没有ide帮忙感觉都很痛苦
: 我做很多项目第一件事就是下ide，呵呵
|
k****i
发帖数: 101 | 44 # Truth of Node in ls
{sleep} = require sleep
delay = (sec, seq) ->
<-! setTimeout _, 1000 * sec
console.log seq
# blocking
delay 3 2nd
sleep 4
console.log 1st
# non-blocking
delay 2 4th
delay 1 3rd
【在 l**********n 的大作中提到】
: async = require('async')
: request = require('request')
: async.parallel([
: function(callback){
: request("http://google.jp", function(err, response, body) {
: if(err) { console.log(err); callback(true); return; }
: console.log("function: 1")
: callback(false);
: });
: },
|
T*******e
发帖数: 4928 | 45 what is the good ide for dart?
【在 z****e 的大作中提到】
: 30层还不够痛苦啊？
: 你真牛逼
: java代码多来几层try catch，下面一堆人骂娘
: 30层估计有人爆发了，呵呵
: 我一直很佩服你，用chrome来debug
: 用vi来写代码，这种工作效率其实是不高的
: 我用dart，基本上就不需要chrome和vi
: 一个人最近写了上万行代码，都一个人做的
: 别人维护起来也没啥大问题，debug没有ide帮忙感觉都很痛苦
: 我做很多项目第一件事就是下ide，呵呵
|
z****e
发帖数: 54598 | 46 dart editor
官方有自己的ide
【在 T*******e 的大作中提到】
: what is the good ide for dart?
|
d****n
发帖数: 1637 | 47 bluebird || highland work with async.
debug 实在是callback hell 引进来得，如果能结合promise and async, 再用些
commercial tools, e.g nodetime, strongLoop ?
【在 L***s 的大作中提到】
: 动态语言，IDE帮助不大的，js/ruby/python都一样，维护都是grep大法。
|
s***o
发帖数: 2191 | 48 多谢分享。
就是说第二层并不是第三层api的一个简单wrapper，而是加了很多其他东西？你们用的
什么Web framework？据说express的作者已经跑路了。另外40万行的coffee
maintainability怎么样？
【在 L***s 的大作中提到】
: nginx是web server，我们用nodejs写的service也是跑在nginx上的。
: 我上面写的第1层就是前端里的client端，第2层是前端里的server端。
: （client-server之间其实还有a cluster of load balancers，
: 由于属于non-functional需求，我前面略去不提。）
: “用js直接从第三层api取数据相比”——你是说第1层client端的js吗？
: 原因A：client js是你首次访问url时，server返回给你浏览器的，
: 既然需要server参与，“绕过server直接从client访问api”这种需求就没有意义。
: 原因B：绝大多数的业务逻辑必须server端实现，因为：1. 业务本身的复杂性
: （各种scenarios, internationalization/localization, A/B testing ...）；
: 2. server-side page rendering for SEO/SEM；3. 商业机密、安全原因；
|
W***o
发帖数: 6519 | 49 the express author wrote this new framework: koa
https://github.com/koajs/koa
【在 s***o 的大作中提到】
: 多谢分享。
: 就是说第二层并不是第三层api的一个简单wrapper，而是加了很多其他东西？你们用的
: 什么Web framework？据说express的作者已经跑路了。另外40万行的coffee
: maintainability怎么样？
|
l**********n
发帖数: 8443 | 50 yield现在很多browser不支持
【在 W***o 的大作中提到】
: the express author wrote this new framework: koa
: https://github.com/koajs/koa
|
|
|
d*******r
发帖数: 3299 | 51 你们第3层主要做个 adapter, 屏蔽前后端的各种细节，认证什么的，也在这里做吗
【在 L***s 的大作中提到】
: 我现在就做“前端”啊，包括browser端的html/css/js assets，和web server端
: 的nodejs micro service —— 由于业务逻辑上耦合很紧，都放在一个repo里。
: nodejs micro service 主要是服务请求、做页面渲染（由于SEO/SEM的原因，
: 越来越多的页面放到服务器上去渲染）；browser端js做强交互性的东西。
: 我们从用户浏览器到DB，大概经过这么几层，每下一层都有一次RESTful call：
: 1. Browser JS
: 2. Nodejs micro services (at customer facing web servers)
: 3. API layer (external; for web, mobile web, mobile apps)
: 4. Backend services (DB access, indexing, ...)
: 5. Downstream backend services
|
W***o
发帖数: 6519 | 52 所以说是next generation 的
【在 l**********n 的大作中提到】
: yield现在很多browser不支持
|
k***5
发帖数: 583 | 53 没IDE是很痛苦，但console.log是很多时候唯一的选择。IDE很多时候会莫名其妙不灵
，所以还是只能靠最原始的办法。
【在 z****e 的大作中提到】
: 30层还不够痛苦啊？
: 你真牛逼
: java代码多来几层try catch，下面一堆人骂娘
: 30层估计有人爆发了，呵呵
: 我一直很佩服你，用chrome来debug
: 用vi来写代码，这种工作效率其实是不高的
: 我用dart，基本上就不需要chrome和vi
: 一个人最近写了上万行代码，都一个人做的
: 别人维护起来也没啥大问题，debug没有ide帮忙感觉都很痛苦
: 我做很多项目第一件事就是下ide，呵呵
|
b*******s
发帖数: 5216 | 54 node is a light weight 'backend' like thing
not a real backend
【在 p*****2 的大作中提到】
: node真不是那么容易驾驭的
: 所以node转go我真不奇怪
|
b*******s
发帖数: 5216 | 55 if you adopt console dev, it takes time to build a tool chain. but worth it
【在 k***5 的大作中提到】
: 没IDE是很痛苦，但console.log是很多时候唯一的选择。IDE很多时候会莫名其妙不灵
: ，所以还是只能靠最原始的办法。
|
l**********n
发帖数: 8443 | 56 胡说。
【在 b*******s 的大作中提到】
: node is a light weight 'backend' like thing
: not a real backend
|
b***e
发帖数: 1419 | 57 0.12会从很大的程度上改善这种情况，如果generators被广泛的使用。Callback hell
将不复存在。
【在 L***s 的大作中提到】
: 动态语言，IDE帮助不大的，js/ruby/python都一样，维护都是grep大法。
|
b***e
发帖数: 1419 | 58 这个各有所好。不过你node做的还不够多。
【在 b*******s 的大作中提到】
: node is a light weight 'backend' like thing
: not a real backend
|
g****t
发帖数: 31659 | 59 obama都写javascript,不服来辩。
【在 p*****2 的大作中提到】
: node真不是那么容易驾驭的
: 所以node转go我真不奇怪
|
l**********n
发帖数: 8443 | 60 巴马是写爪哇吧，还用了design pattern
【在 g****t 的大作中提到】
: obama都写javascript,不服来辩。
|
|
|
i***h
发帖数: 12655 | 61 动态的维护是个问题，换个人可能还不如重新写
【在 L***s 的大作中提到】
: 动态语言，IDE帮助不大的，js/ruby/python都一样，维护都是grep大法。
|
