[mrcwinn]

There's a lot to like about Meteor. Just compare setting up some kind of "dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY FRIDAY NIGHT GO.

Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make.

I would say Meteor is ideal for learning, except that it's important to learn what the request-response lifecycle is all about, and I think it can be detrimental when a "magical" framework does so much for you.

And one thing I just can't get over -- page loads in Meteor.com feel super fast. Until you realize it actually downloaded the contents (not the unseen images, of course) of the entire website! DPP is doing some interesting things, but some of Meteor is some nice magic tricks that we've seen before. 600kb+ of JS on page load is certainly an interesting concept.

Huge amount of work by a talented team. A super nice community. As for the framework itself, give it some time, let it grow, but most importantly, understand objectively its strengths and risks. It has both!

[pluma]

First of all, why is JSX in that list? It's essentially an ES6 transpiler with syntactic sugar for nested function calls. If you mean the additional build step it requires, that doesn't really make sense either: you should be bundling and minifying your client assets already and JSX is just another (fully transparent) link in the build chain.

Secondly, why Rendr? Rendr was built for Backbone. The most recent info I can find that suggests using Rendr with React is over a year old. React can be rendered on the server just fine. The only thing you need to solve outside React is routing, getting the data and making it available to your React components. Either use stores or pass all the data as `props`.

Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the current hotness, not Grunt. And you don't need either of them anyway, there is so little to configure that you don't even need a full-blown build tool.

I don't have a single line of database code in my React app. All the API calls are handled by a small wrapper around my database's domain-specific HTTP API. I could use the same API with zero changes for a native mobile app or a new web app that doesn't use any of the existing code. My web server is a dumb proxy for the database API and a pre-rendered for React (the pre-renderer essentially consists of a single line of JavaScript).

I can understand the appeal of Meteor, but it's not like anything you complain about has to do with React.

(Now Angular on the other hand... let's hope you don't need any prerendering ever.)

[dmak]

I am still using Grunt, and have been wondering how Gulp is. How do you like it? Why is it better?

[pluma]

I switched from Grunt to Gulp because I never liked Grunt's focus on configuration over code. But that's entirely a matter of taste. It's not "better" or "worse" than Grunt, it's just a different approach.

Gulp is pretty neat, until you try to integrate watch tasks. Want to run a transpiler whenever a file changes? Better don't have any compile-time errors or your stream will choke and die (without necessarily killing the process, mind you).

There are some workarounds (e.g. gulp-plumber), but depending on the actual tool you're trying to use they may not actually work -- or only work sometimes, which can be just as bad as not working at all.

Personally I've switched from Gulp to just putting scripts in my package.json file as god (or Isaac) intended. Every tool I want to use has a CLI anyway, and supports stdin/stdout, so it's all just Unix legos anyway. Except for browserify, which I replace with watchify in development for performance reasons (browserify in a large project can take a few seconds, watchify only updates the diffs).

[jakozaur]

Yeah, one of the common critique is that "Meteor" does too much and doesn't integrate well with other stuff.

For me it's a main advantage, I don't need to use "other" stuff to get the final effect.

I wrote few projects and it's the best framework if you start from scratch. Though it's hard to swell if you need to add it later to some existing project.

[pluma]

I absolutely agree, but I don't understand why Meteor is frequently seen as a competitor to React or AngularJS or Ember. It's a competitor to combinations like node/browserify and full-stack solutions like Wakanda.

Meteor doesn't integrate with anything, but that was never a design goal. If you switch from Meteor, you can likely discard your entire stack (well, except the database obviously). It's based on node, sure, but that's an implementation detail.

Meteor is not a node-based stack. That's why it now has its won package manager instead of npm. It's a competitor to node with its own ecosystem. And that's fine.

[dmak]

Well, you can compare it as a fullstack too. It is mainly compared with React, Angular, and Ember as a reactive framework which isn't an incorrect comparison and is very valid.

[pluma]

Sure, but good luck replacing React/Angular/Ember in your Rails/Django/Node/What-have-you app with Meteor.

It's not really a relevant option unless you are at liberty to swap out the entire stack. It makes more sense to compare Meteor with MEAN rather than simply AngularJS itself.