[methehack]

Haters gotta hate.

The framework is brilliant from a productivity and sheer enjoyment perspective. I don't know if it will scale; you don't either. My estimation, though, is that the team building it is very clever and super-aware of what they need to do to make the framework succeed from a scaling perspective.

A lot of the comments here are spitballs from the back row of the classroom. They are willfully uninformed and unfair. It is hard to imagine these commenters are paying much attention during the learning portion of class.

So go forth, meteor team. You're fighting a great fight here. Ignore the naysayers and do the great work you know you can do. Your best way forward is to prove the haters wrong. Maybe a few will even become lovers, though I wouldn't count on it. If you build it, they may come. [update to spell 'perspective' correctly. Ugh]

[joshowens]

I love this comment, great job!

Also, people are scaling it, we just aren't hearing about it much. I am working to correct that, these trials of scaling need to be more public right now.

[niallobrien]

Scaling Meteor is my biggest concern right now as I contemplate diving any deeper with it. I'm well aware of Mongo's oplog but the lack of Mongo sharding, the sticky session requirement, server resource consumption (RAM required per client), lack of proper offline support (last write wins) and sheer devops work required to scale is off-putting. Hopefully tomorrow's release of the remaining Bulletproof Meteor content will ease my worries. But I cannot shake the feeling that in terms of cost, something like Firebase would work out to be much more cost efficient. Also, the whole ecosystem of wrappers is plain silly. It feels like the MDG & the community are just reinventing the wheel time & time again. Oh we got Cordova support? What's that exactly other than some CLI tools? Of course any web tech should support Cordova, that's what it's built for. The Ionic Framewoek are light years ahead in this regard.

[joshowens]

Niall,

I sense that you don't really want an answer to this, you have already made up your mind...

Why is the sticky session requirement a huge devops concern?

From what I understand Mongo sharding shouldn't be hard to implement, but I haven't tried it myself. I spoke to Abigail Watson about it, and she said her first tests with it were promising.

RAM is always a precious resource, so I understand being concerned about it. Are you seeing some absurd usage per client? I am seeing about 350mb processes to handle around 75 connected clients.

Is there a framework or platform that gets the 'last write wins' correct? I seriously doubt that because I doubt you can apply a blanket set of rules for offline support.

I don't think scaling is off-putting, you just need a mongo cluster and then you can add oplog enabled Meteor processes to your pool. I don't see how this is any different than something like Java or Ruby...

The idea of adding Cordova may seem simple or small, but MDG putting it in led me to building my very first mobile app. Prior to trying Cordova and Meteor integration, I usually advised clients it would be easier to just build a responsive design instead of trying to build a native app.

I am sure if you looked at the commits around adding Cordova, it was a little more then just glueing together some CLI tools.

That being said, if Ionic floats your boat, go enjoy it :)