If you had one wish for Meteor, what would it be?

21

What is the driving force for you there?

22

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
23

awesome and out of box thought!!!

1 Like
24

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.

25

Word, to me Node/NPM and Meteor used to be Android vs iPhone

26

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.

27

Passenger is pretty nice to deploy meteor apps.

28

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.

29

It seems like you could go back to things like DO, Heroku, Modulus, etc., but why?

Cheaper

30

Time is moneyā€¦

31

There are a few things keeping me for returning to Meteor (which I did like a lot):

  • the build system, compared to webpack, rollup, etc.
  • the fact that I canā€™t install and use it fully through npm
32

A way to debug problems, like I would like to see what my string variables are. Hard to know which of my functions arent working properly.

33

I wish the development experience with Meteor was cleaner and simpler. A full blown open source IDE experience would be awesome. A free coding environment that fully supports things like ā€œgo to definitionā€, find all occurrences of a variable (not just the characters, i.e. a variable of the same name in another scope shouldnā€™t match), all of the basic refactoring operations, changing code in the debugger instead of having to change source and starting over, solid automatic profiling, code-coverage, etc.

I have been working on one small piece of this puzzle, automatically identifying and adding the import statement necessary to resolve an undefined variable.

In doing so, Iā€™ve had to borrow a lot of code out of the meteor tools directory. The experience has led me to think that it would be awesome if this code was broken into smaller, standalone packages to encourage development of other tools to work with a Meteor project. It could spur tool development if there were packages available to easily understand identify and process Meteor package.js files and isopacks for example.

Also, I greatly appreciate Meteorā€™s package.js and isopack structures. They have a whole lot more information in them than npm packages. Automatic static analysis of npm packages is virtually impossible. Not so with Meteorā€™s packages. If we switch to npm packages, we desperately need to add a layer of information somewhere either through additions to package.json or through a separate json file.

3 Likes