Meteor, the dark side of the moon.

This article was not written in order to break the framework and the community. Just a feedback after a few months on the creation of an application by learning all the intricacies of the framework. All that is written here is the experience I had with the framework which can vary according to each .

TL;DR

I have seen many articles about how great meteor is few about the “drawbacks”. How it is to grow an app with meteor for a long term project with scaling purpose.

During almost one year, I wrote a big app with meteor During almost one year, I wrote a big app with meteor called Nice to Mate You, a social network to find the right roommates for your lifestyle.

Maybe I expected too much from this framework, and used it in the wrong way, but I hope that my experience will help all the new Meteor users. Here is my feedbacks :

The Good Parts

Last year, I had to choose a framework to begin the development of a social app. I discovered meteor and I was very excited about all the features the framework brings.

1. Javascript on both the server and the client and the ability to share some code between the two.
2. Live page updates. Meteor has a very compelling model and performance has improved significantly with blaze.
3. Package management with meteor and npm works pretty well and there is a growing ecosystem of packages available around the meteor atmosphere.

Building features is very easy and exciting because you can very quickly build things that can “live” that you can try and use directly. All the template system with helpers or events attached is one of the reason that allow you do to that. In addition to the wow effect of meteor and you get something really pretty.

The Good Parts (not that good)

Lack of structure

The first thing you realised when you start developping with meteor, is the absence of specific tree structure (except for the client/server). Wich means your are absolutely free to create your own.

This looks pretty cool at the beginning but looking back it’s very difficult to maintain the whole structure.

Because when you have more than 10 features which themselves have more than 10 features, etc. (1 feature = at least 3 files. html, js and optionnally a css/less file).

Indeed you must be extremely accurate when you are choosing all your filename and the way you are going to create your structure because this will follow you until the end of the project.

Okay but which structure ?

A good tree structure would be something which is divided into functionnals blocks.

With this method everything is going to be “in place” and when I’m going to read the file at the line 9 (on the example) I would be reading all the helpers/utils function for my recover-password account feature.

Now Imagine something much more permissive.

Battle against the framework

Livereload.

One of the key features of meteor is the live reload. This function which avoids you reloading the browser whenever something is added to a file.

Actually this feature is very good at the beginning. However as your codebase increase the small latent period between the moment you’r changing something and the moment the browser is reloading increase as well.

I have more than 300 files (less, js, html and assets) whenever I change something the latent time takes at least more than 5 seconds.

Thus my browser have to render all the DOM with assets and everything everytimes I press Ctrl + S with the latent period.

I have a late 2011 Macbookpro with 8 Gb of RAM and it blows a lot lately …

Oh and If you want to disable the hot code push feature do yourself a favor!!

Debugging

Without IDE (such as WebStorm) debugging in server side is quite complex and you have to use the old fashioned console.log.

Debugging on the client works well enough using Chrome’s developer tools. Things get hairy again on the client when something goes wrong with your templates.

I definitely wasted too much time with meteor debugging on both the server and the client.

MongoDb

I came from the Node/Mongoose world where mongodb fit just perfectly with nodejs. But in the meteor world is not that simple … Because meteor use the mini mongo driver so you have some limitation.

Minimongo is reimplementation of (almost) the entire MongoDB API, against an
in-memory JavaScript database.

In fact in meteor mongodb’s findAndModify, upsert, aggregate functions, and map/reduce aren’t supported (for now I hope) without installing a third-party package.

Production

Deploying for free in meteor.com is a nice feature.

When it’s your turn to deploy on a bare metal server it’s not as easy as meteor deploy command.

Indeed the deployement show us that all the code is minified in one single file for the html, js and css and we are back in a node.js app. You have plenty of packages installed by default which process a lot of things and are very expensive in terms of CPU/Memory on a production server.

So meteor is only about dev workflow ?

Yes.

In fact meteor is very “narrow minded” and if you want to make thing out of the boundaries, the framework will make you understand that it’s not possible, you have to make different or hack the process.

Bottom line

Meteor is a very good idea and a good framework BUT.

• Be sure that you need all the features provided by meteor.

Do I need all those reactive features things and everything to create a blog ?

• I wouldn’t recommend it as primary choice except to build a prototype to test your idea and move forward in a leaning process spirit.
• If you want to use meteor, be very rigorous and ask yourself if you need all of those fancy things. (Otherwise you will regret it later I guarantee it).

MEAN vs METEOR

This picture express exactly the way I see meteor now.

You rely too much on the framework, you’re only the driver so if something break or does not work as expected. You either have to go to the mechanic or fix the thing by yourself (which has the end is not what we would expect from a framework).

I learned meteor during the past year by doing and making mistakes (the best and fastest way to learn). I struggled against the framework, maybe because all the features provided by meteor does not fit my needs. So I have decided to stop using Meteor and move on something new. First because I want to focus on my features rather than focus on “holy crap why is this not working normally” and secondly it’s always exciting to learn a new language and framework

Feel free to give your feedbacks about your own Meteor experience, comment and share if you are struggling too.