其实这根本不是技术栈的问题，而是node工程师没有后端经验的问题。如果有的话，会仅限于node吗？语言差距根本不是问题，语言本身就是工具，重点应该去考虑不要有太多异构，维护起来太麻烦。还要考虑开发者群体。node最适合的地方还是提供小型的工具服务，前端工程师不用去了解太多的后端知识，只要会基础的数据库读写，缓存的使用就能解决的问题。
评论0
加载中...
我专业前端做了很多年了，对js不能说是感情浅。但是node做后端，我还是觉得宁可重学一门后端语言也不会冒这个险，除非我干完项目拿钱走人别人去维护。我也知道一个大银行不是国内的，前几年被哪个头脑发热的技术牛人用js做了微服务，—后来项目用java重写了。第一, node没有多线程，以至于cpu-bound 任务是不可能的，如果没有守护程序和 load balance 来做服务程序去响应微小的负荷也是冒险。第二，node 如果不用 async 写出来的代码就是 callback hell, 如果再没有typescript, 维护起来是个噩梦。callback 是解决阻塞问题，但泛滥了就恶心了。 第三，也别想着维护三四年了，npm还没干什么就引用几十万个库了，有的库也就10行代码，库质量差，寿命短，真用的复杂库，几年后依赖的库有些已经不存在了。第三还是线程问题，别告诉我你多小的程序都配一个redis,部署和安全都是头痛问题-没有线程技术就无法共享数据缓冲数据。
总结：用nodejs做后端很作死。nodejs 在后端说白了只是一个高级的event bus, 一无是处。
评论0
加载中...
node之所以容易被接受，是应为js语言的普及性，但是考虑到全栈开发的话node并不是首选，传统的.net core和java还是首选。
如果仅仅考虑到各种各样的代码包，node确实有优势，但是在高精度运算方面js语言就和java，c#没法比了。
在服务器性能层面，node和j2ee,.net core,go比起来性能相差的非常多（大家可自行google一下benchmarking），因此其并不适合对性能要求比较高的服务环境。
另外，所谓全栈，还要包括移动应用和桌面应用，在移动应用方面原生开发的主要还是java和c#和oc，swift。
桌面级的原生跨平台应用主流的技术还得是c#，qt+c++等。mfc就不推荐了，估计近十年微软也没怎么太更新了。
把全部的技术堆栈全都赌在node上是比较危险的，因为node最初的想法是希望能给前端开发人员提供一个服务器端环境，一开始的定位就和经典技术栈的定位也不一样。
写好服务程序，除了会crud以外，需要程序员在内存控制，数据结构，算法过程控制等方面都要有更好的经验，即便像java，c#这样自动回收内存，内置数据结构的语言，也都要很小心内存开销，否则你的Stack Overflow，就真的只能去Stack Overflow去查了。
评论0
加载中...
有些公司觉得node全栈很厉害，做服务器小菜一碟。有些公司根本不认为node和服务器开发有一毛钱关系，别说重要系统了，次级系统node都别想沾下边。两级分化严重，这就是node和传统服务器的区别。
评论0
加载中...
1 没有成熟的微服务框架，主城还是喜欢java或者go
2 动态语言难以维护，需要很多文档，按照文档约定编码，但没法从代码层面强制约束
3 CPU运算利用不好，需要调用其他语言支持。但问题在于node一般都是快餐型小项目，节约开发成本npm包特别多，不是长期大项目的技术选型
4 随着golang的出现，大家都在往go上转了，node更适合外包小门户网站和前端。
评论0
加载中...
0
回答0
回答0
回答4
回答3
回答10
回答0
回答0
回答0
回答0
回答
