javascript - ¿Sproutcore o Cappuccino para Ruby-on-rails?

rails 5 documentation (3)

Cuando observamos los marcos MVC en funcionamiento, consideramos SproutCore y Cappuccino. Ambos se inspiran en el marco Cocoa de Apple y en Objective C.

Elegimos usar SproutCore porque:

Aprovecha JavaScript de una manera que está alineada con la visión de Douglas Crockford de JavaScript como se describe en JavaScript: las partes buenas .
Buen framework MVC que produce aplicaciones rápidas.
Buena comunidad que respalda el proyecto. Charles Jolley, el padre de SproutCore, trabajó en Apple hasta hace poco, y ahora está trabajando a tiempo completo en SproutCore. Apple aporta una gran cantidad de código a la base de SproutCore, y está haciendo un buen uso de la misma, como lo demuestra el hecho de que iWork.com se construyó utilizando SproutCore.
SproutCore fue diseñado para aplicaciones muy pesadas que tienen miles de elementos, utilizando técnicas optimizadas como el reciclaje de elementos de listas en listas grandes como Google Wave o Google Maps.

No elegimos Cappuccino porque:

Crea un lenguaje diferente en el que ejecutas tu aplicación. Esto no es intuitivo, te hace pensar en Objective J, que proporciona beneficios en el hecho de que no traes malos hábitos de JavaScript, pero descuida el hecho de que JavaScript Es hermoso, extensible y poderoso. (No estoy de ninguna manera ''golpeando'' el Objetivo J, solo proporciona información sobre el hecho de que ejecuta JavaScript en el navegador, no el Objetivo J. Si ejecuta otro idioma en su navegador, puede resultar confuso ya que está interpretando un lenguaje interpretado utilizando un lenguaje interpretado.)
Sin embargo, Objective J y Cappuccino crean aplicaciones hermosas y aprovechan la arquitectura de lenguaje de Objective C, que es un buen modelo para observar en el mundo de MVC.

(Tenga en cuenta que no tengo mucha experiencia en Cappuccino y en Objective J, así que si hago afirmaciones amplias e ingenuas, ¡dímelo!)

Debe mirar más a lo que quiere como un marco de frontend en lugar de lo que "funciona mejor" con Rails. Ambos marcos son buenos. Elegimos SproutCore porque se ajustaba a nuestras necesidades que teníamos para nuestra aplicación más y se ajustaba a nuestra ideología.

Desde la experiencia de vadear a través de la fuente de SproutCore, puedo decir que es bastante independiente de la implementación del servidor que está utilizando. Usamos Prosody, un servidor BOSH escrito en Lua. Quieres usar rieles. SproutCore ofrece esto fuera de la caja:

DataSources para Rails despliega. FYI- DataStores es la capa de modelo de gama baja de SproutCore para enganchar en servicios web. Es muy probable que este sea el punto de encuentro entre su aplicación SproutCore y su aplicación Rails. SproutCore no está realmente destinado a correr en Rails, ¡pero ciertamente puedes hacerlo!
DataStore para servicios RESTful Rails. O cualquier API REST para ese asunto. También permite la inserción del lado del servidor, si es necesario.

En cuanto a su requisito de SECO, ¡todo depende de usted! Puede aprovechar el marco para hacer que su código sea independiente y SECO, o tener dependencias ajustadas y repetir. Cualquiera de los dos marcos es bueno, solo depende de sus necesidades. ¡No te pongas nervioso! ¡Conoce las comunidades y lo que está pasando en cada una de ellas! No mordemos ... demasiado.

Rails es un marco de backend muy bueno que mantiene todo limpio y estructurado.

Supongo que todos ustedes han pensado en hacer lo mismo para la interfaz.

Sproutcore
Capuchino

¿Utiliza uno de estos marcos de MVC javascript para la interfaz con Rails?

En caso de que lo hagas, ¿te sientes satisfecho con eso?

