Component + SourceMaps 的模块化方案前景怎样?

[tiye]

我没有参与过学校外面的项目, 说的有局限... 纳入考虑吧,,
另外看英文老长的 AMD CMD 争论我也是不得要领...

今天早上是 CoffeeScript 更新 1.6.1 开始支持 SourceMaps
http://coffeescript.org/#source-maps
以前是 CoffeeScript-Redux 有支持 SourceMaps, 当时真没当回事
http://ryanflorence.com/2012/coffeescript-source-maps/
另外一个是前些天看到的 *-Redux 项目作者的另一个项目
https://github.com/michaelficarra/commonjs-everywhere
当时看介绍只是把 CommonJS 模块编译到单个 JS 文件, 并且保持文件不破坏什么的
之前有 Browserify 这么做, Component 项目也是这么做的
我冒失地发了一个帖, 至少我觉得会是一种可能...
http://cnodejs.org/topic/5135c32bdf9e9fcc581a66b5
像之前那个神一样的讨论里说的, 打包后的代码破坏了各种调试信息
dexteryy/OzJS#10
而不打包就有加载速度和兼容性的问题

SourceMap 本来发明就是为解决这个场景里的问题, 只是我没察觉到
在 commonjs-everywhere README 里给的例子却很清晰了
压缩后前端的代码, 在调试的控制台里还是精确定位 .js .coffee 的文件
当这成熟了, Component 的方案在调试上问题解决了, 上手就很轻松
搜索 Component 项目, 也看到提及 SourceMap 支持的, 只是文档没找到
componentjs/component#85
再往后也会有 Grunt 的插件提供更多编译的方便

我做一些设想, 如果后端能直接写 require, 我个人非常倾向用简洁的 require
类似地, 采用这套方案的人人会增多, 意味着又一个 NPM 类似的社区
Component 现在模块已经不少, 模块列表改来改去也非常清晰
http://component.io/
那么其他的 AMD CMD 方案会不会是更少人会去用, 而形成一家独大?
至少 RequireJS SeaJS 社区本来不如 Component 大
我主要是有这样的想法, 不知道几种技术上的优缺点会不会结果变成那样?

[island205]

@jiyinyiyong 就目前来看，require、seajs、nodejs很流行，导致模块就是使用require、exports、module这三个关键字来组织代码。使用npm包管理工具。Bodule这个项目想做的就是：遵循NodeJs模块规范，编写客户端代码，然后选择不同的wrapper（require、seajs等等各种客户端模块loader）打包的客户端。开发时，模块尽量独立。source map在这里恰好可以解决打包后的代码调试问题。当然source map只是一种解决方案，而且很合适。

[island205]

@jiyinyiyong 如何走更远？ 客户端比起node复杂的地方在于有html结构和css样式。不知道如何把它们融入到模块化的js中。

[tiye]

@island205 用 JS 代码生成 HTML 和 CSS 怎么样?
我看到 TJ 的博客里有讲到 Rework 这个模块, 用来生成 CSS
https://github.com/visionmedia/rework
http://tjholowaychuk.com/post/44267035203/modular-css-preprocessing-with-rework

var rework = require('rework');

var css = rework('string of css here')
  .vendors(['-webkit-', '-moz-'])
  .use(rework.prefixValue('linear-gradient'))
  .use(rework.prefixValue('radial-gradient'))
  .use(rework.prefixValue('transform'))
  .use(rework.vars())
  .use(rework.colors())
  .toString()

HTML 前端模板就多一些, Lilyturf 是我个人的方案:
(资源相对路径问题在这个地方影响严重..)
https://github.com/jiyinyiyong/lilyturf/blob/gh-pages/src/handle.coffee#L89

  document.body.appendChild lilyturf.dom ->
    @div id: "disqus_thread",
      @script type: "text/javascript", disqus_js
      @a href: "http://disqus.com", class: "dsq-brlink",
        @text "comments powered by"
        @span class: "logo-disqus", "Disqus"

[tiye]

Require、Seajs 有什么特别的好处么?
我在想 SourceMap 解决了打包后的调试问题的话, 其他文件分离的调试方式作用会变小, 是不是这样?

[island205]

@jiyinyiyong RequireJS Seajs的好处在于，开创了客户端的模块化开发，最终要的是在页面加载时只加载最小的js，然后按需加载，提高页面响应速度。他们都是在初期的脚本加载器（LAB.js等）加以模块化产生的。

[island205]

