Anyone from Meteor?

Is anyone here from Meteor? In your opinion, how does Phoenix compare to Meteor? We all know that Phoenix scales much better so it would be more interesting to hear about developer productivity.


I don’t know meteor at all, but took a look at its webpage and just from the brief I do see a very major difference (apart from the language): Phoenix is not for desktop or mobile applications but web only.

Meteor isn’t desktop or mobile either. It just has good build system with Cordova.

I used meteor briefly for a few production apps.
Phoenix blows Meteor off the face of the planet for my use.

Meteor is faster for some prototyping / product to market because of the packages that are available to it.
That said there were like 1300 hex packages starting this year , now theres almost 1890 packages. so I se that gap closing. Meteor apps in production are a nightmare compared to a phoenix application.

in short , the amount of black magic that makes Meteor interesting is the same thing that leaves it vulnerable. If you want to do something out of the box you have to invent your own black magic and wrap it in voodoo and hope that it does backfire.

We migrated the meteor apps to phoenix btw :slight_smile:


What I know about Meteor, but maybe you can correct me. It enables client <----> server state synchronization. The client has local database. It writes/reads to local database and this database is “automatic” synchronized with server database.
The backed is written in nodejs. It only support some databases like mongodb.

We don’t have so tight integration client - server in Elixir,Phoenix. Phoenix can only export REST API/ websockets. The client <—>server synchronization must be done by developer. I know there is plan form more tight integration with ELM.

There are some alternative for example if you want use facebook graphql with relay
The graphql is openstandard, implemented in many lagauges awesome-graphql. There is elixir implementation also.

Other similar solutions: with
Om next clojurescript <----> clojure, video


It claims to be (on an inaccessible webpage [in terms of can’t copy that part of text]):

1 Like

Have a look at this thread - there are quite a few people who have come to Phoenix from Meteor :slight_smile:

//cc @MichaelC @drb @Mandemus

I discovered Phoenix due to this mega-thread on the meteor forums.

As was said previously Meteor is great for prototyping. However the only way to scale past 200 or so concurrent users appears to be ripping everything out of meteor that makes it meteor. It neither scales vertically or horizontally as it’s crippled by the oplog tailing.

I’m happy I made the switch and haven’t looked back.

In terms of productivity I’m nowhere near as productive. That mostly being because I’m new to FP and still in the learning stage.

So far it seems to be quite declarative and self documenting as an app is essentially a series of pipes. It’s obvious what my code is doing. It’s also very terse.

Once I’m as comfortable with elixir and phoenix as I am with Javascript I can honestly see myself being more productive.


Yep, that forum post was good gateway to elixir/phoenix platform

1 Like

This is not true! I’ve pitched Phoenix from the very beginning about being a framework that goes “beyond the browser”. See the heading in our 1.0 announcement:

Phoenix channels targets all platforms, desktop, embedded, native iOS/Android and whatever transport you want to build on top of.


Can there be some connection of Phoenix channels to clients: RxJS, RxJava, RxSwift?. I think this could be interesting :slight_smile:

1 Like

This is how I found out about Elixir and Phoenix as well!

I’m glad at least one person said this:

1 Like

This is true with minimongo built in into Meteor but it seems like the trend is going towards leveraging other technologies (Flux, Redux, etc). This is because allow, deny rules are arguably known to have security flaws and Meteor community is moving towards using React instead of Blaze. Although there are other benefits of using Meteor, the client and server technologies are more decoupled meaning Elixir/Phoenix developers should be able to achieve similar results using those front-end technologies.

1 Like

The client - server state synchronization is complicated topic and it hard to do it right. For example for mobile less requests to server is better. The facebook graphql - relay handle this by collecting all data needed by page and sending one request to get this data. On the relay client you build page with components. Each component defines data which needs to render. So page knows what data needs to render it.

Big fan of Meteor, but lack of first class SQL support, and the usage of Fibers as a Node crutch doesn’t sit too well with me…

The concurrency patterns and performance benefits of using Elixir/Phoenix on the server are what drew me to this platform.

I am very excited about the Apollo project that MDG is working on.
An Apollo client w/React + Phoenix/GraphQL back-end would be an awesome stack.


By the day we have native channel support for all (important) platforms, with this, of course you are right, and of course, as the creator you do know it best ;).

But, the big difference I do see here, and which I wanted to point out, is that meteor advertises to be full stack, at least thats how I read the aforementioned quote!

Meteors advertisement reads as if I only need to pull a switch and have an Android App, iOS App, or Windows Desktop Program without any change of code. And exactly this is not possible using Phoenix (probably never will). For Phoenix you still need to code distinct applications for each platform.

They are using Cordova (Webview apps) to achieve this. I believe you could get similar results using phoenix.

Sorry, going to partake in some necromancy here…

