I would like to see a module system for stylesheets similar to ES6 modules. Any time a Blaze/JSX template or a JS class makes a reference to a CSS symbol (or any other static resource such as an image), I’d like to be able to declare an explicit fine-grained dependency on that resource, so that in some future where code splitting (a la webpack) is supported, it knows to only load a subset of the static resources instead of having to load everything on the initial page load.
So for example MainView.jsx would require MainView.scss as a dependency, thus whenever the code for the former is loaded in the browser, the latter would be included as well. In addition, declaring dependencies between stylesheets would allow precise control of loading order, making it easier to reason about the cascade instead of having to play games with selector specificity or using !important.
In a similar vein, I’d like to see support for compiling multiple SVG icons into a single static resource which only needs to be downloaded once, instead of either having to have a separate network connection for each image, or having to inline all SVG imagery in the HTML causing potential duplication of common icons. Ideally, it should be able to search my template code for references to icons (possibly using the same dependency system as described above) and create a minimal subset of the artwork I need, which could be inlined into my top-level template. (I know Polymer manages to do something similar to this but I am not sure how it works).
Basically what I’m after here is minimizing latency and bandwidth by reducing the number of network connections needed to download artwork and styles.
Interesting. Although I’m less concerned about global selector name conflicts, and more interested in late loading and predictable rule ordering. (Also, not all selectors should be locally-scoped - selectors representing dynamic states such as .disabled or .selected should be the same across all components.) And I’d want it to work with Sass or whatever your preferred brand of stylesheet syntax is.
In the beggining there was this strong marketing on Meteor about creating universal code. So we got allow/deny rules that are not recommended anymore and should be deprecated.
We got .isServer/.isClient/.isWhatever methods for the sake of this universal trend, and I find those really helpful for some scenarios.
Then, we got Fibers on the server for the sake of async thinking. There are some requests to remove Fibers and I totally agree with that, because Fibers totally breaks the universal client/server feeling on Meteor. So, it’s my next point: remove Fibers, and avoid breaking the universal client/server feeling. I think async/await es7 functions a lot cleaner about what is happening and works on the browser too using babel+regenerator.
Also, Fibers make it harder to upgrade Node.js (we still use v0.10.x). Maybe right now this upgrade to v4/v5 is not only a Fibers issue, but I’m pretty sure it was the main issue on the v0.12.x days.
TL;DR
officially deprecated allow/deny rules
remove Fibers, use Promises and es7 async/await instead (seems to be available on Meteor 1.3)
upgrade Node.js (already on roadmap for immediately after Meteor 1.3)
Most other javascript frameworks favor promises. I would also like to see integration with Bluebird or some other framework, making promisification super straight forward and easy.
Quite frankly, I think the javascript ecosystem has changed and futures no longer make sense for meteor. Also, promises work on both client and server, so they go hand in hand with meteor’s basic paradigms
High compatibility with Node.
Things that work with node, in general, should be able to transfer seamlessly to meteor.
Take for example Electron. It is a pain to make it work appropriately with Meteor. Should be able to work with Meteor as if it were node.
Might even be cool to download it as an NPM package in an existing project and use something like node_modules/meteor/meteor to execute project, and node_modules/meteor/build to compile into an application that can be run the same as any node
Reactive aggregation and mongo 3.2 upgrade
Sometimes, plain publications just don’t cut it or end up being insanely complicated to accomplish some means.
Take for example, publishing a user record, but only publishing their common groups. Very irritating and hard to read with plain publications.
Aggregation provides the means to tackle complex data structures and queries. If they could be used in publications? Game-changer, I think.
Easy way to only load the code you need on a given page?
A more opinionated framework (well a framework), like not chose the templating you like, the db you’re used to etc. That’d make it much easier to start because no question asked, and unify the packages created by the community (atm moving to React is quite annoying because so many open source things are on Blaze…)
Integrated access to mongo functions like aggregation, map reduce.
wish”