在软件开发中，追求新的技术意义大吗？

回复内容：

可怜的孩子，如果你上手的是 Vue 就不会这么惨了

---

为了避免偏题，我还是针对题主的感受多说一点。你用 Angular 遇到的这些挫折，根本原因不是因为你追求新技术，而是因为你在进入一个你比较陌生的领域的时候，却还选择了一个 learning curve 很糟糕的框架。

Angular 1 本身的 API 设计很繁琐，这些东西其实是 java 程序员把他们习惯的那一套『仪式感』带入了前端框架导致的，简言之就是『抽象概念太多』。然而这些东西在前端的语境下大部分都是除了增加系统复杂度之外毫无意义的糟粕。更糟的是对于新手来说，这些东西极大的增加了学习成本和挫折感。（讽刺的是另一方面也让很多投入了大量精力学习 Angular 的人产生了一种斯德哥尔摩情结 - 好不容易搞懂了，怎么能承认这些东西毫无意义？）

Angular 2 为什么要付出兼容性断层的代价彻底重写？就是因为 Angular 1 的 API 友好度太糟糕了。Angular 2 也转向了『一切都是组件』这样清晰易懂的模式，而不是上来就跟你提什么 dependency injection, controller, scope, service, factory, provider...

到目前为止，可以说你只是因为随大流所以选择了一个不理想的上手方向。但到你去追着用 Angular 2 的 router 的时候，就有些操之过急了。对于这种尚未发布的试作品，Google 自己都没用到生产环境里呢，如果你不是已经对 Angular 本身和前端架构有了深入的了解，基本上是 hold 不住的。

最后，追求新技术笼统来说肯定是有意义的，学无止境嘛。但是在解决实际问题的时候，选择一个自己 hold 得住的方案才是靠谱的。什么时候是在解决问题，什么时候是在学习，这个就得你自己拿捏了。 自己学习时要激进，要主动去了解最新的技术进展，以把握技术发展的脉博。
开发正式项目时，特别是商业项目则要保守，用最多人用的，坑己经被填得差不多的技术。 用最新的主流技术，并尝试理解相比它替换掉技术，改进和原因所在。

至于“用 5 到 10 年前的技术”这种说法我不是没听过，只不过首先这样的项目都是在处理 5 到 10 年前就被人解决完成了的问题，往大了说 10 年前还没有 iOS 开发呢不是（笑）前端是如此活跃的领域，倒退 10 年人们还在烧高香期待 IE 6 解放生产力，跟你现在了解的东西几乎没有什么关系。
其次你在可以试错的时候不去尽可能的犯错，等到你必须维护一坨 PHP 代码并赖以糊口的时候你就只有哭的事了。

所以，做足功课，如果现在在前端 MVC 上的主流前沿是 AngularJS 1.4，就不要浪费时间在 1.2 上。给自己一个时间框架，然后全力以赴去试；如果到时间了还是不能解决问题，那么立刻放弃，用自己熟悉的技术把项目完成，然后再去在没有项目时间压迫的地方试验。

不要停止脚步。 一定要更新知识结构
否则很快成为古董！！！

学习新的技术
不会让过去的知识显得过时
而是为你点亮了又一盏路灯

相信我
身后的路灯，
虽然离你渐远
其光芒一直在助你前行

迟早有一天
你会发现
你已经点亮了地图上的所有路灯
这让你自由驰骋
一往无前

少年，冲吧！ 基本功稀松
看什么都是新技术
基本功扎实
看什么都像是新瓶装旧酒 别问别人爽不爽，要问自己疼不疼

