说说我自己对 node 和 js 当前发展路线的“困惑”：
首先，用户群体本身没有啥问题的，js 在语言排名上长期处于 5 名左右。用户社群可能比不上排第一的 java，但是也差不到哪里去。
按理说，当一门技术有相当的使用者，哪怕这个技术本来其实不咋地，但是用户的需求会倒逼技术本身进步，使它逐步补全自己的短板，比如 JVM 刚诞生的时候也不咋地，硬是靠着开源社区的反馈磕磕碰碰但是逐步完善到了今天。

我曾经也是这么看待 JS 语言以及 NodeJS，甚至几年前 NodeJS 向后端渗透时，我曾经很乐观的认为，对后端的介入会让 JS 和 NodeJS 理解到自身的短板在哪里，并加速进步。

然而几年过去了，JS 和 NodeJS 进步了吗？进步了，但是那些应该补上的短板呢？补上了吗？没！

JS 委员会忙着添加各式各样的语法糖，但对前端业界面对的业务复杂度上升，需要工程化，需要更严谨，需要多人协作的呼声视而不见——你们去用 TS 好了，TS 挺好的，类型系统完善，语法优美，社区支持度高。至于我们 JS，那当然要添加更多的特性，更加的灵活，更加的“动态”。。。

你们 JS 技术委员会真的认为只挖新坑不填旧坑就可以了吗？

再说 NodeJS 向后端进军的努力，前后端使用一种语言，降低开发者心智负担，伟大的理想，应该支持啊。然而几年过去了，NodeJS 仍然守着事件机制不放手，好不容易加入了多线程支持，我一看那实现方式我就觉得自己受到了智商侮辱，你管这个叫多线程解决方案？

NodeJS 这几年的技术发展没有一点向别的语言技术学习长处弥补短板的意思，始终停留在自己的舒适区里。若非如此，哪怕 js 本身有各种问题，NodeJS 也不至于只是在 SSR 这个保留地蹲着，早就该扩散了，毕竟前后端同一种语言可是能节约巨量的成本的，然而现在拿 NodeJS 搞 web api 的都没几家（不用拿我公司用了之类的留言，事实就是没几家，对 web 的传统服务领域一点威胁都没有）。

用户真的不是傻逼，1 个领域经过长期发展遗留下来的有历史包袱，但也有时宝贵经验，你总觉得那些都是历史包袱，我和他们不一样是我先进，所以我能取胜，那你只会换来冷遇。不是所有的不同都是你先进，也可能其实是你落后，该补课。

最后说一嘴 NPM，这里我不谈技术好坏，我就想问问，bug 各家包管理里的代码都有，但是，你这包管理工具三天两头的被黑客黑进去放恶意代码，你是缺钱呢还是缺人呢还是缺钱呢？？


说真的，我看到 NodeJS 和 JS 现在这个样子，对我自己的经验产生了深深的怀疑，因为历史上没有哪家技术获得了用户的广泛使用后，发展路径是这个样子的。感觉 js 和 nodejs 的技术掌舵人们一副我行我素，完全不理会工程界实际需求的味道，而且 NPM 屡次出现黑客渗透事故也让整个 NodeJS 背后的组织透出一股贫穷的气息。这不符合你的身份啊，全世界的 web 都要用的东西，你缺钱缺人？也许我老了，看错了，NodeJS 其实根本没到大众推广阶段，还只是早期使用阶段，所以才这么多问题？需要再给多点时间？

我会继续关注 JS 和 NodeJS，毕竟一个控制着世界上最广泛使用的开放标准 UI 系统，一个有着前后端同一种语言编写的梦想。但你要说他们现在就很有前景。。。我心里有困惑。

最后 PS 一下，JS 和 NodesJS 的主要竞争对手可没闲着，JVM 正在执行瘦身计划以解决启动内存占用过大问题，Go 正在突飞猛进。并且你 JS 在挖后端的墙角，就没注意到那个 TS 其实是你在前端最大的问题吗，一众后端语言都觉得和尚摸得我摸不得？为啥不能借着编译干脆把 JS 埋葬掉算了？更别提那个野心勃勃的 WebAssembly。别到时候后端没啃下来，前端的基本盘岌岌可危啊

