¿Cuáles son las desventajas de construir con MeteorJS?

Quizás el único “inconveniente”, si puedo llamarlo un verdadero inconveniente, es el cambio de pensamiento requerido. Mientras que las aplicaciones web tradicionales tienden a seguir la apatridia del protocolo HTTP, las aplicaciones Meteor son totalmente con estado. Meteor favorece conexiones de socket duraderas donde el cliente y el servidor pueden usar la conexión para una comunicación bidireccional (pub / sub), a diferencia de la solicitud / respuesta tradicional.

El otro punto difícil de ser completamente con estado, es que la sesión se sincroniza implícitamente entre el servidor y todos los clientes conectados, para evitar que el servidor obtenga constantemente el último estado (como en la solicitud / respuesta). Si bien puede parecer una forma más óptima de manejar el estado, mantener una sesión gruesa sincronizada entre el cliente y el servidor, plantea algunas preguntas de escalabilidad. Principalmente sobre la distribución del estado de la sesión en varios servidores.

Divulgación: no soy desarrollador de Meteor.js, y mis observaciones se basan solo en un par de horas dedicadas a su documentación, así como a una entrevista de podcast con sus creadores.

Sentimos que Meteor todavía es una tecnología en desarrollo y aún tiene que madurar. Mientras desarrollamos nuestra aplicación (zipBoard) usando MeteorJS, enfrentamos una serie de problemas, y he enumerado algunos de ellos aquí.

Despliegue: ¿por dónde empiezo? No hay muchos proveedores de servicios decentes disponibles para Meteor. ¡También nos emocionó escuchar el lanzamiento de Galaxy, pero la emoción no duró ya que Galaxy es demasiado caro para una startup como nosotros! Así que probamos Modulus y DigitalOcean.
El módulo estaba demasiado ennegrecido para nuestro gusto, y teníamos muchas dependencias externas, así que tuvimos que darle un pase. Luego probamos DO, y nuevamente, las cosas no salieron bien. Su guía paso a paso no funcionó y tuvimos que improvisar mucho. Sin embargo, todavía carecía de consistencia, y tuvimos que usar la herramienta mup de Arunoda al final. ¡La implementación fue un desastre para nosotros!
Entonces, sí, dependiendo de la cantidad de dependencias externas y activos externos que esté utilizando, puede llevar una gran parte de su tiempo implementar la aplicación correctamente.

CFS: cuando comenzamos a escribir las características de ‘deleite del usuario’, como ‘cancelar una descarga mientras se carga el archivo’ o ‘mostrar una barra de progreso de carga más reactiva’, no había nada disponible. Pudimos hackear nuestro camino y hacer que estas opciones funcionen. Pero, sería realmente bueno ver que este paquete madure más antes de que las aplicaciones puedan usarlo en producción.

• También tuvimos que escribir nuestras propias implementaciones personalizadas para averiguar si un archivo se ha cargado completamente y está disponible en el servidor.
• Notamos que algunos de nuestros ayudantes estaban corriendo por todos lados una vez que comenzamos la producción. Todavía no tenemos idea de cuál es el flujo de trabajo con respecto a esto, aunque no creo que afecte demasiado a la aplicación. Sería genial saber la razón.
• También tuvimos que usar demasiados paquetes NodeJS para analizar archivos XML, comprimir / descomprimir archivos y manipular la estructura de archivos. Un ecosistema de paquete dedicado sería realmente bueno a largo plazo.

Todo eso está fuera de mi cabeza.

MeteorJS nos gusta mucho a pesar de sus defectos, y nos quedaremos con él. Pero sería genial ver un esfuerzo dedicado de MDG con respecto al desarrollo de MeteorJS.

También escribimos una publicación de blog detallada al respecto recientemente, que puedes leer aquí: ¿Meteor Production-Ready? Nuestra experiencia de primera mano – zipBoard

Echa un vistazo a nuestra aplicación.

Espero que esto haya ayudado.

Todas las respuestas a continuación son evaluaciones precisas.

