Sails.js vs Meteor - ¿Cuáles son las ventajas de ambos? [cerrado]

81

He estado leyendo mucho sobre Nodejs y sus marcos y recientemente terminé mi primera interfaz de JavaScript completa (usando Angularjs).

Decidí que mi próximo proyecto favorito será una aventura de Nodejs usando uno de estos dos marcos:

He leído sobre ambos, pero todavía no puedo entender sus diferencias y por qué debería elegir usar uno sobre el otro. Así que por favor póngase su mejor sombrero de vendedor, elija un marco y véndamelo.

Algunas características que necesito para mi proyecto favorito son:

  • Puntos de vida
  • Hilos similares a Reddit, en tiempo real
  • Edición de página similar a Wikipedia
  • Usuarios / Roles
pedropeixoto
fuente
1
Consulte este enlace: vschart.com/compare/meteor-web-framework/vs/sails-js . ¡¡Puede ayudarte !!
tuchi35

Respuestas:

138

No puedo hablar por Meteor, pero puedo ayudar a proporcionar un poco de información sobre Sails porque lo creé.

tldr; Sails no es una panacea para todos los problemas de la web, pero creo que Node.js sí lo es. El objetivo de Sails es proporcionar un marco práctico para desarrollar aplicaciones completas, escalables, de inicio y amigables para la empresa construidas en node.js. Comencé Balderdash con la pregunta "¿Podemos usar Node.js para todo?". Sails es la respuesta.


De nuestros nuevos documentos :

Sails es, por supuesto, un marco web. Pero da un paso atrás. Qué significa eso? A veces, cuando nos referimos a la "web", nos referimos a la "web front-end". Pensamos en conceptos como estándares web, HTML 5 o CSS 3; y marcos como Backbone, Angular o jQuery. Sails no es "ese tipo" de marco web. Sails funciona muy bien con Angular y Backbone, pero nunca usarías Sails en lugar de esas bibliotecas.

Por otro lado, a veces cuando hablamos de "frameworks web", nos referimos a la "web back-end". Esto evoca conceptos como REST, HTTP o WebSockets; y se basa en tecnologías como Java, Ruby o Node.js. Un marco de "back-end web" le ayuda a hacer cosas como crear API, interactuar con bases de datos, entregar archivos HTML y manejar cientos de miles de usuarios simultáneos. Sails es "ese tipo" de marco web.

Hace un par de años, me comprometí a usar Node.js para todo , fue amor a primera vista . Construí Sails sobre Express y Socket.io porque eran (y siguen siendo) los módulos de nodo mejor establecidos para sus respectivos casos de uso. El código de manejo de solicitudes en Sails es compatible con Express, con la ventaja adicional del soporte implícito para Socket.io.

Sails está diseñado para ser compatible con cualquier estrategia que tenga para construir su (s) front-end (s) en Angular, Backbone, iOS / ObjC, Android / Java, o incluso simplemente ofrecer una API sin procesar para ser utilizada por otro servicio web o su comunidad de desarrolladores. Si termina cambiando su enfoque (por ejemplo, cambiando de Backbone a Angular) o construyendo una nueva interfaz por completo (por ejemplo, construyendo una aplicación nativa de Windows Phone), su aplicación Sails seguirá funcionando. Como ya sabrá, algunas personas llaman a este enfoque una Arquitectura Orientada a Servicios o SOA ( Joe McCann tiene una excelente presentación sobre el tema).

En la misma línea, Sails mantiene otras convenciones familiares para construir servidores web: una estructura MVC estándar, la capacidad de crear API limpias y módulos centrales que son abiertos, configurables, extensibles e incluso intercambiables. Esto significa que Sails se puede personalizar para adaptarse a las necesidades de sus usuarios, tan bajo nivel como sea necesario.

En 2013, el marco experimentó un tremendo crecimiento en popularidad y nuestro negocio de consultoría creció. El resto de los mantenedores principales y yo ampliamos nuestro enfoque en hacer que el desarrollo de backend sea lo más rápido y sencillo posible. Los aspectos relacionados de Sails, como los ganchos (complementos), las pruebas y los documentos, han recorrido un largo camino durante el último año gracias a los esfuerzos tanto de nuestro equipo central como de la comunidad (en constante expansión) de Sails en general. Hay muchos elementos de la hoja de ruta en los que todavía estamos trabajando, pero creo que Sails es la mejor opción que existe para el desarrollo de MVC estable y mantenible en Node hoy. El resto del equipo y yo estamos comprometidos con su mantenimiento continuo y desarrollo de funciones, y dado que lo usamos para todos los proyectos de nuestros clientes, no va a ninguna parte.

