个人理解楼主可能并不是对前端技术感到失望，而是对自己所处的职业环境感到不满。对产品设计和发展，以及技术问题的解决和架构的完善，的参与度不高，无法实现自身的价值；也很难跟上技术发展潮流，更难以体会到各种思想、轮子存在的价值。

个人反而觉得现在反而是前端技术人员的春天，主要是因为 JS 栈的崛起，各种新思想萌发，使得前端技术人员一下子有了近乎无限的发展潜力。以前你在做前端开发，几乎不可能参与和了解其他领域的技术；现在越来越多的前端工程师转型成全栈型人才，Node、Electron、ReactNative、MongoDB|PGSQL 等等技术使得技术人员在架构设计方面可以得到飞速成长，同时这个职业的状态也非常适应国内互联网创业热潮，这是个大金矿。

关于轮子的问题，社区上好多人都在抱怨各种框架和思想太过于复杂；实际上轮子是用来解决麻烦的，而不是用来制造麻烦的；技术选型的精髓就在于找到最适合项目和团队的轮子，以最低成本验证最大假设，短时间将项目成熟化，这对于包括我在内的大多数人来说都是一个需要长时间钻研的事情。

建议楼主尝试去发现自己职业的闪光点，比如前端开发是离用户最近的，如果不能参与视觉设计的话，起码还会参与性能优化和一定程度上细节的交互设计，用户会直接感受到你的工作的价值。
另外如果自己所处的职业环境让自己觉得没有发展，那是不是可以考虑换个地方了呢？

个人之见，求同存异。

表示同情，祝早日康复。

正好我上上周比较严重的急性肠胃炎，肠胃剧痛难忍，半夜三甲医院急诊，打了一针止痛的，开了一堆西药，第二天止泻，第三天大便结块。一周吃粥吃面之后消化系统恢复正常。

自己生物学得好，平日里对西医有业余爱好，分析大夫的治疗如下：

病因：化验得出是非病毒性的急性肠胃炎，致病微生物超标。

基本策略：像革命一样，把肠道内所有微生物排出体外，药物辅助恢复肠胃功能，再补充益生微生物，逐渐恢复肠道微生物平衡。

治疗过程(药理过程)：
1. 先使用止痛针，缓解难忍的疼痛。
2. 补充生理盐水，维持体液平衡，避免腹泻流失大量的水和无机盐。我这边是开的口服补液盐散，定时用定量的温水冲服。
3. 使用微生物抑制剂，广谱抑制体外微生物(肠胃属于体外环境)，如大蒜肠溶片，这药真的有大蒜味，闻起来还挺有食欲，对很多致病细菌、真菌、寄生虫都有抑制作用。
4. 使用吸附固定剂，如思密达，物理治疗，吸附固定肠道内的微生物，有效将微生物随排便排出体外，辅助提升肠道免疫力。
5. 使用解痉剂，如匹维溴铵片，抑制肠胃平滑肌收缩，有效缓解恶心和腹泻。
6. 补充益生菌，我这边开的是复合乳酸菌胶囊，含有以乳酸菌为主的多种益生菌，益生菌产物（如乳酸）对有害菌有抑制作用，正常的肠道应该是稳定的益生菌和有害菌互相抑制的平衡状态，能产生人体消化适宜的环境（如酸碱度）。

恢复的时候基本上都是吃白粥，后期偶尔吃面条。

最后一句话：用药还是遵医嘱，毕竟只有医生有可能对你的病情做出正确判断，以对症下药，不对症乱用药可能会对健康造成进一步的损害。

顺便分享一下之前看到的一个公益行动，叫 DON ’ T GOOGLE IT，是致力于让公众关注医疗搜索问题的： http://www.ddb.be/work/all/clients/all/don-t-google-it

旧显卡的兼容一般都比较好，只要是新显卡都有兼容性风险；
台式机硬件的兼容性一般都比较好，只要是笔记本都有兼容风险；
Linux 上虽然能跑 Steam，但娱乐消遣这种事毕竟是体验至上，玩游戏还是老老实实用 Windows 吧。

Linus 说“ Fuck you nvidia ”的时候是很多年前的事情了，现在已经有改善了。
兼容性好的显卡，一般 GUI 用途的话，通常开源驱动闭源驱动都无所谓。

What：

个人理解，这是分层解耦的一种思想，即“前端”开发的时候不需要考虑“后端”是如何实现的，“后端”开发的时候也不需要考虑前端如何设计。
上文所谓的“前端”是指完全和视图层以及和用户交互相关的系统，“后端”通常是指完全和资源以及和资源相关的业务逻辑的系统；前者通常指的是客户端，后者通常指的是服务端。
当然和整体架构规划是有关系的，有些大型网站会将客户端以及和视图层强相关的服务端统称为“前端层”。比如典型的 Front-End=>Front-Back-End=>Back-End 架构中，Front-End 和 Front-Back-End 统称为前端层。

