Great news! Using build engine on top of Webpack sounds good to me. There a lot of ‘cool’ things in Javascript Universe, but not so much organizing and structuring mechanisms that put them together.
Great news! Congrats on 1000 customers. By the way, any plans (and if so, what sort of timelines) for some sort of Galaxy Corporate Edition that can be deployed on non-public infrastructure? Those of us that have to deploy behind corporate firewalls would love to be able to play that game and contribute to MDG’s bank account…
For the name Apollo, I do think it should be reconsidered. When I think of Apollo, I think of the moon missions, where most of them ended in failure and death. I know it’s easier to get data to the client than to get to the moon, but the name doesn’t inspire confidence. Satellite, Transmission, Beam, Warpseed, Wormhole, something along those names would still be spacey and have a better meaning.
where most of them ended in failure and death
??? What the hell are you talking about? Apollo never lost a man in space. Of the 12 Apollo missions, 10 were brilliant successes. Apollo 1 ended in tragedy – fire on the ground. Apollo 13 was the “successful failure.” I think it’s a great name, if anything a little too grandiose!
Hmmm, I have no idea. I always thought there were like 14 attempts to get the moon or something, with one of them being successful.
Well, think again.
IMO Apollo was the boldest and most successful exploration program humanity has ever accomplished. I guess you might say Kepler discovered more but certainly wasn’t as bold.
Right?
Also, Apollo was the God of Physicians and is to whom the Hippocratic Oath is made.
http://www.medspirit.com/logo/emblem/index_clip_image001.jpg
Plus he was a kickass character in Star Trek (original series), in which the greek god is actually a powerful alien being. And in Battlestar Galactica where he’s just a dude.
We might be getting off topic. I like the MDG goals too although it makes me sad to see them moving away from stuff they worked so hard on.
IMO the Apollo thing may be the truest expression of what Meteor is/was. Ultimately, an easy way to get and set data between the client and server. The result will be you can stick any front-end and database.
I still have a preference for Satellite, as it’s gender neutral and spacey/technical, but Apollo is respectable too.
I am currently listening to Matt’s talk and your announcement is awesome. Its good to hear that IKEA is using Meteor. That means if they keep using it others will follow. And congratulation on your customer bases Nevertheless, what is the advantage to divide up the maintenance responsibility for Meteor’s tools? I can see that this is a better solution for you, but what does that mean for developers? Is that a good move? Thanks and keep up the good work!
Glad Meteor is finally being taken by the scruff of the neck and being driven forward. I just want the ability NOT to use MONGO for my db and generally for MDG to take the best of javascript that’s out there and make it their own rather than trying to shoe-horn in projects from other copmanies/groups. I want a stable environment and peace of mind for my career in knowing that if I’m going to put the time in to learn this that it’s still going to be around in a few years. Tighten up the commercialisation and it will be uncontestable.
Satellite just sounds too bland, imho.
I was waiting for these changes to start learning meteor more than for the todolist Really happy to see this change coming in 1.3 .
Apollo (Απόλλων) is a great name and very famous in Greek Mythology as he was the 2nd most important of the twelve Olympian gods behind Zeus.
I remember at my first job (back mid 90s) we had named our network Olympus and our PCs were given names after the Gods. That was fun.
Apollo means flexibility. It’s not that I don’t like Mongo, I just want to use right tool for a job.
Poor Google…
“How do I use apollo with mantra for meteor without blaze but react?”
Besides being its new DataLayer and freeing Meteor from MongoDB, will Apollo finally address some of the Meteor’s scalability issues, too?
The main difficulty that developers seem to run into with Meteor’s livedata is that it is hard to reason about scalability and difficult to turn off (or dial back) reactivity when it might be necessary for scaling.
We want to address these issues in Apollo by a) making it easy to reason about the cost of reactivity for each query, and b) allowing developers to fine-tune reactivity when necessary.
You can read more in Sashko’s blog post and the high level design overview for Apollo.
+1 on local build performance, it takes a long time to rebuild the app for me, this makes pixel pushing take an inordinate amount of time. About 45 seconds… Can’t wait for this, i need some time savers.