Hacker News Reader

Comment by btown | Hacker News Reader

A very common pattern that's been found vulnerable. Glad to see it mentioned here.

To the larger point: It's great to see that people are still taking Meteor seriously (there are dozens of us! dozens!). If you're willing to use Mongo - which is VERY flexible if you use it as a materialized view that's fed by other processes, rather than the canonical source of CRUD data - then there's still no better way in 2017 than Meteor/React to prototype a real-time interface whose infrastructure you control. Almost all the code is regular old React, and there's minimal impedance mismatch moving from Meteor HOCs that grab a nested Mongo object, to HOCs that grab a nested object from GraphQL/Apollo allowing you to use other databases.

View on HN

I disagree, Meteor project are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug.

Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly.

On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure.

I say this as someone who has used Meteor for multiple projects and used to love it!

Agree. I've used Meteor for several large projects and this has been my overall feel. MDG didn't take official stances when it was needed (e.g. Router), and the "Meteor way" to do things was constantly changing.

Now there is only one developer left working on Meteor, where the rest of their resources have been dumped into Apollo, and Galaxy their self hosted service. I can't speak to Apollo, but my experience with Galaxy has been frustrating and I eventually moved away from it.

For new projects I'm looking into Elixir + Phoenix, Vue, and others. Could you speak to your testing experience in a large app with Phoenix + Elixir? You mentioned that testing has always been a third class citizen in Meteor and I have to agree.

Meteor was great to get started with, and like sergiotapia I used to love it. After working with it for a while, I think Meteor's limitations (particularly mongo) really start to show, and it lacks the driving development behind it that new frameworks like Phoenix and Rocket have

If you use contexts (which is a fancy way of saying use a business layer) for your applications logic, you end up with small, isolated functions that are super easy to test.

`mix test` just nukes your tests and runs them really fast. About 200 tests run in about 5 seconds. Since tests run so fast you end up writing more tests, you end up writing smaller functions, you end up with cleaner code. Everything just falls in the right places almost by itself.

Do any of you guys use Elixir/Phoenix with React and Absinthe GraphQL?

And how about Clojure(Script)? Now that ClojureScript can consume almost all JS libraries, isn't it a serious contender?

Structuring code is easily done by setting standards for a project. I don't understand that issue. Nothing stops a team from having consistency and even building a meteor app MVC rails style folder structure or a per module-mvc type of style.

I built one (semi major) project in meteor because it looked cool and easy to spin up - which it was.

The problem as stated here was that when there was a chrome update, iron-router broke and spent quite a bit of time trying to figure it out.

Not to mention that shortly after I got it fixed one of the only hosting solutions that I had it hosted on (modulus.io) went under and so did my app.

It was brutally frustrating. Saying that, I would probably use it again in some sort of hackathon or startup weekend, but not anything of scale.

Meteor works on top of Node, so any host that can host a Node.js app can host a Meteor app. I'm also not sure if I'd use Meteor at scale, but I love writing the initial version of projects in it.

Doing a project in Meteor + React right now, and it's kind of fun.

I also did a reasonable size project in Meteor, was pretty quick to get going, but the nightmare started as the project evolved, packages got abandoned, and Mongo was really very very average.

The real value proposition of Meteor wasn't really it's data reactivity (still nice to have), it was having a prebaked authentication / data backend from the get go.

Disclosure: I am the author of a competing MIT/ZLIB/Apache2 system.

> "There's still no better way in 2017", RethinkDB's Horizon ( http://horizon.io/ ) and our tool, GUN ( https://github.com/amark/gun ), seriously contest that fact.

For instance,

- You get realtime data sync out of the box with an infrastructure you control and do not have to manage. See our demoes that survive Split Brain failures correctly, compare this with the delicacy needed of configuring MongoDB clusters properly, or the overhead of using Galaxy.

- You also get realtime GraphQL subscriptions for free, via https://github.com/brysgo/graphql-gun .

- You get graph data structures that support circular references in plain old JavaScript objects, or use tables or key/value pairs, or full documents! See https://github.com/amark/gun/wiki/graphs .

- You can go entirely P2P and decentralized, the community just launched end-to-end encrypted user accounts that I demo in this video: https://youtu.be/ik_dqXBMBHw .

