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!
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.
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.
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.
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.
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.
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.