Please, tell me more 
I canāt say I agree, but then again - I donāt really know that much yet anyways.
This also depends on a lot of factors. Iām getting ~5-15, depending on project size.
I think this is where the term āThere are Rails developers and Ruby developersā because people get so dependent on packages that they canāt code in Ruby well.
I think thereās a lot Meteor can learn from Rails, especially in package choices (different DBs view layers, etcā¦), as well as thinking about tradeoffsā¦ adding gem install some-hairball saves you time now but makes it hard later.
I totally agreeā¦ Iām getting fairly āJS fatiguedā myself and I love to tinker.
You make me worry. I am developing an app for which I am expecting way more than 100 CC users. Does that mean that I have effectively chosen the wrong framework?!
how much of that is pub/sub ? you can hold way more if you only use methods
Iām using pub/subs on each page, but typically only about 1-2 subs per page (using template-based subscriptions).
What are the most important load factors for the server? The number of users, the number of pub/subs per users, the number of concurrent pub/subs per user, the amount of data sent with each subā¦?
Do you happen know any good tutorial on how to make your app scalable without loosing reactivity?
You can have way more than 100 users on one Meteor server, you just have to be careful with your publications. Unfortunately we donāt have clear documentation right now on what is and is not performant, but hopefully we will soon.
5 Likes
Thatās what I was going to ask, I barely use pub/sub at all unless itās an obvious use case, both for performance and security. Also I find āmethodsā is a better way to encapsulate and even document what Iām doing. For instance Iām on the fence about mongo vs mysql in the future of my app due to the extensive need for relationships on fairly large datasets. This approach makes that switch relatively straight forward if I ever need to.
As an aside in all this debate on platform, Iām trying to use Angular2 and finding it quite enjoyable. I have the luxury of using what I like. Blaze is certainly easier but as the application grows and I have to bring more developers in I know there are a lot of Angular developers out there. React seems more limited to find. Also Iām finding Angular2 to perform better than React so that has been on my mind lately.
Iām still new enough with Angular2 that I certainly canāt make general statements about which is better but Iām very happy with it so far. In every non-meteor/ non-react forum I visit it sounds like Angular is the more popular choice but here itās third or fourth. Itās a really interesting challenge to figure out which and I look forward to learning more from all of you along the way.
As for why use Meteor? I agree with the comments made on this but I donāt think I have heard the obvious issue of writing code once and running in two places. This is not trivial to me. The less code you write the better for maintenance and cost and quality. While you could do this with other packaging solutions I havenāt run across any this intuitive and straight-forward
I know everyone says āchoose the one platform/library thatās best for youā but the reality is there will be winners and losers over time and if you pick a āloserā what that means is you will be stuck with less support and less options for rapid development and will be forced to switch.
Thatās fine on new work but I have applications I have supported for 10+ years. You donāt get to just restart every time the wind blows. Heck I have an iOS native app I wrote in 2008, still selling on the app store today with zero changes until now when Iām introducing some new features which is doable because of Appleās support of the platform and the community around it. So these discussions are important to me and choices do matter so I donāt view any logical fact-based argument as right or wrong and I really appreciate the dialog so thank you!
1 Like
Looking forward to this documentation! I think it is urgently needed. When I started with Meteor, I was not aware of the bottlenecks it has (e.g. oplog tailing), and from the tutorials I got the impression that it is pretty ok to use pub/subs heavily. Itās just too tempting 
It would be great if the Meteor guide would take a more ārealisticā point of view in this respect, to prevent that developers fall into the performance trap.
Anyway: Could you give please me some first hints what you mean by ābeing careful with publicationsā?
3 Likes
Yes, majority of the apps there do not need pub/sub for most of their stuff, even the so called āreal timeā apps. The only true real real real time apps is only something like messsaging (think WhatsApp). When you need something like that you would want to look for platforms dedicated to real time huge concurrency(elixir/erlang).
But that truly begs the question, that in 2016, if you dont need full real time, if you are using methods over pubsub, if you are using deperate view layer(react, angular) for front end, then why is meteor the right choice besides it is easy to do meteor install?
When meteor started, the landscape was different, nothing was as easy to make as a meteor app, no one had hot reload, no one compiled sass automatically for you without a build tool, no one has pub/sub, etccā¦
Now many years later the choices are there because for each of the thing meteor was good, at, there is a group of people dedicated to solve those problems on (npm).
The biggest value proposition for meteor right now is that it is a coherent javascript developing experience. No spending a long time trying to duck tap things together from npm. While also letting you choosing w.e you like from the wider ecosystem.
Thats why I think they are doing a good job with 1.3 module/npm support and the new meteor guide.
But how much of that value(easy to setup and get a project going) is going to matter vs doing it yourself in the future, we have to wait to see.
edit: RethinkDB support is coming i think, that would eliminate a lot of bottleneck with oplog, but still you wont want to use too much real time.
2 Likes
Now that is surprising. I thought pub/sub is what Meteor brings to the table as a core, super duper important feature.
It sure is! Hang tight, we are working on a plan to make this part of Meteor much much more awesome soon, and a big part of that is making performance much easier to optimize and understand.
Data loading is definitely Meteorās number one feature in my mind, and itās the thing Iām working on full-time after the Meteor Guide.
20 Likes
Great post and I agree with your points. Also, from a mobile perspective, with Ionic adopting Angular 2 - Angular will make a lot more sense in the greater job market. If MEAN.JS and MEAN.IO adopt Angular 2, youāll see this penetrate the enterprise a lot more than React imo. Right now adopting React seems like youāve to glue a lot of different pieces together, much like the npm ecosystem. Wasnāt this what drove people to Meteor in the first place, an all-in-one-solution?
Best news of the day!
4 Likes
you canāt just nonchalantly drop that and not expand upon it! 
4 Likes
@sashko Any chance of moving core Meteor packages to NPM modules? I really like DDP, Pub/Sub, and am 100% cool with providing my own build system. Would MDG be cool with developers picking and choosing the parts of Meteor they want? Right now, Iām working on an experimental pure Node / React app and Iām getting super lean deployments (~100kb .js file gzipped in production mode)! It would be awesome to drop in DDP and Pub/Sub, since the Meteor APIās for those are killing it imo.
2 Likes
Would love to see this too.
1 Like
Yep, I donāt think this will happen around 1.3 release, but expect more parts of Meteor available on NPM as soon as we can make it happen. I think a big goal is to make āMeteor appā more similar to āJavaScript appā - same module system, same packages, etc, but with easier setup, simpler build system, and hopefully the best data loading system of any platform.
11 Likes
please stop comparing a simple view layer (react) to all the (M)MVCs out thereā¦ Angular can easily go without anything; use firebase and you donāt need meteor. React is merely a rendering engine (for the client and server). Meteor and react are like Romeo and Joliet right in that sense
But efficient pub/sub and code splitting is even more important with react native inside apps, watches, phones and your toaster 
2 Likes
When I say React, I, like many others (in a Meteor context) arenāt just just referring to the view layer, but router, store etc.
1 Like
I find that confusing because for routing and stores you can choose whatever you want to use with React. So using React as an umbrella term for a set of specific tools that are not part of React is just confusing.
2 Likes