Looking at the releases, that should be in 1.3.3
So, moderately useless, then. I’m liking Mongodb less and less. There’s a reason why you try to normalize stuff in a database - yes, I can denormalize the data and put it into every document it’s relevant to.
And then I update the data - and now I have to do multiple updates instead of just one (and god help me if I forget one). I’m really not seeing the usefulness of these kind of dbs unless you have a singular table with next to no external dependencies.
2 Likes
This is exactly why Apollo is a thing.
Woo on v1.4!
why not just let us use whatever node version we want. why do we have to lock into v4.
Especially since Apollo desires v5 
Node 4 is still LTS so it makes sense to support it. Node 5 doesn’t have a future (and won’t be LTS), and Node 6 is so new that certain npm packages that Meteor relies on break with it (see https://github.com/meteor/meteor/pull/6923). So for now it makes sense to stick with Node 4, but Node 6 support is coming.
This is impractical as we’d need an n^2 matrix of architectures to node versions.
1 Like
We’re hoping to have a beta that includes Node 4 within the next few weeks. Not sure on a timeline for Mongo 3.2 yet but we’re making solid progress, you can follow along here: https://github.com/meteor/meteor/issues/6957
3 Likes
This is the only way we could work this out.(and even less liability to MDG). It would be nice if we have done this before since most of the users already have these build tools setup.
3 Likes
Mongo 3.2 is long available, I’m running it without problems for months. Only difference is that it becomes the standard version for everyone. If you run it on WT, the space implications are tremendous. Have seen that it takes only 1:25th of the previous space, as older Mongo keeps the file size per collection at it’s maximum size, even when you delete all docs in it.
It’s also faster but that’s not so apparent as the space saving
3 Likes
Is the aggregation pipeline by any chance something that feeds into a result that ultimately is reactive? [hopeful expression]
You can make it real-time by yourself now. But you need do extra steps.
The book Meteor in Action talks about this.
With Node 6, coming, will you consider to use directly Ecmascript 2015 with no transpilation? WebKit has 100% coverage, Chrome and Firefox 95%, Explorer is a dead fish for Academic applications and Edge is doing well as well. The only thing needed will be async/await polyfill. Would be great to finally comfortably debug apps in native code! What will it take in Meteor? Will it be only to remove the “ecmascript” package?
They can remove transpilation when they move to node 6 for server side code but they cannot remove transpilation for browser as people use all kind of browsers not just the cutting edge.
It’s all right when developing mobile apps or web apps in closed “company/academic” environment where you can assure the use of the latest browser. Which in my case is ok for 10000s of users. I really can’t wait to ditch babel 
Is there any problem with debugging with babel currently?
There are some issues that i do face when using async/await on client.
sashko, yes, the source maps never really work … the async code keeps flying around, setting a breakpoint is a pain … and debugging transpiled code is …not pleasant to say at least. Also, sourcemaps slow down the whole debugging experience and webpack compilation functionality .
Good stuff Well done, MDG!
1 Like