Why I won’t recommend Meteor anymore


#1

Hi!

Today i read this article and i felt a little bit bad for Meteor :frowning:

The core points are :

  • You can’t authenticate a user if the client is not talking over DDP which is really bad when you want to provide API endpoints for your customers.

  • If you have transactions running when you restart your server, you are dead.

  • How much CPU would it takes to observe thousands of writes per second ?

  • Server-side rendering for SEO not officially supported

What does the community think about these downsides ? Are they critical/real ?


What kind of tests must be made before launching my app to production?
Client side talk (opinionated)
#2

Some of the points are correct. But some points are not an issue or a problem of Meteor itself. Let me give you what I think of it.

To authenticate a user on your app Meteor provides an “Account” package that handles things over DDP, security, sessions revocation, reset password links etc…

Meteor is all about DDP. So, deal with it. This is not the biggest issues we need to worry.


There is also no mecanism to do a graceful shutdown of the server.

This is the cloud era. Apps could be able to crash anytime. So, you need to design apps like this. Apps written for heroku already had to deal with this from the beginning. This is not something bad (or new).


To access your data on the client-side, you have to subscribe to your MongoDB collection. The server then tails the oplog to detect changes and pushes the new data to the client.

It works, but it’s not clear what would happen if you observe too much collections/fields at the same time and you have a heavy write load.

Subscribing too much is a problem of the app. Meteor has nice data caching features on the server. Heavy write load is an issue. But we’ve some workarounds like moving that data to a different DB and connect to without oplog access.

For these kind of things, you need to have a reactive DB support. Like rethinkdb.
But, moving to pure node or something else, does not solve this.


Actually server-side rendering is not officially supported, you can use a community package but it’s still a hacky way.

Yes. This is an issue. We will have it soon. (May be from MDG or from the community)


What makes Meteor cool is the way the view updates itself live and you get rid of HTTP roundtrips to receive fresh data.

But few applications components really need live updates via socket, if you don’t write a messaging app it’s ok to refresh your view every 15 secs via an HTTP roundtrip.

Data sync is the core problem of any app. You can hack and do stuff for a small app. Once your app became big and team became big, you’ll have to face real issues. End of the day, you may have built something like meteor yourself. :smile:


And building a messaging app would require a more specific stack like a pubsub server.

Yes it is. You may need to use a queue like Kafka or an ESB. But, who’s going to stop you from doing it. Meteor is a node app end of the day. We can use any npm module we like.


The Blaze rendering engine can be replaced by React, which also is a better way to tie logic with the view, is going native on iOS and can render HTML on server-side for SEO.

React is really good. I agree. But react has the same data sync issues and architectures. That’s why they are experiment with techniques Flux and now Relay and GraphQL. I don’t like flux but Relay and GraphQL seems to be a good concepts. But never know how they are going to work in a real app. Need to wait and see.

React Native is super awesome.
There is good discussion about React Native and use Meteor as a backend. There are some successful experiments like using DDP for a React Native app.

But if your app needs to expose API endpoints with authentication, don’t mess running transactions when restarting the server and be more resilient to embrace incoming technologies (like React Native, new databases…), you will be stuck with Meteor.

You’ll be able to use React, Angular with Meteor soon officially.(or in stable manner).
Transactions and hard. Reactive transactions will more harder. But, we’ll be able to see SQL support before end of this year (I think). With that lets see what we do about this.

I think we need to invest more on DDP(mostly servers) and move it to other languages.


Having said that, if you decided to use Meteor. You’ll have to depend on Meteor or customize/hack it as you needed. Someone can think like it’s a kind of vendor lock in. But, such kind of locks are hard to prevent.

I think Meteor is way beyond Meteor itself. DDP is the key. MDG should form a team to decide the future of DDP. I think that should done in the community level. MDG should give us the leadership. There is a lot community can done, if correctly organised.


#3

I find such articles plain foolish. (Not the author, I don’t mean to insult)