Meteor no es para todo, aprendí que la construcción de una aplicación que obtiene principalmente sus datos de una API y luego hace toda la magia de Meteor con esos datos.

Es mejor ahora para la creación rápida de prototipos de la etapa MVP (producto mínimo viable) de desarrollo de aplicaciones. Donde necesite y desee que se muestren e interactúen rápidamente datos reactivos en tiempo real para que pueda intercambiar ideas con su cliente sobre cómo deberían comportarse todos los datos y las interacciones del usuario.

Hay algunos desarrolladores y organizaciones realmente excelentes que trabajan con él ahora. El equipo central está bien financiado. Debo suponer que están profundizando en la resolución de las diversas limitaciones del marco y que el escalado al nivel de producción ocupa un lugar destacado en la lista.

Creo que el marco crecerá, se expandirá y mejorará con el tiempo. Junto con esto vendrán más buenas soluciones a las deficiencias y una adopción más amplia.

No es una gran opción para nada relacionado con muchos activos estáticos. No es genial para los blogs, pero funcionará.

Puede crear rápidamente un prototipo completamente funcional con el que su cliente puede jugar para determinar la mejor manera de lograr y mostrar diversa información y prototipo de cómo los usuarios interactuarán con eso.

Pero tiene problemas de escala, que se abordan principalmente a través de lo que yo llamaría soluciones a cómo se comporta node.js. El libro Pro Meteor cubre todos estos problemas de escala y proporciona algunas formas de solucionar las limitaciones. Nunca he probado estos, pero los leí. Por lo tanto, no tengo experiencia directa con las soluciones de libros Pro Meteor.

Obtuve mi aplicación para hacer lo que quería y disfruté de lo rápido que tenía el código de trabajo con el que podía jugar.

Recursos que he usado:

Página en meteor.com

Descubra Meteor: aprenda a crear aplicaciones web JavaScript en tiempo real con el marco Meteor.js

Página en gentlenode.com

Página en atmospherejs.com

Los mejores recursos de aprendizaje para Meteor.js

Plataforma de monitoreo de rendimiento para meteoritos

Josh Owens

hay muchos más y en crecimiento … pruébalo y toma tu propia decisión.

Después de haber jugado un poco con él, no estoy convencido de que Meteor sea adecuado para aplicaciones grandes / complejas. Lo veo como una herramienta útil para poner en marcha un proyecto rápidamente para un hackathon o MVP, pero cualquier cosa más compleja no ahorrará tiempo a largo plazo.

El uso de variables globales, tiempos de inicio lentos, dependencia de MongoDB, problemas de seguridad (“inseguro” no debe ser predeterminado; confusión sobre permitir / negar / métodos, etc.), enfoque NIH (¿por qué no usar npm? ¿Por qué no usar require / AMD en su lugar? ¿de carga de módulo implícita frágil?) falta de estructura (¿este bloque de código se ejecuta en el cliente o servidor o en ambos?) y falta de funcionalidad básica en el núcleo (por ejemplo, paginación y validación de formularios, sí, hay paquetes pero la calidad es desigual) haga un viaje lleno de baches cuando intente escalar más allá de una aplicación simple.

Dicho esto, hay un montón de buenas ideas en Meteor, y si logra hacer un seguimiento de los cambios propuestos, como el soporte para React o SQL, entonces puede tener un futuro. Si necesita, por ejemplo, en tiempo real, simplemente use, por ejemplo, socketjs con nodo (o cualquier otra solución similar) y si solo necesita una aplicación web simple, alguna pila express / hapi, Rails, Django, etc. funcionará bien.

¡Gracias por preguntar!

Meteor es una especie de marco de “producto terminado” si puedo llamarlo así. Hace mucho por ti. Para mí eso es una desventaja. No me gustan los frameworks que hacen demasiado. Cuando hacen demasiado, se hace mucha magia sin tu conocimiento y al final puedes encontrarte limitado. ¿Seguro que desea utilizar un método que vuelva a representar la página completa o algo así, por ejemplo? A veces no sabes que está sucediendo. Prefiero algo más simple como Backbone. Realmente no me gusta la magia en frameworks. Para mí, demasiada magia sin mi conocimiento es un inconveniente.

