4 ms·

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

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!

thsowers 9y ago
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
- sergiotapia 9y ago
  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.
  - malloryerik 9y ago
    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?
dfischer 9y ago
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.
chasedehan 9y ago
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.
- dvt 9y ago
  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.
keithnz 9y ago
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.

thsowers 9y ago

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

sergiotapia 9y ago
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.
- malloryerik 9y ago
  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?

dfischer 9y ago

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.

chasedehan 9y ago

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.

dvt 9y ago
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.

keithnz 9y ago

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.