It looks like it is an article which has been put hard work into, but in fact not that much. All those items can be addressed in one way or another, given one does the research.

To seek an out-of-box solution that does anything and everything app development, like the holy grail of development stacks, is foolish. Perhaps we’ll have such a framework in the (near) future, and perhaps Meteor would be the one entitled so.

But what matters is being able to choose a development stack based on the actual requirements of an application. No serious application that requires all those things together will have been delivered using a single stack. As engineers, we have to assess our tools, select the most appropriate (not the best) one or (an appropriately sized) mix the necessary ones that fit the job at hand.

Meteor is growing, the company behind it is growing, the community is growing, so are some (funded) early adopters. Some will move away, some will come joining in. But there is one indisputable fact that Meteor has been a game changer. The direction of the game may not cater to all players, and there are plenty of other games for those who prefer/require those others.


#4

I find the article ill-informed. It is all too easy to criticise something when you don’t fully understand it. It is much more difficult to take the time to thoroughly get to know a product in order to present an unbiased view of its strengths and weaknesses.

@pierre joined this board on May 27th, asked one question on May 30, and posted his medium blog on June 1.

Well researched?


#5

There is also a parallel thread on crater.io on this topic.


#6

As a shameless plug, the simple:rest project I’m working on with a few other people is going to straight up solve the whole HTTP authentication thing. We are working on a set of middlewares and login endpoints that will make it easy to interact with your app over HTTP if that’s what you need. (I agree that Meteor is all about DDP, but DDP is not a great protocol for serving files, or interacting with an external service that only knows how to call HTTP endpoints).


#7

I’ve advocated and evangelized for Meteor in countless situations over the past three years. Have had, gosh, nearly a dozen consulting clients, and two or three jobs that lasted for a year or longer. And at really good rates. So, Meteor has treated me well in that regard.

But I’ve also lost jobs because of Meteor. It’s burned me a couple of times. And probably the biggest burn was with a pre-existing Mongo installation, and how the Meteor accounts system doesn’t support ObjectIds with timestamps. If a company already has a mongo installation, especially if it’s been sharded… no way. Can’t recommend Meteor to such a company.

HTTP authentication was also a hot-topic issue for the previously mentioned company that had the preexisting mongo installation. It was more of an issue on principle than in practice, since they didn’t actually have anybody using the HTTP authentication. But I’ve definitely had to do a lot of defending of Meteor on that issue as well. Explaining that Meteor had most all of the same internals as Express. Glad to see that there’s a solution for HTTP authentication in place nowdays. Thank you very much for the hard work in getting that resolved, Sashko.


#8

I think the right question is: how important are these issues to you and your project? There are certainly companies out there that are successfully running on Meteor (LookBack, WorkPop)–my company also has Meteor apps running in production since version 0.6.4. There are probably all kinds of reasons why this or that framework might be less than ideal for a specific project. You have to make that risk assessment for yourself. In our case we feel strongly that Meteor is the best framework for our needs. We’ve been doing all new development in Meteor for just over 2 years–and we’re loving it.


#9

If you can’t learn all the ins and outs of a framework in 4 days then what’s the point, right? /sarcasm


#10

This guy’s blog is just a great example of link baiting. I took the bait, so more fool me.

In the scheme of things that article means nothing and will just wither. I take way more seriously comments such as those made by @awatson1978, but the point there is not throwing all your toys out of the pram just because Meteor may not be the best fit for everything right now. It’s about a solid understanding of Meteor core, when a community package is appropriate to fill a gap, when an alternative approach to a shortfall will work, and in some cases a view of what’s coming up. If you have nothing after that, then fine: for that particular project use something else and evaluate the next independently.


#11

anyone care to elaborate on why the guy said meteor is bad for transactions? much appreciated!

thanks :smile:


#12

I think it’s not meteor it’s mongodb. There is nothing meteor stopping to do transactions.


#13

Hi Rob, author here,

if you want to know what I achieved with Meteor, which are pretty big apps actually, why don’t you just send me a tweet or an email instead of trolling here and https://crater.io/posts/TjumT4eQv6SANY4Yq ?

