The author says that Meteor is a framework that is "pretty similar" to Rails, but that is not true.

Meteor is totally different and strongly geared towards "real-time"[1] responses, unifying client-server code bases and automatic state propagation to all connected clients.

Rails embodies convention over configuration and the don't-repeat-yourself principle. It's ecosystem is generally geared towards server-side processing, although there is nothing inherent in Rails itself that would make it a bad choice for single-page apps with "real-time" responses.

Meteor is much more useful than Rails for certain classes of applications, but likewise Rails is much more useful than Meteor for other classes of applications.

[1] I don't like this word. This is what "real-time" should mean: https://en.wikipedia.org/wiki/Real-time_computing

I didn't use demeteorizer for https://lawyermatch.me, but after making a meteor bundle you just get a node app anyway, so deploying to production didn't really hold any surprised in store for me.

Related to production-meteor, I guess phusion passenger supports meteor now, does anyone have experience with the pluses or minuses of passenger over node/forever + nginx? LawyerMatch has been a way for me to test new tech to begin with, so I'm interested in giving passenger a try for a production app...

Author asserts Meteor scales poorly, which inspired his script "demeteorizer" which helps only if the project is deployed to author's hosting service "modulus.io"

I ran a meteor app as an entry system for a local design awards show last month. Everything went swimmingly well and people loved the fast app-like interface. The only place I had trouble was on the admin side where large amounts of items were sometimes not loading properly (usually a page refresh would clear the problem though). My takeaway was 1) This is beta software people, of course its not going to be perfect and 2) Deciding what should be sent to the client takes some thought and I could have almost certainly made things more efficient. With time, I think both of those issues will be resolved what with the highly active meteor community and MDG making great progress on the framework, and with me thinking more 'meteor-like' and building my apps more efficiently.

If you need to strip a lot of boilerplate and modify the code of a large framework in order for you to use it enjoyably, maybe you should look into different frameworks instead? Perhaps a microframework.

One note on the Meteor's Scalability. Meteor cannot be scaled with the traditional way we scale apps. Adding more instances does not leads to a scalable meteor app.

Since Meteor gets updates from Mongo. Since one write happens, every instance needs to be get that change as well. In Order to have that, we need to use the Mongo Oplog integration. See more info on that.[0]

Official Mongo OPLOG integration comes with Meteor 1.0 (early 2014), Since then you can use my Smart Collections[1] for Oplog Support.

[0] - http://meteorhacks.com/lets-scale-meteor.html

[1] - http://meteorhacks.com/introducing-smart-collections.html

Is it just me or does that page not really work on a touch screen device (iPad)? It loads with width exceeding screen width and the pinch gesture doesn't seem to work. It just scrolls horizontally. Or does that not make sense?

If the Meteor packaging/dependency system can be easily automatically converted to node.js standard...

...this makes me ask why the heck Meteor doesn't just use the node.js standard to begin with?

I made this with Telescope and Meteor: http://usability.userium.com/

It's a bit slow, might be because I can only use one dyno on Heroku with Meteor, because it needs session affinity.

"If you need video streams like CodersTV. All of these are built with Meteor and are awesome examples of things you can build."

I need video streams in Meteor. Show me where.

I thought of building something akin to a social network for the sole purpose of letting the users create user scripts to customise their profile in lua.

I don't get it. There is the "meteor bundle" command, which as far as I can tell does the exact same thing. "meteor bundle" turns your Meteor app into a regular Node.js app. It does not bundle Node.js itself and it does not bundle MongoDB.

The author mentioned that Demeteorizer allows a Meteor app to be able to run on any Node.js hosting provider. "meteor bundle" does that too. In last week's announcement about the Phusion Passenger app server + Meteor support, I documented how one can use Meteor bundles with Passenger. If you look at the instructions[1] you'll see that the instructions for deploying a Meteor bundle are the same as deploying a Node.js app.

So how is Demeteorizer different from "meteor bundle"?

[1] http://tinyurl.com/mj9ex3y

As pointed out by another user, I was annoyed as you reading the article, but the script can be used outside of their PaaS and the source is on Github [0], even though the author did not link to the repo. Typically, I have noticed the prevalence of Github and free repo hosting means people link less and less, and expect you to auto-magically find their code via Google search, or by just clicking one of the social buttons (even though the nerdier you are, the more you hate them and refuse to use them).

[0]https://github.com/onmodulus/demeteorizer

I think the author was only talking about how to make Meteor scale on any hosting service by making it into a raw node.js app, something that more people have experience scaling. The NPM package demeteorizer, which was written by the modulus team, can actually be used to turn any meteor app to a core node.js package, which can then be hosted as you would any other node.js apps and can use any node.js hosting service (nodejitsu, heroku, appfog, modulus.io) or roll your own on bare metal (dedicated/aws).