#21 楼 @darkbaby123 所有语言都可以不在乎依赖对项目产生的影响，偏偏 JavaScript 不行... 哪天干掉浏览器其实也行，因为别的用 JavaScript 的地方其实也不在乎大小依赖这件事..

#19 楼 @luikore 早些年有人投入 compressor 事业，也不会有 small-focused-module 这种事.. 主要还是那些人在瞎搞事...

我心目中理想的 JavaScript 工程化应该是 Yarn + rollup + small focused modules, 这个估计是办不到了。

所以，我现在还是会用 url download + concat + order 的方式来打包自己的类库，手动 resolve dependencies.

毕竟在做产品的过程中，还是比较关注打包后前端的文件引用的大小，自己控制依赖比打包好后去发现文件为什么这么大成本低多了。

好处就是 yarn.lock 锁定版本，npm 这个问题很严重。

安装上是有很大进步的，有一个 repo 的地方。

总的来说，我觉得没什么大的变化。跟 npm 区别并不大。可以替换 npm 但并不解决本质问题。

yarn 还是解决不了一些最基本的依赖问题，yarn install --flat 的时候有冲突其实你还是无能为力，其实需要用户自己去 resolve dependencies, 这个过程就很麻烦了。而且这个只能靠社区来推动，因为你也处理不了两个包依赖的 underscore 版本不一致类似这样的问题。

真的要解决这个问题，其实应该从本身 npm 的社区的类库入手，像 small focused modules 这种东西，在有新的 ES6 tree-shaking 技术支持的情况下，这里应该像其他语言类库，类似 Ruby 一样变成相对大的类库。这样在打包的时候 resolve dependencies 才有意义。不然装一个 react, 依赖了成百个包。这成百个包都有可能会升级，会依赖。你怎么 resolve dependencies… 基本是不可能的任务。

#7 楼 @huacnlee 看来大家都在用 Go 做些事情。我们主要是在 Docker 的基础上做 PaaS, 周边生态都是 Go, 所以要用。

#8 楼 @lgn21st 重载没啥用，还是需要一个 src 目录。对于有强迫症的人来说受不了... 😖😖😖

GOPATH 就是最大的遗毒...

虽然现在也在用 glide, 但是 src pkg bin 目录简直没法用。

最简单的需求，保证依赖与自己的源码分开。用户可以自定义源码路径。

#20 楼 @mimosa

还在杭州，有时间大家约出来嗨...

#14 楼 @rei

嗯，这个工具和架构是与 Rails 无关的，当初写的时候也不是用在 Rails 上面的，现在我们后端对接的是 Java 平台。

各取所需吧。

#9 楼 @w7938940

去掉 Asset Pipeline, 在启动 rails 的过程中再启动 linner 就好了，可以通过一个 rake 命令挂起来。

在 application.erb 里面直接写最终的 assets 链接就好了，很简单的。

#8 楼 @luikore

服务端更新了 assets 执行 linner build 会生成新的 rev md5 自动更新。

SEO 可以直接走后端渲染，view.hbs 是后端的模板，也可以是 view.erb

sprite 这个只有自己保证了，有一个 issue 是自动生成 x2 和 原始的，不过暂时还没做。

团队氛围真的很重要，也很难培养。珍惜好的团队，有想法就直接加入吧。

#22 楼 @jacarrichan 目录结构是一个最佳实践，没有公开标准。同时这个目录结构也不是固定的，你在 Linner 中可以随意修改。

@rod libxml 需要 brew install 一下，按理来说 rvm 安装的话是没问题的。

#25 楼 @xhj6 Ionic 最大的问题就是选型错误，选择了 Angular...

你可以去 Google: ionic without angular

React 的有 TouchStone.js 不过还未成熟。

Google 出来的东西工业化痕迹都很重。

