node.js - node - RailwayJS vs TowerJS

node js server hosting

Question

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

Ambos están basados ​​en Express, ambos son frameworks 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 industrial en el que confiar, para estar más o menos seguros de que el marco se desarrollará en un par de años ...

Por favor ayuda, necesita una sugerencia de experto. Gracias

Answer 1

¿Has prestado atención a Derbyjs ? Este, aunque aún no es beta, es bastante emocionante. Está siendo escrito por un ex empleado de Google y el autor de everyauth . Deberá escribir javascript mínimo en el lado del cliente con este. Vea los extractos tomados 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á las bibliotecas populares actualmente, como Rails y Backbone.

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

Muchos desarrolladores ahora incluyen un marco MVC de cliente como Backbone para estructurar mejor el código de cliente. Algunos han empezado a usar bibliotecas declarativas de enlace de vista de modelo, como Knockout y Angular, para reducir la manipulación repetitiva del DOM y los enlaces de eventos. Estos son conceptos geniales, y agregar cierta estructura definitivamente mejora el código del cliente. Sin embargo, todavía conducen a la duplicación del código de representación y a la sincronización manual de los cambios en bases de códigos de servidor y cliente 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 la plantilla, el empaquetado y las fijaciones de la vista modelo desde el primer momento. Dado que todas las características están diseñadas para funcionar juntas, no se necesita duplicación de código y código de pegamento. Derby equipa a los desarrolladores para un futuro cuando todos los datos en todas las aplicaciones están en tiempo real.

Flexibilidad sin el código de pegamento Derby elimina el tedio de cablear un servidor, motor de plantillas de servidor, compilador de CSS, secuenciador de scripts, minificador, marco MVC de cliente, biblioteca JavaScript de cliente, motor de plantillas y / o enlaces de cliente, biblioteca de historial de clientes, 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, incluyendo Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB, y pronto otras bases de datos populares y áreas de almacenamiento de datos. Estas bibliotecas también se pueden usar directamente. La capa de sincronización de datos, Racer, se puede usar por separado. Otras bibliotecas de clientes, como jQuery, y otros módulos Node.js de npm funcionan igual de bien que Derby.

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

Pero también viene con la siguiente exención de responsabilidad

Derby y Racer son software alfa. Si bien Derby debería funcionar lo suficientemente bien para prototipos y proyectos de fin de semana, todavía está experimentando un gran desarrollo. Las API están sujetas a cambios.

Todavía no cuenta con una implementación de autorización y está plagado de problemas de seguridad , aunque se solucionarán en los próximos meses. Si puede esperar unos meses, este parece ser un marco prometedor.

Answer 2

Aquí hay una breve tabla para la vista general, hablaré sobre algunas de las cosas a continuación.

+-----------------------+------------------------------+------------------------------------+ | | RailwayJS | Tower.js | +-----------------------+------------------------------+------------------------------------+ | First commit | Jan 2011 | Oct 2011 | | Rails | 2.3.x | 3.x | | Node.js | >= 0.4.x | >= 0.4.x | | Server | ✓ | ✓ | | Client | | ✓ | | Template agnostic | ✓ | ✓ | | Default engine | EJS | CoffeeKup | | Database agnostic | ✓ | ✓ | | Default datastore | MongoDB | MongoDB | | Model validations | validatesPresenceOf(''email'') | validates(''email'', presence: true) | | Query scopes | ✓ | ✓ | | Chainable scopes | | ✓ | | Param parsing | | ✓ | | Controllers | ✓ | ✓ | | Resource controllers | | ✓ | | File naming | users_controller.js | usersController.coffee | | vm.runInCustomContext | ✓ | | | Asset pipeline | | ✓ | | Asset compression | | ✓ | | Routing | map.resources(''posts'') | @resources ''posts'' | | Nested routes | ✓ | ✓ | | Generated url helpers | ✓ | | | Generators | ✓ | ✓ | | Command-line api | ✓ | ✓ | | REPL (console) | ✓ | ✓ | | CoffeeScript console | | ✓ | | Asset cache method | timestamp | md5 hash | | Production asset path | /app.css?123123123 | /app-859c828c89288hc8918741.css | | Preferred Language | JavaScript | CoffeeScript | | CoffeeScript support | ✓ | ✓ | | Internationalization | ✓ | ✓ | | Heroku support | ✓ | ✓ | | String case | snake_case | camelCase | | Form builder | ✓ | ✓ | | Semantic form builder | | ✓ | | Table builer | | ✓ | | File watcher API | | ✓ | | Live-reload assets | | ✓ | | Test suite | | ✓ | | Generators for tests | | ✓ | | Twitter Bootstrap | ✓ | ✓ | | HTML5 Boilerplate | | ✓ | +-----------------------+------------------------------+------------------------------------+

Creé Tower.js para lograr varios objetivos que ninguno de los marcos existentes funcionaba adecuadamente. Estos son algunos de esos objetivos.

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