Why：

分层解耦是计算机领域用来降低系统复杂度的两种基本方法，所以其实前后端分离是用来降低整体系统复杂度的，因为前后端完全分离，后端和视图层完全无关，所以后端具备相当强的通用性。理想情况下，一个系统的多个前端（如 WEB、Android、iOS ）可以使用同一套 API 共用一套后端，后端只需要一套设计就可以。而且由于后端和视图层无关，所以后端可以很容易拆解进行服务化设计，以具备服务化的优势。对于前端来说，需要对 API 提供的资源以及对资源的操作进行封装抽象，以满足自己在 UI 上的特异性。

How：

后端提供资源以及资源相关的操作，这些是从产品上对资源的描述和设计决定的，有些资源可能是以数据模型的形式存在，另一些可能是以非数据模型的形式存在（如对第三方服务的抽象），后端提供的 API 也是更贴近于资源的设计，有一种设计风格是 REST，可以满足这种 API 设计需求。
前端通常需要自成一套系统（比如前端本身就具备一整套 MVC 机制），使用 API 从后端获取资源，自己再进行抽象（ Model ），然后对自己抽象的模型封装一些 UI 上面的展示和交互逻辑（ Controller ），再通过前端路由、模板引擎之类的机制展示出来（ View ）。浏览器端常见的技术选型有 React、Vue、Angular 等。

总结：

前后端分离的思想可以用来在一定程度上降低整体系统的复杂度，但是由于是更高级的抽象思想，所以在性能上会差一些，在架构规划上按照实际的情况和需求判断是否要使用这种设计。

代码是给人看的，顺便给程序执行而已。
我写 JS，所以会用 JSDoc 和 URIDoc 格式来用注释写文档，看代码及文档。
你若代码极其清晰，一眼就看懂，可以不写注释或文档。
我达不到这种程度，一边写代码一边写注释，之后还会时不时补充注释，基本上注释量和代码量一样多。

我在 pixel 出之前是用 nexus5x 当过度，整体性能挺弱的，如果只用国外的应用的话没有问题，一旦安装了淘宝之类的国内应用就会发热、续航直线下降。
我之前是尽可能用国外应用，国内应用使用冰箱 https://play.google.com/store/apps/details?id=com.catchingnow.icebox&hl=zh_CN 冻起来，勉强撑到换手机。你若执意要买 5x 的话可以参考一下。
当然现在 nexus5x 上市已经很长时间了，不好说买到的是不是翻新。建议不要一味图便宜，容易上当。能等换 pixel2 还是再忍忍吧。

为什么每次有人离职都有种跳槽待遇会变好的感觉？

VGA 怎么还没淘汰 +1

先不说性能方面，接口寿命和易用性方面 HDMI 就妥妥胜出了吧，现在除非有极特殊的需求，通常有 HDMI 都不会用 VGA 了吧。

网上说 VGA 最新标准已经能达到超 1080p 的性能了，但是问题是不一定自己的笔记本和线缆就能发挥到这种极限性能。

SSD 寿命远比你现象中的要长，操作系统也会对 SSD 的使用进行优化，比如 trim 功能。。。
http://www.iapps.im/single/30288 这还只是 2013 年出品的 SSD，花了两年的时间进行极限测试。

已经习惯英语脏话了，听起来比国骂柔和很多。。。
https://www.vidarholen.net/contents/wordcount/

另外一个方面，产品设计上会因为某些目的故意对用户做出限制。举个例子，如果市场营销方面认为手机号极其重要，那产品设计上有可能会故意关闭除了手机号以外的其他注册方式，虽然用户可能会觉得不够友好，但是产品设计和市场营销方面认为可以在其中获得的好处远大于对用户的影响。

@autoxbc

这并不是单单需要多少人月开发的问题，通常在正式制定开发方案之前就要首先评估需求的“合理性”，可能要考虑更多的问题：
1. 受众有多少？目标用户在其中的占比为多少？
2. 能带来多少盈收或潜在盈收？
3. 长期维护成本有多少？
4. 运营成本有多少？
5. 目前全公司整体项目计划优先级和排期以及人力资源的分配是什么情况？

第 1 项我已经做过简单说明，我不清楚知乎自己在市场营销和产品设计方面的“目标与用户”是什么定义，所以也无法给出估计。
第 2 项需要有进行中的或者实验中的盈利模式，和内部的数据分析，这个外部人是不知道的。
第 3 项肯定是存在的，而且不一定会少，基本上日后所有产品需求设计都需要考虑是否要同时在两个前端上实现（或修改）、有什么区别设计、功能逻辑是否互恰、现有架构是否能够实现、因为差异化带来的额外技术成本有多少。
第 4 项不一定会便宜，最起码渲染用服务端要有一套分布式集群，要做负载均衡和弹性伸缩，而且也要长期负担带宽和流量费用，也要有足够的人力运维。
第 4 项要看知乎内部的具体情况了，如果项目排满而且有很多更高优先级的项目在占用资源的话，即便服务端渲染机制要开发，也会被排到后面，而且前面有可能会不断有更高优先级的新项目插入。

