我選擇了sproutcore作爲Ember從sproutcore分叉之前的框架。我無法確定應該走哪條路，並且由於分裂造成的努力顯然被稀釋而感到有些沮喪 - 這很少會導致更好的事情發生。 Sproutcore 2.0（現在的Ember）的努力似乎正朝着其他javasript組件（jQuery）的模塊化和重用的正確方向發展，然而，從外部來看，它真的不清楚爲什麼這兩個努力必須分裂......不能，我們有模塊化代碼，還有一個小部件庫模塊？Sproutcore和Ember之間的差異
的主要問題是：
作爲一個擁有Sproutcore應用程序和Ember應用程序接近產品發佈的人，我會採取刺探您的問題（爲了清晰起見而重新排序）。以下所有內容都是我在沒有內幕知識的情況下觀察到的。有一點是猜測，所以我在這個答案上啓用了維基模式，以便更多的知情人可以糾正細節。
什麼是分裂的歷史？
這裏是我所拼湊起來：
SproutCore的是由查爾斯·喬利的Sproutit的公司在2007年喬莉其收發室產品的基礎上創建的後來加入了蘋果和SproutCore的被用來建立原始的Web應用程序移動我。其任務是重新創建像蘋果和iCal這樣的Mac應用程序的體驗，並且這一努力今天將繼續在Sproutcore上使用iCloud。
Jolley離開蘋果公司，在舊金山組建了一家名爲Strobe的公司，其部分願景是利用Sproutcore。 Strobe的團隊決定Sproutcore並沒有很好地適應許多Web 2.0用例，並且對開發人員來說太過於一無所有，因此他們開始了對Sproutcore 2的努力.Sproutcore 2的目標是模塊化，以及更多的HTML感知方法，可供任何地方的Web開發人員使用。骨幹早期的牽引力是這一分析的一部分。
在努力將Sproutcore代碼庫移向此願景之後，Strobe團隊決定用Sproutcore 2（內部代號琥珀色）重新開始。 Charles編寫了核心Run Loop和鍵值觀察員代碼。 Yehuda Katz和Tom Dale是該項目的主要Strobe開發人員。當時的願景是，Strobe和社區最終將大部分功能從Sproutcore 1.x移植到Sproutcore 2.
頻繁的業務努力並沒有產生希望的結果，公司權衡了它的選擇，最終決定通過Facebook收購Strobe人才。在此之前，包括Katz和Dale在內的一些Strobe員工分手，組建了一家名爲Tilde的新公司。
Tilde決定繼續開發Sproutcore 2，但更改名稱（以Amber.js，然後Ember.js）和項目的目標。他們放棄了與Sproutcore向後兼容的長期目標。他們放棄了對任何類型的視圖控件庫的支持，並專注於HTML/CSS用例，並將數據綁定與Handlebars模板語言緊密結合。
由於頻閃的溶解，SproutCore的1.x中的領導已經從喬利傳給泰勒·基廷，並得到了社會各界重新集中清理SproutCore的1.x中，這是在不舒服的地方了，而當Sproutcore 2的想法即將到來。
這兩項工作的有效區別是什麼？
項目中的相似之處在於它們具有非常相似的對象模型。他們也有類似的財產，觀察員和約束力系統。
Sproutcore包含一個視圖窗口小部件庫，如工具欄，列表視圖，網格視圖，按鈕和主題系統，重點在於通過Javascript定義視圖層以及由庫管理的絕對定位。它在網絡上創建桌面風格的應用程序非常強大。
Ember的佔地面積較小。它與Handlebars緊密集成。它是許多項目的Backbone的替代品。它旨在爲客戶端應用程序提供標準的應用程序體系結構，並消除樣板代碼。
這些差異可能會導致框架分歧，儘管採用相同的核心有一些考慮因素。在這種情況下，Sproutcore會使用Ember的「金屬」庫和其他核心庫）。
什麼是Sproutcore的未來，它現在在哪裏？
此線程與最近的貢獻者的聚會有分鐘。
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
短期藍圖是把重點放在固化營銷材料，演示和代碼庫。該團隊最近發佈了Sproutcore Showcase。關於使用基於Javascript（node.js）的解決方案取代Sproutcore的Ruby構建工具abbot已經達成共識，該解決方案目前正在積極開發之中。還有人希望蘋果等公司的代碼與更頻繁的版本「代碼大小」合併。 Sproutcore 1.8最近發佈。
Ember正在開發成爲sproutcore的完全替代品嗎？
不太可能。 Ember核心團隊明確表示他們無意親自開發這些缺失的功能。社區成員可能會將這些項目作爲單獨的項目開發 - flame.js是迄今爲止最雄心勃勃的嘗試。 Ember的設計選擇使它更容易與jQuery UI等項目集成，因此完整的替換可能需要也可能不需要。
事實上，SproutCore是在查爾斯公司Sproutit創建的，作爲他們Mailroom產品在2007年加入蘋果之前的基礎。除了那個小細節外，+1先生。寫得很好。 – 2012-02-24 20:32:27
謝謝你，羅伊。我已經相應地更新了答案。 – 2012-02-25 00:13:27
感謝您的詳細解釋。 當選擇一個框架外出時，喜歡知道它是穩定的並且有長期的社區支持--jQuery就是一個很好的例子。 這些事件當然是不幸的，並且對Sproutcore和Ember的未來置疑於更加沉悶的努力領域。當然，大多數人需要的是一個小型的模塊化代碼庫和易於使用的UI小部件和主題（可以選擇自定義或將其全部拉出）。 – 2012-03-04 00:59:29
1）官方的線是Sproutcore是爲RIA和Ember.js打算用於「網絡風格」的應用程序。所以，當你看着iCloud認爲Sproutcore，並且當你看到Twitter時，會想到Ember.js。
從技術角度來看，Ember.js專注於更多的模塊化代碼和視圖的所謂「語義模板」。 Sproutcore更加單一。
2）我不確定有人真的知道。如果你看看時間表，查爾斯喬利離開蘋果組建了一家名爲Strobe的公司，該公司開發了一個應用程序開發的全棧平臺。 Strobe聘請了Yehuda Katz和其他人，他們開始致力於減肥SC，以便在移動設備上運行得更好。大約一年後，耶胡達離開成立了蒂爾德公司，一個月之後，Facebook以被廣泛認爲是人才收購的方式購買了Strobe。
因此，你會這樣解釋。
3）這是一個很好的問題。 Recently there was a meetup and several things were discussed。討論的要點是：
可能有其他人，我錯過了
4）絕對不是一個替代品，雖然你可以使用任何框架來建立任何應用程序（這是所有的JavaScript ， 畢竟）。
爲了增加一個快速點，這個週末有一個文檔/網站「衝刺」，讓SC修復一些破壞的事情，並幫助新開發人員用正確的工具快速啓動並運行。你可以在這裏閱讀更多有關衝刺的內容：http://blog.sproutcore.com/sprint-towards-1-8-release/ – 2012-02-24 16:07:18
因此，我花了一點時間閱讀聚會節點並看着Blossom ... Blossom看起來像是正確的方向，但我擔心Blossom會放棄移動/觸摸功能，這讓人擔心任何人都會考慮在2012年放棄移動支持。關於這裏發生了什麼以及觸摸/移動是真的在未來的sproutcore支持？ – 2012-03-04 01:07:30
目前正在構建的工具將編譯開發應用程序，以在任何平臺上本機運行。很明顯，每個平臺都需要單獨實施，但我認爲您可以期待對主要平臺的支持很快。根據我在#blossom IRC中看到的，這些工具將於4月1日發佈。需要注意的是運行時支持需要許可。我建議你在freenode上放下#blossom並開始提問。或者點擊sproutcore google group – hvgotcodes 2012-03-04 02:24:58
我自己有這些問題。每個人都在說，如果你正在用Sproutcore 1.x構建一個類似於桌面的應用程序，那麼應用程序將隨Ember（以前的Sproutcore 2）一起發佈。我認爲這樣的一個部門沒有意義，是不是都是爲了客戶端RIA？對我來說唯一真正的區別是雖然Ember更易於使用，但它仍處於開發階段，並且遺漏了許多功能。 – 2012-02-24 08:43:34