@jiyinyiyong 确实可以把CSS和HTML编译为JS，存储为JS字符串即可。更棘手的问题是，不同模块间的CSS没法隔离，会互相影响。HTML倒还好。有什么规则，可以使得CSS不互相影响么？

[tiye]

@island205 CSS 真是. 现在 scoped 属性和 Shadow DOM 只有 Chrome 实现了
http://css-tricks.com/saving-the-day-with-scoped-css/
http://html5doctor.com/the-scoped-attribute/
http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/
http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
... 文章老长, 我只读了大概..
用编译的方案, 能不能按需要生成唯一的 id 来对 CSS 作用域形成限定, 模拟 scoped 属性
Shadow DOM 就只能用 <iframe> 吧.. <iframe> 成本高, 但貌似啥都能解决...

[island205]

@jiyinyiyong 考虑下，兼容的方案。我们先讨论下CSS的模块化。

[tiye]

@island205 隔离 CSS 的方案我只知道 <iframe>.. 也要求 HTML 用 <iframe> 隔离
https://github.com/jiyinyiyong/banyan/blob/iframe/action/main.coffee
相应的就是任何模块都需要用 <iframe> 包裹, 允许窗口嵌套
如果这样, 现在的常用 JS 模块化方案都不够用了, 需要"子窗口<=>父窗口"做消息的封装

[island205]

@jiyinyiyong 使用iframe应该不行。是不是可以做一些规则，来隔离CSS？

[tiye]

@island205 想不出来了. 一般约束 CSS 选择器用 id class 能做到,
问题在模块里包含模块时, 子模块容易被上层的模块的样式作用到, 还有太松散的选择器也会对子模块作用
... 有没有对每个元素 CSS 做 reset 的方案的..
能阻断 CSS 选择器过程的, 我了解过的只有 Shadow DOM 和 iframe..
你说的规则, 指的是什么? 是要约束选择器的使用么

CSS reset 的方法没有尝试过, 这样能不能足够好地隔离..
http://snipplr.com/view/7438/

[kebot]

@island205

html很简单，主干的html是后台生成的，所有不存在模块化的问题，需要模块化的是html模板，模板的话很容易编译成js文件（比如，handlebars就可以编译成amd模块，hogan可以编译mustache，jade也是支持预编译的）并被当成js模块来处理。

现在主流的css模块化方案是基于css预编译器的（比如less，scss和stylus), 而这些css预编译器一般是支持 require类似的语法的。

现在主要的问题是主流的模块加载器是不支持 css 的依赖匹配，所以不能在写js模块的时候定义需要的css文件。（requirejs应该会有插件来干这件事，但终非正途。）

非amd加载器比如 do.js 是支持css和图片等静态资源的按需加载的，但是css文件一般都是优于js文件预加载，所以一般的做法是在后台的模板引擎上做文章。

我在做bubbler的时候，为了方便起见，直接把所有要用到的css编译成一个文件，对于小项目来说比较实用。

我觉得接下来的重点是如何直接用js来管理css依赖（定义一种语法，或者扩展目前的脚本加载器）。

题外话：两位一位是我校友（一个团队的），一位也比较熟识了，可见贵圈真小。

[tiye]

@kebot coffee 中文圈子好小...
如果可能, 我挺想要个一劳永逸的方案, 前端代码完全编译发送到浏览器, 再用调试工具原样展开
不过现在卡在隔离 CSS 代码上,,

---

刚翻到这个文档, "Introduction to Web Components",
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
模块化的方案这里考虑很多, 可惜大大都没有实现
还有一个比较清晰详细的幻灯片, 讲了怎么用,, 表示英文太 😅
http://html5-demos.appspot.com/static/webcomponents/index.html
代码: https://github.com/ebidel/html5demos/tree/master/html5-demos.appspot.com/static/webcomponents

[tiye]

转了 TJ 两个视频到土豆, 细看了操作过程, 操作过程没问题
Web Components - Introduction [12:47]
Creating components [14:08]
麻烦的是对应的 SourceMap 支持始终没找到文档, 莫非真没实现..
另外 commonjs-everywhere 还没文档, 给的例子只能跑单个文件, 也没说合并文件的事情 - -!
还是脑子发热了.... - -!

昨天看到 https://spmjs.org/ , 有机会问了下, 第二版似乎快发布了
https://twitter.com/lepture/status/310338234746011648
Grunt + SeaJS 方案... 还是 CSS 和 HTML 怎么重用的问题...
看到 TJ 在 Twitter 上讨论 Rework 的, 顺手标记了吧...
https://twitter.com/tjholowaychuk/status/307325521082085376