81–86 of 86 posts
There's a problem I have with frameworks in general. They tend to streamline your thinking too, which is fine if you don't care about making something original or can't see how developing with new approaches can impact the outcome of your product.
Earlier quoted context omitted.
> Both language and platform affect performance, otherwise JRuby would be the same speed as native Java, which is not the case. No. JRuby is the platform, that's why JRuby is not the same speed as native Java. But CoffeeScript has the same speed as plain JavaScript, because both are running over the same platform (NodeJS) even if they're different languages. It just happens JRuby can only run a single language (Ruby)…
I'd like to disagree. The language specifications provide various limits on the kind of performance you can get, regardless of the platform. Performancewise, for the record, I find JavaScript to be wholly adequate for writing servers, but to say that the platform is what makes it slow(er) doesn't ring true to me. For example, JavaScript has a few poor design decisions that make implementing performant arrays really h…
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
Earlier quoted context omitted.
Usually I would agree, but this is a website built by the team behind the framework. When you're making a tool for people to use you really need to put your best foot forward.
Atmosphere is built by Percolate Studio. I know Tom Coleman works there, but as far as I know, he's not a part of the MDG. He should be given how good Iron Router is, but that's another issue :)
Earlier quoted context omitted.
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.
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…
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 :)