[anonytrary]

I started using Meteor in 2014. I was active for two years, posting frequently on their forums, writing packages, building MVPs, etc. As I started building more things with Meteor, I realized that it doesn't scale well. It's great for proof-of-concept work. Frameworks can be incredibly productive for low-scale work, but they are painful to scale. No framework that can be simultaneously optimized for every use-case. Now, I always DIY with a router like Express.

Meteor's problems were rooted in its real-time protocol, DDP, which had some problems. Firstly, everything is real-time by default. It's better to minimize the amount of real-time components in your application as there are very few things that need to be real-time. Secondly, the pub-sub caching mechanism made it infeasible for situations with many concurrent users. I was able to get around this by proxying some of their internal functions.

Significant people in the ecosystem started leaving (e.g. Arunoda), probably for the same reasons. AFAIK, it's still the best JavaScript framework out there for prototyping and MVPs. Their accounts system makes whipping up a user-driven application trivial. MDG (the phenomenal team behind Meteor) is likely focusing their efforts on Apollo now, because they understand DDP's shortcomings. If you're interested in Meteor, I suggest looking into Apollo.

[ramezrafla]

I respectfully disagree on some key points.

- 'key' people left because they were service providers (including Arunoda). When the platform became mature and easier to use, they could not get business.

- DDP works great, Apollo is a GraphQL layer, two separate projects and target users. If you have a lot of users you need to design pub/sub carefully regardless of tool. Reactivity makes it a bit tougher, but comes with great benefits (unless your project is 'simple' or more static)

- Scalability? It's great, and we are the proof -- you just need to know what you are doing (i.e. redis)

[KajMagnus]

About: "we are the proof" — who are you? :- ) It'd be interesting to have a look at your website or web app or Git repo or something. And, if you have time, I think it'd be interesting with a few words about how / why that shows Meteor works well? E.g. num concurrent users that get pub/sub messages? (Your HN profile is blank, there's a GitHub user though with your username, who seem to do lots of Meteor related work. I'm using Nginx and Nchan for pub/sub messages, and ... I'm curious about Meteor and other things too. No plans to switch from Nchan though.)

[kamyarg]

What do you mean by it does not scale well? number of users using it or size of the project?

[justaaron]

The server "publishes" particular queries as a kind of feed, and the client "subscribes" to some number of these feeds and behind the scenes, a miniature mongodb-like-api (mini-mongo) in local storage gets filled with all the published data you are subscribed to, so both the number of documents needed should be limited, as well as the scope of the query itself, for performance reasons... Scaling in the sense of: 1) number of simultaneous users maintaining a DDP connection with the server and the beating the db and backend take 2) amount of documents that get shoved down the tubes.

So, the more fundamental issue: Nothing about meteor's approach allows substituting components from the rest of the javascript ecosystem, other than the view layer, as the server side only speaks DDP, as does the client, etc.

One cannot easily optimize the various routes of the application as it's all just one very tightly coupled SPA with a ddp backend?!

I ended up being able to use an apps existing data, and taking the templates/components and patching in 1)routes and all dynamic data and what not from the server side needed to "dish-up" the template plus some 2) vanilla javascript to post data to server routes that may return either markup + data or simply data that get's patched into the specific place in the dom that needs updating.

This at least provided a basis for further work on individual routes/views etc.

[vlasky]

For real-time webapps when you need minimum latency updates, Meteor is a dream. IoT, GPS tracking, messaging apps and stockmarket trading apps are all well suited to being implemented in Meteor.

DDP is a simple protocol that runs on top of WebSockets, which runs over TCP. Back in 2013, someone achieved 12 million concurrent WebSocket connections on a commodity server. There is no reason why Meteor should not be able to handle a comparable number:

https://mrotaru.wordpress.com/2013/10/10/scaling-to-12-milli...

Meteor fully supports the NPM ecosystem. Meteor does not have to always use DDP. You can implement RESTful APIs and serve static pages using the many router packages available.