
Meteor-JS versus AngularJS - thinkerer
Sorry if the title sounds a bit broad. Im building a mobile&#x2F;web app with AngularJS. For background, the app is a simple service app with 2-3 pages and some interactivity with users with mainly text and some media, it functions much like how Instagram does. I started to look into the backend and wondered if theres any real time backend other than Firebase.<p>Specifically, I was exploring into a RDBMS like a MySQL for example. Reason being there&#x27;s requirement for data-manipulation as well as future amendments to the data schema. Would that mean losing real-time capabilities and if real-time is overrated?<p>A couple of friends in programming recommended Meteor-JS for its real-time abilities but it seems like a heavy full stack MVC framework, including backend and with less support and open source stuff?<p>Would anyone have any opinions and views on this matter? Any experience to share app performance is very much appreciated.
======
pm24601
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.

~~~
jf22
Can you explain 2 a little better.

Its my impression that no single bad call could take down an entire apache or
IIS server?

------
whatthemick
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.

------
massimosgrelli
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?

~~~
thinkerer
From preliminary obervations, Meteor.js as some users have earlier mentioned,
is actually a full platform but yet with sketchy documentation and little
support from users in terms of open source stuff and help.

------
oaksagelew
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).

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

~~~
thinkerer
Thanks Nico, I was in this direction just that real time comes with a hefty
price tag and little or no open source options.

------
meric
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.

------
nstart
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...](http://stackoverflow.com/questions/25376541/why-are-all-meteor-
template-helpers-within-a-with-each-block-called-when-an-unre) My google
groups question which got just one answer was -
[https://groups.google.com/forum/#!topic/meteor-
core/2VKHCK0u...](https://groups.google.com/forum/#!topic/meteor-
core/2VKHCK0uAtQ) . 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.

~~~
thinkerer
Thanks for the lengthy feedback, appreciate the elaboration on the bindings
and the UI. Its actually the strength of Angular but I guess when it gets too
big, it gets unwieldy in the case of meteor.js

