fis3和webpack有啥区别

Posted 2023-05-02

fis/fis3是grunt、gulp之后兴起的一个比较优秀的前端工程解决方案。它的本质是基于静态资源标记+动态解析静态资源表，在模板、js里边使用特殊的标记方法引用前端资源，构建的时候生成一张资源依赖表，浏览器或者后端模板语言在解析的过程中通过查表得到某个静态资源在不同环境下的引用路径，所以不管是纯前端渲染（标记方法已经转换成浏览器能识别的了）还是后端（php、node、java）渲染，都很容易支持到，这样可以做到非常精细化的控制资源的按需加载。可以说fis真正做到了静态资源动态按需加载。
再来说说webpack，其实本质上是静态打包，生成chunk需要手动配置entry，虽然可以使用CommonsChunkPlugin、dll等插件辅助提取公共代码，以及采用code split切割进行懒加载，但这个粒度十分难把握，配置起来也比较困难（fis是自动生成依赖关系和自动处理懒加载）。
单从原理上来讲，fis比webpack要先进好多好多。但是fis先进的理念也成为它的一个缺陷，就是自定义的一套标记语言，大量自定义的资源标记语法并不能被浏览器直接接解析或者被社区流行的工具（browserify/babel）转换，比如fis依赖自家定制的mod.js来解析`require()`函数（即定位资源）以及资源base64内嵌语法`__include()`等。这一点直接导致了fis无法和后来的强大的npm社区对接，大量的npm前端模块在fis用不了，笔者认为这是导致各公司在选择前端统一的构建工具标准时不考虑fis的最大原因吧。
fis的作者
曾经说过，webpack只差一步——生成支持静态资源表，就完美了，深以为然！目前，webpack好像有生成sourcemap的插件，但是缺少配套的解析sourcemap的工具，后端的模板引擎貌似也没有支持sourcemap。
webpack现有的懒加载手段不完美，但是基本够用，主要是它直接支持commonjs规范的require语法，再配置babel等还可以直接解析ES6语法（当然，fis也可以通过插件支持ES6的），加上可以直接使用npm模块这一点，依托npm社区强大红利来搭建公司级公共组件化规范。所以综合考虑，webpack目前是前端构建工具的首选。 参考技术A fis/fis3是grunt、gulp之后兴起的一个比较优秀的前端工程解决方案。它的本质是基于静态资源标记+动态解析静态资源表，在模板、js里边使用特殊的标记方法引用前端资源，构建的时候生成一张资源依赖表，浏览器或者后端模板语言在解析的过程中通过查表得到某个静态资源在不同环境下的引用路径，所以不管是纯前端渲染（标记方法已经转换成浏览器能识别的了）还是后端（php、node、java）渲染，都很容易支持到，这样可以做到非常精细化的控制资源的按需加载。可以说fis真正做到了静态资源动态按需加载。

再来说说webpack，这货其实本质上是静态打包，生成chunk需要手动配置entry，虽然可以使用CommonsChunkPlugin、dll等插件辅助提取公共代码，以及采用code split切割进行懒加载，但这个粒度十分难把握，配置起来也比较困难（fis是自动生成依赖关系和自动处理懒加载）。
单从原理上来讲，fis比webpack要先进好多好多。但是fis先进的理念也成为它的一个缺陷，就是自定义的一套标记语言，大量自定义的资源标记语法并不能被浏览器直接接解析或者被社区流行的工具（browserify/babel）转换，比如fis依赖自家定制的mod.js来解析`require()`函数（即定位资源）以及资源base64内嵌语法`__include()`等。这一点直接导致了fis无法和后来的强大的npm社区对接，大量的npm前端模块在fis用不了，笔者认为这是导致各公司在选择前端统一的构建工具标准时不考虑fis的最大原因吧。
fis的作者
曾经说过，webpack只差一步——生成支持静态资源表，就完美了，深以为然！目前，webpack好像有生成sourcemap的插件，但是缺少配套的解析sourcemap的工具，后端的模板引擎貌似也没有支持sourcemap。

webpack现有的懒加载手段不完美，但是基本够用，主要是它直接支持commonjs规范的require语法，再配置babel等还可以直接解析ES6语法（当然，fis也可以通过插件支持ES6的），加上可以直接使用npm模块这一点，依托npm社区强大红利来搭建公司级公共组件化规范。所以综合考虑，webpack目前是前端构建工具的首选。
我们公司前端内部，也在试图搭建基于webpack+npm的前端模块化生态。本回答被提问者采纳

全局导入与单个组件导入 + webpack：最终（捆绑/打包）大小有啥区别吗？

【中文标题】全局导入与单个组件导入 + webpack：最终（捆绑/打包）大小有啥区别吗？

【英文标题】：Global import vs individual component import + webpack: is there any difference in final (bundled/packed) size?全局导入与单个组件导入 + webpack：最终（捆绑/打包）大小有什么区别吗？

【发布时间】：2018-10-30 00:47:53

【问题描述】：

我发现了类似的话题What are the pros/cons of importing components in main.js (for VueJS)?，但我想深入挖掘一下。

例如，bootsrap-vue 允许通过main.js 一起导入所有组件：

import Vue from 'vue'
import BootstrapVue from 'bootstrap-vue'
Vue.use(BootstrapVue);

或任何单独的组件，例如：

import bAlert from 'bootstrap-vue/es/components/alert/alert';
Vue.component('b-alert', bAlert);

bootstrap-vue的很多组件我根本不会用，所以，这里我有2个问题：

webpack 是否添加到站点的捆绑/打包版本中只是真正使用了组件（以某种方式检查使用了哪些组件？是否有必要指定任何 Webpack 设置？）或webpack 只是添加所有内容是全局导入的（main.js）？

基于第一个问题：在仅使用单个组件的情况下，捆绑/打包（如果使用webpack）网站的大小是否有任何盈利能力？

我有一个相当大的项目，在 main.js 中导入了很多组件，我想知道，我应该保持原样还是重新组织所有内容。

更新

我用我需要的组件替换了Vue.use(BoostrapVue)（我经常使用）。在npm run build 之后使用Vue.use(BoostrapVue)，我的dist 文件夹为4.6MB。一旦我开始导入每个需要的组件，dist 文件夹大小变为 4.2MB。

【参考方案1】：

如果你 import * webpack 将无法知道哪些东西没有使用，哪些东西是。它会将所有内容放入最终捆绑包中。

最佳做法是使用命名导入，因此可以“摇树”。

【讨论】：

那么，基于bootstrap-vue 的示例，导入component individually 而不是all components together via main.js 更可取，如上所示，对吗？在这种情况下，最终捆绑包的大小会更小，因此可以更快地下载网站，对吧？

是的。只要得到你需要的，最好从 es 发行版 ('bootstrap-vue/es/components')