javascript - page - SproutCore vs. Cappuccino
title label html (5)
Además de las diferencias idiomáticas Javascript vs. Objective-J, ¿qué beneficios aporta Cappuccino a SproutCore y viceversa en sus experiencias?
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.
Desde el sitio web de Cappuccino:
"En el otro extremo de los marcos existentes están las tecnologías como SproutCore. Aunque SproutCore se propuso objetivos similares a Cappuccino, adopta un enfoque distintamente diferente. Todavía depende de HTML, CSS, JavaScript, Prototipo y un conjunto completamente nuevo y único. de API. También requiere un software de desarrollo especial y un engorroso paso de compilación. Creemos que este es el enfoque equivocado.
Con Cappuccino, no necesita saber HTML. Nunca escribirás una línea de CSS. Usted nunca ha 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 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 compilación y abstrae completamente el navegador del desarrollador. Mientras que en Sproutcore obtienes herramientas de compilación (un servidor de desarrollo, por ejemplo) y el desarrollador debe estar un tanto al tanto de qué es DOM.
Escribí un artículo de blog exactamente sobre "cappuccino vs. sproutcore". No es una comparación técnica, pero compara otros datos interesantes.
Esta es una pregunta interesante, que ha estado apareciendo 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 las personas observan son las siguientes:
1) Su respectivo conjunto de características
2) Facilidad de uso
3) Apoyo de la comunidad y documentación
Miremos el primer punto - allí conjunto de características respectivas. 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.
Con respecto al lenguaje, creo que es importante que no descartes lo que se está usando (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 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.
Al observar la arquitectura de los dos marcos, ambos analizaron el marco de Cocoa de Apple en busca de orientación / inspiración de una u otra forma. 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 puntos de vista 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 de 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ás renderizando 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 listo para usar. 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, ahora vamos a hablar sobre 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.
Finalmente, 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!
Aclamaciones,
Micro
La respuesta de Michael Cohens prácticamente cubrió todo, ya que era extremadamente detallada.
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 api de tienda de datos mejor que la que tiene el 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 de acuerdo a 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 un buen 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. Visita http://githubissues.heroku.com/ .
A pesar de que no tengo experiencia en Object-C y prefiero la sintaxis de js puro, probablemente me vaya con el cappuccino en mi proyecto actual y espero que Sproutcore tenga una mejor vista de tabla en el futuro.
Me gustaría tocar los comentarios hechos sobre el objetivo-j Michael.
No perderás nada si seleccionas JavaScript en lugar de Object-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 solo una capa 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 puntos tradicional, si lo desea ... Me gusta pensarlo de esta manera: una vez que comienza a escribir un método, en general está escribiendo JavaScript. 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 "puenteo sin cargo" de 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.
Entonces, por ejemplo, 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 pueden ver, estoy usando la sintaxis objetivo-j y la sintaxis js juntas ... Pueden imaginar el poder si esto.
Lo último que quiero exponer, 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 sienten innecesariamente desilusionadas por el objetivo-j como si fuera una bestia monstruosa que llevara tiempo aprender, y mientras que el objetivo-j agrega muchas características increíbles a js, realmente aprenderlas no te llevará a la realidad. es mejor parte de un día si ya estás familiarizado con la programación orientada a objetos, y obviamente si vienes de cacao podrás saltar directamente.