以上几项评估出来的结果会被作为此项需求“合理性”的参考。举个例子，如果成本远大于盈收期望，而现阶段还有更多盈收期望大于成本的项目在计划中，那么这个需求就暂时可以被定为“不合理”。

如果是“合理”的需求，可以安排开发计划的话，只从开发成本上来说：
1. 因为之前是前后端完全分离的项目，至少需要单独写一套渲用染服务端，渲染用模板要重新开发，简单来说会按照原有纯前端渲染的产品能设计取一定的完成度比例重制。
2. 原有提供数据和业务逻辑的服务端，要针对渲染用服务端，进行 API 和业务逻辑的重新设计，以保证通用性或者兼容性；因为如果服务端渲染的产品呢不能完全实现纯前端渲染产品的所有功能的话，必须要确保服务端渲染的产品也能够具备严密的业务逻辑。这其中最恶心的莫过于在两个前端产品中出现完全不同的功能逻辑设计，这会增加数据资源服务端的复杂度。
3. 原有纯前端项目里，要重新考虑整个优雅降级的机制如何糅合进去，如果遇到架构或可行性问题的话可能要对其进行一定程度的重构。
具体工作量要按照产品设计者规定的产品设计来评估。当然因为并不清楚知乎内部的项目运作方式，这里只是做一个简单的猜测。

有外号的叫外号，没外号的怎么顺口怎么叫，最好能一入职就自己给自己起个外号，并标注在通信录里。
我们那边叫 X 哥的也比较多，称谓不分上下级，一切图个轻松高效。

@autoxbc

楼主是从完美主义来考虑的，而我以及一些朋友们是从实用主义来考虑的，双方考虑的角度完全不同。

楼主对于技术本身的观点没有问题，但仅限于学术上面，实际情况往往不像学术研究那样理想化，而且复杂得多。

相信这里回复的朋友们在企业里工作的居多，企业的最终目的是赚钱，赚钱的主要原则是以最小成本实现最大收益，只有高性价比的事情都做完了才会考虑性价比不那么高的事情。知乎也是企业，而且是互联网创业企业，对于互联网创业企业来说，收支平衡+稳定的盈利模式才算作“能活下去”，暂且不说他们在技术层面的决策是否合理，但毕竟作为一个离“能活下去”还相差甚远的企业，不得不持续和融资余额赛跑，所以必须在每一个决策上都要掂量性价比。

只有企业实现了“能活下去”的目标，并过上了“衣食无忧”的日子，才会逐渐从实用主义转变为完美主义，一个很好的例子就是 Alphabet(Google)，靠着强大无比的营收能力，Alphabet 现在市值 6295.74 亿美金，基本上到了想干啥就干啥不愁钱花的状态。
而知乎前段时间才估值 10 亿美金，看起来觉得很多，但实际上只是估值而已，实际余额远少于这个数。余额就这么多，搞出了稳定的盈利模式以及达到了收支平衡，公司就可以活下去；否则的话运气好还能再融资续命，运气不好就只能散伙。

综上，知乎的网站并不适合拿来讨论“平稳退化，渐进增强”，因为技术理想并不是决定知乎技术团队决策的唯一因素，甚至可能都不是主要因素。

个人不认为纯前端渲染就一定是只为了高逼格，任何技术的选型都是要综合考虑的，而不是凭借书本上或者老师的一句话。

通常会在以下几个方面考虑：
网站业务特点：网站是更适合纯前端渲染还是更适合非纯前端渲染？
开发成本：使用纯前端渲染技术和非纯前端渲染技术的成本差距有多大？
风险：纯前端渲染和非纯前端渲染在网站可靠性方面的差距有多少？是否有额外的产品设计可以保证在有问题的情况下正常提供核心功能或者引导解决问题？
运营成本：使用纯前端渲染和非前端渲染，在网站的运营成本上有多大差距？
人力资源：目前有限的开发人力资源是适合纯前端渲染还是非纯前端渲染？
技术发展趋势：目前网站技术的发展趋势是纯前端渲染还是非纯前端渲染？趋势是否已经成熟？

