Además de las diferencias idiomáticas Javascript vs. Objective-J ¿Qué beneficios aporta Cappuccino sobre SproutCore y viceversa en sus experiencias?SproutCore vs. Cappuccino
En términos de un pronóstico a largo plazo, ¿SproutCore es más "compatible" que Cappuccino porque está respaldado por Apple?
Estoy tratando de elegir entre los dos. Estoy familiarizado con JavaScript y Objective-C.
Esta es una pregunta interesante, que ha aparecido con bastante frecuencia en varios grupos de mensajes, twitter, e incluso IRC. Hay un par de maneras de evaluar SproutCore versus Cappuccino, pero, tal vez, algunas de las habilidades inmediatas que la gente observa son las siguientes:
1) Su característica respectiva establece
2) Facilidad de uso
3) El apoyo comunitario y documentación
Veamos el primer punto - no conjunto de características correspondiente. Por "conjunto de características" hay un par de maneras de verlo. De la cantidad de widgets de UI que tienen; el soporte fundamental para conectar cosas y comunicarse con algún tipo de back-end; el enfoque arquitectónico general del marco, aunque no necesariamente una "característica", pero aún importante; y, sí, incluso el idioma que puedes usar.
En cuanto al idioma, creo que es importante que no descarte lo que se está utilizando (JS versus Obj-J). ¿Por qué? Debido a la adopción y de dónde vienes. SproutCore vino desde la perspectiva de que JavaScript es de hecho el lenguaje de la web, por lo que es lo que usas para programar contra el marco. Cuando JavaScript carece de la completitud de OO del lenguaje (herencia adecuada de objetos y objetos, etc.) lo compensa en el marco (por ejemplo, MyApp.Foo = SC.Object.extend ({...})). Cappuccino viene desde un ángulo diferente. Usan Obj-J como una mejora del lenguaje principal para JS con el fin de inyectar características de lenguaje que JS no encuentra; esto en lugar de inyectar esas características del lenguaje directamente en el marco (Cappuccino). Por supuesto, como la gente de Cappuccino ya ha notado antes, todavía puedes usar JS para programar contra Cappuccino, pero, luego, te pierdes lo que Obj-J ofrece. Nota para la comunidad Cappuccino: Por favor corrígeme si me equivoco :-). Finalmente, si eres alguien que ya está familiarizado con Obj-C, entonces Obj-J puede ser más una taza de té. Oye, incluso Sony aparentemente se está subiendo a todo el carro de Obj-C para desarrollarse contra su plataforma móvil :-P.
Mirando la arquitectura de los dos marcos, ambos miraron el marco de Cocoa de Apple en busca de orientación/inspiración de una forma u otra. Cappuccino tomó Cocoa completamente en su corazón y básicamente portó Cocoas API. De nuevo, si vienes de desarrollar aplicaciones en Apple usando Cocoa, entonces probablemente te sientas como en casa. SproutCore por otro lado se inspiró en Cocoa donde se sintió bien. En cuanto a la arquitectura pura, ambos siguen MVC, ambos utilizan enlaces de estilo Cocoa, ambos tienen un mecanismo de almacenamiento de datos, y ambos tienen su propio estilo de representación y composición de widgets/vistas de IU.
La representación de vistas es, para mí, un área particular de importancia. Ambos marcos tienen una cierta abstracción de nivel con el fin de eliminarlo de tratar directamente con CSS y HTML, aunque al final del día tienen que procesar lo que el navegador web finalmente entiende.
En el lado Cappuccino, abstraen completamente CSS y HTML de usted. En su lugar, utiliza las diversas primitivas de representación del marco para "dibujar" sus vistas. Debido a este nivel de abstracción, Cappuccino puede utilizar el mejor enfoque de representación disponible en lugar de acoplarse, en cierta medida, con CSS y HTML.
En cuanto a SproutCore, está apareciendo más cerca del "metal" por así decirlo. Cuando realiza una representación pura de una vista, utiliza un objeto de contexto de representación que proporciona un cierto grado de abstracción, pero, en última instancia, está inyectando directamente HTML y agregando nombres de clase para aplicar CSS. Incluso después de que se visualice su vista y desee manipular ciertas partes de la vista en función de un evento, puede acceder directamente a los elementos DOM y manipular sus propiedades. Dependiendo de dónde vienes, esto puede parecer bueno o malo. Bueno para aquellos que están acostumbrados a trabajar con CSS y HTML y les gusta el control más directo sobre cómo se representan y diseñan las vistas. Es malo si desea generar genéricamente una vista para utilizar el mejor enfoque de renderizado según lo que permita el navegador (HTML/CSS, SVG, lienzo HTML5, etc.). Pero, tenga en cuenta que hay planes futuros para hacer que SproutCore tenga un enfoque de representación más abstracto pero que le permita trabajar directamente con HTML y CSS, si así lo desea. Entonces eventualmente obtendrás lo mejor de ambos mundos.
Ahora, en cuanto a los widgets/vistas de UI de stock, vienen los dos frameworks: ambos tienen mucho que sacar de la caja para que funcione. Botones, etiquetas, listas, vistas segmentadas, botones de opción, desplazadores, etc., están todos allí. Por lo tanto, es seguro decir que estás bien en ambos campos.
Yendo todo el camino de regreso, veamos ahora la facilidad de uso. Para mí, la facilidad de uso se basa en su propia experiencia personal trabajando con JavaScript, HTML, Obj-C, Cocoa, otros frameworks MVC, documentación y soporte de la comunidad. Si nunca has trabajado con Cocoa, o nunca has desarrollado una aplicación tipo mazo o iPad, entonces es justo decir que vas a tener un poco de curva de aprendizaje sin importar el marco que elijas. Dicho esto, lo que no sabe y quiere aprender puede adquirirse a través de la comunidad y los documentos respectivos de cada marco. Ambos tienen comunidades activas en una u otra, por lo que no te quedarás a la intemperie si te quedas atascado en alguna parte. En cuanto a los documentos, Cappuccino, sin duda, tiene la sartén por el mango. Los documentos para SproutCore son deficientes, pero la base del código está al menos completamente comentada. La comunidad de SproutCore está completamente al tanto de los documentos que necesitan ser actualizados, y actualmente es algo que se está tratando, así que sigue comprobando.
Por último, mencionó el pronóstico a largo plazo para los dos marcos. Es de conocimiento público que Motorola compró el marco Cappuccino, por lo que sin duda tiene una gran compañía que respalda su crecimiento y longevidad, o al menos así parece por ahora. En cuanto a Apple y SproutCore, personalmente no puedo hablar por ellos, pero Apple no es el propietario del framework. Hay muchas compañías y varias personas que usan y contribuyen de alguna manera al marco.Eso podría darles a algunas personas y compañías una pausa o incomodidad para aquellos que están mirando a SproutCore debido a la naturaleza más orgánica del desarrollo del framework, pero no lo veo como un problema. Tengo la sensación de que ambos marcos estarán vigentes por mucho tiempo, especialmente ahora que más están buscando desarrollar aplicaciones de escritorio y iPad de próxima generación utilizando marcos de código abierto. Y, oye, la competencia entre los marcos es buena: mantiene a todos en sus respectivos dedos :-).
Espero que esta información te ayude con tu decisión.
Saludos,
Mike
En los últimos 10 meses, ¿cambió su opinión con respecto a los dos marcos anteriores? ¿La representación de SproutCore se volvió más abstracta? ¿La adquisición de Motorola por 280no fue buena para Cappuccino? Estoy tratando de decidir entre los dos en este momento y tu comparación es genial. Entonces me pregunto si ha habido algún cambio significativo que valga la pena mencionar. – SpacyRicochet
Agradecería cualquier actualización de esta respuesta. La situación después de casi 2 años puede ser diferente ahora. –
Motorola pertenece a Google ahora. – asmaier
Desde el sitio web Cappuccino:.
"En el otro extremo de los marcos existentes son tecnologías como SproutCore Mientras SproutCore partió con objetivos similares a Cappuccino, se necesita un enfoque distincly diferente Todavía se basa en HTML,. CSS, JavaScript, Prototype y un conjunto de API completamente nuevo y único. También requiere un software de desarrollo especial y un engorroso paso de compilación. Creemos que este es el enfoque incorrecto.
Con Cappuccino, no necesita saber HTML. Nunca escribirás una línea de CSS. Nunca habrás interactuado con DOM. Solo pedimos a los desarrolladores que aprendan una tecnología, Objective-J y un conjunto de API. Además, estas tecnologías Las tecnologías son implementaciones de las ya conocidas y bien entendidas. Los desarrolladores pueden aprovechar décadas de experiencia colectiva para acelerar realmente el ritmo de creación de aplicaciones web ricas. "
Parece que Cappuccino no tiene/necesita ninguna herramienta de construcción, y abstrae completamente el navegador del desarrollador. Mientras que en Sproutcore obtiene herramientas de compilación (un servidor de desarrollo, por ejemplo) y el desarrollador debe estar al tanto de qué es DOM.
Para ser más específico, Cappuccino no te obliga a construir después de cada cambio, pero incluye un gran conjunto de herramientas diseñadas para optimizar tu producto de lanzamiento final. –
Michael Cohen respuesta cubren casi todo ya que era extremadamente detallado.
He estado luchando con una decisión de las últimas 3 semanas. He leído todo lo que hay en la web sobre ambos frameworks y he escrito muchas muestras de fuentes con ambos y todavía no puedo tomar una decisión. Los siguientes problemas me hacen saltar de un marco a otro y seguir tomando mi decisión más difícil.
Sproutcore tiene una mejor tienda de datos api que la que tiene cappuccino.
Sproutcore hace uso de enlaces mejor que cappuccino actualmente. Cappuccino también tiene soporte para kvc/kvo, pero los enlaces no están totalmente ahí todavía. Por ejemplo, en sproutcore puede implementar la carga incremental con enlaces y ArrayController muy fácilmente donde, por otro lado, en cappuccino no es tan sencillo. Por supuesto, cappuccino ofrece la api de DataStore CPTableView, que es bastante limpia y puede lograr resultados similares simplemente no con enlaces. Es lo que hizo el cacao antes de los datos básicos. Sin embargo, las fijaciones se trabajan constantemente en capuchino.
Cappuccino tiene una mejor vista api según mi gusto personal. Aunque estoy acostumbrado a desarrollar html y DOM, prefiero la idea de abstraer completamente el DOM y deshacerme de css.
Un problema que es realmente importante para mí es la falta de una buena TableView en sproutcore. Actualmente SC.TableView está en alfa y no funciona en absoluto. No sé de una línea de tiempo para la tabla en Sproutcore. Intenté preguntar en el canal irc sproutcore pero no obtuve una respuesta satisfactoria. Cappuccino, por otro lado, tiene una excelente y muy optimizada vista de tabla.
He encontrado más aplicaciones del mundo real escritas en cappuccino que en sproutcore. También hay una muy buena aplicación completa que es proporcionada por cappuccino como una fuente de muestra y es muy útil. Consulte http://githubissues.heroku.com/.
A pesar de que no tengo experiencia en Objective-C y me gusta mucho más la sintaxis de JS puro, probablemente voy a ir con cappuccino en mi proyecto actual y la esperanza SproutCore sale con una mejor vista de tabla en el futuro .
¿Qué te falta en cuanto a la compatibilidad con los enlaces Cappuccino? Debería ser muy posible utilizar un CPArrayController para la carga incremental, así que asegúrese de avisarle a alguien del equipo si hay algún error o peculiaridad que lo detenga. –
Pasé por el grupo cappuccino irc y pregunté cómo implementaría la carga incremental con CPArrayController. Ross boucher me dijo cómo y fue muy útil, pero también me dijo que el soporte aún no está allí y me sugirió que si tuviera una solución funcional con la fuente de datos de la vista de tabla, debería seguir con eso.Para decirte la verdad, estoy de acuerdo con él. La API de TableView está bastante limpia y no tengo problemas para usarla. Lo único que realmente falta es una buena fuente de muestra y documentos. Sproutcore hace que sea un poco más fácil comenzar, ya que los enlaces son los predeterminados. –
Escribí un artículo de blog exactamente sobre "cappuccino vs. sproutcore". No es una comparación técnica, pero compara otros datos interesantes.
El enlace ya no es válido (desde el 24 de abril de 2012). – trudyscousin
me gustaría tocar en los comentarios vertidos sobre el objetivo j-Michael.
No perderá nada si baja a JavaScript en lugar de objetivo-j. En realidad, la distinción es algo difícil de hacer, especialmente en los casos en que tenemos clases puente sin cargo (más sobre eso en un momento).
Objective-j es realmente una envoltura delgada sobre js. Proporciona a la herencia clásica algo que tradicionalmente se ha implementado como función de idioma, que sproutcore implementa como una función de marco, también proporciona importación de código, generación de acceso, alcance estático y soporte para mensajería nula.
Las variables de instancia de Objective-j son accesibles a través de la sintaxis de punto tradicional si quieres ... Me gusta pensarlo así: una vez que comienzas a escribir un método, estás escribiendo JavaScript en su mayoría. Es decir, bucles, variables, funciones, cierres, etc. son solo javascript. No estás perdiendo nada al dejarlo caer, así es exactamente como está diseñado el lenguaje.
Damos un paso más allá mediante el "puente sin cargo" algunas de nuestras clases CPDate, CPArray, CPException, CPString y tal vez más que no recuerdo. El puenteo sin cargo solo significa que un CPArray IS es un array js nativo, y un array js nativo es un CPArray, por lo que puede usar métodos y funciones de ambos países indistintamente.
Así, por ejemplo, se podría hacer:
var foo = [];
[foo addObject:"bar"];
foo.push("2nd push");
var value = foo[0];
var value2 = [foo objectAtIndex:0];
alert(value === value2); //true
Como se puede ver que estoy usando la sintaxis objetivo-J y la sintaxis js juntos ... se puede imaginar el poder si esto.
Lo último que deseo hacer, solo para asegurarme de que no haya confusión: objetivo-j se analiza en el navegador. No es necesario compilarlo de antemano (aunque proporcionamos herramientas de compilación para cuando esté listo para implementar su aplicación).
Creo que algunas personas se ven desorientadas innecesariamente por Objective-j como si fuera una monstruosa bestia que llevara tiempo aprender, y mientras que Object-j agrega muchas funciones increíbles a js, aprenderlas realmente no lo hará realmente te llevará la mayor parte del día si ya estás familiarizado con la programación orientada a objetos, y obviamente si vienes de cocoa podrás saltar directamente.
¿quizás esto debería ser una wiki? no estoy seguro de cómo puedo convertirlo en uno? –
Dada la edad, el número de upvotes, el estado protegido de la pregunta y la popularidad de la respuesta aceptada, una recompensa por "información actualizada" parece más apropiada como una nueva pregunta, como lo haría el contexto proporcionado en dicha recompensa. en esencia, cambia la naturaleza de la pregunta y la respuesta. – Claies