Como Node.js hizo posible el uso de 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 todo menos SECO. 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 expreso. Tower.js también está construido alrededor de expreso, 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 significó que tuve que reescribir algunas cosas como el enrutador para que funcione igual en el cliente y el servidor (además, te permite hacer cosas como history.pushState con #fallback, usando el mismo conjunto de rutas).

2. Mismas "vistas" en el cliente y el servidor

Pasé mucho tiempo en Rails y escribiendo plantillas de Haml. Al mismo tiempo, estaba escribiendo interfaces de JavaScript web y móvil usando lenguajes de plantillas como Mustache. Eso es más duplicación de código ... Debería poder usar el mismo conjunto de vistas / plantillas tanto en el cliente (como plantillas de JavaScript) como en el servidor (representación de HTML estático).

Dado que Haml era bastante impresionante (súper limpio, le permitía ejecutar 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 le permite escribir plantillas con todo el poder de JavaScript, por lo que no tiene limitaciones. Crear un FormBuilder en Moustache requerirá mucho trabajo o mucho código, o ambos.

Sin embargo, tenga en cuenta que puede cambiar los motores de plantilla y usar Jade, Moustache, Manillar, etc. para el cliente o servidor. CoffeeKup es simplemente un valor predeterminado limpio y potente.

3. API modelo de calidad de rieles en el cliente y el servidor

ActiveModel (implementado por ActiveRecord para SQL y Mongoid para 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 poderoso 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 => /[a-z/).page(2).limit(20)

Deberías poder hacer eso en JavaScript:

App.User.where(email: /[a-z/).page(2).limit(20)

Tower.js viene con "alcances encadenables", lo que significa consultas complejas + paginación. Se basa en la API de MongoDB Query , pero esta "entrada" de API se convierte en los comandos de base de datos apropiados para los diferentes almacenes de datos.

4. Interfaz uniforme para las áreas de almacenamiento de datos SQL y NoSQL

Tower.js actualmente tiene una tienda MongoDB y de memoria (en el navegador), y tiene como objetivo proporcionar una interfaz uniforme para el resto 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 algunas razones. En primer lugar, parece que se está construyendo alrededor de la API de Rails 2.x (el User.validatesUniquenessOf "email" . User.validatesUniquenessOf "email" frente a User.validates "email", presence: true ). En segundo lugar, no tiene la riqueza de consultas encadenadas que hace Rails 3. En tercer lugar, quiero poder agregar código a la base de código rápidamente, y dado que soy muy exigente, probablemente terminaré refaccionando todo para usar CoffeeScript, jaja. Y no quiero construir una capa alrededor de eso porque tiene que funcionar también en el cliente, por lo que mantener la arquitectura de la biblioteca lo más mínima posible es una alta prioridad.

5. Controladores ingeniosos

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

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

En Tower.js, puede indicarle a un controlador que observe los parámetros específicos en la url y los convertirá en un hash listo para aplicar a una consulta de 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}

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

No está en Rails, pero desearía que fuera.

7. Formas semánticas

Estoy súper en HTML semántico. El creador de formularios de Rails genera HTML bastante feo, por lo que muchas personas y yo usamos 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 de búsqueda / ordenables para vistas de administrador.

8. Gasoducto de activos

Rails 3 tenía una impresionante cartera de activos, donde podía escribir su JavaScript en CoffeeScript, su CSS en SCSS, y se recompilaría automáticamente. A continuación, rake assets:precompile sus activos y obtendrá los activos gzipped md5-hashed listos para S3. Es bastante difícil de construir tú mismo, y no vi a nadie trabajando en eso para Node.js.

RailwayJS usa el método Rails 2 de sellado de tiempo de la ruta del activo, por lo que en lugar de esta versión md5-hashed:

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

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 más importante es que S3 no reconoce la marca de tiempo, por lo que está leyendo /stylesheets/application.css, y si configura un encabezado Expires futuro lejano y ha cambiado su CSS, cualquiera que haya visitado su sitio antes deberá purgar su caché o forzar la actualización de su página para ver las actualizaciones.

RailwayJS tampoco tiene la cartera integrada de compilación de activos (al menos que yo sepa).

9. El archivo Watchfile

Guard fue un gran refuerzo de productividad en Rails. Le permitió escribir "tareas de observación" rápidas, esencialmente tareas de rastrillo / torta, que se ejecutaban cuando se creaba / actualizaba / borraba un archivo que coincidía con un patrón.

Tower tiene esto incorporado (usando design.io ). Esto es en realidad lo que está diciendo a los activos de CoffeeScript y Stylus que se compilen en JavaScript y CSS. Pero puede hacer cosas muy potentes con esta característica, consulte https://github.com/guard/guard/wiki/List-of-available-Guards para ver ejemplos.

10. CoffeeScript

Gran admirador de CoffeeScript.

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

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

Las pequeñas cosas

Soy un fanático 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, así que Tower fue con eso. CamelCase también tiene algunos beneficios adicionales, como que no necesita convertir Rails snake_case en el servidor en camelCase para el cliente, y eliminar ese carácter adicional le da un tamaño de archivo pequeño y pequeño.

También estoy enamorado de código súper limpio. Antes de considerar contribuir con un proyecto, leo el código fuente ... y si es súper desordenado, probablemente voy a reescribirlo.

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

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

Espero que ayude.

Answer 3

La selección de un marco se reduce a su nivel de confort con ella .. generalmente se basa en ...

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

• ¿Cuántas publicaciones de blog puedo encontrar en el marco? Si nadie habla de eso, eso suele ser 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 para que al menos pueda obtener una idea básica. Si no hay, entonces eso en sí mismo es un gran problema.

Erm ... por supuesto, la pregunta obvia es si quieres un marco RoR ... ¿por qué no usar RoR? ;)

Answer 4

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