获得徽章 0
- 为什么前端一定得学 node？
前后端分离模式已经偏离了当初的目标，原本通过并行 + 专业化来提高效率，但事情正在起变化。
1、并行率。在多个项目穿插迭代的情况下，前后端通常不能做到完美并行。
2、成本。本质上前后端分离仅仅是把一份工作拆成两份，让两个人去做，并没有减少整体的工作量。从增量运营时代进入存量运营时代，效率的权重一旦下降，那么前后端分离就会显得有些昂贵。
3、额外的信息成本。接口文档、数据结构约定、技术评审、联调（反正有前端测试接口，后端就不管接口质量，都等到联调时再说）...
4、公地悲剧。有部分工作既可以前端做，也可以后端做，那谁来做？这既是一个技术问题，也是一个政治问题。
5、逆向选择导致技术退化。反正都是前后端分离，前端就一点不管后端，后端也一点不管前端。
6、维护成本。但凡出点问题，就得拉前后端一起排查。
前后端分离还造成了以下分离前本不存在的困难：
1、首屏性能
2、A/B、灰度能力
3、桌面端 SEO
综上，从大方向上看，未来的趋势是客户端与前端融合，前端与后端融合。
阮一峰：未来只有两类工程师：端工程师、云工程师。展开713 - 以前一直以为 commonJS 就是个模块化规范，今天查了下，发现事情并没有那么简单。
commonJS 这个项目于 2009 年由 mozilla 工程师 Kevin Dangoor 发起，最初的目的是想给 js 搞一套服务端 api 规范及其实现，所以最开始名字叫 serverJS，后来运行环境又进一步扩展（命令行、桌面端、混合应用等），于是改名为 commonJS。
搞这么大事情，commonJS 到底包含了哪些内容呢？
- 模块系统
- 二进制和 buffer
- 字符集编码
- I/O流
- 进程环境
- 文件系统
- socket
- ...
嚯嚯嚯，commonJS 乃是现代 js 的起点啊，大部分标准规范的前身都在 commonJS 里提出来了，node 其实就是 commonJS 的一种实现。展开318 - 业务开发的五个能力阶段：
1、实现需求。能“搞”出来，搞出来能用
2、合理的实现需求。能关注代码设计，知道怎么实现才“好”
3、合理的实现合理的需求。能关注需求本身的合理性，对需求有管理意识
4、合理的实现合理的需求，并保证提测质量。自测是研发三板斧中的第二板，不要觉得自测不关我事或者很简单，被测出一堆 bug 能叫“办事靠谱”吗。大多数人都能做到实现需求（即三板斧第一板），能做到第二板的少一大半
5、合理的实现合理的需求，同时保证提测质量和线上质量。监控是最后一板斧，能做到对线上质量了如指掌的再少一大半
很多人以为能力就是代码能力或技术能力，其实这只是单个维度。从专业过硬到办事可靠还是有一段距离的，能干活不等于会做事。展开111 - 好的资料那么多，注定看不完的情况下如何取舍？被动学习（订阅、浏览文章）和主动学习（遇到问题再搜）哪个效率更高、收获更大？
被动学习注定只是留个印象，目的是“什么都知道点儿，开眼界，求广”
主动学习是要拿结果，目的是“搞懂原理、习得技能、有所产出”
好的文章看不完或没看到？警惕完美心理作祟，注定不可能全，注定只是局部，就是要适应信息残缺和不确定的现实
收藏一堆链接，注定是不会看的，虽然都是好东西，但要坚持原则：凡是不会看第二遍的，就不要收藏
信息囤积症的一个隐蔽心理，可能是低估了自己的搜索能力，以及高估了自己的学习意愿
保持一套高中低频梯队式信息渠道，严格控制总量，否则会消耗太多时间。把精力聚焦在核心，避免因放弃产生无谓的损失感
提高主动学习的比重，主动学习是核心展开59 - 要了老命了
。我在面向浏览器的项目里引用了 tapable（就是 webpack 的一个核心库），源码里有动态生成的 es6 代码，编译编不了，拦截校验也没拦住，上线后低版本机型咣咣报错。
引入一个库，至少得满足两个条件之一：有别人跟你在【相同的环境】下大量实践过 or 你读过每一行源码。展开114 - React Native 诞生于 2013 年 facebook 的 hackerthon 技术活动。换句话说，RN 并不是一个技术规划的产物。创新，是没有办法规划的。技术规划，必须有稳定产出、有成本核算、有阶段目标，在这些约束条件下，技术规划的基本策略只能是求稳，求稳就意味着在能力范围内做事，不求大的突破，避免做有风险的预期不确定的探索型工作。
这就是 side project 的意义。你不可能在公司内拿着工资走排期去规划出一个 RN，除非你早就做出来了。展开评论6 - Service Worker（以下简称 sw）是在浏览器后台独立于网页运行的脚本，一旦在浏览器后台安装（install），除非手动卸载，就会一直存在于浏览器中，作为独立的线程运行，与网页的运行状态无关。由于 sw 运行在后台环境，意味着 sw 只能访问特定的 api。
sw 主要能力是操作（拦截）网络请求，相当于代理服务器，既能处理 request，也能处理 response。sw 并非单独服务于某个网页，而是服务于某个域名或路径下的所有页面，具体是在安装时通过 scope 参数指定的。之所以这么设计，是为了保证缓存的资源像 localStorage 一样可被同一域下所有页面共享，这也意味着同一份缓存逻辑可以复用到服务域内的所有页面。
sw 只能在 https 或 localhost 下使用。
sw 为离线化而生，因此必然要通过客户端缓存网络资源，专门供 sw 使用的存储 api 是 CacheStorage（以下简称 cs）。
cs 的最大容量并没有具体的规定，不同浏览器有不同的算法，通常而言，移动端单个 sw 使用的容量不要超过 50 MB。如果存储容量超过了上限，浏览器会删除部分数据（origin eviction），具体可参考
developers.google.com。
sw 可以拦截所有的网络请求，也可以缓存任何网址可寻址（URL addressable）的资源，包括 html、js、css、图片、字体、接口等。查看被缓存的资源：devtools => Application => Cache Storage。展开评论1
developers.google.com