I guess it wouldn’t hurt to link in this post: What is Meteor missing?
Infinite possibilities!
Let’s not ressurect super old threads though - I’d suggest keeping the discussion in here.
3 Likes
Build tool is of course very important and was biggest pain point for some time but also already worked on. So I voted scaling and performance (second place currently so if MDG is listening it should work on it next). Time for meteor to grow up 
Nice poll, but it would’ve been nice to be able to select multiple answers.
2 Likes
Indeed - we abandoned the poor thing in its childhood!
With the build tool, production source maps that could be sent to various services on deploy (without being deployed to production themselves) would be great (recently mentioned here). I also hope MDG pushes the envelope for something past route-based code-splitting (demand-/ config-/feature-based, etc. Not sure what it’s all called, but with the idea that over- and underbundling and/or over- and underfetching of actual code is kept to a minimum.)
1 Like
Indeed - though I wonder if the real solution is something like Fast-Boot by Ember. We actually want all the code/templates to load upfront for performance, we just don’t like how long that takes to render for visitors.
1 Like
The one thing I need for Meteor to be usable for me is better offline support with service worker
My wish would be a meteor fully transitioned to npm.
Ah that would be cool. I suspect someone can roll this functionality on their own though?
What is the driving force for you there?
I started with meteor without knowing node, and was happy that meteor took care of everything, but now that abstraction layer is broken, so I want to be able to rely mostly on node and opt in to the parts of meteor I really need.
2 Likes
awesome and out of box thought!!!
1 Like
Not a serious wish but I think that npm is a deeply flawed dependency system. Not only does it allow people to delete their repositories (leaving others in a lurch), not only does it seemingly create a kind of braindeath - this is an actual function from a package used by quite a number of apps
function isBetween(number, upperBound, lowerBound) {
return number < upperBound && number > lowerBound;
}
… no, it also still seems to pull in everything at least quadruple times.
I’m currently deleting the UbuntuOnWindows subsystem (to reinstall it, due to me installing it when it was in alpha, it behaved a bit bonkers) and due to the long filenames restriction on Windows, I have to rename some folders.
And I think I have seen the module babel-plugin-transform-react-jsx-source at least five(5) times now. A sane system (aka “the system they spent 5 minutes thinking about how it ought to work instead of blindly coding ahead”) would have pulled in a dependecy exactly once.
On a more serious note, easier non-Galaxy deployments would have my vote.
Word, to me Node/NPM and Meteor used to be Android vs iPhone
It would be an epic troll if someone who writes one of those packages which seemingly exists octatuple times in every project then put the text of the epic saga Edda or something similar into his source code only to make everyone’s source folders explode in size.
Passenger is pretty nice to deploy meteor apps.
It’s been a while since I researched anything, but yeah, a usable first render ASAP is all-important. With transfer- and loading, I’d want pretty granular control, since apps and clients vary a lot. In extreme cases, I’d want to transfer and load in the fore- and background by priority (of actual, then anticipated need, without overloading). Something like transfer/load data X with no thought to performance after initial render. Then transfer/load data Y in background on idle. In time, maybe something more sensitive to performance (using some metric like RAIL). Hoping Meteor and Galaxy could make stuff like that more accessible.
It seems like you could go back to things like DO, Heroku, Modulus, etc., but why?
Cheaper
Time is money…