node.js vs. meteor.js : quelle est la différence ?

Question

J'ai beaucoup lu et entendu parler de Meteor.js. Les tutoriels le font paraître très sportif comme framework, mais je suis encore un peu novice en matière de programmation web.

Au cours du dernier mois et demi, j'ai essayé de vraiment apprendre node.js et de comprendre comment tout cela fonctionne. J'aime la rapidité et la facilité avec lesquelles on peut le mettre en place et le rendre opérationnel, ainsi que la communauté qui l'accompagne (ce qui est illustré par le nombre époustouflant de frameworks que l'on peut obtenir pour Node).

Mais qu'en est-il des météorites ? Quels en sont les avantages réels, et quelle est la différence ? Quelqu'un a-t-il commencé en tant qu'utilisateur de node.js et s'est-il " converti " ou s'agit-il plutôt d'un nouveau cadre curieux ?

Answer 1

Une analogie libre est : "Meteor est à Node ce que Rails est à Ruby." Il s'agit d'un grand cadre de travail qui utilise Node sur le serveur. Node lui-même n'est qu'un cadre de bas niveau fournissant des fonctions pour envoyer et recevoir des requêtes HTTP et effectuer d'autres entrées/sorties.

Meteor est radicalement ambitieux : par défaut, chaque page qu'il sert est en fait une Guidon qui est maintenu en synchronisation avec le serveur. Essayez le Exemple de classement : Vous créez un modèle qui dit simplement " Lister les noms et les scores ", et chaque fois qu'un client modifie un nom ou un score, la page se met à jour avec les nouvelles données - pas seulement pour ce client, mais pour tous ceux qui consultent la page.

Une autre différence : Alors que Node lui-même est stable et largement utilisé en production, Meteor est dans un état "preview". Il y a de sérieux bugs, et certaines choses qui ne correspondent pas au modèle conceptuel centré sur les données de Meteor (comme les animations) sont très difficiles à faire.

Si vous aimez jouer avec les nouvelles technologies, essayez Meteor. Si vous voulez un framework web plus traditionnel et stable construit sur Node, jetez un œil à Express .

Answer 2

Meteor est un framework construit au dessus de node.js. Il utilise node.js pour le déploiement mais présente plusieurs différences.

La clé étant qu'il utilise son propre système d'emballage au lieu du système basé sur les modules de node. Cela facilite la création d'applications web à l'aide de Node. Node peut être utilisé pour une variété de choses et, à lui seul, il est terrible pour servir du contenu web dynamique. Les bibliothèques de Meteor rendent tout cela facile.

Answer 3

La force de Meteor réside dans sa fonction de mises à jour en temps réel, qui fonctionne bien pour certaines des applications sociales que l'on voit aujourd'hui, où l'on voit les mises à jour de tout le monde pour ce sur quoi on travaille. Ces mises à jour sont centrées sur la réplication de sous-ensembles d'une collection MongoDB sous les couvertures en tant que mises à jour locales de la base de données mini-mongo (leur sous-ensemble MongoDB côté client) sur votre navigateur Web (ce qui entraîne le déclenchement de multiples événements de rendu sur vos modèles). Cette dernière partie concernant les multiples mises à jour de rendu constitue également une faiblesse. Si vous voulez que votre interface utilisateur contrôle le moment où elle se rafraîchit (par exemple, les pages AJAX jQuery classiques où vous chargez le HTML et contrôlez tous les appels AJAX et les mises à jour de l'interface utilisateur), vous devrez vous battre contre ce mécanisme.

Meteor utilise une belle pile de plugins Node.js (Handlebars.js, Spark.js, Bootstrap css, etc. mais en utilisant son propre mécanisme de packaging au lieu de npm) en dessous ainsi que MongoDB pour la couche de stockage dont vous n'avez pas à vous soucier. Mais parfois, vous finissez par vous battre contre lui... par exemple, si vous voulez personnaliser le thème Bootstrap, cela perturbe la séquence de chargement du fichier responsive.css de Bootstrap, qui n'est plus réactif (mais cela se corrigera probablement lorsque Bootstrap 3.0 sortira bientôt).

Donc, comme tous les "full stack frameworks", les choses fonctionnent très bien tant que votre application correspond à ce qui est prévu. Si vous dépassez ce cadre et repoussez les limites, vous risquez de vous battre contre le framework...