Estoy totalmente comprometido con hacer de Sails el mejor marco web que existe, pero nunca a expensas de Node.js. El equipo central y yo estamos implacablemente dedicados a la mejora del ecosistema de Node, y eso significa adoptar la NPM, aprovechar las tecnologías de Node existentes y las mejores prácticas, etc. No solo porque tiene más sentido, sino porque somos desarrolladores de Node.js. La motivación de todos nuestros esfuerzos es hacer que Node sea más accesible, no reemplazarlo. Entonces, si, en algún extraño universo paralelo, me dieran una opción fáustica entre convertir Sails a algún otro idioma, o deshacerme por completo de Sails pero aún poder usar Node, elegiría el último.


Recursos adicionales:

FAQ | Sails 101 | Screencast original | Guía de contribución | Desbordamiento de pila

Grupo de Google | Hoja de ruta | IRC: #sailsjs en Freenode | Estado de construcción

mikermcneil
fuente
2
Encontré otra buena perspectiva sobre esta pregunta aquí (la primera respuesta): linkedin.com/groups/…
mikermcneil
@AaronShafovaloff gracias por los avisos, aquí está el enlace actualizado: sailsjs.org/get-started
mikermcneil
30

He construido un par de proyectos con Meteor y aún no he trabajado con Sails. Así que mi opinión será ciertamente parcial, con suerte será útil de todos modos.

Construyendo el front-end

Meteor proporciona su propio marco de front-end llamado Blaze, que se incluirá en la próxima versión 0.8. Meteor se encarga de vincular los datos de sus colecciones a sus vistas. Debido a esto, no tiene que preocuparse por decirle a sus vistas que se actualicen, simplemente lo hacen.

Por otro lado, Sails solo proporciona un marco de backend y tendrá que traer su propio marco de front-end.

A diferencia de la mayoría de los frameworks de Node.js, Meteor es sincrónico

Meteor se ejecuta en un bucle y si desea utilizar los paquetes de Node.js, tendrá que hacer un trabajo adicional para asegurarse de que funcionan correctamente en Meteor.

Sails parece ser un marco MVC Node.js sencillo, por lo que no debería haber nada demasiado sorprendente cuando lo analizas.

Deberías usar MongoDB con Meteor

Sí, puede usar otras bases de datos con Meteor, pero no tienen el mismo soporte que MongoDB. Mientras que con Sails, parece que tienen ORM para un par de bases de datos.

Actuación

Para aplicaciones a gran escala, es posible que Meteor no funcione bien . Se está trabajando mucho para abordar este problema y, para fines de 2014, podemos esperar que haya soluciones de escala para Meteor.

Estabilidad

Meteor todavía está muy fresco y aún no ha llegado a 1.0. Debe esperar que se realicen algunos cambios en las próximas versiones que romperán la compatibilidad con versiones anteriores. Si está comenzando con él lo antes posible, entonces puede considerar usar la rama 0.8-rc0. Dicho esto, algunas de las características en desarrollo son realmente geniales y harán que la versión 1.0 sea muy atractiva.

¿Pensamientos finales?

Me gusta Meteor por su idiosincrasia. Tendrás que aprender la forma Meteor de hacer las cosas, pero una vez que comiences a hacerlo, sentirás que te has bebido el kool-aid. Debido a la forma en que los datos están vinculados a las vistas, las líneas entre el servidor y el cliente no están distantes. Meteor representa un cambio de paradigma en la arquitectura de aplicaciones y si aún no lo ha probado, lo recomendaría.

PD: Consulte la hoja de ruta para tener una idea de lo que se avecina.

MSaforrian
fuente
5
Sugeriría modificar la declaración "meteoro es sincrónico", ya que puede dar una impresión incorrecta a aquellos que no están familiarizados con las fibras de nodejs. Meteor se ejecuta en Node.js, por lo que aún obtiene sus beneficios sin bloqueo impulsados ​​por eventos. Meteor integra de forma transparente las Fibras de nodo para que el código del lado del servidor se pueda escribir en un modelo de ejecución lineal en lugar de dividir las cosas en devoluciones de llamada tradicionales. Esta es probablemente la mejor referencia con respecto al uso de npmpaquetes con meteor: meteorhacks.com/complete-npm-integration-for-meteor.html
alanning
Gracias Alanning, incorporaré tus comentarios en esta respuesta.
MSaforrian
8
Quizás una cosa importante es que sails.js es solo para el backend, mientras que meteor ofrece un marco completo de javascript de front-end para trabajar fácilmente con el backend.
Michael
Gracias por mencionar eso, @Michael. Sails.js y Meteor realmente no compiten: Sails.js es un marco de backend para Node.js que puede usar en lugar de algo como Django, Rails, Express, etc., mientras que Meteor es una nueva forma de pensar sobre cómo Cree aplicaciones reactivas de arriba a abajo, lo cual creo que es realmente genial por cierto :)
mikermcneil
¿Le gustaría actualizar su comentario ya que han pasado más de 4 años desde su revisión? Ciertamente me gustaría una opinión con respecto al nuevo meteoro 1.7 que cambia el juego ..
Shyam
19

