FIS 目前有下一步发展的规划吗？2.0？

zzmmzz777 commented 9 years ago

希望了解一下 fis 团队对 fis 未来的发展规划。

oxUnd commented 9 years ago

会在近期以里程碑的方式放出下一步的规划，感谢对FIS的关注。

iamaddy commented 9 years ago

不知道现在的构建方式改变了没有，现在项目3k+文件，完成一次构建的时间要好几分钟，希望未来fis能够更轻便。fis的入门也不太简单，当然完成简单的构建是完全没问题。但随着项目的不断扩大，越来越多的问题都暴露出来。比如产出很多与本次版本无关的文件，导致发布的时候需要挑选文件，后来经过修改源码，能做到只产出相关文件。样式、雪碧图合并也存在一些问题，雪碧图的合并也并不要一刀切的全都合并在一起，会导致冗余。

fouber commented 9 years ago

@iamaddy

关于文件很多的问题

现在的fis从一开始就设计为大型项目使用的，上述问题fis的有很多巧妙的解决方案，比如在百度，大型项目都是拆分成了多个子系统进行开发的：

所有子系统可以独立构建，独立上线，部署到一起之后再形成完整的整体，并不是fis设计上没有考虑大项目的使用，而且fis通过map.json等技术提供了更巧妙的系统拆分实现，使得fis并不需要直面文件多的问题。

此外，3k+的文件确定都是前端项目吗？很多使用fis的团队还是保留着传统的开发思路，把前后端代码放在一起经过fis构建，其实fis更加提倡前后端分离开发的规范设计。比如你这里提到的3k+文件，很大程度上可能是有非前端代码的，举个例子，我有这样的项目：

- project
  |- public  -- 仅这里是前端代码，有1k文件
  |- server -- 这里是后端代码，有1k文件
  |- node_modules -- 这里是lib目录，有1k文件
  |- fis-conf.js

这样一个有着3k的文件，对它进行构建，fis做了很多没有意义的工作，其实这种情况下，fis主张将前端代码进行分离，得到这样的项目：

- project（非前端代码）
  |- server -- 这里是后端代码，有1k文件
  |- node_modules -- 这里是lib目录，有1k文件
- front-end（纯前端代码）
  |- js|css|img -- 这里是原来project/public目录下的前端代码，有1k文件
  |- fis-conf.js

开发时，执行命令：

cd front-end
fis release -wLd ../project/public

把代码发布到原来的project/public目录下，得到我们预期的部署效果，然后在project中进行预览。fis就只专注处理纯前端的那1k文件而已，性能不会有问题。

关于csssprite的问题

csssprite其实是一个非常复杂的问题，要实现的很完美必然会带来非常复杂的规范或者繁多的配置。所以在当初设计sprite的时候，fis定的目标是只解决60%~70%的sprite问题，让配置趋近于0，剩下的就不管了。这种选择兼顾开发效率、使用成本和优化要求，算是一个平衡点，所以，不要期待sprite解决100%的合并问题，其结果背后隐藏着更多的麻烦。

为了尽量减少配置，fis的sprite规定，合并以css文件为单位，也就是说一个css文件可以合并出一个sprite。当然，这是一个比较暴力的规则，但是正是由于这种规则简单粗暴，使得其使用起来更加灵活可靠。雪碧图的合并完全是以css文件为单位的。这就意味着，用户有自己的选择权，想合成多个，就拆成多个css文件就行了。如果要更加复杂的合并策略，必将引入复杂的合并配置，这会导致sprite的使用和维护成本增加，未必是正收益。

关于冗余文件

不知道是指的什么冗余文件，如果是指sprite后，被合并的图片还要输出，那是为了保证程序的可靠。因为没有办法得知被合并的图片是否以其他形式被使用（比如被js引用、被其他css单独引用等），所以，保留这些文件是合理的。如果是md5冗余，这也是合理的，因为在上线的过程中会有部署时间，如果没有冗余文件的存在，部署时间内会出现文件加载错误的问题，这比冗余要严重的多。

我们自己经过工程实践觉得冗余是合理的，没有必要单独挑出来或者对其进行清理，你也可以再考虑一下这个问题。

关于下一代fis

我个人比较关注的是fis的使用成本和工程化这个概念的推广，之前也列了一些，期待fis团队最终的行动吧

oxUnd commented 9 years ago

:100:

iamaddy commented 9 years ago

@fouber 感谢这么详细的回答。 1、关于拆分子系统不是没有拆分这方面的考虑，只是这些业务确实是整个项目，只是属于不同的功能模块，包括组件，公共的基础逻辑，原则上是要做到复用，而不是维护多份，随着业务越做越多会导致文件不断的变多。当然不同的项目理应拆分。就算是拆分不同的子系统，fis的配置成本不太低，学习成本有点高，导致组内的成员都要去学习。 2、1k文件也存构建上的性能慢问题，压缩、雪碧图、md5等差不多要一分钟左右，目前猜想耗时主要花在压缩，md5计算上。 3、css-sprite的已经找到解决方案，针对单个文件做一次雪碧图合并就行，合并css之后在合并一次，需要添加一个新规则。 4、我指的冗余更多的是指md5文件的冗余面对这样的情况，我觉得应该是会抓狂的。后来想为什么构建的时候要产出不相关的文件，所以这里又对代码改造了一次，可以指定文件构建，产出其所依赖的文件，这样一来就解决了这个问题。

另外小组成员写了一个简单的gui，使得构建更加便捷。

现在慢的问题，归根结底是fis基于整个项目构建，如果是基于相关文件构建，应该会轻很多。

oxUnd commented 9 years ago

@iamaddy 来，把你的工具分享出来，让我使使

fouber commented 9 years ago

@iamaddy

关于拆分，你在仔细看一下我前面回复的第一个截图，那个系统是拆成了多个小的项目进行开发，那么这些项目之间是如何复用的呢？其实是借助了fis构建后生成的map.json，架构设计是可以解决拆分和复用之间的矛盾的，其关键就是资源表的共享。
平时开发，不需要压缩合并sprite，只有上线前才需要，上线前的构建我们一般是准备一台好一些的机器，安装CI，然后持续集成构建和部署，所以效率也比较高。本地开发只有文件监听和浏览器自动刷新，另外还有编译缓存支撑构建，速度通常不成问题。
csssprite问题OK
构建后的文件不应该纳入版本管理。正确的用法是只有一份源码，然后每次代码提交，CI平台自动构建，将构建结果打成tar包，线上部署这个tar包，也就说，构建后的文件从未进入过版本控制。这种方案无论是在大公司还是小公司都是被证明行之有效的发布和迭代管理手段

fex-team / fis