RailwayJS vs TowerJS

De nuevo … seleccionando marco. Me he detenido en estos dos TowerJS y RailwayJS, pero parece que son muy similares y es muy difícil elegir el camino.

Ambos se basan en Express, ambos son marcos de estilo RoR …

¿Cuál es el más prometedor, cuál será más popular?

O tal vez ya estoy en el camino equivocado? Tal vez debería elegir otro marco.

Odio cuando hay tantos marcos para elegir, no hay un estándar de la industria en el que confiar, ni más ni menos seguro de que el marco se desarrollará en un par de años …

Por favor ayuda, necesita sugerencia de expertos. Gracias

Aquí hay una breve tabla de resumen, hablaré sobre algunas de las cosas a continuación.

 + ----------------------- + ------------------------- ----- + ------------------------------------ +
 |  |  RailwayJS |  Torre.js |
 + ----------------------- + ------------------------- ----- + ------------------------------------ +
 |  Primer compromiso |  Ene 2011 |  Oct 2011 |
 |  Rieles |  2.3.x |  3.x |
 |  Node.js |  > = 0.4.x |  > = 0.4.x |
 |  Servidor |  ✓ |  ✓ |
 |  Cliente |  |  ✓ |
 |  Plantilla agnóstica |  ✓ |  ✓ |
 |  Motor por defecto |  EJS |  CoffeeKup |
 |  Agnóstico de base de datos |  ✓ |  ✓ |
 |  Almacén de datos predeterminado |  MongoDB |  MongoDB |
 |  Validaciones de modelos |  validatesPresenceOf ('email') |  valida ('email', presencia: verdadero) |
 |  Ámbitos de consulta |  ✓ |  ✓ |
 |  Alcances de chainable |  |  ✓ |
 |  Param análisis |  |  ✓ |
 |  Controladores |  ✓ |  ✓ |
 |  Controladores de recursos |  |  ✓ |
 |  Nombre de archivo |  users_controller.js |  usersController.coffee |
 |  vm.runInCustomContext |  ✓ |  |
 |  Tubería de activos |  |  ✓ |
 |  Compresión de activos |  |  ✓ |
 |  Enrutamiento |  map.resources ('posts') |  @resources 'posts' |
 |  Rutas anidadas |  ✓ |  ✓ |
 |  Ayudantes generados url |  ✓ |  |
 |  Generadores |  ✓ |  ✓ |
 |  Línea de comandos api |  ✓ |  ✓ |
 |  REPL (consola) |  ✓ |  ✓ |
 |  Consola CoffeeScript |  |  ✓ |
 |  Método de caché de activos |  marca de tiempo |  hash md5 |
 |  Ruta de activos de producción |  /app.css?123123123 |  /app-859c828c89288hc8918741.css |
 |  Idioma preferido |  JavaScript |  CoffeeScript |
 |  Soporte de CoffeeScript |  ✓ |  ✓ |
 |  Internacionalización |  ✓ |  ✓ |
 |  Soporte heroku |  ✓ |  ✓ |
 |  Caja de cuerdas |  snake_case |  camelCase |
 |  Constructor de formularios |  ✓ |  ✓ |
 |  Constructor de formas semánticas |  |  ✓ |
 |  Builer de mesa |  |  ✓ |
 |  API del observador de archivos |  |  ✓ |
 |  Activos de recarga en vivo |  |  ✓ |
 |  Sala de pruebas |  |  ✓ |
 |  Generadores para pruebas |  |  ✓ |
 |  Twitter Bootstrap |  ✓ |  ✓ |
 |  HTML5 Boilerplate |  |  ✓ |
 + ----------------------- + ------------------------- ----- + ------------------------------------ +

Creé Tower.js para lograr varios objectives que ninguno de los marcos existentes hizo adecuadamente. Éstos son algunos de esos objectives.

1. Mismo código en el cliente y servidor.

Dado que Node.js hizo posible JavaScript en el servidor, no hay razón para escribir una parte de la aplicación en Rails y la otra en Backbone. Eso es cualquier cosa menos SECA. Debería poder definir los modelos una vez y usarlos tanto en el cliente como en el servidor.

