前端精读专栏，给大家拜年了！
趁着过年，先聊几句咱们前端精读：
前端精读不仅仅是知识的搬运工！前端精读不仅仅是知识的搬运工！重要的话重复两遍。
论搬运知识量，我们比不上前端周刊；论翻译水平，我们比不上专业翻译计划。各位读者也一定不是冲着这两点来的，恰好，我们也不是为这两点做的。
前端精读能带给读者的，是对如今互联网海量信息的思考能力。
想这么一个问题，当人人都能订阅鱼龙混的前端消息，真的是每天扫一眼就天下大势尽在手中了吗？说的不好听一点，可能啥都看个皮毛，最后什么都跟不上。
更可怕的是，多如牛毛的消息早已钝化了我们的神经，让我们养成了浮躁的性格，似乎提到一个单词，点一个头就心领神会了，其实什么也不会。而当真正好的思想出现时，可能已经被淹没在质量层次不齐的海洋中，就算有眼力识别出来，也早已对其麻木，更何况大部分人还做不到辨别消息的质量。
以前，前端精读想把有误导性的，不正确的文章挑出来加以指正。现在发现行不通，其一是具有误导性文章太多，实在是挑不完，其二是现在更多的文章如同白开水一般，味如嚼蜡，你挑不出毛病，但也挑不出亮点。
所以前端精读把我们认为有价值，值得大家关注的东西挑出来，深入的写一篇读后感。也许不是每一期选题都值得深入了解，但我们只求在广袤的知识沙漠中，画一个小圈，不断扎根。
好了，废话不多说，本周精读的文章是：introducing-rekit-studio-a-real-ide-for-react-and-redux-development。
以前，我们不断完善前端基础设施建设，现在前端不缺工具和库了，下一步怎么发展？
发展方向有很多，比如继续完善框架和库、争论数据流的取舍、推动 ECMA 规范打造未来蓝图、投入新语言的怀抱、可视化规范与平台的建设等等。
有一个没啥技术含量的领域正在成长，就是前端工具链整合。
我这里说的没技术含量可不是贬义，所谓有技术含量的 “造轮子” 才是贬义呢。当我们陶醉于前端技术能力时，产品和后端往往就认为我们是写网页的，根本没啥深奥技术，如果改个文案都喊着成本高，更会被人看不起。
前端的职责就是提升人机交互体验，这不是大话空话，蚂蚁的体验技术才代表了前端技术的精髓，代表了互联网大行业对前端的期望。
前端工具链的整合，拿的都是已有的技术，目标也是把复杂的项目维护变简单，最终要推动的是解放前端开发人员的精力，让我们不再陶醉于自己的一亩三分地，转而将精力投入到业务与人机交互体验的提升中。
正如之前所说，现在不缺前端基础设施了，我们对项目管理的思路也要有所转变。JS 无所不能，但做项目不能无法无天，约定产生效率，工具链保证约定。
当我们用工具链保证了项目结构的约定，就可以抽象出项目的逻辑结构。
有人走在更前面，Rekit Studio，就是根据文件结构解析出逻辑结构的工具，让开发以逻辑结构管理项目，真的可能带来项目维护、开发成本的大幅优化。
一图胜千言，仔细看完图，不然文章就漏掉了一半。
Rekit Studio 以逻辑视图重新组织了项目，文件目录不见了，取而代之的是路由、Action、组件等，原本若干文件拼凑成的 Action 被聚合成一个按钮，统一管理。
同时支持在线管理本地文件、集成了 https://microsoft.github.io/monaco-editor/ 在线编辑文件，以及在线构建、测试等功能。
同时利用和弦图分析了路由与数据流之间绑定关系，路由与文件绑定关系，可以很轻松找到被遗弃的孤立节点。项目维护时，以看图代替看代码，效率至少提升 2 3 倍。
Rekit Studio 还提供了 Rekit CLI 可以完全用命令行达到可视化的效果，在比如插件化、二次开发，或者特定场景下保留了通用拓展的能力。
Rekit Studio 虽然拥有强大项目管理能力，但它不参与项目具体开发流程，项目可以脱离它独自开发，并且 Rekit 也不会内置任何 npm 包在项目中。
也就是说，Rekit Studio 的设计初衷，是为了增强项目管理能力，而不是参与到项目的开发流程中。
传统的云端开发应该不会大规模普及，毕竟网页的体验和本地 IDE 差距还是非常大的。
但网页优势在与图形化表达，以及脚本化，如果一个按钮可以帮你管理许多本地文件，那这种混合式云端开发的价值就非常大。
Rekit Studio 的尝试，给我们打开了一个网页管理本地文件的脑洞，再结合 next.js 看看，可以碰撞出什么火花呢？
next.js 支持许多约定，比如自动路由：
在 pages 下创建的文件会自动识别为路由，url 路径就是以 pages 开头的文件路径。
正因为如此，所以 next.js 对项目拥有强力的约束能力，支持了更多特性：
因为路由和构建脚本都有 next.js 控制，因此支持将页面级别模块按需加载。
由于 next.js 包含对 node 端控制，自然可以处理静态文件：将 static 文件夹下的文件路由到 /static 路径。
每个页面级组件都支持静态函数 getInitialProps，这个方法的返回值不仅会注入到 props，更可以在 ssr 时预加载这部分数据。
成为 Prefetching Pages，只要在 Link 标签添加 prefetch 属性，就会在空闲阶段预加载这个页面的按需 js 文件，几乎同时保证了整包的用户体验，与按需加载带来的 js 文件体积优化，只要用户别点击的太快。
支持动态 import，这个是 webpack 刚支持不久的 TC39 新特性，可以按需加载任何文件与 npm 包。详情见 react-loadable.
next.js 支持自定义错误处理、自定义 webpack、babel 和 next.js 导出配置等。比较有用的是 publishPath，因为大公司开发的 js 文件肯定会存储在专门的 CDN 节点。
主要目的是做 GitHub Pages，这个功能与去年火起来的 gatsby 比较像。天下技术一大抄，之前还有 hexo、jekyll 几乎功能与 gatsby 一摸一样，起码应该在 readme 里写个 Inspired by hexo 吧。
到这里，next.js 核心功能差不多介绍完了，大家可以发现，next.js 对项目自动化管理能力很强，唯独缺少了可视化管理功能。
实在对不起大家，这里要做一个硬广。
因为我同时看好 next.js 对项目约定化管理能力与 Rekit Studio 的可视化辅助能力，同时又很欣赏 parcel 的零配置理念，因此基于 parcel 做了一个三合一项目工具链：pri。
我真不是为了赚 star，这个项目在写文章时是 0 star，而且是过年这几天刚写的，很多功能还没开发完，就又赶着写精读了，所以不指望通过这篇文章赚粉，而是希望抛砖引玉，看看能不能吸引志同道合的朋友。
此刻想吐槽的同学别着急，等过段时间我写一篇彻彻底底的硬广软文时，再吐槽也不急。
硬广时间结束。下面重点说说为什么做 pri，以及制作过程中的一些思考。
提取这三个框架的精华：
- 融化在项目中的脚手架 - next.js。
- 网页也能管理代码 - Rekit Studio。
- 坚持零配置到底 - parcel。
我为什么觉得这三点叠加起来一起提高项目的开发效率和可维护性？
都说一个项目中一百个文件可能有一百种写法，这就是为什么要约法三章。不仅约束目录结构，我们还约束 npm 包，固定 react/vue/ag 的版本号，提交时不仅强制 lint，还强制检测文件结构是否符合约定。
项目开发时，遵守约定可能带来一点的不自由的感觉，但是对项目进度影响微乎其微，不稳定的项目结构对后期维护成本的影响，可能导致 “这个文案改不了”。
构建脚本也固化下来，云构建时使用的就是项目依赖的脚手架做编译，脚手架不再游离于项目之外。
最后不用说的，满足条件后，就可以前面罗列的 next.js 强大的功能。
我看中的可不是 Rekit Studio 在线写代码的功能，那个是鸡肋！而是按照规范自动生成文件的功能，恰恰可以解决约定带来的不适感。
任何上手的人，不需要了解约定，就可以通过可视化界面看到项目拥有几个路由、数据流、组件等等，然后在网页上一键创建新页面，新数据流、新组件，不仅省去了机械化劳动，省去了查看约定规范文档的时间，还带来可模版市场的可能性。
可视化带来的不仅是项目理解成本大大降低，由于项目约定的存在，网页管理可以更加智能。甚至是自动检测项目是否有文件存在异常、通过语法树，比如 typescript 包分析各文件中语法层面的关联，让可视化界面显示更加详细的项目关系图。
当新版本脚手架发布时，如果对项目约定产生了修改，也可以按照规则写出固定的升级方案，并通过可视化界面提示用户如何一步步升级到新版约定结构，甚至一键升级。
正因为对项目拥有强力约束，所以脚手架才知道老项目该如何升级。唯一的缺点是，不要有任何项目开发细节游离于规则之外，这需要对业务方案进行完整设计，当产生新需求时，将其固化到规则中，而不是任其自由发展。
parcel 坚持认为，如果提供了配置文件，那和 webpack 有什么区别呢？pri 的理念也一样，如果提供了配置文件，那抛开可视化功能，和 next.js 以及其他脚手架又有什么区别呢？
配置是为了扩大通用范围而产生的，设想 webpack 如果只解决简单的 commonjs 脚本引用，那也不需要复杂的配置。parcel 内置了对 sass less typescript png json html 等等文件的处理，所以也不需要配置。
但是，没有配置的 webpack（且不说 4.0）无法解决基本项目开发需要，而无配置的 parcel 几乎可以胜任任何项目开发，而它唯一的缺点就是，可能无法胜任未来某个新语法的支持。但只要 parcel 继续维护，这个语法需求足够大，都可以继续内置进去。
可以看到，parcel 与 webpack 的竞争，是开源界一场配置战争的缩影，大到对所有类型项目的支持，parcel 都敢坚持无配置，那么小到某条业务线的管理，真的还需要配置吗？
对于
publicUrl这种参数，或者页面title之类的本身就无法确定的项目，还是需要提供配置的，当然这种配置是可控的。
项目开发中，遇到新需求，就将这个特殊处理逻辑内置到管理脚本中，恰恰解决了程序员最头疼的 “历史包袱” 问题。
同时对特殊逻辑内置的取舍、讨论，可以促进项目积极的发展，而不是配置能力过强，导致开发者时不时偷偷给项目增加一些新逻辑，以满足业务临时需求，累积到最后导致项目无人能接手。
谈来谈去，并没有涉及到复杂的算法或者新技术，讨论的只是一种项目管理思想的不断自我挑战，整合与创新。
我并没有打算留下一个中庸的结局，我现在正在积极投入文中提及的三条思路的整合开发，并相信这是未来的趋势之一，并且确实能解决项目开发与维护遇到的难题。
我列出我认为应当拥有的所有功能与特性，欢迎大家在评论区补充，或者给 pri 提 issue：
- 页面即路由。
- 支持 layouts 布局。
- 404 处理。
- 自定义配置。 - 主要解决
publicUrl等无法给出标准值的配置。 - 内置数据流并自动绑定到页面。
- 前端环境变量。 - 可以由自定义配置拓展，内置基本变量，比如是本地环境还是生产打包。
- Serve static files。
- 项目单测。
- 生成静态 HTML，支持 github pages。
- 项目可视化管理仪表盘。 - 可视化管理代码，根据约定规范。
- typescript 支持（个人偏好的）。
- tslint（jslint）在执行任何脚本时强制校验。
- Dynamic import。
- 热更新 | HMR（parcel 内置）。
- code splitting（parcel 内置）。
- 公共依赖提取（parcel 内置）。
- 自动补全项目配置文件。 - 比如
.gitignoretslint.json等等，可以以 merge 的方式保证基础配置存在。 - PWA 支持。
- Tree Shaking（parcel 暂时不支持，webpack 支持）。
- Scope Hoist（parcel 暂时不支持，webpack 支持）。
- Prefetching.
如果你想参与讨论，请点击这里，每周都有新的主题，每周五发布。