Meteor-JS versus AngularJS

We are using Meteor and have been for about a year. The biggest caveats are :

1) MongoDb - I know the NOSQL really believe that NOSQL is awesome... but it isn't. SQL support is coming - but isn't there yet.

2) NodeJs on the server - Once again the single thread model has its true believers. My response: preemptive scheduling and multithreaded environments were created for many good reasons by people smarter than I (or you). Sure it is possible that you may do o.k. with it. Just remember 1 bad call kills the entire server.

3) It is still maturing and changing.

4) Suggested coding style is a little sloppy with security

5) Performance issues are still being addressed. (pub/sub model imposes burden on database)

Positives:

1) It is cool to write code that runs on both client and server

2) The pub/sub module to ship data to the client and keep it refreshed is a definite win.

3) packaging system is pretty good.

4) Meteor leverages the nodejs community. ( it is pretty easy to shim a npm package into meteor )

More later if desired.

You need to consider how much of your app needs to be realtime.

Do likes, comments, whatever absolutely need to be updated in realtime? If they do, you should consider going with a full realtime service. If not, i would go with a backend that you feel comfortable with and build realtime where you need it.

I'm building a Ionic (AngularJS) based mobile-app aswell and went with Firebase for full realtime, but in hindsight i would probably have had a better go with using a RDBMS on the backend (which i'm way more comfortable with) and used Socket.io or similar for the parts that really needed realtime.

No experience with Angularjs. Meteorjs is great, I just started a couple of mounths ago and I love how easy is to make complex real-time things. They should work on better documentation, there is only 1 valuable book right now to buy. Others are coming. The main problem is that meteorjs community is small compared to angularjs, and that is pretty strange to me. It's a well founded company - $11M - with a slow ramp of adoption. Why?

For real-time aspects, have a look at PubNub: lots of features, very low latency, many global data centers, SDKs for every language/platform, good docs and support. You can easily replace FireBase with PubNub (I did on a project and results were positive). Really depends on what real-time needs you have (simple data synching or more complex persistence requirements).

Just use what you know, it's not about the stack. It's about what will get the job done asap.

MeteorJS sounds like a all-in-one package that'll give everything you need, rather than having to mix and match components by yourself. I have not used MeteorJS. I have been building AngularJS apps for almost a year - when I started MeteorJS was nowhere ready.

I know the question was meteor js vs angular js, but having developed heavily in meteorjs before it hit 1.0, I can at least speak of it. As whatthemick said, consider how much of your app needs to be in real time. Meteor js gives you a huge amount of power to wield when it comes to building real time applications, but it doesn't lend itself very well to building a stable experience. Not that meteor js isn't stable, just that it's very very easy to bugger yourself while using it.

For me there are a few major reasons I wouldn't use meteorjs just yet on projects I'm doing on my own.

1) Documentation is scrappy and is full of bad practices.

The best example for this is the use of the {{with}} parameter bindings; essentially the data context issues. I discovered some time ago that if you aren't careful with data contexts you could end up causing connected methods to run many times over when something completely irrelevant changes in the data context. I in fact pushed the meteor community to give me an answer for this one but ultimately I solved it on my own (I tried the google group, IRC, and stack overflow channels). The SO question and answer can be found here: http://stackoverflow.com/questions/25376541/why-are-all-mete... My google groups question which got just one answer was - https://groups.google.com/forum/#!topic/meteor-core/2VKHCK0u... . In that too, notice the hacky way in which it was suggested that I solve the problem.

2) Test Driven Development was problematic at best.

This problem is going away fast though so it's a little glib of me to mention it. The meteor community is big on TDD and they are pushing to make it happen. Again though, documentation is scrappy. Separation of concerns is tough. And this brings me back to point number 1. Best practices related stuff is hard to find. I love the style of keeping use cases separate from the interface, but meteor seems to encourage mixing it all up. This makes TDD difficult because good luck trying to setup tests to run in 0.0781 seconds for that small area you are making changes on.

(Maybe take the above with a bit of skepticism. I haven't used their testing framework since it hit v1 and I've heard they had big changes and improvements in it)

3) Manipulation of UI is strange.

Since meteor and its templating engine are bound together in a really really tight way. Meteor actually binds stuff based on the location within the HTML documentation. So if you muck around with inserting and removing elements by yourself, Meteor suddenly can't keep track of where it's supposed to change things. Example: We wanted to do a simple "fade out and below element slides up" animation when deleting a row from a table. Since meteor reacts immediately to deleting an element, you actually have to run the animation (animate the element to be deleted by fading out opacity while setting height to zero) and then run the delete function on the animation callback. Let's assume we deleted the second row in the table. So just before the delete function runs, the second element has a style of opacity 0 and height 0. After you run the delete function, the element that was the third element (and is now the second) vanishes. Why? Because the element previously in the third row, is now in the second, and meteor thinks the second element should be invisible and it's height should be zero. From what I know, this peculiarity is still there. The "meteor" way around this is to actually store the animation completed status value IN THE DB and if it's false, the height and opacity should be explicitly set to the correct values (or something along those lines. Either way, animation status, in the db).

Those three points really hurt my experience of meteor js. And while I enjoyed it at its best moments, it hurt too bad at its worst for me to recommend wholeheartedly to anyone, including myself.