¿Cómo se codificó antes y cómo ha cambiado?

Sproutcore no es más adecuado para Rails porque usa js + css + html, lo que también hace Rails. En Cappuccino no usas ninguno de estos.

Comparta sus pensamientos y experiencias porque estoy verde en este campo y no sé cuál debería usar con Rails.

Solo sé que es mejor tener un marco MVC en la interfaz para obtener la estructura DRY y las mejores prácticas.

Usé Rails con Cappuccino y fue realmente un dolor para mí, aunque esta opinión tiene un fuerte sesgo personal. En primer lugar, simplemente no me siento cómodo con el objetivo-j; No tenía ninguna experiencia previa con objetivo-c y simplemente no me gusta todo el asunto de envío de mensajes de tipo smalltalk (soy más bien un programador orientado a las funciones).

Además, si desea integrar Rails y Cappuccino, se ve obligado a usar JSON en todas partes, así que prepárese para refactorizar casi todo para responder a muchos formatos (es posible que también desee responder a HTML simple, en caso de que el navegador del usuario no funcione con capuchino - o js en general).

Además, estará atascado en problemas por un tiempo bastante más largo de lo habitual, porque no hay muchas aplicaciones y desarrolladores de Rails + Cappuccino (afaik) y todo está mal documentado en Internet.

Por último, pero no menos importante, pasará una gran cantidad de tiempo construyendo cada pieza de la interfaz en object-j; como es de esperar, es mucho más parecido a escribir una interfaz de usuario de cacao que a una web (¡esto es un inconveniente para mí!) y no tengo conocimiento de ningún software / ide para ayudarlo en el proceso (280atlas ha sido anunciado un par de Hace años, pero nunca abierto al uso público).

En resumen, no recomendaría Rails + Cappuccino en esta etapa, a menos que lo esté usando solo por diversión y / o para aprender algo nuevo acerca de la programación web.

Ya lo dije en un comentario, pero me pediste que lo publicara como respuesta, así que aquí está. :)

Rails realmente no le ofrecerá mucho si está creando una aplicación de cliente enriquecido. Los marcos de desarrollo web del lado del cliente generalmente ponen la mayor parte del trabajo duro en el cliente, y utilizan el servidor solo para el almacenamiento y, posiblemente, algunos cálculos pesados (si es necesario). Por lo tanto, personalmente diría que ni siquiera necesitas Rails, podrías usar algo mucho más simple, como Sinatra . Ya que el cliente es la "fuente" de su aplicación, realizará la mayor parte de su desarrollo allí, así que concéntrese en encontrar una buena biblioteca / marco del lado del cliente primero, y luego preocuparse por el lado del servidor.

Dicho esto, probaría los dos y vería cuál te gusta más. El capuchino es muy ... diferente, y muchas personas se desaniman por ello (sobre todo por Objective-J, creo). En mis pruebas limitadas, también parecía cargar mucho más lentamente que otros marcos que he usado. Te recomiendo que intentes escribir una pequeña aplicación en ella, y si sientes que no es para ti, tómala de la lista.

Personalmente, elegiría SproutCore en este caso porque ya sabe JavaScript (¿lo estoy asumiendo?) Y el estilo de desarrollo será mucho más familiar para usted. También le permitirá utilizar cualquier marco de servidor que desee.

No sé si lo has visto, pero también hay ExtJS , que es otro marco muy popular para crear aplicaciones web ricas. Lo he usado y es genial, pero la licencia requiere que usted lance su software como fuente abierta o compre una licencia comercial. No sé cuál es su situación, pero esto fue un factor decisivo para mí.

Al final te recomiendo que los pruebes . No puedo decirte si un marco se adaptará a tu gusto personal.

Descargo de responsabilidad: nunca he usado en serio SproutCore o Cappuccino para otra cosa que no sea la prueba, así que tome todo lo que diga con un grano de sal.