Sproutcore和Ember的区别
在Ember之前，我select了sproutcore作为框架。 我不确定要走哪条路，而且由于分裂导致的努力明显被稀释，有点沮丧，因为很less会导致更好的事情。 Sproutcore 2.0（现在的Ember）的努力似乎正朝着其他javasript组件（jQuery）的模块化和重用的正确方向发展，然而，从外部来看，为什么这两个努力不得不分裂呢？我们有模块化代码，还有一个小部件库模块呢？
主要问题是：
- 这两个努力有什么有效的区别？
- 什么是分裂的历史？
- 什么是sproutcore未来，现在呢？
- Ember正在发展成为一个完全取代sproutcore？
作为一个Sproutcore应用程序和一个Ember应用程序接近产品发布的人，我会采取一个刺你的问题（为了清晰重新sorting）。 以下所有内容都是我所观察到的内部知识。 有一点是猜测，所以我已经在这个答案启用维基模式，以便更多的知情人可以纠正细节。
什么是分裂的历史？
这是我拼凑在一起的：
SproutCore由Charles Jolley的Sproutit公司创build，作为其2007年Mailroom产品的基础。Jolley后来join苹果，Sproutcore被用来为Mobile Me构build原始的networking应用。 其任务是重新创build像苹果和iCal这样的Mac应用程序的体验，而这一努力将继续在Sproutcore上使用iCloud。
Jolley离开了苹果公司，在旧金山组build了一家名为Strobe的公司，其目标是部分利用Sproutcore。 Strobe的团队认为Sproutcore并不适合许多Web 2.0用例，对于开发人员来说太多了，所以他们开始了对Sproutcore 2的努力.Sproutcore 2的目标是模块化，还有更多的HTML感知方法，可供任何地方的Web开发人员使用。 骨干早期的牵引是这个分析的一部分。
在努力将Sproutcore代码库移向这个愿景之后，Strobe团队决定用Sproutcore 2（内部代号Amber）重新开始。 Charles编写了核心Run Loop和键值观察者代码。 Yehuda Katz和Tom Dale是该项目的领先Strobe开发人员。 当时的想法是Strobe和社区最终将大部分function从Sproutcore 1.x移植到Sproutcore 2。
频频的业务努力没有产生希望的结果，公司权衡了它的select，最终决定是否收购Facebook的频闪人才。 在此之前，包括Katz和Dale在内的一些Strobe员工分手，组build了一家名为Tilde的新公司。
蒂尔德决定继续开发Sproutcore 2，但更改名称（Amber.js，然后Ember.js）和项目的目标。 他们放弃了与Sproutcore向后兼容的长期目标。 他们放弃了对任何types的视图控件库的支持，并将注意力集中在与Handlebars模板语言紧密集成的HTML / CSS用例上。
自Strobe解散以来，Sproutcore 1.x的pipe理权已经从Jolley转移到了Tyler Keating，并且社区重新关注了Sproutcore 1.x的清理，Sproutcore 1.x在Sproutcore 2的想法中处于一个不舒服的地方正在逼近。
这两个努力有什么有效的区别？
项目中的相似之处在于它们具有非常相似的对象模型。 他们也有类似的财产，观察者和约束力系统。
Sproutcore包含一个视图小部件库，如工具栏，列表视图，网格视图，button和主题系统，重点在于通过Javascript定义视图图层和由库pipe理的绝对定位。 在networking上创build桌面风格的应用程序非常强大。
灰烬的占地面积较小。 它与Handlebars紧密集成。 对许多项目来说，它是Backbone的替代品。 它旨在为客户端应用程序提供标准的应用程序体系结构，并消除样板代码。
这些差异可能会导致框架的分歧，尽pipe采取同样的核心也有一些考虑。 在这种情况下，Sproutcore会使用Ember的“金属”库和其他核心库）。
什么是Sproutcore的未来，现在呢？
这个线程有最近的贡献者的聚会的分钟。
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
短期路线图是关注于巩固营销材料，演示和代码库。 该团队最近发布了Sproutcore Showcase 。 关于使用基于Javascript（node.js）的解决scheme取代现有的Sproutcore的Ruby构build工具abbot（目前正处于积极的开发阶段）已经达成共识。 苹果等公司的代码和更频繁的版本之间的代码合并也越来越less。 Sproutcore 1.8最近被释放。
Ember正在发展成为一个完全取代sproutcore？
不见得。 Ember核心团队明确表示，他们无意亲自开发这些缺失的function。 社区成员可能会将这些项目作为单独的项目进行开发 – flame.js是迄今为止最雄心勃勃的尝试。 Ember的deviseselect使得与jQuery UI等项目的整合变得更加容易，因此完整的replace可能也可能不需要。
1）官方的线是Sproutcore是用于RIA和Ember.js是为“networking风格”的应用程序。 所以，当你看着iCloud认为Sproutcore，并且当你看Twitter时，会想到Ember.js。
从技术的angular度来看，Ember.js专注于更多的模块化代码和所谓的视图模板。 Sproutcore更单一。
2）我不确定有谁知道。 如果你看时间表，Charles Jolley离开了苹果公司，组build了一个名为Strobe的公司，该公司开发了一个应用程序开发的全栈平台。 Strobe聘请了Yehuda Katz和其他人，他们开始致力于减肥SC，以便在移动设备上运行得更好。 大约一年后，耶胡达离开了蒂尔德公司，一个月后，Facebook买下了被广泛认为是人才收购的Strobe。
所以你会这样解释。
3）这是一个很好的问题。 最近有一次聚会，还讨论了几件事情 。 讨论的要点是：
- SC还活着，踢
- 改进文档（我们已经听到了一段时间）。
- 保留好的部分在SC2的开发中引入了1.4.5的代码，并除去或移动到可选模块其他东西（如模板）
- 新的基于JavaScript的构build工具
- 全新的基于canvas的视图层，叫做Blossom。
- 为SC提供某种基础/公司支持
有可能是我错过了其他人
4）绝对不是替代品，虽然你可以使用任何框架来build立任何应用程序（毕竟这是所有的JavaScript）。
