这是一个创建于 4193 天前的主题，其中的信息可能已经有所发展或是发生改变。
IO大会中对我最有启发的是GOOGLE最新的UI项目 Web Components. 大家来讨论一下自己看法吧。
我觉得 Web Components 是对前端生产力的彻底解放，也会推进前端的技术进步。
相比backbone，ember，meteor, angular 等前端框架，它提供了一种更彻底的解耦方式，而且更加方便了UI的开发和模块化。我常用backbone和Require.js，觉得backbone的一个缺点是不能够彻底的模块化，即使自己可以把一个功能的m，v，c,和template都拆成文件放到一个模块目录，模块还是要依赖一个"全局APP"的event emitter 和 view manger(用于管理view的生命周期)，所以只是个人的做法，无法把模块彻底打包成组件。
模块化制约了Backbone的发展， 因为这造成了UI无法开源和共享。试想一下如果谷歌开源docs的编辑器UI，那么在你的APP里也许你只要插入<g-editor>你就可以引入一个全功能的编辑器是多么方便的功能，你不用担心CSS被覆盖，有全局变量冲突等。除了编辑器还可能是顶部的导航栏，侧边栏，播放器，数子可视化组件，甚至一个论坛组件。
其他的框架如ember，meteor, angular，也没有很好的解决这个问题，做到组件的彻底解耦（比如css，相互通讯，文件布局），而Web Components是让组件彻底的跑在sandbox里，组件可以彻底自由的折腾；
相关的链接：
https://developers.google.com/events/io/sessions/324149970
http://www.html5rocks.com/en/tutorials/webcomponents
我觉得 Web Components 是对前端生产力的彻底解放，也会推进前端的技术进步。
相比backbone，ember，meteor, angular 等前端框架，它提供了一种更彻底的解耦方式，而且更加方便了UI的开发和模块化。我常用backbone和Require.js，觉得backbone的一个缺点是不能够彻底的模块化，即使自己可以把一个功能的m，v，c,和template都拆成文件放到一个模块目录，模块还是要依赖一个"全局APP"的event emitter 和 view manger(用于管理view的生命周期)，所以只是个人的做法，无法把模块彻底打包成组件。
模块化制约了Backbone的发展， 因为这造成了UI无法开源和共享。试想一下如果谷歌开源docs的编辑器UI，那么在你的APP里也许你只要插入<g-editor>你就可以引入一个全功能的编辑器是多么方便的功能，你不用担心CSS被覆盖，有全局变量冲突等。除了编辑器还可能是顶部的导航栏，侧边栏，播放器，数子可视化组件，甚至一个论坛组件。
其他的框架如ember，meteor, angular，也没有很好的解决这个问题，做到组件的彻底解耦（比如css，相互通讯，文件布局），而Web Components是让组件彻底的跑在sandbox里，组件可以彻底自由的折腾；
相关的链接：
https://developers.google.com/events/io/sessions/324149970
http://www.html5rocks.com/en/tutorials/webcomponents
 |
1
chemzqm 2013-05-19 16:03:37 +08:00 via Android
我觉得是基于web应用的未来，不过大概得再等几年才好用
|
 |
2
hooluupog 2013-05-19 16:31:28 +08:00
最近在angular.js之后又弄了一个新框架好像叫Polymer，可能和这个有关吧。
|
 |
3
meteor 2013-05-19 16:38:53 +08:00
我觉得Google的那个和下面2个有点像.
TJ的components https://github.com/components/components Dart的web_components https://github.com/dart-lang/dart-web-components 不过现在集成到Web UI里了. |
 |
4
Frannk OP @meteor 的确很像，TJ好牛逼。不过感觉好像TJ做的更像是一个包管理器；Google做的更进一步，而且没提到怎么做组件的包管理，初期并不关心吧。
|
|
5
Frannk OP @hooluupog Polymer 就是我说的 Web Components： http://www.polymer-project.org/
|
 |
6
chuangbo 2013-05-19 18:10:52 +08:00
这个和 TJ 的 components 完全不是一个东西吧...
|
 |
7
jiyinyiyong 2013-05-19 18:27:15 +08:00
正好在这个话题上看到让我激动的进展
以前搜集的 Web Components 的链接先放在这里: https://github.com/Bodule/bodule/issues/6#issuecomment-14537068 还有另外若干个视频: https://github.com/coffee-js/languages/issues/59 前端开发最头疼的问题就是组建不能模块化 用 Node 可以模块化, 代码写一次, 下次 require 就好了 当然有些副作用操作的步骤也不方便写成模块, 一次编写一劳永逸.. 问题是, 前端开发大量这样的问题, 想要快速开发, 却只能用 Bower 拉 repo 然后再想快一点, 用模块化方案, 又这个方案那个方案搞不定, 没有社区一起把坑填好 加上 CSS 不能直接和 JS 这样 Hack, 这个就几乎无解了, 只能忍 希望前端的模块化能快点到来 |
|
8
chemzqm 2013-05-19 18:39:42 +08:00
google的Polymer是基于html语义化的web component，更类似于AngularJS，跟TJ的component，twitter的bower，以及requirejs所做的模块化完全是两个概念。
|
|
9
hooluupog 2013-05-19 18:39:54 +08:00
感觉服务端、系统开发中的一些工程化的成熟的思想正不断被前段开发吸收进去，提高生产效率；
那么前端开发、设计中一些天生的优点(例如比较灵活更亲近人，好像未来会出现可视化编程和设计)，不像做后端开发那么死板工程化，这些东西也能带给后端的开发者就好了，最终大家都高兴了。 |
 |
11
heroicYang 2013-05-19 23:08:01 +08:00
@Frannk TJ的components应该是实现前端的组件模块化，并自带一个包管理器，跟node和npm相似；而twitter的bower才是单纯的包管理器，和mac下的brew相似。
其实使用backbone + requirejs已经可以实现很高程度的模块化（JS/HTML Template），不过CSS是个痛点，用backbone应该还解决不了。 看这个样子，HTML语意化的才是未来？ |
 |
12
iwege 2013-05-20 00:43:15 +08:00
“而Web Components是让组件彻底的跑在sandbox里，组件可以彻底自由的折腾"
啊喏~ 请问怎么个彻底法？怎么自由折腾？ＣＳＳ终于不要带ｎａｍｅｓｐａｃｅ了？ |
|
13
Frannk OP |
|
14
Frannk OP @iwege Web Components 给了组件一个自己的世界，好像每个组件都在一个 iframe 里一样，这是其他框架都没有提供的。当然参数和css还是可以被宿主控制的。
|
 |
16
otakustay 2013-05-20 11:26:48 +08:00
前段时间看过shadow DOM，里面不能改外面的，但外面依旧能改里面的DOM，这导致component自身还是会被外部的脚本干扰，隔离性不够啊
|
Select Language