It looks to me like Horizon and Meteor are solving problems in different scopes of the application stack.

Horizon looks to be more like the Minimongo/DDP/Accounts parts of Meteor, and doesn't help with any more of the stack like Meteor does (eg: In Horizon its more up to you to wire it into Angular/React/etc). Meteor is more of a platform and Horizon is more of a real-time client DB and account framework.

If I had to choose between the two, Horizon would be good for if you had a strong opinion/technical need for very specific coupling between UI and DB, and Meteor for when you don't or need to get something out very quickly (eg: this weeks internal CRUD app for a few dozen users).

There's one on the website:

http://horizon.io/faq/

IMO it hand waves Meteor away without acknowledging (perhaps out of ignorance) some of it's other strengths.

I'll watch Horizon but I'm taking it all with a grain of salt. Standard new javascript framework protocol people.

The FAQ repeats some things I've heard about Meteor -- specifically that its architecture doesn't scale.

But Meteor isn't completely prescriptive. There are several pieces that can be swapped out: You can use Angular, React, or Blaze on the client, for instance.

From what I've read, it doesn't look like Horizon is a complete framework, just a database client/server component that can be used with any framework.

We have a short-burst, write-heavy, mostly cpu-bound, work-load, which according to the various financially incentivized critics would completely knee-cap us for our use of Meteor.

Except we:

1) optimized our database operations

2) relegated cpu-bound work to micro-services that could process work from a queue at their own pace

3) Leveraged the ecosystem to writer smarter and more concise code

Know your enemy and know yourself and you need not fear the result of a thousand battles (Sun Tzu). Meteor is an amazingly productive ecosystem for writing real-time applications. No it will not solve every problem you throw at it.

Just to be clear I'm not hating on Horizon. I definitely will try it in the future.

OK, glad to hear that it does work for you. Sounds like you have a robust architecture.

I don't actually know what is supposed to "not scale" about Meteor. I've just read it multiple times. But because of the nature of Meteor (Really easy for anyone to set up! Anyone can create a real time app in ten minutes or less!), it probably attracts a lot of junior developers. It therefore should have occurred to me to translate "It doesn't scale!" to "I don't know how to scale it and my app is slow!!!". :)

There are two major issues that crop up in my experience.

* Node as a runtime is deeply mediocre, in my experience. You can usually solve this by throwing more (usually virtualized) hardware at the problem.

* Meteor's architecture is (at present) tied into MongoDB's oplog tailing. You can scale it up through sharding, through alternate libraries, and DDP itself is not tied to MongoDB at all. IIRC fixing this was a goal for Meteor 2.0.

Both of these can be worked around. If nothing else, the Meteor web side will talk to anything doing DDP, and DDP is not that hard to deal with.

It comes up because Meteor gets slow faster then most other solutions will get slow. It kind of reminds me in Django how a common mis-step for beginners is using an O(n^2) algorithm on the Django ORM. Meteor is the same way if you aren't using proper indices, or are trying do something that SEEMS doable to the uninitiated (like say pushing ~n thousand JSON objects into a MongoDB set), it's going to give you a bad time.

"2) relegated cpu-bound work to micro-services that could process work from a queue at their own pace" doesn't this defeat the primary selling point of meteor?