Sproutcore和Ember之间的区别

Question

在Ember从Sproutcore分叉出来之前，我选择了Sproutcore作为我的框架。我现在不确定该走哪条路，对于因分裂而导致的努力分散感到有些沮丧 - 因为很少有这种情况会导致更好的结果。Sproutcore 2.0（现在是Ember）的努力似乎朝着模块化和重用其他JavaScript组件（jQuery）的正确方向发展，但从外部视角来看，两个努力为什么要拆分还不是非常清楚...难道我们不能有模块化的代码，同时也有一个widget库模块吗？

主要问题如下：

1. 这两个项目的有效区别是什么？
2. 它们分裂的历史是什么？
3. Sproutcore的未来在哪里？它现在去哪里了？
4. Ember是否要成为Sproutcore的完全替代品？

- Troy Harvey

---

我自己也有这些问题。每个人都说，如果你正在构建类似桌面应用程序的应用，请选择Sproutcore 1.x；如果是Web应用程序，请选择Ember（之前是Sproutcore 2）。我认为这样的划分没有意义，它们都旨在用于客户端RIA。对我来说唯一的真正区别是，虽然Ember更容易使用，但它仍在开发中，缺少很多功能。 - Panagiotis Panagi

Answer 1

作为一个即将推出Sproutcore应用和Ember应用的人，我会尝试回答你的问题（为了更清晰地表达，我重新排列了问题顺序）。以下所有内容都是我从外部观察到的，没有内部知识。其中一部分是猜测，因此我在这个答案上启用了wiki模式，以便更有经验的人可以纠正细节。

“分裂”的历史是什么？

以下是我所搜集到的信息：

SproutCore是由Charles Jolley的公司Sproutit于2007年创建的，作为他们的Mailroom产品的基础。后来，Jolley加入了苹果公司，Sproutcore被用来构建Mobile Me的原始Web应用程序。任务是重新创建像Mail和iCal这样的Mac应用程序的体验，这项工作今天仍在Sproutcore上通过iCloud进行。

Jolley离开苹果公司，与他人在旧金山创立了一家名为Strobe的公司，其中一部分愿景是要利用Sproutcore。然而，Strobe团队认为Sproutcore在许多Web 2.0用例中并不够好，并且对于开发者来说过于全面，因此他们开始着手开发Sproutcore 2。Sproutcore 2的目标是模块化以及更加注重HTML的方法，这将更容易地被Web开发人员所接受。Backbone的早期使用也是这项分析的一部分。

经过努力将Sproutcore代码库向这个方向移动后，Strobe团队决定重新开始开发Sproutcore 2（内部代号为Amber）。Charles编写了核心Run Loop和关键值观察器代码。Yehuda Katz和Tom Dale是该项目的主要Strobe开发人员。当时的愿景是，Strobe和社区最终会将大多数Sproutcore 1.x的功能迁移到Sproutcore 2上。

Strobe的业务努力没有产生预期的结果，公司权衡了各种选择，最终决定由Facebook收购Strobe的人才。在此之前，包括Katz和Dale在内的许多Strobe员工分裂出去，成立了一个名为Tilde的新公司。

Tilde决定继续开发Sproutcore 2，但更改了名称（分别为Amber.js和Ember.js）和项目目标。他们放弃了与Sproutcore的向后兼容的长期目标。他们放弃了对任何类型的视图小部件库的支持，并专注于HTML/CSS用例，并将数据绑定紧密集成到Handlebars模板语言中。

自从Strobe解散以来，Sproutcore 1.x的管理权已从Jolley移交给Tyler Keating，并且社区重新关注清理Sproutcore 1.x，在Sproutcore 2的想法出现时，它一度处于尴尬的境地。

这两个项目的有效区别是什么？

这些项目的相似之处在于它们拥有非常相似的对象模型。它们也具有类似的属性、观察者和绑定系统。

Sproutcore包括一个视图小部件库，如工具栏、列表视图、网格视图、按钮和主题系统，重点是通过Javascript定义视图层，并由库管理绝对定位。它非常适用于在Web上创建桌面风格的应用程序。

Ember具有较小的占用空间。它与Handlebars紧密集成。对于许多项目来说，它是Backbone的替代品。它旨在为客户端应用程序提供一个标准的应用程序架构，并消除样板代码。

这些差异可能会导致框架发生分歧，尽管已经考虑采用相同的核心。在那种情况下，Sproutcore将使用Ember的"metal"库以及其他核心库）。

Sproutcore的未来是什么，现在它的发展方向是什么？

这个帖子记录了最近一次贡献者聚会的会议内容。

https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#

