Learn Meteor Fundamentals and Best Practices

by agscala • 14 years ago

56 17 14 years ago

jchung• 14 years ago

Man, Meteor is a pretty interesting framework. Looking forward to spinning up my first app on this.

The thing that concerns me about Meteor right now is that they seem to be fighting the use of the existing node ecosystem (e.g. not using npm, fibers) which makes it harder to use existing node libraries. Derby.js (http://derbyjs.com/) in contrast, build upon existing node components and plays nicely with npm.

agscala• 14 years ago

I agree, but Meteor is still young and it actually has a reason for doing it that way. Meteor doesn't have a built-in module system right now, so when you add something like underscore.js to your Meteor project, you don't need to require("underscore"), it's simply available on both the client and server globally.

I feel like they chose to go for convenience rather than consistency with existing practices.

But like I said, Meteor is still in its infancy. It's entirely possible this will all change down the line.

norviller• 14 years ago

I don't think this will change. I think one of the design goals is to have it's own ecosystem.

stuffihavemade2• 14 years ago

To me, that's not a compelling reason to avoid using npm. I haven't played around with node that much yet, but Rails uses ruby gems just fine, and it doesn't require require everywhere. Even if you do have to use require in some manifest file, that seems to be a small price to pay to interact with existing code.

edmellum• 14 years ago

How is having all second party modules be global automatically a convenience? That sounds like the worst possible way second party modules could work.

Throwing away a package manager as great and as tried and tested as NPM, which could easily be used seems so counter-intuitive.

j_s• 14 years ago

I appreciate the brief diversion at the end (which I would summarize as 'make sure your users can't delete your entire database'), but it seems like there's nothing on which to base fundamentals/best practices for Meteor security yet...

jfb• 14 years ago

How can there be best practices when there's no production ready software? Best practices aren't derived from first principles -- they're a reification of all of the human experience that has gone into writing and MAINTAINING software systems.

pacomerh• 14 years ago

I feel left behind, I thought Meteor was pretty new and already a fundamentals and best practices article?

trung_pham• 14 years ago

Still waiting on the day that I can use Meteor without giving up on SEO...

dinkumthinkum• 14 years ago

Meteor is interesting but like others, I have some concerns. It's position within node.js community is a little strange to me. Also, this idea of "best practices" for something so new is just a little odd. Is it really a "baked" state where people can really build non-trivial apps or complex apps? I think you need a baked state plus time for best practices to actually develop.

ehutch79• 14 years ago

If best practice for database access security is to monkey patch the functions... ON THE CLIENT... i'm writing this off.

shawndrost• 14 years ago

"Note: Execute $ meteor remove autopublish on every project from the root project directory. It publishes all your data by default to the client and is poor practice."

This note does not belong in any article that also contains the heading "What is Meteor?". You should remove autopublish eventually, but it's a great piece of scaffolding.

Learn Meteor Fundamentals and Best Practices

Related Stories