I think meteor is really a modern app.
But I’ve always had a problem with that.
I was traumatized when I had to scale meteor to thousands of users simultaneously a few years ago. I had to start getting too much under the hood, felt hacky and there was no much documentations about it. Meteor shined for me for “internal” projects, where less than 100 users use it simultaneously, making reactivity shine, or when you can make an independent deploy for a client. Above that, you need to start cutting reactivity out and start using a lot of techniques that on the infinite, will make you stand on Next.js-like grounds.
Agree, Next.js has no accounts or db implemented. But it comes with easy of use data-fetching api that is called seamlessly in the client/server by Next (it does have some magic in this regard).
So, when I’m developing an app that I want to rest assure it can scale globally, meteor scares the shit out of me in this regards.
Also, in terms of cost, Next.js is cheap to host (serverless kind-of architecture), where for Meteor I needed to become a Devops expert to do horizontal scaling, specially with MongoDB so tightly coupled. And galaxy is expensive.
I wish to be proven wrong, so I can return to Meteor for projects that need to handle global usage at ease, with peace of mind.
Meteor development still seats in my golden days, before I had to go out to the JS and corporate wild world.
You were feeling the FUD, did you actually build an app that scaled to thousands of users in any other framework? can you please share it with us?
First, not all apps will scale-like to Facebook, scaling is a solvable problem, in fact, especially with Meteor is has been discussed until exhaustion, and there are many ways to scale. But getting off the ground when you’re tight in resources is usually the main bottleneck for entrepreneurs and this where Meteor has way more to offer than NextJS (the hyped framework).
NextJS doesn’t really solve the scaling problem, because it has no backend to speak off or any built-in real-time capabilities, you’ve to figure this yourself, in addition to accounts. What you are talking about is deploying static sites on CDN and you can do that with Meteor backends, we’ve several apps like that. To put simply, unless you completely outsource your server (serverless and platform as a service) you’ll always have to think about scaling and start optimizing once you start hitting certain traffic size.
Did you see the new pricing by Tiny? I think it’s very well priced now (although it could always be lower) given the value of its offering (completely remove the need for DevOps). And where exactly are you planning to host your NextJS backends if you want to avoid vendor lock-in?
Yesterday I build a Covid19 stats app for my local state for fun using Meteor. Here is the API call from the client:
let data = await server.call('novelCovidProxy');
Can you think of anything easier?
You were proven wrong. Many folks did scale and make money, create public-facing scalable apps. I really don’t understand how can you repeat the same statement, when it is very obvious that is not true, that is the definition of FUD, please check what others managed to build, keep an open mind and ignore the FUD/hype.
No, I haven’t, I always had to decouple bottlenecks into independent scalable services, so far.
The problem I had was that every new connection would open a new ddp socket, that somehow would impact in around 0.5MB RAM increase in the Mongo router. Going from subscriptions to only methods would only alleviate the problem.
I remember I would max out Galaxy’s resources and still, when the webapp was mentioned on a TV show, and thousands of connections would bubble up in minutes, everything would melt. I remembering using the biggest Galaxy’s VM’s and each one would handle no more than 400~500 connections at a time, having a maximum of 25 instances available. I would also hitting limits in mlab router sizes to handle the load.
I admit I’m a DevOps novice, but this wasn’t easy to fix, In fact, I couldn’t.
How would a scenario like this be handle gracefully today in Meteor?
Exactly, at the end I want every endpoint of my app to be served statically from a CDN, then hydrate from that. Not even SSR beats that.
Vendor lock-in is not an issue for both Meteor and Next.js, thankfully.
I can’t. 
But using
const { data, error } = useSWR("/api/whatever", fetch);
will be called on the client AND/OR server without you worrying about it in Next, that’s sweet.
Thanks for proving me wrong. Still, I just shared my experience a few years ago, when building a marketplace in Meteor maybe was not the best idea to scale it out easily.
Hope that today is different, and I would love for anyone to drop a nice article/doc about how this can be done, in a way that follows Meteor simplistic spirit. Because if even today, to scale Meteor you need to turn off so much of that sweet magic and easy of development/deployment, then I’m back to my point, I would use Meteor for niche applications, MVP’s, or when use case allows for easy tweaks that scale easily.
Thanks, @alawi
P.S: I’m currently just trying out Next.js, not married to it, have no idea what scaling challenges I will have here, but on papers seems to be structured in a way it’s easier to do so.
These are all great answers. I guess Meteor is the best way to go and I started my application development with Meteor.
There won’t be any need for me to use the traditional pub/sub system, since I’ll be integrating React + Redux with Meteor method calls instead. It has been working out great the past few days and I hope this will help limit some of the performance issues that could potentially arise for a larger user base.
perfectly understandable as a business concern and nothing to do with FUD. Its where a lot of us who come back to look around are. You were not proven wrong depending on when your experience was. It probably was because some unofficial work arounds were not solidified yet. diaconutheodor for example here Meteor Scaling - Redis Oplog [Status: Prod ready] has done some work on things that might make your experience different now.
A lot of the things that make Meteor more workable from the old days are not reflected in doc or guides. The expectation from some is that you should dig around and know this but hopefully these things will soon be more upfront and official because thats an unreasonable expectation.
So yeah Meteor may well work for you This time around. Just know your concerns are rational and not FUD. I am in the same boat you are .You are just doing your Due diligence based on a real past experience. Thats what a good developer should do.
Good luck to you.
If you have scaling issues with Meteor, you should give redis-oplog a try. I have no idea why it still not part of the Meteor core. We also had issues with our chat application on the beginning, because the MongoDB Oplog killed our whole application when we‘ve executed the cronjob for cleaning the database from old messages. After switching to redis-oplog everything runs fine and our VM handles hundreds of concurrent users without any problems.
The FUD is when folks don’t use the tech, don’t do research on how it could be scaled, don’t try the potential solutions in production, abuse pub/sub, don’t offer viable alternative, and go and claim to everyone else it doesn’t scale, or repeat thoughtlessly what they hear. And please don’t take my statements personally, I am not referring to you specifically, I know you were looking at RedisOplog, looking around and just on the fence, I am speaking in general.
Unless you outsource your infrastructure (Firebase, Serverless, etc), you will need to develop knowledge to be able to handle large scale in any framework, there is a reason why DevOps is a full time job and for Galaxy (Firebase, Serverless and other PaaS) existence, it is to outsource DevOps at certain cost and trade-offs (specially vendor lock-in). Meteor scaling behavior is very well understood (it has been around for 8 years) and there are well known solutions and unique offering at every stage of scale you will reach (if you manage to reach), which you won’t find if you go plain Node (nest or feather js etc.).
NextJS still does SSR for every page (which means server CPU, unless you generate static site), still open socket to the server (to push the components), and has no backend, so really they didn’t solve the scaling issue, they just delegated it and focused on the front end, and only one front-end (React) and with very opinionated offering. That is my issue with NextJS, I really think it is an overhyped, it needs some scrutiny, they somehow managed to convince a lot of folks that they have solved performance and scaling, when they didn’t, but they have safer defaults and delegated/decoupled the back-end, good marketing and another PaaS offering to make money.
I personally think NextJS is good only for blogs and CMS (not even landing pages because React is heavy), although Gatsby is better for those use cases, so I really don’t know what its unique selling point and I personally suspect that its authors don’t know either, that’s why they initially marketed as SSR React framework (SSR was trendy), then static site generator (JAMStack became trendy) and now “hybrid” framework, so perhaps it is called NextJS to refer to the next trend they will surely be after.
Regardless, Meteor is very different tech from NextJS (the opinionated React only front-end framework), and I don’t really think they are comparable, they solve very different things.
At this point I’m not even sure if you’re serious or just trolling anymore. 
Why? I am really being honest, I really don’t see it (maybe I am stupid or something) and I explained my thinking it’s not far fetched to think NextJs authors don’t now where to position it long-term, it’s competitive and rapidly changing market and they already pivoted several times in their short existence, I think they are the React of WordPress, they wanted to be the PHP of React but they ended up the WordPress of React (and not the best at it either)… 
Don’t you think that Gatsby is a serious competition to NextJS and they are competing over the same offering and market (i.e. the WordPress market)?
Anyway, I really don’t want to sound like a troll, I think (hope) I made perspective clear, that’s my honest opinion and people can do their research and form their opinions, I will go back my coding :).
It is like with all development efforts: what are you planning to do?
We use Meteor, because we need the reactivity in a classroom environment so we can provide a learning process that goes beyond behavioristic models. This is from my research perspective impossible with any other framework.
If we have another use case we may use a different framework but if there is a DB required and accounts, code splitting etc. I will still use Meteor because this is all there without any extra integration.
Regarding scaling: If it does not scale it is usually your app architecture that prevents you from it. If you target 10000+ users you will have to make distinct changes what when and where to subscribe, stop, oberserve etc. and this takes time and effort. Do other “reactive” frameworks eliminate this process? I highly doubt it.
Very timely discussion. I too am looking at the benefits of meteor over nextjs and similar stacks. I have being following the jamstack hype especially around gatsby and Nextjs. If meteor is for fullstack apps with db integration, can this be achieved with nesxtjs? What is the price we have to pay in long run when my nextjs app requires the use of real-time data fetching as appose to pre-fetched.The interesting part for me as a beginner is deploying your app for free over netlify or vercel etc. Some of my thoughts.
The selling point of NextJS is super fast dev time (yes faster than Meteor’s) of React based apps with SSR, SSG, folder based routing with serverless API functions. All of these things are difficult or impossible to do in Meteor.
SSR works well enough in Meteor, but it’s not nearly has easy as it is with Next.
SSG? I don’t think it’s possible with Meteor
Serverless architecture for API functions? Not sure how that would work with Meteor either.
Folder Routes? Not doable in Meteor.
You can maybe argue that you personally don’t need or want any of these things, but it’s obvious that tons of people do. And as someone who’s used both platforms extensively, I can say that they are very useful. IMO those features are certainly not limited to the WordPress market. Just ask some of their clients like Hulu, Nike and the like if they are using it for just blogs.
That’s right, yes I don’t personally need them (folder based routing and SSG, not much value added to my users) since I want full stack framework and I am not creating Nike landing pages (although I think Svelte and even Gatsby would have been better choice for that).
And yes that what tons of people do, that’s why WordPress and the like are popular. My personal preference is (CRA or Gatsby) if I want to use React, and Svelte for highly optimized landing pages, and Meteor for full-stack, real-time, accounts.
But I agree with you, static sites, serverless and faster dev time (because of webpack HMR) are the selling point for NextJS (and Gatsby). It’s good we have many choices for different use cases and NextJS is a good framework, I just wanted to scrutinize and challenge it a bit since it’s very hyped (I actually like it too since I am a big React fan myself, but it’s not for every use case).
I think it should be clear now the difference and pros/cons of each stack.
I’ll just say this and leave it there (we’ve had enough back and forths recently) -
You (but not only you) are using the term wrong which isn’t constructive and is frankly inflammatory Here’s a good definition https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
People dealing with real information of what they experienced and was undoubtedly real are not engaged in or the victim of any STRATEGY. If you had a well known past history of failing your wife or significant other in regard to fidelity prospective mates wouldn’t be involved in FUD to think you might let them down. You would have earned that reputation, Assuming THEY have the responsibility to “do research on how” or where you might have changed isn’t a winning strategy to improve your love life.
“Honey you got to do your own research on how faithful I am now or you are just engaged in FUD” is going to get the next guy in line closer to a first date.
This I agree with. FUD is too often used to describe legitimate issues.
Why compare it? these are incomparable things! NEXT for websites but a Meteor for the coolest web applications!
That’s all!
NextJS is very much for webapplications
It has a backend. API routes are built in. NPM is the only package system it needs (imo that’s a strength).
It requires a server for SSR rendering (when it is not used as a static site generator), and lately as of last year, they added the ability to add API routes (added in version 9), because it was highly requested. But it has no opinions about your backend or your data sources (which might be good in many cases), it is very different than Meteor which is much more opinionated about your backend.
For me the difference and the use cases for two frameworks are very distinct and clear.