Cortex - 让前端开发轻便而有趣

demo项目: http://cortexjs.github.io/todos.backbonejs/, http://cortexjs.github.io/autocomplete/

欢迎查看demo, 和bootstrap, jquery, backbone这些框架都轻松集成哦

很酷,下次有应用场景时会试一试

重造轮子？看起来不错，但是确定转到spm后就不想折腾其他的了。。

当年TJ说 component 要实现自己的 registry，结果是不得已用了很变态的方式实现了 Semantic Version。

@chemzqm component用github做registry name/repo最后就弄的很复杂，而且在公司里面的生产环境就没法用了，不能直接用github也没法自己搭registry

哈哈，支持一下

这个类似bower吧。

@villadora 我到是觉得 name/repo 挺好的，经常是在用别人模块然后发现需要稍微改点才能更好满足需求，因为break api等原因让人家接受PR不太可性，所以干脆直接fork然后改成自己名很方便。
component 1.0支持bitbucket，也可以比较容易的实现自己的registry，我的实现是第一次从 github把代码拉下来，以后除了 master 的代码都直接从本地读取，只是现在版本管理都交给tag，效率很低，也不容易使用

cortex 能用来配合requirejs或者sea.js来用么？还是说只支持点评自己的模块系统？

@iwege 感谢关注~

