有一些技术观点，如果要一一细说，只怕得搞出几万字来，所以趁着春节放假，先写个概要出来，不打算仔细说，否则肯定写不完，又弄成虎头蛇尾的东西了。
一、相对于后端，前端是幸运的
后端的系统，运行的花销，是老板掏钱。前端的系统，运行的花销，是用户自己的电费和硬盘。目前的计算机（智能手机）已经足够强大，使得大多数用户，都不太在乎执行效率、网络传输、空间占用之类的问题（大型游戏除外）。尤其是在浏览器中运行的程序，现在的网络速度那么快，加载几百K的js，简直就是一眨眼的功夫。虽然还是会有人去优化、压缩js的大小，其实主要还是出于对服务器压力的考虑。
为什么就说前端幸运呢？因为后端掌握在公司自己手里，所以会考虑各种选择，比如后端的操作系统、硬件配置、语言选择、框架与类库等等等，排列组合，简直有几十万种选择。
而对于前端来说，唯一的选择就是HTML+CSS+JavaScript，而且考虑到很多用户，从来不会升级自己的浏览器，前端开发也不必（不该、不能）专门发挥某种特定浏览器的特长。 btw：JS这种语言，地位事实上无可动摇。
另一方面，也可以认为前端还是很不幸的。因为：后端的优劣标准已经很明确了，单台服务器的负载能力，多台服务器的平行扩展能力，系统的稳定性、可靠性，都是可以有确切的量化指标的。对于老板来说：同样的访问量，他需要花费的成本是否合理，能不能更加减少，这是硬指标。
因此，虽然后端系统看起来花样繁多，其实架构模式、最佳实践，都已经相当成熟，现在新出现的容器化浪潮，也不过是在省钱、省电的道路上，更进一步而已。
但是，前端的优劣，现在还没有什么特别刚性的标准。公说公有理婆说婆有理，说起花样繁多，后端完全自愧不如。前端工程师疲于奔命，也是难免的。当然，乱世出英雄，也不能说完全是不幸。
二、对于Ruby而言，成也Rails，败也Rails
没有rails，ruby大概只会是一门和Java同样古老，却始终默默无闻的语言。但是由于rails的火爆，很多人开始关注并喜欢上ruby这门优秀、优雅、但是运行效率却不够快的语言。
而且，在硬件高速发展的时代，语言、框架慢一点，似乎也并不要紧，再过18个月，新的服务器就会解决所有性能问题。
但是，随着后端发展大潮的日趋明确，云计算和容器化的兴起，榨干服务器的每一滴性能，成为语言和框架的使命。不能很好的契合这一使命的技术，就会变成事实上落后于时代的技术（即使我们依然喜欢）。
如果展开讨论，实在是要说太多，就一句话吧：Rails并没有什么迹象，考虑对docker的支持。而且，要让rails对docker有很好的支持，需要在架构层面，做天翻地覆的改造。但是这对于一个诞生接近12年的框架，几乎不可能。
也许，最理想的期望是：ruby社区诞生一个更好的框架，能够更加完美的支持容器和微服务的架构。
三、对于后端来说，node.js的潮流会过去的
这个话一出，估计就会有很多人不同意了，比如非常了解我的朋友：雪愚现在就一心认为nodejs非常有前途。
就像我在上一篇文章里说的：“后端开发...真正需要解决的问题，都不是语言层面的，也不是前端知识领域的。一个曾经的后端程序员，能够用好nodejs。一个专攻前端的程序员，其实用不好nodejs。”
对于后端有好奇心的前端程序员，他们在到达某种阶段时，难免会出现力不从心的现象。而对于一个有着丰富经验的后端程序员来说：其实他们现在有了更好的选择——“go”。因此，我的判断是：node.js的潮流会过去的。
四、对于前端来说，TypeScript只是又一个微软发明的搅局语言而已
“还记得VBScript，JScript，J++，J#吗？为何我对TypeScript保持警惕，就是因为前面这些技术。 ”
这是我在微博上写的一段话。微软曾经发明过很多搅局性的语言，目标都是为了挑战当时市场上的事实标准——然而，始终没有成功过。
在上一篇文章里，很多人因为这个观点，和我争论，我也不打算再仔细表述，立此存照吧。
五、语言看起来层出不穷，其实却越来越像了
还是不打算细说，那些编程语言的特性，其实在不同的语言之间，正在不断的互相借鉴，在实际编程实践中，各种语言特性，也在不断的经受检验，然后互相学习。
然后，语言的选择，很多时候就是“偶然+品味+偏好+误会”的结果，几乎很难有啥对错。比如说：我曾经因为go语言的fmt，感觉不爽，就一直没有下决心开始学，现在想来，也有些后悔。
六、比起语法特性，语言的生态圈更加重要
其实，我一直认为类似于gem、bundler、npm、maven、pip之类的包管理工具，是构筑编程语言生态圈的关键设施。
语言在Github开源+依托网络的包管理工具+所有包也在Github，基本上，现代编程语言，都在走这条路。至于优劣高下，完全取决于生态圈的健康繁荣程度了。
《开源也要讲注意力经济》，学会运营社区，非常重要。