你不觉得疼你用新技术来做什么？先就自己想做的定义问题，然后看看根据自己现有的知识要怎么解决，如果能解决就开始动手，如果动手觉得工作量大／繁琐／心塞，这就是疼了，这时候看看别人怎么解决这个，过渡就很平滑，学习成本就很低。如果一直不疼，那你没事找什么事？ 我觉得作为技术人员，更应该focus在为什么会出现这种新技术上。
比如Javascript大家不是用的好好的么，为什么会有coffeescript、typescript出现？
比如jquery操作dom不是挺好的么，为什么会有knockout、angularjs出现？
比如memcached不是挺好的么，为什么会有redis出现？
而且上面所说的，看似关系不大，但其实又有关系，如果你不知道你为什么要去用angularjs，你也一定会觉得MV(Whatever)是MV(What the fu*k)，单纯为了发明一种技术而推出的技术不是技术，那是商品，而你是他们的产品。因为某种需求“自然而然”产生的技术是技术，你是他们的用户。
你们的项目越来越大，越来越慢，你难道不应该去想为什么慢，怎么能不慢么？

说到这儿，我想到一个故事，说MIT有几个人闲的无聊去监听俄罗斯卫星，后来尝试定位俄罗斯卫星，他们也确实做到了。有一天将军说，你们能不能用卫星定位自己？这在军事中会非常有用。于是有了GPS。 angular的话，你要用路由干什么？我觉得angular本身的路由功能应该很强了呀？如果你设不对的话，很可能是因为你的web service接口定义没有完全符合HTTP 1.1标准吧？或者有可能如果你看看编译原理就能找到一些可以绕过bug的方式了？

至于语言学习本身，我觉得语言可以说是贪多嚼不烂的典型，尤其python这种传统的OO语言和Javascript这种功能型语言可以说是风马牛不相及的（对于初学者而言）。所以我觉得先把其中一门大体吃透再去学下一门比较好。

不过不论如何，大四能做到这些东西还是很厉害的。坚持下去的话你一定会做的比大多数人好的多。 新的技术本质是伴随着"重构"的，你要做一个新东西，当然用最熟练和稳定的技术，实现的差不多了，再考虑重构，web里面的前后端分离，mvc也只是新瓶装旧酒罢了，正如《modern operating system》里面所说的那样，计算机科学中各个技术发展是个迂回的过程，一些没有意义的旧技术可能会在某个时间点重新发光，现在的新技术也会很快过时。
我很久以前也很喜欢追新的技术，xx框架来了，赶紧学，而且只要官方有了v xx.xx.xx,就算不是stable version，也不想使用v xx,xx,xx-1,后来发现没什么卵用，v00.00.01里面的feature都够用了。
框架是"你为框架服务"，这虽然对养成所谓的"best practise"有点用，但是你这样写出来的代码是死的，一旦出bug很痛苦(更何况现实情况是bug层出不穷呢，那就一直非常痛苦了)，即使框架开源，你在漫无边际的源码中找到自己的bug原因也是非常困难的。在找这些bug的过程中，虽然可以一定程度上学到一些东西，但这些东西系统性很差 ，花费很多时间来接框架的锅是真的事倍功半。
我现在一般不会用别人的框架，而是每次重构都为自己的框架增添东西，可能自己的框架并没有那么flexiable,也不能应付所有的应用情景，但我每次都尽量完善它。
你还会发现，一些语言的feature,你自己不写框架的话，可能永远都不会用到，这对于喜欢这门语言的人是个多么大的损失啊！
所以，我最后想说的是，自己慢慢写一个小的框架吧，然后培育他，让他长大。
实际项目过程对于大多数人来说真的只是一步步google，这个过程只能让你达到你能到的最低点，但你能到的最高点，取决于你的基本功。
多看书，多写代码，少写那些所谓的实际项目(特别是那些两三个人，一个月就能做完的那种)，外包更是有多远离多远，全栈工程师不需要追求，一层层的都弄懂，随时完成C++->全栈的进化。
还有，那些说("自以为了解底层越多，程序越好")的前端工作者，我忍你们很久了。
手机快没电了，知乎码字都这么费电-.- 不止一次问过自己这个问题。

快做了十年软件开发，这个问题上，个人是偏向保守的，下面回答几点是做了这些年的感悟，请独立思考，判断取舍。

