@kthomas88 yes there is some black magic involved, particularly at the "authentication" level and the transport layer.

The big issue is you can't provide a clean Rest API to your customers with a Meteor app and Meteor does not shutdown gracefully.

I explained some details at medium.com/@pierrebaz/why-i-won-t-recommend-meteo…

I would use meteor for things like building a quick website for something like pitching a quick mock website to someone. But to build a full website with all the functionality at my fingertips I would use another full stack approach.

A picture that always stuck with me was a comparison of Meteor and MEAN. Meteor is a finished car that you can drive, and MEAN was all the parts of a car so that you could build your own car to drive.

This poll is vague. The title implies that a yes answer means Meteor is black magic, but the question at the end implies EITHER yes/no I am/am-not comfortable working with Meteor or that yes/no a simple Mongo+Node stack is the way to go.

What exactly is the question?

Meteor used to be black magic. They used to reinvent everything and this caused them all kinds of trouble. They even claimed NPM was a bad match for Meteor because "it's not isomorphic enough" (whatever that means when talking about a package manager). The most blatant problem this line of thinking caused was their hard dependency on MongoDB and an increasingly outdated and exotic front-end framework that didn't even provide server-side rendering capabilities.

However things have changed. Meteor has replaced its front-end components with React and the database communication is being replaced with Apollo (i.e. GraphQL). They're even embracing NPM now. This is a good thing.

The only fly in the ointment is that now that all the major components have been replaced there just isn't much left that gives Meteor the edge over other stacks. It's just an opinionated React stack with a few weird idiosyncrasies that don't provide any obvious benefits. It hasn't become any worse, it just has become obsolete.

Meteor had a good value proposition when the main competitor was AngularJS 1 and the majority of new websites were still being built with Backbone. Its target audience were beginners who weren't yet invested into standard JS tooling (i.e. NPM). That value proposition no longer holds up today.

So in other words: Meteor has tried to shed a lot of its magic but the magic was only part of the problem. The real problem is that it tried to be a huge monolithic solution that was completely incompatible with the existing ecosystem. That has changed, but it is just too late. Parts of it may live on (e.g. Apollo seems to be getting some interest if not adoption) but as a whole it's simply outlived its usefulness.

Same here, I feel like there's to much magic to Meteor. Like how does it know something has changed in the database? It must be querying the same queries over and over again. And that's just one of many things.

Meteor seems to me like a tool for people who are not able (or have no capacity) to learn javascript or the technologies which they need to work with to achieve their implementation, so they jump into Meteor because it promises a lot. But they lack optimisation and for me even micro-optimisation is important.

Definitely. I kinda know how Meteor works and how it achieves its reactivity, but it's still too much of a black box. It's really frustrating, because this disables you to perform optimisations. I recently stopped working with Meteor, because it feels like it's really bloated and the reactivity seems very unnecessary at times (despite really loving the developer experience).

When I started writing raw Node applications it felt really good to have control over nearly everything. The problem with Node stacks these days though is that you have to spend an enormous amount of time on configuration. That's where boilerplates like MERN come into play.

In the end it all comes down to your application requirements. Meteor makes it ridiculously easy to build realtime applications, but feels quite heavy and it's too much of a black box. For now, I'd go with the Node stack, as long as you use a boilerplate.