你尚未登录,仅允许查看本站部分内容。请登录使用邀请码注册
berg

组件化这事又在逐渐升温,谁才是未来? 24个回复 专栏 @ 框架与库

berg 发布于 3 年前

最近很多组件化相关的讨论和主题,比如 @xufeihttp://div.io/topic/908@errorrik 关于AMD的 http://div.io/topic/909 ,我所知道的组件化方案有这么几种:

  1. 最原始的,基于命名空间和原型链的组件化,可能跟文件和目录结构也有关联
  2. 基于AMD或CommonJS的模块化方案
  3. 基于Web components 或者 HTML Tag的方案,
  4. 基于框架私有的方案,可能是前面三种的任何一种,比如早期的Extjs,现在的Angular和React。
  5. 经过 @Kyrios 提醒,ES6里面也有组件化规范,这个跟 3 还略有不同,姑且单算一类

你喜欢那种,或者你觉得哪种才是发展的未来?

  • errorrik

    AMD肯定不是未来。在HTTP2还没普及的时候,AMD还能发挥一段不短时间的余热

    #1
  • 前端农民工

    组件化应该建立在模块化的基础上,模块化是对资源的管理,组件化是对业务逻辑的管理,各自要有不同的发展方向。

    #2
  • berg

    @前端农民工 或许我这里模糊了这二者的概念,在我看来这两者是一体的,最好的组件化方案就应该是一个模块化方案,既保证了js、html、css的解耦,也能将他们组合成一个完整的业务逻辑。

    当然了,在现实中,由于多数模块化方案都只管js,所以大家都会选一个模块化方案,然后在上面撘一套组件化方案。

    #3
  • 前端农民工

    @berg

    恩,“最好的组件化方案就应该是一个模块化方案”。

    其实只要模块化方案能完备的管理一个组件的js、css和html,就已经具备组件化的雏形了,剩下的工作就是对三者的封装和使用问题

    #4
  • berg

    @前端农民工 但是现在没有一个被广泛使用的方案,而且前端很变态,需要分别管理html+js+css

    #5
  • 前端农民工

    @berg

    所以我觉得模块化本身还没有走到头,*MD只是一种js的管理模式而已,远远不够。web components概念很好,但还是缺少一个完整的资源管理方案

    #6
  • jimnox

    Web Components对资源的管理方式没有很好的解决,Polymer也没主张如何管理资源,都是零散加载。
    Polymer现在对custom element注册时机的要求会和异步加载JS模块的方式冲突。
    如果对Web Components的资源打包没有新的方案那就有点无为而治的意思了,也许得依赖HTTP/2什么的,让请求数变得不是问题,那时候资源打包可能就成历史了?

    #7
  • 前端农民工

    @jimnox

    或许资源打包会成为历史,但资源管理不仅仅是打包,还包括各种加载问题,同步加载、延迟加载、预加载、按需加载、依赖加载、缓存更新、终端适配加载等,就是要求资源管理本身是可编程的。

    #8
  • berg

    @前端农民工 其实这个问题在很久很久之前就有山寨解决方案,但一直没有形成生态并且考虑周到的方案。我本来以为多屏时代的到来会迫使大家解决这个问题,可是没想到的是……多屏时代大家都不共用一套代码了 囧。

    #9
  • 前端农民工

    @berg 资源管理如果能达成标准,组件化就是天然的了

    #10
  • <。)#)))≦

    我们现在尝试的是用 CommonJS 的规范来管理代码,这样可以用NPM来管理组件。

    对于CSS和HTML TEMPLATE 我们会也将它们编译为一个JS模块,这样就可以直接通过require的方式来引用模板和样式了。我写了一个简单的小工具 componizer 来做这件事情。

    但是具体组件应该怎么使用那就是每个组件自己的一个方案了,可以是用 custom element 也可以是一个JS接口,也可以是AngularJS的一个指令,也可以是一个jquery插件,这个还在探索中。但是不管这个组件怎么用,引用它的方式都是在JS里面通过

    require('xxx') 来引用,但是现在也在考虑如果是用custom element的方式那么可以写一个扩展的库来自动require对应的模块。

    #11
  • nimo

    @<。)#)))≦

    可以看看 spm 也是 CommonJS开发代码,最终打包成 cmd 、 standalone 或 umd

    https://github.com/spmjs/spm/issues/1200

    #12
  • jimnox

    我现在写玩具用ES6的module/package然后用6to5,如果是node玩具就编译成CommonJS,如果是浏览器玩具就编译成AMD,感觉还算良好……

    #13
  • vvian00

    最近正在思考 AngularJS 怎么做组件化,关注一下

    #14
  • 前端农民工

    模块组件关系

    这是一个页面的组织架构图,我想表达的是,UI组件化和模块化必然是相辅相成的。UI组件应该是一种页面展现和可交互的高级模块,而这些组件也需要很多js和css模块来支撑,比如网络操作封装就是一种纯JS模块,语法高亮就是一种带有CSS的JS模块,字体图标、过渡动画等是一种纯CSS功能模块。

    UI组件封装的是组件的生命周期,暴露的是界面交互和事件;JS模块封装的是算法,暴露的是接口;CSS模块封装的是展现形式,暴露的是指定的选择器。三者的封装和复用方式不尽相同,如果都以组件化为基础是不合理的设计。

    我想即便是webcomponents时代到来,我们仍然不能放弃模块化。

    #15
  • nimo

    @前端农民工 Hi,又来求 fouber 指点了,请教:
    如何看待支付宝的 (alice arale) http://aliceui.org/docs/widget.html http://aliceui.org/docs/javascript.html

    我现在组件的模块区分和依赖关系参考的是它们提供的组织方式。 alice 和 arale 之间的关系是否和你在楼上所说的类似?

    #16
  • berg

    @前端农民工 单个语种的模块化不会被放弃,只是被隐藏在更好用的组件化里面

    #17
  • 前端农民工

    @berg

    在统一的模块化基础上建立模块生态,生态包括js模块、css模块,js模块生态中又有多个组件化框架,基于不同的组件化框架和相同的模块化框架,又会建设很多UI模块(组件),这样整个生态更容易融合在一起互通有无。

    但是如果改成先有组件化框架,然后组件化框架中提供模块化管理,这样,不同的组件化框架可能衍生出不同的模块化方式,那么那些比较独立通用的js模块和css模块就不那么好搞了。

    #18
  • berg

    @前端农民工 当然是先有模块化,再有组件化,这个不用辩论。我的问题是,现在有很多种模块化的方案,也有很多组件化的方案,到底哪个才是未来的趋势?以及为什么?

    比如ES6的模块化 VS CMD VS AMD,我个人当然更看好ES6,虽然现在还不是主流,但是一旦要扯到CSS+HTML,问题就复杂多了。

    #19
  • 前端农民工

    @berg

    恩,统一了模块化和组件化的层次关系之后,我觉得未来的发展要分几个方向:

    1. 模块化语法
    2. 模块化加载器
    3. 模块生态
    4. 组件化框架模块
    5. 组件生态

    5个方向是递进关系。我最期待的是看到2(模块化loader)能以标准的形式统一。每个方向我比较看好的未来是:

    • 模块化语法:ES6必须胜出,因为这是语言层面的东西,语言能支持是最好的了
    • 模块化加载器:HTTP/2 和 ES7的async/await或许能发挥作用,但还远远不够,我们需要把css和html扯进来,在html层面缺少一种模块化loader的标签,link import有点接近,但还不对劲。我认为loader是目前业界最大的阻碍。顺便吐槽一下,感觉web components的命运会和html components一样。
    • 模块生态:语法和加载器实现以后,我们将迎来模块爆发的时代,就好像npm的发展速度一样,甚至比它更快。生态方面可能是npm直接胜出。
    • 组件化框架:我目前倾向于react胜出。它的虚拟dom的概念移植能力很强,很容易连接到其他平台上,还有dom反射机制,只有DOM的反射机制才能解决前后端一体化的问题:我们在后端输出html,React把后端的dom反射为前端组件,进行自动化绑定。此外,react的自定义标签语法糖也特别适合后端组件化渲染使用
    • 组件生态:由于组件只是一种高级的模块,所以组件生态应该只是模块生态的一部分而已,目前也就是npm一家独大吧
    #20
  • berg

    @前端农民工 你的图菊花了

    现在的问题焦点其实很明显。js不是问题,因为即使没有es6,amd也OK了,css+html才是问题

    • web component其实也是一种语法吧,只是w3c的标准一向不靠谱而已。
    • 至于框架的形态,我不是很喜欢react这种机制,太抽象了,其实大家都是在web上开发,虚拟dom这个概念用来跨平台统一是很好,比如react native,但是在web上反而不伦不类了。至于dom的反射机制,这个我倒是希望有一个标准能支持才好。
    • 模块生态和组件生态我不担心,只要标准靠谱了,大厂支持了,自然会发展起来

    说到html+css,我反倒觉得web components相对靠谱,至少这个饼画得还是挺圆的,html可以碎片化加载,内部可以做隔离,你所说的DOM反射,JS也能实现。

    #21
  • jimnox

    web components自带“模块化”了,天然把HTML和CSS和JS组合在一起了。不过还是要解决一些别的问题,比如一个组件的CSS依赖别的东西,一个组件的JS更是肯定会依赖别的JS模块。
    web components的这种方式现在看起来是碎片化了,不过也许在HTTP/2普及以后,连接数不再成为前端性能的针毡,会反而变得方便。
    我也想过,在web components里,CSS依赖直接用@import来做,JS依赖差不多还能按现在的做法,也许以后浏览器支持原生的ES6语法了就JS也没问题了。
    这么说听起来有点无为而治的意思,要推翻当前的好多概念。说实在现在有这么多浏览器里的模块化方案还是因为条件所限,有了新条件的话思路肯定要顺着变。

    说下语法,我喜欢ES6的语法,它有个天然优势是它的所有import声明必须前置,同时它有更明确的导出语法,不像CommonJS你可以exports.xxx = y;也可以module.exports = xxxx。这样对规范化和静态分析是有帮助的。

    #22
  • berg

    @jimnox 我也希望http2能解决现在无休无止的打包+合并问题。

    #23
  • jiangtao

    @berg 大神求解: dom的反射机制 是什么?

    #24
登录后回复,如无账号,请使用邀请码注册