Sproutcore和Ember之间的差异 [英] Differences between Sproutcore and Ember

问题描述

我已经选择了萌芽核心作为一个框架，然后Ember从芽菜中分手。我不确定哪种方式去，对于分裂所造成的努力的明显稀释，有点沮丧 - 很少会导致更好的事情。 Sproutcore 2.0（现在的Ember）的努力似乎在其他javasript组件（jQuery）的模块化和重用方面正在朝着正确的方向发展，但从外界看，为什么这两个努力必须分裂，主要问题是：

1. 这两种努力有什么有效的区别？


2. 分裂的历史是什么？


3. 什么是发芽的未来，哪里现在是吗？


4. Ember是否会发展成为一个完全替代芽菜？

解决方案

作为一名拥有Sproutcore应用程序和Ember应用程序的人，靠近生产发布，我会采取刺激您的问题（为了清晰起见重新排序）。以下所有内容都是我所观察到的，没有内部知识。有一点是猜测，所以我已经在这个答案上启用了wiki模式，以便更多的知情人士可以更正细节。

什么是分割？

这是我拼凑在一起的：

SproutCore是由Charles创建的Jolley的公司Sproutit是2007年的Mailroom产品的基础。Jolley后来加入了Apple，Sproutcore被用来构建Mobile Me的原始网络应用程序。该任务是重新创建Mac应用程序（如邮件和iCal）的经验，而今天在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）和社区将最终将Sproutcore 1.x的大部分功能和功能从Sproutcore 2移植到Sproutcore 2。

对于结果，公司权衡其选择权，最终决定通过Facebook收购Strobe人才。在此之前，一些Strobe的员工，包括Katz和Dale，分裂成一个名叫Tilde的新公司。

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

自从解散Sproutcore 1.x的管理员已经从Jolley转到了Tyler Keating，社区已经重新清理Sproutcore 1.x，Sproutcore 2.x在Sproutcore 2的想法即将到来时处于不舒服的地步。 / p>

这两个努力有什么有效的区别？

项目的特点是非常相似的对象模型。他们也有类似的属性，观察者和绑定系统。

Sproutcore包括视图小部件库，如工具栏，列表视图，网格视图，按钮和主题系统，以及重点是通过JavaScript定义视图层，并由库管理绝对定位。在网络上创建桌面式应用程序非常强大。

Ember具有更小的占位面积。它与Handlebars紧密结合。它是许多项目的Backbone替代品。它旨在为客户端应用程序提供标准的应用程序架构，并消除样板代码。

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

Sproutcore的未来是什么？ em>

这个线程距离最近的一个贡献者的聚会数分钟。

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

短期路线图重点是巩固营销材料，演示和代码库。该团队最近发布了 Sproutcore Showcase 。关于使用基于JavaScript（node.js）的解决方案来更换Sproutcore的Ruby构建工具，现在正在积极开发中，有一般共识。还有一个希望减少像苹果这样的公司的代码更少的大合并和更频繁的版本。 Sproutcore 1.8最近发布了。

Ember是否正在发展成为一个完全替代芽菜？

不太可能。 Ember核心团队已经明确表示，他们无意亲自开发这些缺少的功能。社区成员可能会将其作为单独的项目开发 - flame.js 是最有野心的到目前为止。 Ember的设计选择使得它更容易与像jQuery UI这样的项目集成在一起，因此完全替代可能是也可能不是必需的。

I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?

The main questions are:

1. What are the effective differences between the two efforts?
2. What is history of the split?
3. What is sproutcore future, where is it going now?
4. Is Ember going develop to be a complete replacement for sproutcore?

解决方案

As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.

What is history of the split?

Here is what I've pieced together:

SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.

Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.

After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.

Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.

Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.

Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.

What are the effective differences between the two efforts?

The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.

Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.

Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.

Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).

What is Sproutcore's future, where is it going now?

This thread has minutes from the a recent contributor's meetup.

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

The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.

Is Ember going develop to be a complete replacement for sproutcore?

Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.

这篇关于Sproutcore和Ember之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！