2012-02-29 10 views
13

Empecé en el mundo del desarrollo web con PHP, y luego con Rails en los últimos años. Desde entonces he estado haciendo todos mis proyectos web en Rails.Frontend Backbone.js con back-end RESTful Rails?

Recientemente parece haber un movimiento hacia la fabricación de Rails como un servicio de backend RESTful puro y el uso de framework de frontend como Backbone.js para todas las interacciones frontend. Me pregunto ¿qué piensan ustedes de eso? ¿Será este el futuro eventual?

Además, además de Backbone.js, ¿cuáles son algunas otras alternativas para frontend framework para este propósito?

Suponiendo también que quiero admitir tanto una versión de escritorio como una versión móvil de mi aplicación, ¿sería esta una ruta adecuada? ¿Así que tendré un solo servicio de backend con diferentes servicios frontend? De esta forma, no necesito administrar todas las vistas del lado de Rails.

Gracias!

+0

Compruébelo si todavía no lo ha hecho, http://railscasts.com/episodes/323-backbone-on-rails-part-1 y http://railscasts.com/episodes/325-backbone-on -rails-part-2 me ayudó a entender bootstrap mucho mejor. Def comienza a ver la utilidad de dicho marco. Ryan puso todas sus rutas de rieles en un espacio de nombres api para separarlo de la parte de aplicaciones web, que también me parece intuitivo. –

+0

uuummmm, backbone, no bootstrap ... :) –

Respuesta

19

Para los marcos del lado del cliente, este artículo tiene una lista de 20 de ellos con pros y contras: http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/

Aquí está la lista:

  1. Backbone.js
  2. Knockout.js
  3. Asana luna
  4. Cappucino
  5. Sproutcore
  6. BatmanJS
  7. corMVC
  8. TrimJunction
  9. pureMVC
  10. jamal
  11. choco
  12. sammyjs
  13. extJS
  14. agilityJS
  15. eyeballs
  16. activejs
  17. spinejs
  18. qooxdoo

Estos son más o menos todo acerca de la creación del lado del cliente, basado en Ajax-javascript marcos MVC.

Si está buscando comenzar en algún lado, entonces le recomiendo que piense en Plantillas del lado del cliente (... ates ... ates ... ates) (solo la "V") para admitir un servicio- arquitectura orientada (muchos clientes son compatibles con los puntos finales de servicio que crea).

Es una nueva técnica que consiste en modularizar el código del lado del cliente, llevar MVC al cliente y dejar que la lógica de negocios viva en la plataforma.Muchas aplicaciones de Software-as-a-Service las están aprovechando, y con el aumento cada vez más sofisticado de las bibliotecas y frameworks de JavaScript, así como las capacidades del navegador con HTML5, CSS3, etc., habrá una creciente sofisticación en la presentación del lado del cliente. .

Así que apréndelo.

¿Cuáles son los beneficios?

Parafrasear Linked In: para aprovechar el almacenamiento en caché del navegador, desencoplando su presentación del lado cliente, carga asíncrona, representación progresiva (para algunos marcos), rendimiento, interacción ajax, y más.

Varios grandes marcos incluyen:

  1. mustache
  2. dust.js
  3. handlebars
  4. Google Closure Templates
  5. Nun
  6. Mu
  7. kite

recomiendo encarecidamente mirando Linked In's move away from JSP towards Client-Side Templates y por qué eligen dust.js en Linked In's front-end client-side templates throwdown para una comparación. Explican mucho más detalladamente, e investigan, por qué cambiaron su pila para soportar esto (involucraba el uso de 3 tecnologías del lado del servidor), así como sus comparaciones de todos los marcos que podían encontrar.

+0

Gracias por la respuesta. Acabo de leer los dos artículos de linkedin que me has proporcionado. Creo que estoy empezando a entender un poco mejor la escena de plantillas del lado del cliente.Sin embargo, una vez más la pregunta persiste, ¿cuál es realmente la diferencia entre esto y algún framework MVC como backbone.js? Esto suena como lo que me gustaría tener, pero cuando escuché sobre backbone.js con Rails, también sonaba como lo que estaba hablando. Cuáles son las diferencias entre ellos? ¡Gracias! – gtr32x

+0

¿Qué quiere decir con "this" y "algún framework MVC" como backbone.js? Cada uno de estos marcos básicamente son frameworks MVC que aprovechan ajax (y otras tecnologías) para interactuar con la aplicación services/server-side. Simplemente tienen sus pro y sus contras. La red troncal es muy popular y sigue mucho a los modelos ajax +. –

+0

Oh ok, pensé que backjone.js era algo diferente de los que has enumerado. Dado que no estaba en su lista de marcos y de LinkedIn. Supongo que había asumido erróneamente que ustedes pensaban Backbone. Habría sido una opción también jaja. ¡Gracias! – gtr32x

2

Hice algo así hace unos años en .net. No fue a través de .NET MVC y no usó los nuevos frameworks JS, pero el principio era el mismo; el código del servidor devuelve JSON a javascript que crea la página y las interacciones, etc.

El resultado fue un sitio web encantador y receptivo, pero el mantenimiento fue una pesadilla. Tenga mucho cuidado de mantener su código JS bien organizado.

Personalmente, me resulta más fácil mantener el código del servidor (en cualquier idioma) que javascript, así que no volvería a hacer esa ruta.

(en mi humilde opinión)

Fran

Cuestiones relacionadas