There is an unfortunate belief that any programming system which is significantly easier to use must automatically have caveats that make it unfit for 'production' use. And another similar belief that such systems are unfit for use by 'real' engineers. For example, if AngularJS had come up with an easier-to-understand way of creating components (directives) then it may have been dismissed as just another tool for novices. But some aspects of AngularJS are sufficiently complex that it is acceptable to 'real' engineers.
These are false beliefs and one of the reasons that (this is obviously an estimate off the top of my head) about 95% of programmer time is wasted solving problems that have already been solved numerous times. I see people hinting at security or other concerns related to using Meteor in production, but I have yet to see an example where one of these concerns actually caused a production issue.
I would be very interested to hear if anyone had actually tested Meteor in production, or had specific concerns related to security or anything that leads them to the conclusion that they must come up with their own different/more complex solutions to problems that Meteor solves.
Taking advantage of a system that solves 90% of your problems rather than reinventing six wheels is not lazy. Its just sane and mature.
The psychology of programmers related to tools and frameworks is childlike. Its as if everyone is in a playroom with a bunch of tiny blocks of different shapes. Every once in awhile a kid figures out how to construct generally useful connector shapes or recognizable objects from the smaller blocks. Then when another kid wants to use the larger pre-composed structures to play with, everyone makes fun of him because he is 'cheating' and must be too dumb to use the tiny blocks.
I've used it on a production site. There still is a learning curve, as with any new technology, but I've been very happy with it. I hope to do more with it. I'm working on a CMS built with Meteor, as my clients tend to be less than technically proficient.
The main problem I've had with it relates to IE7/IE8. The standard password encryption results in a JS error on those browsers due to the password encryption taking too long. We run the whole site on top of HTTPS, though, so we took a little hack to remove the extra client-side encryption on IE7/IE8. It's not ideal, but then again the default encryption for passwords is there primarily for those that don't use HTTPS (passwords are sent over the wire hashed such that HTTP sessions still maintain safety with the passwords...this hashing is slow by design, and the IE7/8 javascript engine isn't good enough to do it in a reasonable time frame).
I have deployed app written in meteor serving an API, and while it's a solid framework already, it still has some issues. Form handling is a bit of a hassle, compared to the rest, because it's still all done manually, and deployment on a custom server, while relatively straightforward, is a bit of a pain, because you end up having to manually reinstall some npm packages every time you update code. None of that are fundamental issues with the design of the framework, though. There's some quirks that aren't yet worked out, because it's a young tool, but it's already extremely powerful.
Comments
There is an unfortunate belief that any programming system which is significantly easier to use must automatically have caveats that make it unfit for 'production' use. And another similar belief that such systems are unfit for use by 'real' engineers. For example, if AngularJS had come up with an easier-to-understand way of creating components (directives) then it may have been dismissed as just another tool for novices. But some aspects of AngularJS are sufficiently complex that it is acceptable to 'real' engineers.
These are false beliefs and one of the reasons that (this is obviously an estimate off the top of my head) about 95% of programmer time is wasted solving problems that have already been solved numerous times. I see people hinting at security or other concerns related to using Meteor in production, but I have yet to see an example where one of these concerns actually caused a production issue.
I would be very interested to hear if anyone had actually tested Meteor in production, or had specific concerns related to security or anything that leads them to the conclusion that they must come up with their own different/more complex solutions to problems that Meteor solves.
Taking advantage of a system that solves 90% of your problems rather than reinventing six wheels is not lazy. Its just sane and mature.
The psychology of programmers related to tools and frameworks is childlike. Its as if everyone is in a playroom with a bunch of tiny blocks of different shapes. Every once in awhile a kid figures out how to construct generally useful connector shapes or recognizable objects from the smaller blocks. Then when another kid wants to use the larger pre-composed structures to play with, everyone makes fun of him because he is 'cheating' and must be too dumb to use the tiny blocks.
I've used it on a production site. There still is a learning curve, as with any new technology, but I've been very happy with it. I hope to do more with it. I'm working on a CMS built with Meteor, as my clients tend to be less than technically proficient.
The main problem I've had with it relates to IE7/IE8. The standard password encryption results in a JS error on those browsers due to the password encryption taking too long. We run the whole site on top of HTTPS, though, so we took a little hack to remove the extra client-side encryption on IE7/IE8. It's not ideal, but then again the default encryption for passwords is there primarily for those that don't use HTTPS (passwords are sent over the wire hashed such that HTTP sessions still maintain safety with the passwords...this hashing is slow by design, and the IE7/8 javascript engine isn't good enough to do it in a reasonable time frame).
I definitely agree with your main point.
I have deployed app written in meteor serving an API, and while it's a solid framework already, it still has some issues. Form handling is a bit of a hassle, compared to the rest, because it's still all done manually, and deployment on a custom server, while relatively straightforward, is a bit of a pain, because you end up having to manually reinstall some npm packages every time you update code. None of that are fundamental issues with the design of the framework, though. There's some quirks that aren't yet worked out, because it's a young tool, but it's already extremely powerful.