@brucefu 在环境有局限无法直接用域名或者其它方式区分请求是否是静态资源的时候，怎么了？不满，整天一副要改变世界的做派，却是一副这也看不起，那也看不起的做派。技术为需求服务，别自以为是了

你们这是有技术洁癖吗？.do 怎么就不行了，非要各个符合 REST，graphql 你们才满意，有些场合必须用后缀的方法来区分到底是动态链接请求还是静态资源请求的

一个广泛使用，处于活跃期的语言，你说它突然不支持另外一个广泛使用，处于活跃更新期的技术，一般这种情况下请先找自己的问题

软件工程的重点是“与人协作”。不需要与人协作的话，你几乎不需要软件工程，只要你隔几个月回来看代码时（那时等于未来的你和过去的你协作）不被翔山熏死就行

key 都不固定的？ key 不固定我怎么知道你那个键代表啥意思？怎么会出现 key 都不固定的设计？
这是哪个设计的，键盘砸它脸上去

/opt 目录现在是 Linux 官方推荐的用于放置对外提供服务的程序和文件的地方

我见过一个简单的思路，抽奖的请求全部排队，只允许和当前奖品剩余数量相等的请求数进入队列，超出的请求立刻返回“未中奖”。然后进入队列的请求再进行抽奖逻辑，绝不会超出剩余奖品，而且用户体验也还可以，当然对上专业黑产羊毛党会很头疼

@mayx 千万不要预言客户端的趋势，如果你是从 windows 时代一路过来的，应该知道几个历史，windows 从如日中天到被移动端吃掉大部分民用基本盘就 3 年的时间，而塞班这玩意甚至可以称作是“一夜之间”被干翻
其实客户端作为直接和客户打交道的领域，有很大的业务价值，但是这个价值，往往是由设计(美术)带来的，不是由技术带来的，相反技术在客户端这个领域老是不够，这就导致客户端的技术变动极其的剧烈，各路野心家死不绝，客户端领域绝对不会太平，个人深耕一门客户端技术，划不来，说不好突然就城头变幻大王旗了

你是不是参数设错了，数据库的耗时变高后，消费 client 可能因为超时而出错，多次出错后，client 可能会自动停下来，我在别的消息队列里见过这种设计

@master13 你看看 thinkjs 的更新时间，就知道为啥这东西热度下降了，多嘴说一句，这东西提供的命令行工具有 bug，我在 windows 起一个脚手架就卡在那里了，去提 issure 别人说要用 powershell 别用命令行，但是我用 powershell 还是卡在那里

这东西要容易的话，也不会被 C 打败了，要知道这东西在当年的大牛眼里可是“完美的设计”，而 c 不过是“丑陋而笨拙的设计”。结果最后是更简单的赢了

没有事务问题时，你可以这么做，有事务的时候你要当心事务传递失效问题。一般情况下有事务的情况我都是自建一个 service 然后调用多个 dao 来完成事务，代码会有冗余，但是足够安全，而且业务隔离，不会影响到其他

ROR 在当年有非常优雅的 ORM 实现，ActiveRecord 和链式调用的实践开创者。后来这两个套路被别的 Web 框架学过去了，就泯然众人矣了，毕竟动态语言先天的弱点是摆在那里的

Go 这门语言目前最大的问题还是用的人不够多

这东西绝不是单单数据库，需要专线网络，一般人哪里玩的起

lua 才不是胶水语言好不好，你要找胶水语言那 python 是唯一选择，人家和各种语言都能胶水起来，库又多。lua 最多还是和 c 交互，游戏领域用的多（暴雪的 wow 带起来的）

Spring security 实现的非常学术化，很多地方很死板，尤其是对登录处理器的配置，一点都不如 shiro 灵活，我不建议用这个库，甚至 spring 自己的社区用的都是 shiro

Electron 的性能瓶颈在于内存吃的太多，渲染才不是瓶颈，有多少软件 UI 一定需要 60fps 啊？