5 ms·
After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then cam
by sonnym 13y ago
After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then came the funding, and some twelve or sixteen months of development, and I finally decided to dive in.
I really wanted to like it. I was predisposed to do so.
But from the very beginning, I was confronted with something I consider a deal breaker. While I am wary and generally disinclined toward the increasingly popular pattern of curl an installation script and pipe into sh, in this case it is not only skeptical, it is downright ludicrous. Why would I, nay anyone, want to install an npm package this way? Should not the installation instructions simply be `npm install -g meteor`? And what if I need to work on multiple meteor projects with different versions? Surely there is support for adding it to your package.json file, but why is this not the primary means of installation and well documented?
Maybe I am being overly sensitive to these issues, but it really baffled me that the very foundation upon which a meteor project is predicated would be contradictory to the typical node workflow. I will probably try meteor to spike out a project at some point in time, but I do not foresee myself using it extensively in the near future.
- misuba 13y agonpm install -g meteorite Then create a site with it and specify whatever local version of meteor you want. The deets: https://github.com/oortcloud/meteorite/ https://github.com/oortcloud/meteorite/
- geoffschmidt 13y agoMeteor version locking is in core now (as of 0.6.0), and the rest of Meteorite (fetching packages from Atmosphere) will be folded into core as part of 1.0 :)
- flylib 13y agoit's because your getting a full mongo database installed and configured with it
- geoffschmidt 13y agoMeteor is a lot more than an npm package. For example, if you type these four commands.. $ curl https://install.meteor.com https://install.meteor.com | /bin/sh; meteor create myapp; cd myapp; meteor you're up and running with a complete stack including MongoDB, node, the dozen-ish core packages that make up the Meteor pubsub and realtime templating stack, and the 'meteor' build tool (which can do things like compile coffeescript and less, generate source maps, minify your production code, and provide a realtime development environment where whenever you save a file your app updates in your browser.) As for versioning, it's actually got a great way of doing that. Each of your Meteor projects is locked to a specific Meteor release version (similar to an Ubuntu release, it's a release-engineered snapshot of the Meteor core packages), which you can set with the `meteor update` command. And this has automatic `npm shrinkwrap` integration so that if you use npm packages alongside Meteor packages, everyone on your team is always running exactly the same versions of all of the code in your app. The Meteor tools automatically handle all the work of downloading any needed Meteor versions and keeping them installed side-by-side on your laptop, using the correct one for a given project, and notifying you of available updates.
- sonnym 13y agoI want to like meteor. It sounds like the installation script, aside from handling the MongoDB and node setup, could be treated like a typical node package. Based on the fact that meteor has no package.json, seemingly none of those core packages are installed via npm either. I may be alone in this, but I guess I would just prefer if my web framework expected me to have the interpreter and database installed, and used the package manager already provided for this environment.
- parasj 13y agoMeteor does feel a little heavy (especially when you get around to deploying it) but take a look at demeteorizer, at https://github.com/onmodulus/demeteorizer https://github.com/onmodulus/demeteorizer It converts Meteor apps into more traditional node.js with a package.json
- 13y ago
- sgdesign 13y agoSeems to me like you're throwing the baby out with the bath water. I personally think that's a mistake, but in any case if you don't want to run that command on your own machine, you can always try out Meteor with something like https://www.nitrous.io/ https://www.nitrous.io/
- sonnym 13y agoIt is not about the running of the command - I read the installation script, and it looks fine. It is about my desire to work on a node application in what I consider to be a standard way. I want to be able to treat my entire application as a node package, leveraging npm for dependency resolution. Think of it like a rails application. For local development, you probably use rbenv (or rvm), bundler, and have the version of rails you need listed in your Gemfile. You allow the package manager provided with the language and maybe a layer to keep environments separated (already provided by npm) to take care of dependency resolution and updates. I want a node framework where I can use the package.json file as one does the Gemfile for ruby applications.
- sgdesign 13y agoWell, Meteor isn't really just a Node framework. Why not evaluate it on its own merits?
- akbar501 13y agoDon't get too hung up on the installation. I think their point was to make setup/installation/getting excessively simple. With regard to why not "npm install -g meteor", I think the short answer is that the Meteor installation setups up/installs a lot more than just one node package.
- mr_luc 13y agoThank you. Saying that Node has a package manager is a huge understatement. Node has one hell of a package manager, but you have to hack[1] around Meteor to use npm modules, even in the latest version. My impression of Meteor, and the impression a number of node people seem to share, and which I've seen reinforced on HN, is: Meteor is in an almost adversarial relationship with the node.js open-source community, because while they're good hackers building something cool, they took millions of dollars in funding[2] and want to keep their options open for monetizing that codebase. This makes every decision they make differently than other open-source real-time frameworks (to build their own package manager, require a contributor agreement on an MIT licensed project, and use a nonstandard install process[3,4]) considerably more worrisome. And it's frustrating, because there's nothing going on in Meteor that necessitates going outside of the "node.js ecosystem" -- aka NPM [4,5,6]. That impression might be unfair in some way, and obviously the meteor people spend a lot of time responding to just these sort of concerns from the node.js community. But "Meteor" means "worry" to me. --- [1] http://meteorhacks.com/complete-npm-integration-for-meteor.html http://meteorhacks.com/complete-npm-integration-for-meteor.h... [2] http://venturebeat.com/2012/07/25/meteor-funding/ http://venturebeat.com/2012/07/25/meteor-funding/ [3] https://atmosphere.meteor.com/ https://atmosphere.meteor.com/ [4] https://github.com/meteor/meteor/pull/516#issuecomment-12919473 https://github.com/meteor/meteor/pull/516#issuecomment-12919... [5] http://derbyjs.com/ http://derbyjs.com/ [6] https://github.com/substack/node-browserify https://github.com/substack/node-browserify
- glasser 13y agoI'm not sure what your problem with contributor agreements are; basically every sizable open source project has one. You know, like... Node: http://nodejs.org/cla.html http://nodejs.org/cla.html
- curiouslearn 13y agoMeteor is awesome. It considerably simplifies web-development. I just want to let the core team know that many many people really appreciate your efforts and I sincerely hope that negative comments such as those by Mr. Luc don't discourage your team and do not distract you from the really awesome work you are doing.