前端是个比较苦逼的工种，面临着一年一变的开发框架，一季一变的脚手架，一月一变工具库，这几年现已经发展到整个开发生态圈一年一变。
然而对于新技术的追求是一定要有的，毕竟唯一不变的东西就是变化，在互联网行业跟不上变化就等于淘汰。对于比较有开发经验的前端同学们来说，学习一项新的框架是非常轻松的，积极订阅技术周刊、看文档、逛github都可以使你迅速跟上前端变化的节奏。
回到现实，在大公司的大业务线，比如我所负责的百度贴吧，情况没有那么乐观。一个十多年的业务线所积累的业务代码是每一个个体无法想象，也无法掌控的，贴吧的前端代码几乎反应了整个前端历史的发展轨迹：在体系复杂的基础项目、林林种种的创新项目、变化多样的运营项目中，几乎所有博文中介绍过的优雅，神奇，黑科技的方法毫无例外都被使用过，框架集中在了jquery生态，是jquery时代混合php编程的经典范例。然而随着前端的发展，产品迭代的加速，旧的前端开发架构已经越来越无力。
在前后端分离开发方式早就被实践的今天，想在贴吧做一点点改变也会受到编译脚本、模块耦合，php全环境问题的困扰，任何小小的优化都会牵一发而动全身，于是我们开始了漫长的改造，从制作新的编译脚本，使用新开发流程，对fis通用化定制，以及后端UI层改为nodejs全方位辅助前端模块化开发，框架选用了React。
写到这里，应该总结一些为什么要使用React理由，毕竟前端变化那么快，为什么这么看好React呢？React不仅仅有非常优秀的模块化机制，普通的业务模块也能拆出来拥抱npm，更重要的是推出了虚拟dom思想，提高dom渲染效率，使得跨平台开发成为可能。也许在未来web app会替代native app（假设），可是虚拟dom更使后端渲染成为了可能，web app也需要借助虚拟dom的优势优化首屏用户体验。
Fis3 vs Webpack
fis3是完整的前端构建工具，webpack是前端打包工具，现在fis3也拥有了webpack对npm生态打包的能力，详情参考这篇文章：如何用 fis3 来开发 React?。
让 fis3 拥有 webpack 的打包能力，只需要 fis-conf.js 添加如下配置：
|
1 2 3 4 5 6 7 |
// fis3 中预设的是 fis-components，这里不需要，所以先关了。 fis.unhook('components') // 使用 fis3-hook-node_modules 插件。 fis.hook('node_modules', { ignoreDevDependencies: true // 忽略 devDep 文件 }) |
假设我们将项目分为 client 与 server ，可以按需加载前端用到的文件：
|
1 2 3 4 5 6 |
fis.set('project.files', [ // client 按需加载 '/client/index.html', // server 全部加载 '/server/**' ]) |
再将前端文件使用 typescript 编译:
|
1 2 3 4 5 6 7 |
fis.match('/client/**.{jsx,tsx}', { rExt : 'js', parser: fis.plugin('typescript', { module: 1, target: 0 }), }) |
如果上线后需要将文件发布到 cdn 域名下，可以动态替换，同时开启压缩等操作：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
const production = fis.media('production') production.match('*.{css,less,scss,sass,js}', { domain: 'http://cdn.example.com' }) // 压缩 css production.match('*.{css,scss}', { optimizer: fis.plugin('clean-css') }) // 针对以下下文件，开启文件 hash production.match('*.{ts,tsx,js,jsx,css,scss,png,jpg,jpeg,gif,bmp,eot,svg,ttf,woff,woff2}', { useHash: true }) // png 压缩 production.match('*.png', { optimizer: fis.plugin('png-compressor') }) // 压缩 js 文件 production.match('*.{js,tsx}', { optimizer: fis.plugin('uglify-js') }) |
生产环境需要压缩前端文件：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
const pack = { '/client/pkg/bundle.js': [ '/client/index.tsx', '/client/index.tsx:deps' ], '/client/pkg/bundle.css': [ '*.scss', '*.css' ] } // 依赖打包 production.match('::package', { packager: fis.plugin('deps-pack', pack) }) |
这样就将所有 js 依赖文件都打包到 /client/pkg/bundle.js，css 文件都打包到/client/pkg/bundle.css，同时fis3会自动替换html中的引用。
Yog2 vs express
yog2是基于express封装的nodejs UI层解决方案，文档地址。主要特点使用了app拆分，使得协同开发变得方便。业务项目与node根项目分离，本地开发时，使用fis3的http-push能力提交到node根项目子项目文件夹中，保证不同业务项目的分离。
先安装yog2:
然而对于新技术的追求是一定要有的，毕竟唯一不变的东西就是变化，在互联网行业跟不上变化就等于淘汰。对于比较有开发经验的前端同学们来说，学习一项新的框架是非常轻松的，积极订阅技术周刊、看文档、逛github都可以使你迅速跟上前端变化的节奏。
回到现实，在大公司的大业务线，比如我所负责的百度贴吧，情况没有那么乐观。一个十多年的业务线所积累的业务代码是每一个个体无法想象，也无法掌控的，贴吧的前端代码几乎反应了整个前端历史的发展轨迹：在体系复杂的基础项目、林林种种的创新项目、变化多样的运营项目中，几乎所有博文中介绍过的优雅，神奇，黑科技的方法毫无例外都被使用过，框架集中在了jquery生态，是jquery时代混合php编程的经典范例。然而随着前端的发展，产品迭代的加速，旧的前端开发架构已经越来越无力。
在前后端分离开发方式早就被实践的今天，想在贴吧做一点点改变也会受到编译脚本、模块耦合，php全环境问题的困扰，任何小小的优化都会牵一发而动全身，于是我们开始了漫长的改造，从制作新的编译脚本，使用新开发流程，对fis通用化定制，以及后端UI层改为nodejs全方位辅助前端模块化开发，框架选用了React。
写到这里，应该总结一些为什么要使用React理由，毕竟前端变化那么快，为什么这么看好React呢？React不仅仅有非常优秀的模块化机制，普通的业务模块也能拆出来拥抱npm，更重要的是推出了虚拟dom思想，提高dom渲染效率，使得跨平台开发成为可能。也许在未来web app会替代native app（假设），可是虚拟dom更使后端渲染成为了可能，web app也需要借助虚拟dom的优势优化首屏用户体验。
Fis3 vs Webpack
fis3是完整的前端构建工具，webpack是前端打包工具，现在fis3也拥有了webpack对npm生态打包的能力，详情参考这篇文章：如何用 fis3 来开发 React?。
让 fis3 拥有 webpack 的打包能力，只需要 fis-conf.js 添加如下配置：
|
1 2 3 4 5 6 7 |
// fis3 中预设的是 fis-components，这里不需要，所以先关了。 fis.unhook('components') // 使用 fis3-hook-node_modules 插件。 fis.hook('node_modules', { ignoreDevDependencies: true // 忽略 devDep 文件 }) |
假设我们将项目分为 client 与 server ，可以按需加载前端用到的文件：
|
1 2 3 4 5 6 |
fis.set('project.files', [ // client 按需加载 '/client/index.html', // server 全部加载 '/server/**' ]) |
再将前端文件使用 typescript 编译:
|
1 2 3 4 5 6 7 |
fis.match('/client/**.{jsx,tsx}', { rExt : 'js', parser: fis.plugin('typescript', { module: 1, target: 0 }), }) |
如果上线后需要将文件发布到 cdn 域名下，可以动态替换，同时开启压缩等操作：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
const production = fis.media('production') production.match('*.{css,less,scss,sass,js}', { domain: 'http://cdn.example.com' }) // 压缩 css production.match('*.{css,scss}', { optimizer: fis.plugin('clean-css') }) // 针对以下下文件，开启文件 hash production.match('*.{ts,tsx,js,jsx,css,scss,png,jpg,jpeg,gif,bmp,eot,svg,ttf,woff,woff2}', { useHash: true }) // png 压缩 production.match('*.png', { optimizer: fis.plugin('png-compressor') }) // 压缩 js 文件 production.match('*.{js,tsx}', { optimizer: fis.plugin('uglify-js') }) |
生产环境需要压缩前端文件：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
const pack = { '/client/pkg/bundle.js': [ '/client/index.tsx', '/client/index.tsx:deps' ], '/client/pkg/bundle.css': [ '*.scss', '*.css' ] } // 依赖打包 production.match('::package', { packager: fis.plugin('deps-pack', pack) }) |
这样就将所有 js 依赖文件都打包到 /client/pkg/bundle.js，css 文件都打包到/client/pkg/bundle.css，同时fis3会自动替换html中的引用。
Yog2 vs express
yog2是基于express封装的nodejs UI层解决方案，
