5 ms·

Congratulations on 1.0 but these kinds of buzzwordy lines Accomplish in 10 lines what would otherwise take 1000, thanks to a reactive programming model

Congratulations on 1.0 but these kinds of buzzwordy lines Accomplish in 10 lines what would otherwise take 1000, thanks to a reactive programming model that extends all the way from the database to the user's screen. Really bother me. Show me where you eliminated 1000 lines of code and how it was beneficial. Each line of code, to me, is placed with purpose and intent. Are you eliminating thousands of lines of boilerplate? Or are you making best guess assumptions that fit the common need, and we still end up with those 1000 lines for something truly custom?

djmashko2 12y ago
(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 12y ago
  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 12y ago
    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 https://gist.github.com/pluma/61a1639906e188be8423 [1]: https://github.com/foss-haas/flox https://github.com/foss-haas/flox
    - dmak 12y ago
      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 12y ago
        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).
    - uptownJimmy 12y ago
      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.
- deleted 12y ago
  [deleted]

djmashko2 12y ago

(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 12y ago
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 12y ago
  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 https://gist.github.com/pluma/61a1639906e188be8423 [1]: https://github.com/foss-haas/flox https://github.com/foss-haas/flox
  - dmak 12y ago
    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 12y ago
      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).
  - uptownJimmy 12y ago
    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.
deleted 12y ago
[deleted]