Como alguien que tiene tanto una aplicación Sproutcore como una aplicación Ember cerca de un lanzamiento de producción, responderé a sus preguntas (reordenándolas para mayor claridad). Todo lo que sigue a continuación es lo que he observado sin ningún conocimiento interno. Un poco es especulación, así que habilité el modo wiki en esta respuesta, para que las personas más informadas puedan corregir los detalles.
¿Qué es la historia de la división?
Esto es lo que he monté:
SproutCore fue creado por Charles Jolley empresa Sproutit como la base de su producto en 2007. Sala de correo Jolley tarde se unió a Apple y SproutCore se utilizó para construir las aplicaciones web originales para Mobile Me. El mandato fue recrear la experiencia de las aplicaciones de Mac como Mail e iCal, y ese esfuerzo continúa en Sproutcore hoy con iCloud.
Jolley dejó Apple y formó una compañía llamada Strobe en San Francisco con una visión en parte para aprovechar Sproutcore. El equipo de Strobe decidió que Sproutcore no encajaba bastante en muchos casos de uso de Web 2.0, y era una propuesta demasiado completa para desarrolladores, por lo que iniciaron un esfuerzo hacia Sproutcore 2. Los objetivos de Sproutcore 2 fueron la modularidad , y un enfoque más consciente de HTML que sería más accesible para los desarrolladores web de todo el mundo. La tracción inicial de Backbone fue parte de este análisis.
Después de luchar para mover la base del código Sproutcore hacia esta visión, el equipo Strobe decidió comenzar de nuevo con Sproutcore 2 (nombre clave interno Amber). Charles escribió el núcleo Run Loop y el código del observador clave-valor. Yehuda Katz y Tom Dale fueron los desarrolladores principales de Strobe en el proyecto. La visión en ese momento era que Strobe y la comunidad conquistarían la mayoría de las características y funcionalidades de Sproutcore 1.x a Sproutcore 2.
Los esfuerzos de Strobe no daban los resultados esperados, y la compañía sopesó sus opciones, finalmente decidiendo sobre una adquisición de talento de Strobe por parte de Facebook. Antes de que esto sucediera, varios empleados de Strobe, incluidos Katz y Dale, se separaron para formar una nueva compañía llamada Tilde.
Tilde decidió seguir desarrollando Sproutcore 2, pero cambió el nombre (a Amber.js y luego a Ember.js) y los objetivos del proyecto. Dejaron caer objetivos a largo plazo de compatibilidad con Sproutcore. Dejaron de admitir cualquier tipo de biblioteca de widgets de visualización y se centraron en el caso de uso de HTML/CSS con una estrecha integración de enlace de datos con el lenguaje de plantillas de Handlebars.
Desde la disolución de Strobe, la administración de Sproutcore 1.x ha pasado de Jolley a Tyler Keating, y la comunidad se ha centrado en la limpieza de Sproutcore 1.x, que estuvo en un lugar incómodo durante un tiempo cuando el la idea de Sproutcore 2 se avecinaba.
¿Cuáles son las diferencias efectivas entre los dos esfuerzos?
Las similitudes en los proyectos son que presentan modelos de objetos muy similares. También tienen una propiedad similar, un observador y sistemas vinculantes.
Sproutcore incluye una biblioteca de widgets de visualización como barras de herramientas, vistas de lista, vistas de cuadrícula, botones y sistema de temas, y un enfoque en definir la capa de vista mediante Javascript y el posicionamiento absoluto administrado por la biblioteca. Es muy potente para crear aplicaciones de escritorio en la web.
Ember tiene una huella más pequeña. Presenta una estrecha integración con manubrios. Es una alternativa a Backbone para muchos proyectos. Su objetivo es proporcionar una arquitectura de aplicaciones estándar para las aplicaciones del lado del cliente y eliminar el código repetitivo.
Esas diferencias probablemente darán lugar a que los marcos diverjan, aunque se ha considerado adoptar el mismo núcleo. En ese escenario, Sproutcore usaría la biblioteca "metálica" de Ember y quizás otras librerías principales).
¿Cuál es el futuro de SproutCore, dónde va ahora?
Esta discusión tiene minutos de la quedada de un colaborador reciente.
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
La hoja de ruta a corto plazo es centrarse en la solidificación del material de marketing, demostraciones y código base. El equipo lanzó recientemente el Sproutcore Showcase. Existe un consenso general sobre el reemplazo de abbot, las herramientas de compilación de Ruby para Sproutcore, con una solución basada en Javascript (node.js), que ahora se encuentra en desarrollo activo. También hay un deseo de fusiones "grandes" de código de compañías como Apple y lanzamientos más frecuentes. Sproutcore 1.8 fue lanzado recientemente.
Está Ember va a desarrollar para ser un reemplazo completo para SproutCore?
No es probable. El equipo central de Ember ha dejado en claro que no tienen la intención de desarrollar personalmente esas características faltantes. Es posible que los miembros de la comunidad puedan desarrollarlos como proyectos separados: flame.js es el intento más ambicioso hasta el momento. Las opciones de diseño de Ember hacen que sea más fácil integrarse con proyectos como jQuery UI, por lo que un reemplazo completo puede o no ser necesario.
Tengo esas preguntas yo mismo. Todo el mundo está diciendo que, si estás construyendo una aplicación de escritorio, ve con Sproutcore 1.x, para una aplicación web ve con Ember (anteriormente Sproutcore 2). Creo que una división como esa no tiene sentido, ¿acaso no están destinados a la RIA del lado del cliente? La única diferencia real para mí es que, aunque es más fácil trabajar con Ember, todavía está en desarrollo y no tiene muchas funciones. –