其实，无论是 browserify 还是 component，都会默认自带模块系统，因为 requirejs 还是 seajs 做的事情很有限，比如对 [semver ranges](https://github.com/mojombo/semver/issues/113) 的支持，对 [file module](http://nodejs.org/api/modules.html#modules_file_modules) 和 dir 的支持，对 __dirname，__filename 的支持，对 require.resolve 的支持。

当有了包管理器之后，模块加载器其实是不需要存在的，而且用户也不需要写 `define`, `define.amd`. 而且现在生态系统并不好，每个开源项目里面都要去写一大堆 AMD, UMD, *MD，它们基本上是我们平时开发过程中不需要去操心的，事实上，我们只需要跟 nodejs 一样写代码就好了。这也是为什么这些 *MD 一直都只是 proposal。
我们永远希望让开发者写更少的东西。

只有 [Module/1.0](http://wiki.commonjs.org/wiki/Modules/1.0) 是必要的

@pepsin 嘿嘿，谢谢

待过10天左右点评，对 cortext 印象深刻，因为英语不好老是多打一个 t
记得当时是这样， node 起一个服务托管 css/js 。
然后 files:///xx.html 预览，好像没办法直接自动刷新，我做 APP 的，这个只是兼职，所以可能说错了。

@chemzqm 阁下是少有的经常会用包管理的人哪，握个爪。最近正准备写个文章谈谈这个问题。不过从生态环境来看，它会潜在地让用户去制造更多的fork，并且去依赖这些 fork，这个长久来看会有问题的。嘛，而且tj一年前就已经基本上把项目给樱桃哥一个人来维护了，这个才是硬伤 D:

@tinymao 唔，难道是打开方式不对，哪天再来趟点评把，如果是妹子的话手把手教

@AlanZhang 其实 bower 在某种程度上只是一个脚本管理器，把脚本下载到本地，然后让开发者自己搞定后面的事情。另外 bower 并没有用 commonjs，这样一个直接的问题就是，模块间都是用全局变量来交互，这样很糟糕，也因此无法多版本共存。

名字不合适。。。已经被公众默认是 ARM 的商标了。。。

@kaelzhang 我觉得我不关系什么协议的，我只关心运行原理。

从给出的demo来看，你的解决方案按照我比较熟悉的描述就是requirejs的CMD风格， 但是略有不同的是你将__dirname和__filename作为一个参数传递进去。这个倒是不是关键点，不过这种方式却可以简单的解决混淆的问题。这样来看 cortex 只是起了一个server然后将代码包装了一下。把cortex 比作一个简单的express都可以，所以cortex要换成requirejs也相对简单，真正的关键还是在neuron的那套上面的。

按照我的理解，neuron是模块加载，neuron-builder 是模块打包的工具。

不过这里也牵扯出几个问题：
1. 单一模块依赖的第三方模块如何与其他的模块共享，如果采用node 的方式是每个人自带自己的依赖就违反了web领域的优化，唯一命名貌似是唯一的解决方案，但是感觉好麻烦。
2. 非JS层面的依赖无法解决，component 想要解决这个问题，不知道现在解决了没有。
3. 基于前两个问题，怎么解决当前前端共享和打包的问题。


另外neuron-builder 没有针对大小写敏感来设计么？

例如：你的文件名是： c.js，但是在testcase代码里面是：var c = require("./C"); 按照这样的处理结果，如果大小写敏感，应该会直接出错，除非你测试环境都是在windows或者mac非大小写敏感的server上。非大小写敏感的server，虽然会传递script的内容过来，但在requirejs里面，c和C是两个独立的模块（尽管code是一样的）。

另外这个东西还有硬伤：不支持代理。在有代理的公司里面基本上属于不可用状态。

@iwege 关于模块依赖，cortex的方案可以参考博客http://cnblog.ctx.io/post/91333512673/cortex.

非js的依赖其实依赖管理和js的一样已经解决，但非js层面的依赖问题主要在于页面如何按需载入以及如何避免冲突,css里面的资源又如何处理, 这方面实际上大家都还在探索，没有一个满足所有需求的方案。cortex目前也是在管理还依赖的情况下，提供了周边的工具来实现css在html页面的注入。

关于第三点, 不知道共享是指哪个方面，打包现在开发好的cortex项目，本地一个静态服务就可以跑起来，发布打包也就是把cortex install/build之后的项目文件打包好就是一个独立的站点了,比如现在的几个examples都是这么做的。

关于大小写，之前也碰到过，确实需要处理，至于是要像requirejs里面一样是两个独立的，还是统一成小写，这个还希望大家参与讨论, 可以到https://github.com/cortexjs/neuron-builder/issues新建issue.

因为如果是有文件名大小写的不同内容也不同的文件，在windows和mac里面本身这个模块里面的文件就会被自身覆盖, 从而导致出问题。

代理的问题现在还不支持，已经提到issue: https://github.com/cortexjs/neuropil/issues/52

有想法和建议，欢迎提issue～

@villadora 第三点和第一点是有联系的，但是应该不适合web领域。现在所知的模块体系都是源码级别的共享。假设
d
|- a
| |-b
|
|- c
|-b

在源码级别是可以解决的b的依赖重复问题，但是一旦a build成为一个模块，c也同样，那么d在获取ac的时候就依赖了两份b的代码。当然这种主要是针对node-webkit / atom-shell 两个场景下的模块分享问题，而且也算是一个伪命题，因为JS是天然的开源属性...

至于非js依赖，也包含了模板，css，image等，当然都同样不属于web领域...

大小写的问题，最好是两个独立模块，毕竟linux上的server多一点，这种应该只能约束开发规范。只是在windows和非大小写敏感的mac上比较难易调试罢了。

@iwege 所以web领域都没有做套嵌树的模块管理。和node一样的模块管理方式更适合于文件系统，比如node, node-webkit也是这样，不用考虑overhead。像插件更是需要进行模块独立，即使有overhead也是在能不用共享的情况就不使用共享，而自己打包。这个是符合谁使用谁负责的原则的。外层不应该关系内层的实现。

web上的模块管理，cortex都是采用扁平化的，cortex的build的模块也不会包含依赖的重复代码，只会包含自己本身的代码。

d
| - a
| - b
| - c

a依赖于b这个信息都是模块自己申明而不是靠将b整体打包到a中实现, 只要版本兼容，d只会获取a,b,c各一份, 像之前说到的重复就不存在。但这种方式在其他的包管理下会存在冲突的可能，因为b只有一个。

虽然js是开源的，但是每次使用模块都需要用户去自己处理，选择代码甚至修改源码，比如我写d我需要去处理b里面的代码是很奇怪的,就像开发atom的packages的时候如果还要关心别的packages用了哪些依赖一样。

@villadora 嗯，你的解决方案是对的。