Just my ideas and cents in here - and stories of things I saw in other parts of the programming world. It picks up quite something from the current roadmap, but defines some ideas for the long run:
That @cloudspider pointed out that people think that Meteor is an island in my opinion could and should be focussed on in the switch to an NPM package.
I still remember this from my PHP days when Symfony2 came out and revolutionized the community by embracing the idea of bundling your code into packages (and sharing it via composer) and make it all modular. Despite of being a complete rewrite of their earlier system, they also managed to get away from being a big monolithic project to being rather a community with tons of small projects, each fulfilling a small part but doing it perfect - and they took this idea (and a lot others) from the Linux eco-system.
In fact, they ended up with a structure that rather reminded of LEGO, which made the community very flexible and open. Other systems quickly started realizing the potential and kicked in and made use of these packages (https://symfony.com/projects).
But seeing Meteor being quite monolithic and creating wrappers (and I do not mean those created to support Fibers), which even go beyond by getting up to a new major version having breaking changes but still keeping e.g. their old naming convention (yes, I’m talking about you
mongo) is quite a blocker.
Please don’t misunderstand me here. I want to give out a huge thanks for those keeping the Meteor platform in such a good backwards-compatible state. At the same time I don’t know if this is the right way to go in the future because it adds a new stone of stumbling - and you can’t move as fast as the original package does. On the one side we agree that we should keep the packages updated, on the other side we don’t want the breaking changes they introduce, which brings a huge burden and slows down the development (in my opinion).
I know that the mongo package isn’t trivial - specially because we also need to make it work on the client-side (where only a subset is supported) - and this only is a sharing of my impression.
And this is exactly where the thought of Linux comes into play. Any distribution of Linux decides which program to update when and some setup-scripts just need an update when updating the packages.
I would LOVE if a version 2.0 of Meteor would:
- Drops Fibers - which removes the necessity of creating a wrapper for a package to make it look “fit for the environment” (which in itself would qualify to call it a 2.0 from a developers perspective)
- Have the courage to remain upstream with other packages and break when things should break (up for discussion and personal taste …)
- Be more modular by publishing more npm packages, embrace the usage of them
- Take a look at other commonly used libs and define interfaces. Let the main meteor-stack (Symfony called it the standard-distribution) use the previously used package but let the users build a bridge for other libraries which then easily could become the new standard by replacing the self-maintained package with it.
If some of you have worked with PHP and a Symfony project before, you don’t feel bound by anything but you have the impression that everything is so modular that you can just take out the package responsible for the task and write a bridge which makes your favorite package compatible with it.
Pretty long … but I hope you get the point