Różnice między Sproutcore i Emberem

Question

Wyselekcjonowałem sproutcore jako frameworka tuż przed rozwidleniem Ember z kiełków. Nie jestem pewien, którą drogę wybrać, i jestem nieco sfrustrowany widocznym osłabieniem wysiłków spowodowanych fragmentacją - tak rzadko prowadzi to do lepszych rzeczy. Wysiłki Sproutcore 2.0 (obecnie Ember) wydawały się zmierzać we właściwym kierunku modularyzacji i ponownego użycia innych składników javasript (jQuery), jednak z zewnętrznego spojrzenia nie jest jasne, dlaczego te dwa wysiłki musiały się rozdzielić ... nie mogły t mamy modułowy kod i moduł biblioteki widżetów?

Główne pytania to:

1. Jakie są skuteczne różnice między tymi dwoma wysiłków?
2. Jaka jest historia podziału?
3. Co to jest przyszłość kiełków, dokąd zmierza?
4. Czy Ember rozwija się jako kompletny zamiennik kiełków?

Answer 1

Jako osoba, która ma zarówno aplikację Sproutcore, jak i aplikację Ember w pobliżu premiery produkcyjnej, wezmę pod uwagę twoje pytania (ponownie uporządkowane dla jasności). Wszystkie poniższe informacje są tym, co zaobserwowałem bez wewnętrznej wiedzy. Trochę to spekulacja, więc w tej odpowiedzi włączam tryb wiki, aby bardziej poinformowani ludzie mogli poprawiać szczegóły.

Czym jest historia podziału?

Oto co mam poskładane:

sproutcore został stworzony przez Charlesa Jolley spółką Sproutit jako podstawę swojego produktu Mailroom w 2007 Jolley później dołączył do Apple i sproutcore użyto do budowy oryginalnych aplikacji internetowych dla Mobile Me. Mandat polegał na odtworzeniu doświadczeń aplikacji Mac, takich jak Mail i iCal, i ten wysiłek jest kontynuowany na Sproutcore już dziś dzięki iCloud.

Jolley opuścił firmę Apple i założył firmę o nazwie Strobe w San Francisco z wizją, która ma na celu wzmocnienie Sproutcore. Zespół w Strobe zdecydował, że Sproutcore nie pasuje do wielu przypadków użycia Web 2.0, i był zbyt dużym popisem dla programistów, więc zainicjowali wysiłek w kierunku Sproutcore 2. Cele Sproutcore 2 to modułowość i bardziej oparte na HTML podejście, które byłoby bardziej dostępne dla twórców stron internetowych na całym świecie. Wczesna trakcja kręgosłupa była częścią tej analizy.

Po starcie, aby przesunąć bazę kodów Sproutcore w kierunku tej wizji, zespół Strobe postanowił zacząć od nowa z Sproutcore 2 (wewnętrzna nazwa kodowa Amber). Charles napisał rdzeń pętli Run and key-value observer code. Yehuda Katz i Tom Dale byli głównymi twórcami Strobe w projekcie. Wizja w tamtym czasie polegała na tym, że Strobe i społeczność ostatecznie przejrzały większość funkcji i funkcjonalności od Sproutcore 1.x do Sproutcore 2.

Starania biznesowe stroboskopu nie przyniosły oczekiwanych rezultatów, a firma rozważyła swoje opcje, ostatecznie decydując się na przejęcie talentu Strobe przez Facebooka. Zanim to się stało, wielu pracowników Strobe, w tym Katz i Dale, oddzieliło się, tworząc nową firmę o nazwie Tilde.

Firma Tilde postanowiła nadal rozwijać Sproutcore 2, ale zmieniła nazwę (na Amber.js, a następnie Ember.js) i cele projektu. Zrzucili długoterminowe cele kompatybilności wstecznej z Sproutcore. Zrzekli się wsparcia dla dowolnego rodzaju biblioteki widżetów widoków i skupili się na przypadku użycia HTML/CSS przy ścisłej integracji powiązania danych z językiem szablonów Handlebars.

Od czasu rozwiązania Strobe, zarządzanie Sproutcore 1.x przeszło z Jolley do Tylera Keatinga, a społeczność ponownie skupiła się na czyszczeniu Sproutcore 1.x, które przez jakiś czas znajdowało się w niewygodnym miejscu, gdy pojawił się pomysł Sproutcore 2.