I’ve just built and launched a fairly major relaunch of my companies primary app. We also ended up rebuilding the entire data storage and architecture too…what fun! Any way, between some issues with Meteor evolving and feature-creep, the rebuild has taken close to a year. Now, in that time, not only the features it’s expected to deliver, but the scale have changed dramatically. Basically, Meteor will cost us a bomb in hosting!

About two months ago I started writing all new code with a very strict Meteor/React divide, with the intention to break them apart and Phoenix incrementally take over the backend. Now that we’ve launched, I’m thinning out all the Meteor dependancies I can, and replacing them with React implementations (alerts, routers, client-side store, etc).

Even with React acting as the middleman, it’s going to be a tough progression which I expect us to be chewing through for months.

Long and the short, even if Phoenix was drastically less productive (it’s not…it’s more) than Meteor, we still would have been way better off using Elixir/Phoenix. I feel really burnt by Meteor, and won’t be building with it again, purely because it’s so hard to escape from (better now they have nom support).


Honestly I’d say take a look at webcomponents. They are actually part of the HTML5 spec, the polyfills for them work wonderfully (not even had any issues on the IE11 I test on at work), and it is a standard. React emulate webcomponents but via its little render system. There are dozens of webcomponent libraries too but you can just write them in plain javascript with ease anyway, you can even use react to write them (except using them in react is even easier than normal react components as they act like like normal DOM elements).

I’ve personally been using plain javascript to make webcomponents and Polymer (Google’s webcomponent library, adds templating, almost-stupid-easy two-way data binding, etc… but for just data-oriented webcomponents I usually make those in plain javascript).

As an example, here is how one of my HTML files looks:

  <body unresolved>
    <page-spa param-token="<%= Guardian.Plug.current_token(@conn) %>" base-path="/spa"></page-spa>

And my page-spa webcomponent’s html template is just normal html (inside an html5-standard <template> element):

    /* snip css, for note CSS is scoped to only this webelement,
      nothing leaks into a webelement from outside and nothing leaks
      out, feel free to make them simple like matching on something
      specific instead of class matching, users can pass overrides to
      your internal css via html5 css variables, also polyfilled for
      older browsers. */
    <app-location route="{{route}}"></app-location>
    <app-route id="route"

    <phoenix-socket id="socket"



    <app-drawer-layout id="layout" responsive-width="1280px">
      <app-drawer swipe-open>
        <app-header condenses reveals shadow effects="waterfall">
          <app-toolbar style="pointer-events:all;">
            <div main-title>Drawer</div>
        <div style="height: 100%; overflow: auto;">Testing a drawer</div>
        <app-header condenses reveals shadow effects="waterfall">
          <app-toolbar style="pointer-events:all;">
            <paper-icon-button icon="menu" drawer-toggle></paper-icon-button>
            <div main-title>MyServer Title</div>



The app-* elements are from (a repository that people can upload pre-made webcomponents to, these ones are from polymer, which you can use without polymer in your own stuff if you want, it just exposes normal html5 webcomponent interfacing). The phoenix-* elements I made (mostly data elements, they display nothing).

But for example, the <app-route ... I bind basePath into its pattern (one-way, to it, that is the [[variableName]] part) and match out the path after it, which it and other stuff is put in the data variable of moduleRouteData ({{variableName}} is two-way binding, I.E. it can be set ‘from’ the element), which I use later.

The phoenix-socket I built, just a dead simple way to do binding, it auto-disconnects/joins channels that are specified (which you can enable/disable with the connect property, etc…). You can listen for messages and either have the latest stored into a variable or have it appended to a list to keep all (this example only shows latest, but appended is just as easy). Can send messages (though that is not shown in this example) and listen to responses to store in the same way, etc…

Basically a lot of easy data-binding, the javascript side of it is fairly small too. What this does is a SPA with a header and such (this is my testing route) that dynamically loads in or out elements based on what the server tells it to load for its view (it tells it to fetch more webcomponent data from the server if it needs, or does not if it already has it, etc…).

And yes, inside a webcomponent can be whatever library you want, there are react bindings, elm, vanilla javascript is fine, etc… etc… You are just defining your own elements is all. :slight_smile:


I’m very late to this thread, but I thought that I would add a few bits of info that I don’t think have been mentioned yet.

  • Meteor apps are client rendered whereas Phoenix apps will often be server rendered.
  • If you want client rendering with Phoenix, you use Phoenix to develop your API and then pipe that to your JS client.
  • With Meteor your database will by default be Mongo. That’s great if you want Mongo. Not great if you want SQL.
  • Meteor’s Mongo functionality is simple to use and very powerful. From the client you simply start writing to your Mongo database, no REST API layer required. It’s almost that easy.
  • I’m finding my productivity with Meteor/React/Mongo to be excellent compared to using Phoenix/Mongo
  • I’m using Meteor for prototype development to sell an idea of mine. If I later need to switch out the backend to Erlang/Elixir/Phoenix to get the performance I need, I’ll probably end up having to start from scratch.