RailwayJS solo funciona en el servidor porque fue construido alrededor de Express. Tower.js también se basa en Express pero de una manera que lo hace funcionar tanto para el cliente como para el servidor. Tower.js proporciona la misma API exacta para el cliente y el servidor. Esto significa que tuve que volver a escribir algunas cosas como el enrutador para que funcione de la misma manera en el cliente y en el servidor (además, le permite hacer cosas como history.pushState con el # fallback, usando el mismo conjunto de rutas).

2. Las mismas “vistas” en el cliente y servidor

Pasé mucho tiempo en Rails y escribiendo plantillas Haml. Además, estaba escribiendo interfaces web y de JavaScript para dispositivos móviles utilizando lenguajes de plantilla como Moustache. Eso es más duplicación de código … Debería poder usar el mismo conjunto de vistas / plantillas tanto en el cliente (como en las plantillas de JavaScript) y en el servidor (representando HTML estático).

Dado que Haml era bastante impresionante (super limpio, le permitía ejecutar un Ruby arbitrario, construido en impresión bonita, etc.), la alternativa de JavaScript más cercana era CoffeeKup . Y funciona tanto en el cliente como en el servidor. CoffeeKup te permite escribir plantillas con todo el poder de JavaScript, por lo que no tienes limitaciones. Construir un FormBuilder en Bigote requiere mucho trabajo o mucho código, o ambos.

Sin embargo, tenga en cuenta que puede cambiar los motores de plantillas y usar Jade, Moustache, manillares, etc. para el cliente o servidor. CoffeeKup es solo un defecto limpio y poderoso.

3. Modelo de calidad de Rails API en el cliente y servidor

ActiveModel (implementado por ActiveRecord for SQL y Mongoid for MongoDB for Rails) es una API muy completa y bien probada que permite a los desarrolladores definir e interactuar con los datos. Es a la vez potente y agradable. Todas las implementaciones de JavaScript anteriores (y actuales) nunca fueron tan sólidas y bien diseñadas, y no vi que sucediera nada en el futuro cercano.

Si puedes escribir esto en Rails:

 User.where(:email => /[az/).page(2).limit(20) 

Deberías poder hacer eso en JavaScript:

 App.User.where(email: /[az/).page(2).limit(20) 

Tower.js viene con “scopes de chainable”, lo que significa consultas incondicionales + paginación. Se modela después de la API de consulta de MongoDB , pero esta “entrada” de la API se convierte en comandos de base de datos apropiados para los diferentes almacenes de datos.

4. Interfaz uniforme a los almacenes de datos SQL y NoSQL.

Tower.js actualmente tiene una tienda MongoDB y Memory (en el navegador), y tiene como objective proporcionar una interfaz uniforme para el rest de las bases de datos populares (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra, etc.).

RailwayJS parece estar haciendo esto también a través de JugglingDB, y parece un buen comienzo. Pero elijo no usarlo por varias razones. Primero, parece que se está construyendo alrededor de la API de Rails 2.x ( User.validatesUniquenessOf "email" frente a User.validates "email", presence: true ). En segundo lugar, no tiene la riqueza de consultas que puede hacer Rails 3. Tercero, quiero poder agregar código a la base de código rápidamente, y como soy muy exigente, probablemente termine refactorizando todo para usar CoffeeScript, jaja. Y no quiero crear una capa alrededor de eso porque también tiene que funcionar en el cliente, por lo que mantener la architecture de la biblioteca lo más mínima posible es una alta prioridad.

5. Controladores de recursos

La gem de Ruby heredada recortó aproximadamente el 90% del código de mis controladores Rails. Se resolvió un conjunto de convenciones para implementar las 7 acciones básicas del controlador. Tower.js incluye algo como esto, por lo que, de manera predeterminada, no tiene que escribir ningún código en sus controladores, todavía responderán con JSON y HTML. También lo hace para que puedas definir rutas anidadas.

6. Analizador de consultas de URL a base de datos automático

En Tower.js, puede decirle a un controlador que observe parámetros específicos en la url y los convertirá en un hash listo para aplicar a una consulta modelo.

 class App.UsersController extends App.ApplicationController @param "email" index: -> App.User.where(@criteria()).all (error, users) => @respondTo (format) => format.json => @render json: users format.html => @render "index", locals: {users} 

Dada una url que es como /users?email=abc&something=random , entonces @criteria() le dará un hash {email: /abc/} .

No está en Rails, pero me gustaría que lo fuera.

7. Formas semánticas

Soy super en HTML semántico. El creador de formularios de Rails genera un HTML bastante feo, por lo que muchas personas utilizaron Formtastic , que genera más formas semánticas. Tower.js usa prácticamente la misma API que Formtastic. También tiene un generador de tablas semánticas, lo que hace que sea bastante fácil construir tablas con capacidad de búsqueda / ordenación para vistas de administrador.

8. Canalización de activos

Rails 3 tenía una increíble fuente de recursos, donde podría escribir su JavaScript en CoffeeScript, su CSS en SCSS, y se comstackría automáticamente. Luego rake assets:precompile sus activos y obtendría los activos comprimidos con hash md5 listos para S3. Eso es bastante difícil de construir, y no vi a nadie trabajando en eso para Node.js.

RailwayJS utiliza el método Rails 2 para marcar la ruta de los activos, así que en lugar de esta versión hash de md5:

 /stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css 

Usted obtendría algo como esto:

 /stylesheets/application.css?1306993455524 

Este es un problema por algunas razones importantes. La Guía de canalización de activos de Rails tiene los detalles, pero lo importante es que S3 no reconoce la marca de tiempo, por lo que está leyendo /stylesheets/application.css, y si establece un encabezado Expires futuro lejano y ha cambiado su CSS, cualquier persona que haya visitado su sitio antes tendrá que purgar su caché o actualizar su página para ver las actualizaciones.

RailwayJS tampoco tiene el pipeline de comstackción de activos incorporado (al menos que yo sepa).

9. El Watchfile

Guardia fue un gran impulsor de la productividad en Rails. Le permitió escribir “tareas de observación” rápidas, esencialmente como tareas de rake / cake, que se ejecutaron cuando se creó / actualizó / eliminó un archivo que coincide con un patrón.

La torre tiene esto incorporado (usando design.io ). En realidad, esto es lo que le dice a los recursos de CoffeeScript y Stylus que se compilen en JavaScript y CSS. Pero puede hacer cosas muy poderosas con esta función, consulte https://github.com/guard/guard/wiki/List-of-available-Guards para ver ejemplos.

10. CoffeeScript

Gran fan de CoffeeScript.

CoffeeScript reduce la cantidad de JavaScript que necesita escribir en la mitad ( 6,501 adiciones, 15,896 eliminaciones que convierten la biblioteca completa de Node.js a CoffeeScript). Y hace que la encoding sea mucho más rápida y fácil.

Además, CoffeeScript es la única manera de mantener esa experiencia de encoding productiva y agradable que Rails mostró al mundo. JavaScript simplemente no hace eso.

Las pequeñas cosas

Soy un fan de los estándares. RailwayJS se adhirió a la convención de Ruby de usar snake_case, y yo también quería hacer eso, pero la comunidad de JavaScript usa camelCase, por lo que Tower siguió con eso. CamelCase también tiene algunos beneficios adicionales, ya que no necesita convertir Rails snake_case del lado del servidor a camelCase para el cliente, y eliminar ese carácter adicional le da un tamaño de archivo un poco más pequeño.

También estoy enamorado de código super limpio. Antes de considerar contribuir a un proyecto, leo el código fuente … y si está muy desordenado, probablemente lo reescriba.

También me encanta optimizar código. Con Tower.js, un gran objective es estructurarlo para que haga todo lo que hace Rails, proporcionando la misma API exacta tanto en el cliente como en el servidor, utilizando la mínima cantidad de código posible. Sin embargo, existe un compromiso entre minimizar el tamaño de la base de código y escribir código que sea claro y divertido / productivo de usar. Sigo encontrando maneras de obtener lo mejor de ambos mundos.

Definitivamente estoy en esto para el largo plazo también. Esta es la base de nuestra empresa, y todo lo que personalmente construiré en el futuro. Quiero llegar al punto en el que pueda desarrollar una aplicación bien diseñada, funcional y altamente optimizada en un día.

Espero que ayude.

¿Has prestado atención a Derbyjs ? Este, aunque todavía no es beta, es bastante emocionante. Está siendo escrito por un ex empleado de google y el autor de everyauth . Tendrá que escribir un mínimo de JavaScript del lado del cliente con este. Vea los extractos extraídos de la página oficial:

¿Por qué no usar Rails y Backbone? Derby representa una nueva generación de marcos de aplicaciones, que creemos que reemplazarán a las bibliotecas más populares en la actualidad, como Rails y Backbone.

La adición de funciones dinámicas a las aplicaciones escritas con Rails, Django y otros marcos del lado del servidor tiende a producir un lío enredado. El código del servidor representa varios estados iniciales, mientras que los selectores y devoluciones de llamada jQuery intentan desesperadamente dar sentido a los eventos DOM y de usuario. Agregar nuevas funciones generalmente implica cambiar el código del servidor y del cliente, a menudo en diferentes idiomas.

Muchos desarrolladores ahora incluyen un marco MVC de cliente como Backbone para estructurar mejor el código del cliente. Algunos han comenzado a usar bibliotecas de enlaces declarativas de vista de modelo, como Knockout y Angular, para reducir la manipulación de DOM y los enlaces de eventos. Estos son grandes conceptos, y agregar alguna estructura sin duda mejora el código del cliente. Sin embargo, aún conducen a la duplicación del código de representación y la sincronización manual de cambios en las bases de código de cliente y servidor cada vez más complejas. No solo eso, cada una de estas piezas debe conectarse manualmente y empaquetarse para el cliente.

Derby simplifica radicalmente este proceso de agregar interacciones dinámicas. Ejecuta el mismo código en servidores y navegadores, y sincroniza los datos automáticamente. Derby se encarga de la representación de plantillas, el empaquetado y los enlaces de vista de modelo fuera de la caja. Dado que todas las funciones están diseñadas para funcionar juntas, no se necesita duplicación de código ni código de pegamento. Derby prepara a los desarrolladores para un futuro en el que todos los datos de todas las aplicaciones son en tiempo real.

La flexibilidad sin el código de pegado Derby elimina el tedio de cablear un servidor, un motor de plantillas de servidor, un comstackdor de CSS, un empaquetador de scripts, un minificador, un marco de MVC de cliente, una biblioteca de JavaScript de cliente, una plantilla de cliente y / o enlaces, una biblioteca de historial de clientes, un transporte en tiempo real ORM, y base de datos. Elimina la complejidad de mantener el estado sincronizado entre modelos y vistas, clientes y servidores, múltiples ventanas, múltiples usuarios y modelos y bases de datos.

Al mismo tiempo, juega bien con los demás. Derby está construido sobre bibliotecas populares, como Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB y pronto otras bases de datos y almacenes de datos populares. Estas bibliotecas también se pueden utilizar directamente. La capa de sincronización de datos, Racer, se puede utilizar por separado. Otras bibliotecas de clientes, como jQuery y otros módulos Node.js de npm funcionan igual de bien junto con Derby.

Al seguir la estructura de archivos predeterminada, las plantillas, los estilos y los scripts se empaquetan automáticamente y se incluyen en las páginas correspondientes. Además, Derby se puede usar a través de una API dinámica, como se ve en el ejemplo simple anterior.

Pero también viene con el siguiente descargo de responsabilidad.

Derby y Racer son software alfa. Si bien Derby debería funcionar lo suficientemente bien para la creación de prototipos y los proyectos de fin de semana, aún está en desarrollo. Las API están sujetas a cambios.

Aún no cuenta con una implementación de autorización y está llena de problemas de seguridad , aunque serán atendidos en los próximos meses. Si puede esperar unos meses, este parece ser un marco prometedor.

La selección de un marco se reduce a su nivel de comodidad con él. Generalmente se basa en …

  • ¿Qué tan activo es el proyecto? ¿Cuándo fue el último commit? Si no está en github, eso es una preocupación inmediata para mí, ya que eso dificulta las contribuciones de los usuarios.

  • ¿Cuántas publicaciones de blog puedo encontrar en el marco? Si nadie habla de eso, generalmente es una mala señal, ya que las personas naturalmente hablan de cosas que les entusiasman.

  • ¿Qué pienso del marco? Esto puede ser más difícil de juzgar, pero debería haber suficientes ejemplos por ahí que al menos puedas tener una idea básica. Si no los hay, eso en sí mismo es un gran problema.

Erm … por supuesto, la pregunta obvia es si desea un marco de referencia de RoR … ¿por qué no solo usar RoR? 😉

Parece que TowerJS está más estrechamente unido a MongoDB como su almacén de datos, mientras que RailwayJS parece tener la flexibilidad del adaptador de modelo. Eso podría afectar su elección entre los dos. Personalmente elegiría escribir sitios de Rails usando RoR. Node parece prestarse más a diferentes tipos de servicios, ¿no crees? (Estoy pensando en Backbone en el cliente con servicios REST AJAX).