今天在社区看到一个故事，一个开发者17年的故事，讲述了知名语言的辉煌和衰落，2000年的互联网寒冬，大公司新框架的本质，和最近新潮的技术，挺不错的，特此粘贴分享。
作者说：
在我看来，世间万物都是循环的，它们会反复出现，因此我们能够以史为镜，避免重蹈覆辙。
全文3000多字，预计读完6分钟，如果你是名开发者请用心看下
-----------正文开始--------
这张照片拍摄于 1997 年，是我第一张使用网络摄像头拍摄的照片，照片上右边的那个家伙就是我。
我们购买这台 silicon graphics O2 差不多花了一辆小轿车的价钱，然后这个家伙跑过来说“现在我们正在使用网络摄像头一起拍照”。然后 哇哦 照片就出现在互联网上了，在那个时候这真的是一件特别炫酷的事情。
到了 1998 年我就已经开始玩儿 HTML 了。
当时的网站看起来和图片上展示的差不多，而且那个时候这本书还没写呢。
那个时候还木有 Google，木有 Facebook，木有 GitHub，木有 Wikipedia，也木有 StackOverflow。
那个时候我们只有新闻组，我们可以在上面提问，其他人也可以回答问题。有点儿像 email，但和 email 还是有区别的。
时间走到了 1999 年，也就是 17 年前，我在 Square 新闻组里写下了我的问题：
是的，Microsoft Access！
我真的不知道。
其实，我完全不知道。
那个时候，我真正学到的一点是：网络永远不会遗忘。那时我真的是毫无头绪。
进入 2000 年
在 2000 年我成为了一名 web 开发者，当时我在给 Austrian Job Service 教 Perl，因为在那个时候，找不到工作的人基本上都能成为一名 web 开发者，在当时这是种趋势。
那个时候 Perl 语言非常难，但是既然我已经准备教 Perl 了，那就是说明...
我非常非常聪明，是吧？
但是，真相永远是残酷的：其实我一点儿都不聪明。
当我尝试在数据库中更新数据集时，因为我不知道如何实现才算合理，所以一开始我的做法是先删除然后再插入。
那么问题来了：就我这种水平，我又怎么会认为我自己还能教学呢？答案就是：丁达尔效应。
简单来说，丁达尔效应就是：因为你无知，所以你不知道你自己有多无知。
那条绿线是你认为你知道的东西，那条黑线才是你真正知道的。那个时候，我认为自己无所不知，直到我完成了大学学业--应该是在 2011 年--我才知道 “好吧，其实我知道的也就那点儿东西”。
然后，你就开始变得稍微谦虚一些了，因为你开始学习那些你不知道的东西，接着你就开始有点儿绝望了。现在，我认为我在那个绿点的位置。
我们去了银行...
但是不管怎么着，我设法找到了一家公司，然后买了一台服务器。这台服务器还是我们去银行贷了 15,000 欧元买的。
和之前相比，现如今变化真的很大：我们有 serverless 架构，你可以一台服务器都不用就把整个公司创建起来。
那个时候，我们不得不把服务器放在维也纳的一个数据中心的机架上。
每当服务器宕机的时候，我就得开着车到维也纳去重启服务器。
那次我学到的东西就是：你要努力理解什么是全栈。我说的就是上面的这个全栈。
全栈，意味着你至少应该知道一点儿 web 协议、知道路由的工作原理、知道 HTTP 基本的工作机理、知道 SMTP 的工作机制。
当出现问题的时候，知道这些包是如何打包进浏览器的，知道这些东西是如何协调的是很有必要的。
然后夜幕降临，迎来 2002 年
现在我们是在 2002 年，我拥有了一家公司。那个时候，除了澳大利亚，互联网在全球爆炸式疯长。
我们静静地等待着互联网的繁荣有朝一日能够降临到我们身上，然后一切都结束了。
我认为这一切都是从 boo.com 开始的，这是一家运营时尚服饰的初创公司。
在那时，每个人都花大把大把的时间去投资和新经济、新媒体相关的项目，所以整个行业开始繁荣增长。
在两个月内，公司从 10 个人涨到了 100 个人。然后，boo.com 破产了。
我认为这和他们有关，然后所有的投资者差不多都退出了，因为他们意识到新经济公司终将会失败。
这是纳斯达克。我们当时在这个繁荣阶段，紧接着一切都奔溃了。这里是 9/11，一切都随风而逝...
我在 Google 上搜索了一下，这是那个时候硅谷人的想法，你们感受下。
我找到了一个哥们儿这样写到：
"噢，我的天呐，这简直是致命的打击。作为一个年轻的初创公司，我知道的每个人都受到了影响。我知道的大多数人都失去了工作。不久之后，我知道的大部分人都搬走了。"
在这里他写到：
"泡沫时代的对比是史诗级的。开放式的酒吧活动和神话般的发布会都已经一去不复返了。工作和公司也都没有了。不久之后，绝大多数企业家没有了安全保障--很多人回到家里重新组团。"
听着有些熟悉，是吧？
如果今天你去硅谷，看到的也是这个样子。一切都是新兴的。工作在那里的人都是这样的：
"什么？他们公司没有自助早餐？
他们没有这种桌式足球？
噢，我不想在那儿工作了--我想买架飞机。"
这种事情随时都会重现。不过那个时候，我们看到的更多一些。
尽管如果现在我说就算这种事情发生了也不会有什么问题，但是真的当这种事情发生了的时候，就真有问题了。
趁热打铁，抓紧机会！
我从中学到的一件事是：一定要趁热打铁，抓紧机会！我现在并没有高谈阔论地去谈钱。
我正在谈论的是通过投资于你的技能和知识来随时应对不好的时代。
拒绝平庸，对吧？！
编程语言太多了，我认为编程并不是说一定要成为一名 JavaScript 开发者或者 Node 开发者。编程是一种概念、一种思想。就比如，当你在用 JavaScript 写实例的时候，可以尝试一下 Scala 函数式编程的一些东西。
最开始我在 Lynda 和 Coursera 工作，这让我真正的理解了 JavaScript，理解了我使用 underscorejs 的原因，理解了怎样才能让需要的东西更好的融合起来。
所以我想鼓励你们的是：不要把你自己当成一个 JavaScript 开发者或者 Node 开发者，要把你自己当成一个工程师。
要学习思想、学习如何使用不同的语言去解决问题。你的视界决定你的世界，掌握知识的横向链接越宽我们对问题的思考就会越灵活。
这是我这次做的课程。这真的很难，但是这是发明 Scala 的 Martin Odersky 做的，所以他知道他在做什么，这真的很有趣。
所有的这些资源在互联网上都是免费的，所以如果你有时间的话，可以投入一些时间和精力培养一下你的技能。
为未来的你写代码
然后，在 2002 年到 2012 年之间我做了许多项目，大部分都是 web 项目，许多是基于 PHP 的，不管你相不相信，其中的一些项目到现在仍然在线上运行着，比如下面这个：
它们今天还在困扰着我。因为这些应用是我在 2002 年或 2004 年或其他的什么年份完成的，我从来没有想过，在 2015年、2016年、2017年，我还能再次看到他们。
但是之后一通电话打过来了："这个网站挂了，你能不能帮我们搞搞？"--尽管我早已经不是这个公司的员工了。
然后一万只草泥马在奔腾：
"哎呦，我去，这代码是哪个傻逼写的，写得太烂了。"
...恩，我知道这个傻逼就是我。
在我看来，写出未来的你能够理解并引以为豪的代码是很重要的！当你做一件事情的时候，要么不做，要做就把它做好。
代码的破窗效应
我最喜欢的一个理论是破窗效应--这个理论也可以应用到代码上。
想象一下，你身处一座城市，站在一座高楼面前，周围的一切都很美好。然后突然一个哥们儿跑过来打破了一扇窗户。
如果你等上几个星期再回去看，你会发现整座高楼开始腐烂，摇摇欲坠，到处都是乱七八糟的涂鸦，人们也不再 care 它了。
同样这也适用于代码，那些临时的解决方案就是高楼上的破窗，是吧？
"恩，是的，我们改天再改吧。"
然后那些临时的代码片段还保留在那里，然后等到下一个开发人员（有可能还是你噢）过来看了看这代码，然后说：
"好吧，这个已经很糟糕了，我们快速修复下，然后代码又变得糟糕了。"
所有这些丑陋的代码片段都充斥在你的代码里。就算十年过去了，你还是得处理这些代码，所以你为什么不提前和你的小伙伴商量一下？你应该这样想：
"这是一个旧项目了，让我们把这个项目重写一遍吧。"--因为这就是我们喜欢的做事的方式，对吧？
我经常听到开发者这样说 “看，这个项目是我们两年前写的，整个技术栈都已经落伍了，我们把所有的东西都重写一遍吧，很简单的，两周就能搞定！我们已经开搞了是吧？”
我们知道软件都有一个饱和曲线。有时候给代码添加新的特性确实很困难，所以这时候重写代码更换技术栈是完全没有问题的，但是你得注意这里的这个缺口。
当你切到一个新的技术栈时，项目就变得复杂了，从一开始就不会有相同的功能特性。
因为在整个系统中整合了很多固有的东西，所以你不能轻易重做。所以你必须意识到，如果你从头开始做某事，那么至少会有一个特征差距。
网站真的需要 React、需要同构 JavaScript 吗？
好吧，那我们就重构代码，但是网站真的需要 React、需要同构 JavaScript 吗？我知道，这些技术都很酷，我们也想用。但是，我们真的愿意每六个星期就重写整个前后端代码吗？
新技术日新月异，尤其是 JavaScript 方面的。新技术每月都会出现，而且也有公司在推动着这些新技术。
如果某项技术是 Google 出品或 Facebook 出品，那么它一定很酷是吧？因为 Google、Facebook 的这帮家伙们知道他们自己在做什么。
所以当时就去了解了下 React，还看了看他们介绍 React 和 Flux 的那次演讲，会上他们基本上就说了这些：
"我们在 Facebook 上遇到了消息通知方面的问题，当消息被阅读了以后，状态并没有更新。"
"我们的这个 MVC 项目很糟糕，因为 MVC 本身就很糟糕，所以这个项目并没有很好地运行，所以我们发明了 Flux。"
当时，我的反应是这样的：“我勒个去，这都可以！？”
从什么时候箭头可以从 View 层画到 Model 层了？我认为这是错误的。
之后有一个问答环节，但是并没有人提问。在座的每个人可能都是这样想的，“恩恩，MVC 太逊了，我们确实需要 Flux。”
也许她是要表述一个观点，但是这个观点她并没有表述清楚。
然后我往下滚动页面，评论区有大量这样的评论，“这不对啊，这有问题啊，这根本就不是 MVC 啊！”
真搞不明白发布会上他们都在说什么。演讲完了，每个人都感觉 “恩，MVC 是挺逊的，我们确实需要 Flux，因为 Flux 解决了我们所有的问题...”
不过，说实话，我也没有资格谴责他们。我在会上的问答环节也没有站起来说“这个不对”，因为我向来就比较谦虚，我总是认为别人说的都是对的。~^.^~
保持冷静，勿信炒作
提出质疑，勿信炒作--我们早就该这样做了。
毕竟，不管是 Facebook 还是 Google，它们也只是公司。如果 Facebook 将 React 交给社区，他们就会有这样的议程。Angular 和 React 正在交付给新的开发者，或许并不是因为他们想给社区一些东西。
我们应该时刻保持清醒，在大多数的时代都不会平白无故地天上掉馅饼，所有的东西都是期望能够赚钱的。
所以如果有这种炒作的话，你确实应该提出质疑。
毕竟，所有的这些东西都仅仅是框架，是别人的代码！
在 JavaScript 的世界里，我们喜欢谈论不必要的依赖，因为那些由互联网上的某个陌生人撸出来的代码总是完美的，对吧？
使用第三方组件真的有点儿 low，使用整个框架同样也很 low。
问题是这样的，你依赖别人的代码，当你想修改一些东西的时候，你就必须去修改他们的源码。
所以此时此刻，你并没有学习使用编程语言本身来处理问题--你学习的是别人的代码，你调试的也是别人的代码。
过去有太多这样的案例，比如 PHP 的 Symphony 框架。你有一个生成器，然后直接运行就可以了，框架已经为你生成了你所需要的一切。但是，如果在某个时刻框架底层报错了，那你就真的不知道到底是哪里出问题了。
