[djmashko2]

(Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks.

If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to give you the same benefits without making you write code to plumb between several different frameworks.

[mrcwinn]

I'm doing a rebuild of a personal project over the holidays and I spent some time looking into binding together React, Airbnb's Rendr, and JSX through Browserify and Grunt. It's possible, but it's a nightmare. Meteor definitely succeeds and just delivering that.

(Not that that is the only requirement you might have.)

[pluma]

I'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re-rendering a single DOM node.

All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.

This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.

The only problem with React is that it is only a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.

I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).

[0]: https://gist.github.com/pluma/61a1639906e188be8423

[1]: https://github.com/foss-haas/flox

[uptownJimmy]

Two problems here:

1. "I have to admit that Flux has a steep learning curve." & "But I don't see how Meteor is any easier to pick up..." are mutually-exclusive.

2. Most everything else you wrote does a pretty good job of representing why Meteor is so attractive to some of us.

[dmak]

I agree with you that it probably is not easy to pick up, but I have to admit, there is significantly less to deal with. Meteor is the fullstack, and it even has sockets built into it. You definitely have to buy into one ecosystem, and that's convenient because you don't have to know a serverside ecosystem (e.g. Rails) and a frontend ecosystem (e.g. Angular, React, and Ember).

[pluma]

Sure, but my current ecosystem is npm. For browser-specific substitutes to node-specific code I simply use browserify. If I decide React is boring, I can switch to an entirely different front-end without changing anything else. For stuff that isn't on npm I have to work with bower or something else, but that (i.e. ecosystem-external dependencies) is a problem in any application, not specific to npm.

With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).