Otro inconveniente es la huella de tamaño. No puedo encontrar cuánto pesa, pero para tanta magia … Backbone es 23kb. Eso costará en los tiempos de carga.

En mi caso, uso Spoonjs o uso Backbone + Plugin (uno que he hecho para personalizarlo aún más para mi uso). Meteor es una solución de caja cerrada y en mi caso no encuentro espacio para ello. Con grandes proyectos, Backbone + plugin / Spoonjs me dará la libertad de hacer lo que quiera. Lo peor que le puede pasar al desarrollador es llegar a un punto del proyecto en el que descubra que el marco lo está atando. Para proyectos pequeños, Meteor sería excesivo, así que …

Meteor es un marco bien construido, pero nunca tendrá el control de uno más pequeño que no haga tanto. Supongo que la velocidad de desarrollo con él en proyectos pequeños / medianos podría ser interesante.

Por cierto, en lugar del CLI del Meteor, uso Grunt / Gulp y yo y esas herramientas.

Desde mi experiencia trabajando con él, el mayor “problema” sin duda es la velocidad. Debido a que las plantillas a menudo se procesan antes de que los datos se salgan del cable, obtendrá pequeños flashes extraños durante unos pocos milisegundos mientras entra el contenido. Compare esto con el renderizado tradicional del lado del servidor donde la página se junta antes de mostrarse al usuario.

Hay formas de combatir esto, pero podría ser frustrante para un primer contador de tiempo.

Dicho todo esto, la última versión (0.8.0) limpia bastante el renderizado y estoy seguro de que las cosas solo mejorarán con el tiempo.

Definitivamente vale la pena una exploración de fin de semana para ver si el marco es para ti 🙂

Meteor es perfecto para un MVP, pero no una aplicación de producción. Una vez que comience a obtener una cantidad considerable de registros (digamos 7500), comenzará a ver un serio retraso entre el subtitulado y la publicación, lo que hace que la lógica comience a ponerse realmente funky. Además, con Meteor haciendo tanto por ti, no es raro que algo salga mal y que ese error nunca vuelva a aparecer, todo debido a la magia que Meteor está haciendo tanto detrás de escena.

Dicho esto, Meteor es absolutamente maravilloso para la creación de prototipos.

Bueno, el esfuerzo principal para construir una aplicación de producción en meteorito es que nadie sabe en qué dirección va. Comenzó como un marco y ahora es una plataforma, Blaze está casi en desuso y todavía solo admite Mongo DB. Veo mucho de Kadira cuando se trata de noticias de meteoritos, hacen un muy buen trabajo mejorando sus carencias, como la estructura de carpetas, etc., pero el futuro del meteorito es muy brumoso en mi opinión. Debe consultar el blog oficial de meteoritos y leer tres publicaciones de Sacha Greif, aclararán su comprensión sobre los problemas que verá después de crear algo más complejo que una lista de tareas pendientes. Sí, tengo experiencia en la creación de aplicaciones web, por lo que no es un gran problema, solo voy a SO o directamente a la documentación, pero odio cuando veo que la gente recomienda Meteor a un principiante completo. Hay muchos problemas con el estado actual del meteorito. Básicamente lo apoyé desde el principio y construí mi primera aplicación de meteoritos cuando era solo la versión 0.6, pero recientemente cambié a Rails para hacer mi próxima aplicación de producción. No significa que meteorito sea una mala elección y debe evitarlo, en realidad sigue siendo la mejor tecnología (en mi humilde opinión) para una creación de prototipos realmente rápida, pero para construir una aplicación compleja, iría con una tecnología más madura con la que ya tengo experiencia . De todos modos, me centraré en el meteorito.