1. 我们编程最终是为了用户，不是为了老板，不是为了产品部门，更不是为了自己，如果程序提升了用户使用的效率和体验，程序才有价值，用户不关心她用的东西是怎么实现的，但她确实关心是否能早一点用到某个功能，某个功能稳不稳定，如果不稳定我们能多块修复，还有，这个过程会化掉她多少时间和金钱；我说这一点的目的不是要下结论我们应该总是沿用老技术，也不是要宣扬总是去尝试新技术，知道“什么时候做什么选择”比“做了什么选择“一样重要，心里要有一个标准，知道为什么这个时候我做了这样的选择，要有能说服自己的理由；选不选Angular都应该有”具体“的理由，别人说的Angular如何如何先进永远不成为理由，最多就是个参考因素；只要环境允许，我们做技术选择的落脚点都应该是对用户的实际意义
2. 有本书叫做Facts and Fallacies of Software Engineering，有几个章节可以比较好得回答这个困然很多程序员的问题，“盲目追求新技术”带来的隐性成本，最终变成沉没成本
   
3. 新技术有时候只是用一种不一样的“抽象”去做同样的事情，这时候与其把它们叫新技术，不如叫新“方法”，我还是想提醒自己用户并不关心你的技术“方法”，一个例子就是ECMAScript这些年的进化迭代，许多新的语言功能，但事实是这些是程序员自己关心的东西，用了这些语言新功能会否提升编程的简洁度，稳定性，性能等等还需时间来证明，但程序员社区已经趋之若鹜了，巴不得立刻进入ES6，ES7时代；我想说这些事没有它们看上去那么重要，我知道一定很多人不同意，但我说过了这是我个人对技术的判断；我举一个相反的例子，H264视频编码，AAC音频编码以及MP4格式都是存在很多年的技术，但是网络流媒体的发展给了这些老技术许多新机会，他们已经是如今互联网多媒体的事实标准，所以尽管不是新技术，但非常值得深入了解（如果你从事这一块），格式的统一对媒体的消费者和媒体的创作者当然是有意义的，这不仅意味着用户端的工具会更简单，流程更一致，用户端需要的处理时间成本更低，还意味着她们所接触到的视频网站的实现的简化，而这总是导向更好的用户体验，这背后的技术HTML5 video，HLS等等，都值得一并研究。说回来，这里的观点是新技术不一定新，老技术未必老。
4. 不要太相信那些看起来能解决你所有问题的所谓新技术（我觉得Angular算一个）。承诺太多要么是因为这个技术还太年轻，没有太多人用，所以该暴露的问题没有暴露出来，该被看到的短板，人们还一无所知；要么是因为背后的团队把过多注意力放到了市场，太顾及切中市场痛点而忽略了这种技术本身设计上应该有的平衡，这就跟做一个讨好市场的RPG游戏去拿游戏里的香艳截图去吸引用户一样；我想一个技术人员并不需要资深的经验才能明白软件开发本身的开放性和复杂性，不是一个两个工具和技术的更新换代所能够彻底解决的；承诺太多的技术，往往作出不切实际的设计，为了疏通逻辑在架构概念上造一堆轮子，牺牲技术使用者的学习时间，增加他们的知识负担。这里的观念是，做项目的时候，强大全面的新首先意味着项目成本的增加。
5. 大多数语言要学好几年才能到“熟练”的程度，不要说精通了；但大多数人会在一两年内放弃对这种语言纵深的学习，而转而横向拓展（很多人都这样，包括我自己），这并不总是坏事，因为有时候横向生发本身就是纵向的启发；我想说的是这个时候很多人可能意识不到自己其实并不怎么“熟悉”自己认为熟悉的东西；比如用PHP写Web应用，三个月半年换一个框架，但没有试过去理解第一个框架的架构和设计意图，编程技巧，可用性等等，到第二个框架的学习，还是重复那些老的概念，于是天天MVC，也只有MVC，表面上是研究新技术，实质却还是老的思维框架；但如果研究下去，一个普通的Responsibility Chain的设计与应用就可以学到很多。所以这里的观点是，技术的“老”有时候是一种认知偏见，因为你不知道自己不知道的东西。

话题可以展开去说很多，但我想就此打住，千言万语也最终依赖于你自己的研究和判断，真正的回答我相信也在这里，“你自己的研究和判断”。

上面的观点仅作参考。