I do not know how you do it, but I appreciate you so much Meteor Group!
Today I was running my development environment first time since March and Meteor recommended an update for new version. I installed the update and right after my Meteor app became 100x faster. My f****** eyes were in tears when I recognized that modifying CSS-styling was replicated in my application as fast as Mongo live queries! Could not believe that.
I would f****** move to states just serve a coffee for you mates! 
To really enjoy the power of Vue single file components you have to use webpack:webpack and the npm package vue-meteor. It could be smoother for newbies.
Good, lets not distract the core with âI wantsâ.
So DDP will be dying off?
Yâall need a fourth product that starts with an E, so you can have a super cool acronym MAGE. Or products that are I and C so its MAGIC.
And yes, I realize I might be a bit biased.
Looks like rebuilding the build tool for code-splitting and build-time improvements has been pushed out to long-term goals. 
I hope that itâs an evolution of DDPâŚ
Itâs a fundamentally different technology, but I it will be quite easy both to switch from DDP, and to build new apps on top of it. Clearly that wonât happen overnight but I think itâs not so different from how people are building apps on DDP, except with different underlying technology.
Except it means all our current knowledge that weâve built up around building, scaling, and optimizing performance/security of DDP becomes useless.
I guess what I am really asking is if DDP will be worked on at all going forward, or more like Blaze in a PR welcome kind of stance? The roadmap seems to indicate that many things like accounts will a concern of Apollo instead. Feels to me like DDP will be mothballed like Blaze.
This can not happen soon enough imo.
In the interim can we please make the meteor api easily accessible from local npm packages?
what will we see in 1.4 of the roadmap? I think it would be too soon for Apollo, wouldnât it?
Iâm interested in the technical design of the packages transition from Meteor isoformat to NPM. I would love to see the design process happen in the open even at an early stage (as for Apollo) so that people experienced with Meteor packages and build system could shim-in and contribute.
The Meteor and Apollo projects are on independent release schedules.
They did a great job of that with module support. I think Meteorâs delivery process has made significant progress in terms of openness. This roadmap is another signpost on that⌠road.
It will. Expect to see something really soon on this front.
This roadmap is good, imo, but I agree that build tool improvements or rewrite should top the list. At least some kind of explain mode so we can see why running the app takes 5 minutes to start up or building the app takes 20. If we know more about what pkgs or plugins are slowing down our builds, we can make adjustments. Build slowness is really the only remaining serious issue in 1.3.
Build time is still an issue with 1.3.2. Iâm tired of hearing my VP of Engineering yell about the slowness and it is hurting productivity.
This! Meteor gives and takes. On one hand you gain a lot of productivity because the framework allows to build fast and on the other hand you loose all this productivity gains by waiting on the server restarts.
Yeah, I agree - I would love it if we could make a drastic improvement on this.
I have to agree that build slowness really cramps Meteorâs style. It makes it feel like youâre using old and out-dated technology instead of something quick and cutting edge.
Also â all those times when you have 15-seconds with nothing to do make it tempting to quickly check the nytimes or facebook or go get a cup of coffee, which means that 15-second build times end up becoming 3 mins more often than not.