Solo puedo opinar sobre velas. Soy un desarrollador de Javascript con mucha experiencia y he estado construyendo aplicaciones de decodificadores integrados construidas en Javascript desde los años 90.

Cosas que funcionaron muy bien - Comenzar fue genial y me sentí muy apoyado por los materiales publicados - La curva de aprendizaje fue muy corta y hay una comunidad saludable detrás de las velas - Después del aprendizaje inicial es muy fácil ser creativo rápidamente

Cosas que podrían mejorarse - Las estructuras de datos complejas son difíciles de implementar - La integración de Passport.js fue dolorosa ya que no hay materiales de referencia limpios

Recomendaciones : el codificador Ponzi tiene un excelente tutorial y realmente me ayudó a ponerme en marcha https://www.youtube.com/user/ponzicoder - Saber más sobre express y waterline te ayudará cuando intentes desafíos de datos más complejos

En general, recomendaría velas.

Simondelliott
fuente
1
Hola simon, ¿podrías compartir cómo lograste integrar pasaporte con velas? Estoy atrapado en el mismo problema. ¿Ha escrito un blog en alguna parte o tiene algún material de referencia?
Mitremayer Reis
2
Hola Mitremayer, lo siento pero mi blog murió por negligencia hace mucho tiempo. Lo que hizo que el pasaporte funcionara para mí fue darme cuenta de que si hacía dos cosas, parecía funcionar bien. 1 los nombres de campo predeterminados en todas partes (correo electrónico y contraseña) 2 pasar el objeto req a la devolución de llamada passport.use('local-login', new LocalStrategy({ usernameField : 'email', passwordField : 'password', passReqToCallback : true // allows us to pass in the req from our route (lets us check if a user is logged in or not) },
simondelliott
1
Wow gracias. Llevo días teniendo problemas con la estrategia local. Esto merece su propia publicación de desbordamiento de pila
light24bulbs
1
De hecho, la integración de Passport.js necesita más material de documentación, no podría enfatizarlo lo suficiente. Específicamente para el caso de uso de la API REST donde no se está ejecutando el servidor (para clientes angulares de JS, por ejemplo), combinando el inicio de sesión de Facebook / Google y la autenticación local.
Alon Amir
1
Upvote Passport.js es difícil de integrar y está mal documentado
pim
9

Actualmente uso Meteor y no he usado Sails.js.

Ha sido muy agradable trabajar con Meteor y creo que sería una excelente opción para aplicaciones web en tiempo real. Con respecto a los usuarios / roles, puede consultar el paquete de Cuentas integrado y también buscar en Atmosphere los paquetes de roles / permisos aportados por la comunidad.

En definitiva, recomendaría probar un pequeño proyecto con ambas tecnologías y ver cuál te gusta más.

planificando
fuente
¿Sabe si Sail.js tiene alguna variación de la compensación de latencia en el lado del cliente similar a la compensación de latencia de Meteor en el nivel del modelo?
imslavko
No sé sobre Sail.js, pero probablemente puedas incluirlo tú mismo usando la librería sharejs.org . Al menos ese parece ser el objetivo de lib.
Planificación del
1
@alanning: no, sharejs no compensa la latencia. Sharejs realiza transformaciones operativas. La compensación de latencia es cuando Meteor realiza una actualización de su minimongo local y asume que la actualización remota será exitosa, permitiendo al usuario continuar.
gomad
1
@gomad, tiene razón en que sharejs no proporciona compensación de latencia de fábrica. No dije que lo hiciera. Más bien, dije, "probablemente puedas incluirlo tú mismo usando sharejs.org". LC se basa en OT.
Planificación
Solo una nota adicional. Creo que meteor es muy agradable de usar. Hay un poco de curva de aprendizaje, pero aparte de eso, el marco es muy similar a cómo puedes describir rieles a ruby. Mi única queja actual es en este momento, todavía depende del nodo 0.10.40 si desea autohospedar. Debido a que meteoro tiene una base bastante grande, creo que el juego de ponerse al día con el nodo es un poco injusto para meteorito.
Jimmy MG Lim