I've been a huge fan of MeteorJS since 2016, however the issues i had with it back then still seem to be around. So, it may be time to move on.
It seems i'm consistently able to pump out webapps very rapidly with MeteorJS. There's just little doubt in terms of what to do: it's muscle memory at this point.
- create a skeleton with meteorkichen
- create the data collections
Tight binding between the Model and the View
MeteorJS data is realtime, and subscription-based. This is done via MongoDB's OpLog, and DDS: a protocol built on top of websockets. The pros are that it's impossible for the view and the model to get out of sync. The cons are that you have to be very careful with your subscriptions, since a subscription model scales badly: i.e performs degrades as the volume of data being stored increases, and the number users rise.
Serverside Futures and Fibers
This makes sense to the intermediate and advanced, but to beginners it adds to the learning curve, and even to experienced users it may seem a bit arbitrary as to when to operate with a Fiber, besides "meteor told me to".
Deploying meteor apps requires a slow building process, and complicated tooling. The preferred solution is to use [meteor-up](https://github.com/zodern/meteor-up), which changed maintainers and went through a period of being unmaintained.
Lack of MongoDB admin interface
It's all fun and games until something hits production. My main issue with Meteor in production is the lack of free and high quality MongoDB tools. Robomongo was my go to for a long time, but it seems they've changed their product to [RoboT3](https://robomongo.org/) which adds confusing as to what the product actually is.
Yes you read me right. There's no native way to do joins, so one again this has to be an [external package](https://github.com/perak/meteor-joins). The lack of such fundamental functionality really firmly puts MeteorJS in the toy basket.
Kadira is a hugely prolific developer, who created hundreds of packages that are use a lot by the community.
When he fled, Meteor (the company) said they would maintain them, but this did put a big dent in the confidence other package developers have in the ecosystem.
[AtmosphereJS](https://atmospherejs.com/) is the community MeteorJS package repository. It's very common to come across packages that haven't been updated in years. It's only a matter of time before they get into a state of disrepair.
Things break with each NodeJS version update
You may have a MeteorJS app you haven't touched in years, then suddenly a client asks for a change. You try spinning up the app from your local repo, and Meteor claims an update to the latest version is required. You update, and realise it's incompatible with your version of NodeJS. You update your nodeJS and realise you're running into package incompatibility issues.
Ah this issue is not only with MeteorJS, and actually exists in the whole Node, NPM ecosystem, but it still lands on the lap of MeteorJS when evaluating it as a framework.
Installing and using native NPM packages was an odd and difficult process for a long time. It's now getting easier, but this can still lead to issues, such as npm package installations failing during deployments, and needing to intervene manually in that process.
Installing and running MeteorJS takes several gigabytes on connectivity and hard disk space, and creates millions of files. This makes using it on corporate networks where home directories are mounted on NFS drives utterly impossible.
Lack of client-side POST handling
Yes you read that right: posts are handle serverside, making it very difficult to figure out to which client the post request was actually sent to. You also need to intercept the POST request on Node directly, and stream the data. This seems like low-level madness for something that's supposed to be consumed by humans.
Yes the list of grievances goes on. So over this holiday period, i shall explore other frameworks: most likely a combination of Python backends with JS frontends.
Thanks for all the fish MeteorJS, but your stardust may be fading.
This article was written by Shyal Beardsley -- to find out more: https://shyal.com https://ioloop.io.