Instead with Meteor, you get locked into a monolithic framework that chose bad architecture with its technology, that will make it prohibitively complex to scale. There are definitely better options in 2017, and that includes ones other than mine as well. Do yourself a favor and don't shoot yourself in the foot with Meteor.

It sounds like you've built some interesting technologies!

Some food for thought:

* RethinkDB was a startup that both collaborated and competed with Meteor, until it [went defunct](https://rethinkdb.com/blog/rethinkdb-shutdown/) last year, leaving its open-source technologies to be maintained by the community.

* Your gun project depends heavily on graphql-anywhere, which is a project maintained by none other than... Meteor Development Group.

Given the ways in which you've benefited from the community in general, and MDG in particular, I'm surprised you took this zero-sum, winner-take-whatever, nakedly self-promotional attitude. Let's be better than that?

Disclosure: I work on Meteor.

Fair, fair point.

I did not realize (I'm not the author of gun-graphql, it is from an open source community contributor) graphql-anywhere was a Meteor project.

I think that Meteor can be the winner-takes-all in open source centralized realtime services, and they/you have been so far. However, as I've actively debated here and elsewhere, that Master-Slave architecture is not scalable. While I love RethinkDB and think that they were the best, I also criticized that their shutdown was evidence of a systemic downsizing in use cases for centralized infrastructure - and therefore could not gain a large enough market capitalization for Open Source to make sense from a financial model.

The RethinkDB guys are some of the nicest and most brilliant engineers I have ever met (also evidence to that fact is their success with the Jepsen Tests compared to other vendors), but the architecture choice is unfortunately a mistake.

So please take my comments as an engineering analysis, I myself should admit (and thank you for calling me out!) that: If you are building some app that needs Strong Consistency (like a banking application), then Meteor will be a much much better choice than gun, since we are an eventually consistent manner.

Thanks for calling me out!

I greatly respect the work you've put into Gun, but I will stand by my assertion.

Horizon is abandonware (no commits for months), and Gun doesn't even handle unsubscribe-on-unmount in either its official React examples https://github.com/amark/gun/blob/master/examples/react/src/... or in graphql-gun https://github.com/brysgo/graphql-gun/blob/master/react/inde... ... which would lead to memory leaks since the callback still holds a reference to the component instance. In fact, the API documentation doesn't even mention a way to cancel a subscription.

(It's true that Gun's offline-first approach is unique, but with mobile connectivity these days it's not often a requirement for B2B applications.)

Regardless, for both technologies, these are indications that neither has the professional backing that Meteor has enjoyed, and continues to enjoy, throughout its history. A real-time contender to watch with that type of backing is deepstreamhub.com which is significantly closer to having a professional-quality realtime product... but it's only recently released, with a nascent open-source plugin/tutorial ecosystem.

Again, all of this is in the context of the following advice: Build a best-in-class React (or Angular) app, with routing/organization/testing taken from best non-realtime practices in those ecosystems, and have only a small number of containers depend on, and declaratively subscribe to, any specific data layer. As the real-time data ecosystem changes, migration between platforms can be restricted to minor code changes in those containers... in which case it makes sense to choose a framework that provides a stable platform well supported by documentation and amassed questions from years of usage.

I hope to see Gun become a legitimate choice in the near future! But I need to bet on the horse that's miles ahead in the race.

Your comments are very well said and explained in a constructive context! Thank you for this feedback, good chewing material.

What have most people shifted to from Meteor?

I loved Blaze and closest thing to it is Ractive(https://ractive.js.org/). For backend reactive stuff there are many options like horizon/firebase/rapid.io/gun/etc, but for something more complex easiness of RPC through DDP is hard to replace though.

phoenix framework!

sure you may not get the oplog tailing but you do get a realtime websocket system that scales. Also, I'm fron teh school of thought that mongodb should never be your primary database for a whole host of reasons (no multi-record trabsactions, eventual instead of immediate consistency, limited query language to name a few). http://phoenixframework.org/blog/the-road-to-2-million-webso...

you don't get reactive stores (yet) but with absinthe's new subscriptions system, you can add in reactivity where it doesn't bottleneck your development.

Reply on news.ycombinator.com