所以 GWT, Golang, Dart 跟 Angular 都不是那种第一眼就能爱上的东西。(当然第二眼也爱不上

不出意外会到！

创业两年，经常心力交瘁与兴奋万分交替，心情如过山车一般.. 多次想要放弃，一度认为自己是不是抑郁了，但庆幸自己坚持下来了。

创业很难，尤其作为传统的程序员，很多都不是自己的长项，需要学习跟历练。因为除了做好产品，还有太多别的事情也需要处理，但是绝对值得一试。会改变自己很多既有观念。

加油！:plus1: :plus1: :plus1:

#16 楼 @hlxwell 我们没有完全前后端分离，不过前后端公用模板，可以相互切换。有性能问题，就切换到前端渲染。

模板在用 Handlebars

NodeJS 替代了 SpringMVC 和 WebX, 其实这些功能在 Java 里面都能实现。

PS: 这个 Slide 也太水了，前半部分发了无数搞笑图，下半部分啥也没说。还没最后一页 Blog 里面半篇内容多...

键盘是最难拆的组件，非专业人员不要轻易尝试...

可以在淘宝购买键盘组件，很便宜百元级别，然后去最近的大卖场给专业的维修人员修理，支付手工费即可，也是百元...

#5 楼 @yesmeck 是忘记删除 template 了，现在的模板在 lib/simba/templates 里面。不影响 new 出的结果。

#12 楼 @ruohanc

CMD 是一个规范，SeaJS 是一个 CMD 规范的实现。

AMD 也是一个规范，RequireJS 是一个 AMD 规范的实现。

这是两个概念，其实 Linner 里面也有一个 CMD 规范的实现。不过对用户是透明的。

SeaJS 把这个声明暴露给了用户，加上巨复杂的配置。Sigh...

#13 楼 @krazy 下个版本支持 zip/tar 就可以做到了。同样是用 bundle 这种方法，只不过最后拿到的是一个文件夹，而不是一个文件。

以前的依赖一个文件这么写：

bundles:
  jquery.js:
    version: 1.10.2
    url: http://code.jquery.com/jquery-1.10.2.js

依赖一个 zip 或者 tar 可以这么写：

bundles:
  awesome-component:
    version: 1.0
    url: http://code.awesome-component.com/downloads/1.0.zip

这样会默认 install 到 vendor 下面，是一个解压过的文件夹。

#10 楼 @krazy bundle 现在还不能以 component 粒度来依赖。

我们现在的用法是：自己有一套类似 bootstrap 的框架。包含 JavaScript 与 CSS 还有一些前端模板，这些东西被 Linner watch 之后生成 *.js 与 *.css 两个文件。别的项目文件分别在 bundle 里面依赖这两个文件。而依赖这两个文件的项目内部便以 component 的形式继续编写模块。

bootstrap 是同理的，你可以在 bundle 里面依赖 bootstrap 压缩好的 bootstrap.js 与 bootstrap.css 文件，然后用 order 去排序，使他们在最前面就可以了。类似这样：

order:
  - vendor/jquery.js
  - vendor/bootstrap.js
  - ...
  - app.js

... 是 Linner 支持的排序 omit 元素，代表中间的。

下一步准备支持 zip/tar 文件的依赖，就可以解决 component 依赖问题了，实际上现在的前端项目里，依赖管理暂时还不是那么重要。因为人们很在意前端文件的大小，很深层次的依赖会让这个问题变复杂。所以这是 Linner 对待依赖的解决方案。现在工作的很好。

#6 楼 @coderek 按需加载的实用性其实很低，顶多按需 build. 实际上大家再用 requirejs 这类产品的时候最终还是用 r.js 打包了一次。

另外，Linner 和 Component 一样，是将 JavaScript/CSS/HTML 结合起来称之为一个 component. 而不是单纯的 JavsScript. 更进一步，我们将 后端的模板 ( 类似 ERB 也放入前端工程，这样的 component 是完整的。

#5 楼 @ruohanc 用 Java 就代表不能有潮流的 JavaScript 夹沟方案啦？

碰到这种主题就完全把持不住啊，因为这些东西我都玩儿过... 最近前端比较好的解决方案其实是 gulp.