Meteor usa variables globales de manera muy extensa y cuando se usa como se muestra en los tutoriales, esto da como resultado un coude realmente estrechamente acoplado. También hace que sea imposible escribir buenas pruebas unitarias porque no puede probar nada de forma aislada. He leído los documentos sobre cómo estructurar su aplicación, pero eso realmente no ayuda.
# problema de meteorito copiado

Creo que Meteor es un experimento que demostró que el enfoque isomorfo / plataforma única es incorrecto en el desarrollo web en general. El sistema no debe ser sólido. Y esto explica por qué:

La desventaja más seria desde el punto de vista del desarrollo / gestión de proyectos: Meteor es impredecible en el desarrollo , como resultado de demasiada magia y complejidad como precio del isomorfismo.

Ejemplo: en la pila SPA REST siempre puede ver los datos que se envían y las respuestas que recibe, pero con Meteor se convierte en un punto ciego, ¡hasta que registra todo en el servidor! Por lo tanto, es muy difícil predecir cuánto tiempo tomará enraizar un problema en su código, corregir errores, etc. Lo mismo ocurre con el desarrollo de la interfaz de usuario: debido a 2-6 segundos de tiempo de recarga, eventualmente se da cuenta de lo doloroso que es ser rápido e ingenioso con su interfaz de usuario (HTML, CSS): en la interfaz de usuario, es especialmente importante probar diferentes estilos para lograrlo, pero con todas las recargas, una característica simple pero pulida puede llevar días fácilmente y termina inesperadamente más tiempo para desarrollar una interfaz de usuario trivial.

Estas cosas ponen a su proyecto en un riesgo muy alto, y esa es la razón por la cual los gerentes de proyecto empleados se mantendrán alejados de Meteor.

* Nota: ¡Todavía creo que es una tecnología genial y única que vale la pena aprender y elogio a las personas que la desarrollaron! 🙂

Me encantó Meteor cuando lo encontré por primera vez y lo usé en Luzme por un tiempo.

Pero me enamoré de eso, cuando una cosa tras otra parecía demasiado difícil; Las cosas básicas que serían triviales en cualquier otra plataforma web tuvieron que inventarse desde cero.

Estoy en el proceso de cambiar de Meteor a Firebase, y estoy teniendo una experiencia mucho mejor. Comenzando con la documentación, que es excelente. (Meteor’s fue terrible)

Acabo de encontrar este artículo que Sacha Greif publicó ayer (enero de 2016), y resume lo que me salió mal, más elocuentemente de lo que podría articular.

Vale la pena leerlo.

El estado del meteorito Parte 1: Lo que salió mal – Descubre Meteor

Acabo de escribir una publicación de blog sobre nuestra experiencia de primera mano con el uso de meteorJS. La implementación de la aplicación meteorJS fue uno de nuestros desafíos más difíciles.

léalo aquí: ¿Meteor Production-Ready? Nuestra experiencia de primera mano

Pranab
http://www.zipboard.co

Con respecto al ecosistema de pruebas que mencionó Adam, hemos tratado de cubrir algunos de los conceptos básicos sobre pruebas unitarias, integración y pruebas de extremo a extremo con nuestra publicación de blog Meteor.js: Getting Started – con prueba, por supuesto.

¿Le agradeceríamos cualquier comentario o consejo sobre las pruebas con Meteor o lo que podríamos cubrir a continuación?

Genera demasiado para el desarrollador y no es tan estable como debería ser en este momento (ya que intenta hacer todo menos el código que tiene que escribir).

Pone las cosas en cajas y las hace brillar, algunas son realmente buenas (como la capa de datos) y otras no son realmente útiles después de un tiempo (como cargar todos los archivos).

El ecosistema de prueba no está cerca de Rails. Esto hace que sea mucho esfuerzo mantener alta la cobertura del código. Sin embargo, esto solo mejorará en el futuro.

En pocas palabras: es perfecto para un MVP pero no tan bueno para la aplicación de uso final.

comunidad pequeña, todavía no tengo una versión completamente estable (0.8.0)