Jakie są skuteczne różnice między tymi dwoma działaniami?

Podobieństwa w projektach polegają na tym, że mają bardzo podobne modele obiektów. Mają podobną własność, obserwatora i systemy wiążące.

Sproutcore zawiera bibliotekę widżetów widoku, takich jak paski narzędzi, widoki list, widoki siatki, przyciski i system motywów, a także nacisk na definiowanie warstwy widoku za pomocą Javascript i pozycjonowanie bezwzględne zarządzane przez bibliotekę. Jest bardzo wydajny do tworzenia aplikacji na komputery w Internecie.

Ember ma mniejszą powierzchnię. Posiada ścisłą integrację z kierownicą. Jest to alternatywa dla Backbone dla wielu projektów. Ma na celu zapewnienie standardowej architektury aplikacji dla aplikacji klienckich i wyeliminowanie kodu standardowego.

Różnice te najprawdopodobniej doprowadzą do różnic między ramami, choć rozważano przyjęcie tego samego rdzenia. W tym scenariuszu Sproutcore użyłby "metalowej" biblioteki Ember i być może innych podstawowych bibliotek).

Co to jest przyszłość Sproutcore, dokąd zmierza?

Wątek ten zawiera minuty od spotkania z ostatniego współtwórcy.

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

Krótkoterminowa drogowa jest skupienie się na utrwalenie materiałów marketingowych, dema i codebase. Zespół niedawno wydał Sproutcore Showcase. Istnieje powszechna zgoda co do zamiany opata, narzędzi budowania Ruby dla Sproutcore, z rozwiązaniem opartym na Javascript (node.js), które jest obecnie aktywnie rozwijane. Istnieje również potrzeba mniejszej "dużej" integracji kodu z firm takich jak Apple i coraz częstszych wydań. Sproutcore 1.8 został niedawno wydany.

Czy Ember rozwija się jako kompletny zamiennik dla kiełków?

Nie prawdopodobne. Główny zespół Ember nie miał wątpliwości, że nie zamierza osobiście opracowywać brakujących funkcji. Jest możliwe, że członkowie społeczności mogą rozwijać te projekty jako osobne projekty - do tej pory najbardziej ambitną próbą jest flame.js. Wybory projektów Ember ułatwiają integrację z projektami takimi jak jQuery UI, więc pełna wymiana może być konieczna lub nie.

Answer 2

1) Oficjalna linia to Sproutcore przeznaczona dla aplikacji RIA, a Ember.js jest przeznaczona do aplikacji typu "web-style". Kiedy więc spojrzysz na iCloud, pomyśl o Sproutcore i kiedy spojrzysz na Twitter, pomyśl o Ember.js.

Z technicznego punktu widzenia Ember.js koncentruje się na bardziej modularnym kodzie i tzw. Szablonach semantycznych dla widoków. Sproutcore jest bardziej monolityczny.

2) Nie jestem pewien, czy ktoś naprawdę wie. Jeśli spojrzeć na linię czasu, Charles Jolley opuścił Apple, aby utworzyć firmę o nazwie Strobe, która stworzyła platformę do tworzenia aplikacji na pełnym stosie. Strobe zatrudnił Yehudę Katza i innych, którzy zaczęli pracować nad odchudzaniem SC, aby lepiej działał na urządzeniach mobilnych. Po około roku Yehuda odszedł, by założyć firmę Tilde, a miesiąc później Facebook kupił Strobe w tym, co powszechnie uważa się za nabycie talentów.

Przetłumacz tak, jak chcesz.

3) To doskonałe pytanie. Recently there was a meetup and several things were discussed. Główne punkty omawiane były:

• SC jest wciąż żywa
• Poprawa dokumentacji (zostaliśmy słysząc, że za chwilę).
• Utrzymuj dobre części kodu, który został wprowadzony wpis 1.4.5 w rozwoju SC2 i pozbyć się lub przejść do opcjonalnych modułów innych rzeczy (jak Templates)
• nowych javascript oparte narzędzi budowania
• całkowicie nowy płótnie na podstawie warstwy widoku o nazwie Blossom.
• Jakiś fundamentowej/podłożu korporacyjnej dla SC

Istnieją zapewne inni, że brakowało

4) Na pewno nie zastąpienie, chociaż można użyć dowolnego ramy zbudować dowolną aplikację (To wszystko javascript , po wszystkim).