我司（不是知乎）选择纯前端渲染架构是因为：
网站业务特点：我们的网站的业务是以内容展示为核心，UI 有大量复杂的交互功能，而且并不是每次操作都需要重新渲染整个页面，只对页面中的特定元素做变化处理，而且也没有很多的敏感业务逻辑必须要隐藏在服务器端，所以我们的网站是更适合纯前端渲染的。
开发成本：有很多现成的纯前端渲染框架可以使用，不需要开发者关心前端渲染本身，只需要关心交互方式、视觉样式和数据流，极大地缩短了开发时间。
风险：我们使用的 React 只兼容 IE9 及以上版本的“旧浏览器”和所有的“现代浏览器”，截止到 2017 年 6 月，IE 整体的占比已经下跌到 9%，而其中 IE9 以下的版本占 IE 总量的 49%，也就是浏览器市场总量的 4.4%，加点余地的话差不多有 5%的网民是排除在 React 之外，假设我们的用户是在网民中均匀分布的，那么就会有 5%的用户不能正常使用我们的网站，但若为这 5%的用户做兼容的话可能要多花费 50%的开发成本，所以即便有 5%的不兼容也算是性价比较高的方案，同时会有辅助方案如页面发现兼容性问题即引导用户安装现代浏览器或使用 PC 版客户端，可以进一步削弱对这 5%用户的影响。React 本身有世界顶级软件公司的支持，技术水平和质量把控要远远超过我司这种小公司，所以在这方面无论是用前端渲染框架还是服务端渲染框架都是差不多的，毕竟服务端渲染出 Bug 也不能保证前端不是空白的，容灾设计无论在前端还是后端都是要有设计的。
运营成本：纯前端渲染的时候，渲染压力被转移到了前端浏览器上，服务端只需要关心核心的业务逻辑，不需要关心 UI，节省了大量服务器计算资源；用 AJAX 等技术可以有效减少数据的传输量，节省昂贵的带宽费用；前端除了 index.html 以外全部托管在 CDN 上，任何地区的任何量级的用户都能流畅加载前端页面，而且 CDN 的流量费用比服务器的流量费用比起来简直就是白菜价。
人力资源：我司所有前端开发都有纯前端渲染架构开发的经验，所以采用纯前端渲染的架构方案是没有问题的，反而服务端渲染架构的话多多少少需要服务端开发人力的介入，两端工作有一定程度相互耦合，项目可能会互相牵制。
技术发展趋势：这个就不多说了吧，看一看纯前端渲染相关技术栈在国内外受到关注的上升速度，就大概了解了。React 已经是第二代真正意义上的前端框架了，此类技术已经完全成熟。而且我前两个月招实习的时候发现绝大多数的投简历的实习生都自学过至少一种前端框架，而像 Ract 这样的前端框架，正是纯前端渲染架构的基础。

综上所述，我司决定使用纯前端渲染的架构设计。
具体情况具体分析，我司的情况并不一定适应于所有其他公司，但思路可以作为参考。

软件工程没有银弹；没有最好的方案，只有最适合的方案。

有效缓解手腕疲劳性损伤：logitech m570，或者养成闲时将手放在桌子上而不是悬浮在触摸板上的习惯。

工作环境要符合人体工程学：
- 小腿与地面垂直
- 大腿与小腿垂直
- 躯干与大腿垂直，且臀部和大腿在椅子上的受力均匀
- 小臂与大臂垂直，且同时小臂在桌子上受力均匀，重心在中间，不偏向于手腕，也不偏向于肘
- 显示器的上沿稍稍低于眼睛的高度，视线向下与水平线的夹角不要超过 45 度

持续高强度工作，再好的设备和习惯都救不了你，建议每工作一段时间出去休息互动一下，比如番茄工作法。

Cdn 存在的意义之一 ， 就是能让任何地区的任何量级的用户 都能流畅地访问到资源， 所以 cdn 在很多地区都会有大量的分布式节点服务器。覆盖老文件，cdn 需要同步这些节点， 受限于速度、成本和任务量等因素，cdn 通常难以做到及时更新。七牛官方的建议是尽可能不修改已经上传的文件，但如果一定要修改，就要等待七牛每七日一次的节点同步，或者手动去七牛后台刷新，刷新文件数量和频率都是有限制的。所以 cdn 的最佳实践是，修改文件要同时修改文件名（如 abc-1.0.bin ），以新文件的形式上传 cdn，客户端动态从应用服务器上获取最新的 url，访问七牛 cdn 上的最新上传的文件。
另外七牛上也可以配置客户端缓存的时长，如果是浏览器或任何严格遵循 http 标准的客户端都会按照数据头的缓存时常进行本地缓存。

有一种情况，我之前用过一个不给公网 IP 的二级运营商的光纤，他们会根据不同的目标端口号动态切换路由，直观表现就是我 ssh 到我在海外的 vps 速度很慢，但是打开我海外 vps 上的网站就很快，后来我就把网站关闭，将 vps 的 ssh 端口换成 80 了。。。这种情况比较奇葩。