短期路线图是专注于巩固市场推广材料、演示和代码库。团队最近发布了Sproutcore Showcase。有普遍一致的意见要用基于Javascript（node.js）的解决方案取代Ruby构建工具abbot，该方案目前正在积极开发中。还希望较少由苹果等公司进行的“大规模”代码合并，并更频繁地发布版本。Sproutcore 1.8 最近发布。 Ember是否会发展成Sproutcore的完全替代品？ 不太可能。Ember核心团队已经明确表示他们没有个人开发这些缺失功能的意图。社区成员有可能将其作为单独的项目开发，flame.js是迄今为止最雄心勃勃的尝试。Ember的设计选择使其更容易与类似jQuery UI的项目集成，因此可能需要或不需要进行完全替换。

- Luke Melia

---

实际上，SproutCore是在Charles所在的公司Sproutit于2007年创建的，作为他们的Mailroom产品的基础，而在Charles加入苹果之前。除此之外，+1细节没问题。写得很好。 - Roy Daniels

谢谢你的纠正，Roy。我已经相应地更新了答案。 - Luke Melia

感谢详细的解释。在选择框架时，人们希望知道它是稳定的，并且有长期的社区支持 - jQuery就是一个很好的例子。这些事件确实很不幸，在更多努力的领域中，它们对Sproutcore和Ember的未来产生了怀疑。当然，大多数人想要的是既有小型模块化代码库，又有易于使用的UI小部件和主题（可自定义或完全删除）。 - Troy Harvey

@TroyHarvey，两个项目的团队都非常有才华，我个人认为分裂和分叉对两个项目的未来是一件好事。它为项目的目标带来了清晰度，我特别钦佩自从分裂以来涌现出来的Ember社区。我不认为我会同意你的“当然，大多数人想要的是…”这种说法。人们想要什么，甚至我个人想要什么，在不同的项目中变化很大。 - Luke Melia

@Luke。我在“大多数人”的陈述中并不是想显得自命不凡。相反，似乎这些目标并不是互相排斥的。您可以干净地重新设计它，使其由可选组件构建，并且其中一个组件提供Sproutcore当前提供的UI层。然后，每个人都可以选择在其项目中使用哪些组件。但是，越来越多的阅读材料表明，资金和资源可能是分裂的真正原因，而不是软件理念。 - Troy Harvey

Answer 2

1）官方说法是Sproutcore适用于RIA，而Ember.js适用于“Web风格”的应用程序。因此，当您查看iCloud时，请考虑Sproutcore；当您查看Twitter时，请考虑Ember.js。

从技术角度来看，Ember.js专注于更模块化的代码和所谓的“语义模板”来处理视图。而Sproutcore则更加庞大。

2）我不确定是否有人真正知道。如果您查看时间线，Charles Jolley离开苹果公司成立了一家名为Strobe的公司，该公司开发了一个完整的应用程序开发全栈平台。Strobe雇佣了Yehuda Katz和其他人，他们开始精简SC，以便在移动设备上运行得更好。大约一年后，Yehuda离开成立了Tilde公司，一个月后Facebook收购了Strobe，这被广泛认为是人才收购。

因此，您可以按照自己的理解来解释。

3）这是一个很好的问题。最近有一个聚会，讨论了几个重点问题。讨论的关键点包括：

• SC仍然活跃并且发展迅速。
• 改进文档（我们听到这个建议已经有一段时间了）。
• 保留在SC2开发后1.4.5版本引入的优秀代码部分，并且将其他内容（如模板）移除或者放入可选模块中。
• 新的基于JavaScript的构建工具。
• 全新的基于canvas的视图层，名为Blossom。
• 某种形式的基础/公司支持来支持SC。

可能还有其他我没有提到的方面。

4) 绝对不是替代品，尽管你可以使用任何框架来构建任何应用程序（毕竟都是JavaScript）。

- hvgotcodes

---

只是想补充一下，这个周末有一个文档/网站“冲刺”，旨在帮助SC修复一些损坏的东西，并帮助新开发人员快速上手使用正确的工具。您可以在此处阅读更多关于冲刺的信息：http://blog.sproutcore.com/sprint-towards-1-8-release/ - Topher Fangio

所以我花了一些时间阅读meetup节点并查看Blossom... Blossom看起来是正确的方向，但我担心Blossom将放弃移动/触摸功能的说明，这令人震惊，因为在2012年有人会考虑放弃移动支持。对于sproutcore未来是否真正支持触摸/移动，您有什么想法吗？ - Troy Harvey

目前正在开发工具，可以将blossom应用程序编译成在任何平台上本地运行。显然，每个平台都需要单独实现，但我认为你可以很快期待主要平台的支持。从我在#blossom IRC中看到的情况来看，这些工具将于4月1日发布。需要注意的是，运行时支持将需要许可证。我建议你访问freenode的#blossom或加入sproutcore谷歌小组并开始提问。 - hvgotcodes