This is not the place to justify what I do or what I am, if you want more information ask the NSA.

Why don’t you show us your great knowledge by replying like Arunoda did ? would help everyone eh ?

And what linkbaiting are you talking about ? this makes no sense…


#14

Hi @serkandurusoy , you find my article plain of foolish, but you wrote the same thing as my conclusion: the stack depends of the application.

That’s why I gave “my” reasons why you should not put Meteor into your stack, and if you read clearly I never said not to use Meteor at all.

Relax, take holidays, life goes fast, don’t waste your time to hate, and if you want to talk, write YOUR article.


#15

My conclusion encourages research while your conclusion encourages using Meteor only for messaging apps.

Arunoda did reply with a fuller answer which I did not find need to repeat. I find your article foolish because of the first reason I pointed out: “All those items can be addressed in one way or another, given one does the research.

This is not about hatred. This is about pointing it out when people write overly-self-confident articles based on insufficient research which focus on possible problems without so much as a hint about the actual solutions.

If you had asked about any of those so-called problems here on the forum, you’d be surprised by the amount of information and ideas the community would be willing to share to solve them each. And with a little research, you’d actually see that they have actually been all discussed on the forum and been addressed properly.


#16

can you point in direction that shows where meteor has solved http auth. @awatson1978
many thanks
quite new to meteor and trying to determine if it is a good approach for our application - we has an existing application using mongo and it contains its our auth.
thanks


#17

@serkandurusoy My conclusion is not “use Meteor only for messaging apps”, it’s the opposite, building a messaging app requires a much more scalable stack than Meteor. We definitely can’t understand each other so I won’t reply to you anymore.

Yes some of the points discussed in my article can be addressed by some third party packages, but those are so critical that they should not be hacks at all but treated as they should be in the official Meteor API.

I don’t build my business on hacks, so sorry guys but if I need 5 hacks to get a production-ready app, I prefer creating my own stack.

And because I maybe won’t work with Meteor as long as those points are not officially addressed, I wish you all the best for your business.


#18

Facebook is building it’s business on Hack http://hacklang.org/ :wink:
And for your information, the French gov is using Meteor too https://github.com/sgmap/meteor-assemblee-nationale
Maybe you have some point for now, but Meteor is only 3 years old and they are not going to stop, with or without your recommendations :yum:


#19
  1. What is the purpose of your article? If it is to inform, then perhaps one can eliminate the feeling of a “clickbait” TITLE (“Anymore”? were you previously a Meteor evangelist?)
  2. Are your critical points relevant to a potential developer/user ? Aka, will I likely run into the problems you describe as a developer trying to build an app in Meteor? I’m not so convinced of this. Criticizing a holistic platform for it’s components behavior with external systems when applied in non-meteoric ways seems a bit dishonest: A bit like criticizing a hammer for not being a screwdriver.
  3. The “Magic”, as you put it, has the usual turtles inside, and provided you are comfortable with the internals of said turtles, you can swap other turtles out, and generally hack away. This is not necessary for general usage of the platform, so I think that it’s rather a good thing that the “magic” exists and that the MDG has managed to homoiconicly weld all of this stuff together in such a comfortable manner.
  4. If you write a critical (perceived as negative against something or someone) article on a public medium, you can expect to receive reactions. While you may not agree with these reactions, you will find that a dismissive tone merits an equally dismissive reaction, particularly if your criticisms lack a quality of IMMANENCE. An immanent critique uses the internal logic of a system to criticize said system. One “hoists the enemy upon his own pitard”, so to speak. Your critique seems to lack this quality and rather attack from outside, which is why you are getting comments alluding to your article being off target. If you wish to destroy something, understand it first.
    I’m not really that interested in writing an article about how neato Meteor is. I do feel obliged to mention these points, not in any absurd hope of convincing you of anything, but merely to put these points on the table, where I feel they belong, next to your article.

#20

Then please mention them