Hi, there! I wrote an article about MeteorJS weird engineering decisions:
https://medium.com/@kschingiz/weirdness-of-meteorjs-framework-ef4373ff487b
Would be happy for your opinion on that.
Thanks!
15 Likes
Nice, found out new interesting things about Meteor, had no clue about that db thingie.
4 Likes
Yea those are great ideas. Especially the asset management that allows using a glob pattern and NPM dependency management syntax matching that which is used by package,json. It is flexible and familiar to people. Im hoping other people will weigh in on these ideas and we can see what the consensus is
1 Like
I sincerely don’t understand your article.
Not sure why you did not post here, open some PRs, close them later if not needed, encourage people to buy into your opinions and improve the architecture.
Not everyone hates meteor packages, not many have slow internet, I feel your points are stretched, exaggerated, some personal opinions are presented as issues of the developers or of the community .
I think we would all love to see those great ideas materializing in PRs rather than forgetting all the greatness of many years of effort put by many in here.
Since you asked for an opinion, my opinion is that I do not understand the existence of this article.
7 Likes
Correct me if I’m wrong, but wasn’t the Meteor packages system developed before/at the same time as npm?
2 Likes
I’m using Meteor.js for more than 5 years and didn’t complain for any of them. 
1 Like
You didn’t, but someone else maybe did. The author provided valid points and their drawbacks. Hopefully, the suggestions provided in the article can be materialized into PRs.
On a side note though, lol Meteor doesn’t need any more negative press 
but great info nonetheless that I don’t think has been discussed in the new roadmap suggestions.
5 Likes
Meteor can take a little criticism and keep on truckin haha. I mean the author has spent three years using Meteor. He has earned the right to write up a little critique of Meteor, he is obviously a fan of the framework or he wouldnt even bother. And His article showed some of us some new stuff which is always a plus
5 Likes
An interesting read. I did not know about the db. It’s not something that’s caused me a lot of problems, but I agree it’s stupid.
The npm vs atmosphere thing is more complicated. Bpm doesn’t currently allow for custom builds for client/server. Or more importantly for legacy vs modern browser’s. As I understand it this issue is the main blocker to moving to npm. I agree though, moving to npm would make life much easier. We could install meteor packages from github direct, negating the need of custom registries entirely.
If meteor were to fully divest the core packages to npm, we could start using them outside of meteor. I already use a custom.version of blaze outside meteor and it works beautifully, but it depends on some very old npm extractions of packages.
1 Like
There’s no need to be so defensive everyone. We should always keep a critical eye on our tools.
After all, they are there to serve us, not the other way around.
Thanks @kschingiz for sharing your weird discoveries!
I think a lot of the decisions made sense in historical context, but now look very strange in the world where everything is standardised around npm and the package.json format.
There are plenty of things Meteor could embrace to make everything more aligned with the rest of the ecosystem.
At the same time backwards compatibility has long been a goal, so dumping atmosphere packages is just not going to happen.
I am definitely interested in a part 2
10 Likes
Interesting read. Most of the stuff was missed when talking about the roadmap, buried under the Atmosphere vs. NPM debate. I like the idea on getting rid of the local database. But I think the both NPM and Atmosphere packages at the same time is not feasible until all of Meteor is on NPM (but even then I think it is a bit cumbersome at best). I remember @benjamn talking about a possible new feature where there would be (as in the article) a Meteor section in package.json which would allow to properly build the package for Meteor and possible open some additional features in the package for Meteor (for example publications or use of DDP).
3 Likes
Hi, there! Thanks for your responses. I read them carefully and make conclusions on them, thanks! Someones understand me wrong, I am NOT somebody who hates meteor, I use it everyday and I can’t imagine I will be using something else.
The post I have written is a some sort of “top reasons why you should choose meteor”, but showing not only pros but “cons”. Meteor newcomers should know what to expect from the platform.
I know that most of the things are complicated, especially npm vs atmoshpere, but as I see that most atmosphere packages get abandoned quickly (except core packages) and we can’t deploy custom packages to own packages server, I make conclusion that I should avoid using/developing atmosphere packages.
Sometimes to make it better we must accept criticism. I don’t expect the problems will be fixed today or tomorrow, but in my opinion they should be at least on the roadmap for the 2.0.0 or even 3.0.0 version =).
6 Likes
@kschingiz I may have been misunderstood too. Your article is very interesting and raises real questions, and it was not its content that made me react. But it might seem, to someone who does not use the platform or someone who is reluctant to use it, as an article that points to weaknesses in Meteor.
2 Likes
Not to discount your arguments, but It’s easy to say that these are “strange engineering decisions” without understanding why they were made. I’m sure these weren’t made lightly either, and they were made by some very talented engineers. Most of them probably have decent explanations as well, so lets see if we can shed some light on them.
Problem 1: Meteor requires 345mb database on your machine
Yes this is a decent bit of data, but most of it is only necessary to download once. While I’m sure this could probably be be slimmed down a little the reality is that much of this database is necessary for the the constraint resolver to do it’s job. Without the constraint resolver we get into either misaligned dependencies or multiple versions of the same package as is the case with NPM. The Meteor package system is in this way (and many others) far superior to NPM. It solved many issues that NPM faced in arguably better ways, before NPM did.
Problem 2: Strange packages registry workflow
Are we debating the protocol here? It’s DDP utilizing method calls and subscriptions which most of us should be pretty familiar with. If we are to argue protocols, then why REST? Why not GraphQL?
Personally I think the way the package server works is fantastic. You can literally mirror the package database in less than an hour and once it’s done the mechanics to keep it in sync are built right into the API. Awesomely, you don’t have to write hardly any code to do this. You can just install the peerlibrary:meteor-packages package, and call one function and you’ve got a full mirror of the package server database which you could use to create a REST, GraphQL, or any other type of API your heart desires.
As far as custom package repositories goes there’s Stratosphere, which could probably use some work, but it’s FOSS, so you are free to help move it forward.
Problem 3: Managing Package Assets
I agree here… There could be a much better way to add folders of assets. Let’s not forget though that it’s a JavaScript file that will execute and so I’m sure you could read the contents of the directory and build the array to pass to api.addAssets.
Problem 4: Managing npm dependencies
I’m also not a fan of this API, especially because it causes loading of multiple copies of the same library due to the fact that each package gets it’s own personal copy. This could definitely use to be fixed. That being said this API not generally recommended to be used. Instead you should use tmeasday:check-npm-versons which allows a workflow similar to peer dependencies in NPM.
Problem 5: package.js file is a problem itself
package.js is essential to the advanced features provided by the Meteor package system. I don’t believe these could be replicated by moving to fields in package.json.
None of this is meant to be abrasive, but rather provide some insight to anyone who reads the article and wants further explanations. Cheers!
10 Likes
Some Atmosphere packages were abandoned at the request of MDG when they enabled NPM support. I think they were encouraging NPM use, but the effect was negative for those that actively used atmophere packages.
I have been writing Meteor apps since 1.0, but still use atmosphere when available.
This is absolutely correct, and its a good thing to not have tons of wrapper packages for modules already published to NPM now that Meteor has first-class NPM support, but this did cause a lot of confusion about the direction in which meteor would evolve.
The Meteor package system enables really awesome features though, such as conditional module loading per build target or per environment, and the ability to have some code eager loaded while other parts are lazy loaded. Features you can’t even dream of having if you are writing an NPM package.
By all means, If a package doesn’t require meteor specific APIs or the advanced features provided by the Meteor package system, then it should be published to NPM, but there are tons of great packages that make use of these features and I don’t see Meteor packages going anywhere.
3 Likes
I think abandoned packages are just a reality of FOSS. For example, something like 60% of packages on NPM have not seen a new release in over a year. 
If you want to lend a hand in maintaining packages that are important to the community, feel free to drop by Meteor Community · GitHub and pitch in. You can also find a Slack invite link in the readme of the organization repo if you’d like to join our slack workspace.
1 Like
That’s not true. I do know that a lot of developers in Africa (especially Nigeria) are using Meteor. Meteor is the ideal package for good developers to start their own business as a freelancer but yeah, it’s quite difficult to interact with them due to the shaky internet and the low bandwidth.
Even in many first World countries the internet connection isn’t very good. Eg. in rural areas of Germany, I know from my own experience.
And as we share our opinions here, I think your comment/opinion isn’t encouraging that the OP or anyone else will publish such findings in the future.
I’m pretty sure he used Medium because it’s a platform that gives him way more eyeballs than sharing it here. Nothing comes for free, the OP wants to demonstrate his skills with Meteor and for that we shouldn’t shoot him down when he does so on a different forum that gives him a lot more visibility.
But yeah, that’s just my opinion.
4 Likes