3 ms·

I really like coding in Meteor. When deciding instead of thinking as to whether I should use meteor I thought on why I shouldn't. The main reason to not use it

by Tarang 13y ago

I really like coding in Meteor. When deciding instead of thinking as to whether I should use meteor I thought on why I shouldn't. The main reason to not use it was scaling but It's evident the meteor guys are working on that for the 1.0 release. (See https://trello.com/board/meteor-roadmap/508721606e02bb9d570016ae https://trello.com/board/meteor-roadmap/508721606e02bb9d5700...) Hopefully they do this well but I feel from their work before they will. I've been using Meteor since it was sub v0.2 and its just improved each iteration. First it was the license, then authentication, then it was routing, then its ability to play well with JQuery. Slowly all of the issues with it are disappearing. One thing I like is in meteor code is isomorphic. And on the server I'm not in the callback hell I was having with node. So there are evented fibers that do all this stuff and the code remains clean! Best of both worlds.

1qaz2wsx3edc 13y ago
Growing pains, that's all. They've really done a lot of work. The jump from 0.6.4 to 0.6.5 was 775 commits. Wow. We're seeing concepts being fleshed out, they'll be refactored and strengthen in time. The team seems to be fully focused on 1.0. Scalability is still a big concern, but it's only a problem you can be so lucky too have. Meteor still needs to improve code structure, there's no common architectural pattern yet (just some lose guide lines). In my opinion, it would be a benefit. Meteor is still in its infancy and a developer is left to their own devices, rather then common sharable patterns. Rails does this well with the plethora of use-case strengthened API design, a benefit of it's maturity. Meteor will get there.
- joshowens 13y ago
  Yes, I remember rails going through this same "growing pains" of leaving a lot of stuff up to the developers. I look forward to the ride Meteor will provide and see where it gets.
joshowens 13y ago
Yeah, the next release will have OpsLog support for MongoDB and it will help tremendously with scaling if you are willing to figure out how to get OpsLog working for Mongo.

by Tarang 13y ago

1qaz2wsx3edc 13y ago

Growing pains, that's all. They've really done a lot of work. The jump from 0.6.4 to 0.6.5 was 775 commits. Wow. We're seeing concepts being fleshed out, they'll be refactored and strengthen in time. The team seems to be fully focused on 1.0. Scalability is still a big concern, but it's only a problem you can be so lucky too have. Meteor still needs to improve code structure, there's no common architectural pattern yet (just some lose guide lines). In my opinion, it would be a benefit. Meteor is still in its infancy and a developer is left to their own devices, rather then common sharable patterns. Rails does this well with the plethora of use-case strengthened API design, a benefit of it's maturity. Meteor will get there.

joshowens 13y ago
Yes, I remember rails going through this same "growing pains" of leaving a lot of stuff up to the developers. I look forward to the ride Meteor will provide and see where it gets.

joshowens 13y ago

Yeah, the next release will have OpsLog support for MongoDB and it will help tremendously with scaling if you are willing to figure out how to get OpsLog working for Mongo.