介绍下工具
babel / babel-browser.js
就这些ES6, jsx标准等等，现代浏览器不认，我们得把写好的javascript脚本翻译成ES5年代的以兼容大部分浏览器（IE9+），就有了这个。
babel-cli是一个专门的转换js文件的工具，将新语法的new.js转换成旧语法的compatibility.js文件，然后直接在HTML引用即可。
babel-browser.js是一个js文件，在html中直接<script src>引入。
babel还提供了webpack插件版本。
WebPack
把前端的这些页面，看作是主要是js写的（包括排版什么的），但是最终还是要.html去展现吧，于是就在空壳.html上载入js脚本，渲染页面，因此该工具是针对js的，其他都是配角。
其运行机制是，根据写好的webpack.config.js，找到entry: [xxx.js]，将其按照配置要求翻译压缩。
这个工具处理html文件的办法：常用插件html-webpack-plugin，把html文件看作template。因此对于每个输出html，都对应webpack.config.js的plugins[new HtmlWebpackPlugin()]。
深目录的多html文件，可以写function来遍历目录来生成配置文件。webpack.config.js是作为js脚本执行的，所以我们可以尽情发挥，js语法啦！
再介绍个插件 config.optimization.splitChunks https://juejin.im/post/5b99b9cd6fb9a05cff32007a#heading-5~~webpack.optimize.CommonsChunkPlugin简单易用，提取公共库打包:https://segmentfault.com/a/1190000011920743#item-1 已经不推荐使用啦
Parcel
https://parceljs.org/
这个简直太开箱即用了，适合调试用，就直接parcel src/**/*.html出土，他还自动找.babelrc配置文件，好吃不贵啊。
但是坑在：输出居然是绝对路径试着加了好多参数以及看了好多issue都不知道咋整。顶大能加一个prefix-url，但是设成'.'也不能变成绝对路径，他只是指定prefix而已啊和相对绝对路径没啥关系。
Glup
这很像胶水啦 很形象！
就是根据写的配置文件，做如下工作流：读xxx.html，使用yyy工具预处理，放入dist文件夹
他自己不带处理工具，只是一个workflow管理器。
ReactJS
可以直接运行在浏览器端：(ES5版本的?)react.js，直接在html里面引了以后，把babel转换过的代码在引进来就可以直接用啦（如果没写JSX就不用babel转换可以直接用）。
需求场景
情况0：就改动传统html工程里面的一页，想用React+JSX
- 直接在html里引用react.js，不必引babel.js。
- 调试用Parcel开临时环境。
- 输出用babel-cli转换js文件。
- 如果本地没有node环境，还是要引babel.js，但是要把代码都改成
<script type='text/babel'>因为要先载入babel.js然后由babel.js去读它。要不然肯定是普通type=text/javascript段先执行，如果在里面写了调用 text/babel这个js里面的函数，肯定undefined，因为浏览器不认识，等着babel.js去读，当然还没载入啦。
情况A：我只出几个页面，粘贴进传统手打html工程中，又想用React+JSX。编译出的页面当然要手动改起来方便啦！
那就不能压缩，如果用了webpack矛盾在：js压缩就不好改了，html里<script>标签若交给工具管理就不知道js文件会被合并成啥样。
如果用了webpack等工具，出来的js搞不好好几个库合一起了。（也不是不可以用，看看下文！）
我们想象的样子是交给webpack处理html文件里面的各种script引用，包括引用babel处理好的js，现实是如果只用webpack要写很多配置挺浪费时间的。
- 所以 不能在js文件中require()库，如果引了然后 打包一块了or跟HTML原有的冲了 闹不闹♥。（倒是可以写webpack配置文件避免，就是乱了吧唧的，不值当的啊。）
- 结论2 打包直接用babel转换js文件，涉及页面多就写脚本批处理/用glup。HTML文件不用工具处理直接copy过去。
- 结论3 调试时候不用考虑，使用上述Parcel一键，啥环境都能给整兼容了。
情况B：我出的页面，作为传统手敲html前端工程的一部分，但是没人看我代码。
简单了，把页面偏向于js排版，html做壳，直接webpack随便配输出页面即可。
- 该情况不能：在js里require('jquery'); 重复载入库，和传统的库的隐含依赖冲突了咋整。。（当然也可以webpack配置文件跳过库）
- 优势：当然也可以随便require('xxx'); 基本不用配置直接打包，因为没人看输出的代码。
- 打包时写一段function：遍历目录->找寻js和html文件->生成含
html-webpack-plugin的配置->交给webpack - 调试简单，直接开Parcel。
情况C：做全站，排版手打HTML，其余组件化React+JSX，但是希望输出的html和js文件可读可改。
这种比上面更激进一些，可以使用const $ = require('jquery');类似的代码，不会造成相似的资源重复获取。
因为用户在传统和我造的页面切换时，不希望jquery这种还得载入一遍。（打包版本和原始工程版本）
- 公共js库：用
webpack.optimize.CommonsChunkPlugin插件，对jquery这种公共库打包。 - html文件：写function出
html-webpack-plugin配置。 - 自己写的js文件：要求多就写webpack的loader，直接接babel，网上搜个例子就懂了，配置好不压缩，达标！
- 保证输出可读：公共库没人看随便压缩。自己写的库代码只做了新旧语法转换，也没压缩合并，易读易改。
想清需求，去套工具，不容易找到可心的啦！
再说点别的
React中，我们可能按需封装了一些组件，谁持有数据，谁又要使用class，为什么不用function component?
我的做法是，负责ajax的组件持有数据。在其下方的组件均为function component。
- 但此时我们就非常急迫的想要 data-view在function组件上双向绑定。
- 如果存在大量重复可优化部分，尝试封装ajax
- 量太大就不能靠react打补丁
- 代码量过大，可以引入其他框架，并将react做纯粹 view + view_control
为什么(用/不用)Redux
我有时在想，为什么需要框架去开发。框架好，大幅降低开发门槛。且框架提供统一规范，精准sample，以及符合众多口味的教程，让代码交流变得容易。
解决的问题是，我们没有必要造轮子，也没必要持有造车能力再去开发。