Meteor or NextJS: What's more viable today?

8

You don’t need virtual dom and tons of JS for that, again Svelte, Ruby & Rails with Turbulinks and other frameworks figured out how to do that without virtual dom and tons of JS. Virtual dom is too heavy for static pages, and I don’t see a React-based app ever getting faster than simple HTML with a bit of JS, it is just not logical. They had to do tons of convoluted and complex workarounds to optimize it.

Again, I think NextJS and Gatsby are both very over-hyped frameworks, they are ok frameworks, good at marketing, they are not the best at anything (maybe only blogs) so they’re absolutely no-go tech for us. They a probably a year away from the peak of their hype, and there are much better and flexible modern tech out there for the tasks they’re trying to achieve.

I’d go with Svelte or just plain HTML and some basic lightweight JS instead for simple sites and landing pages.

9

Yes, you already stated those points. I strongly disagree with most of them, especially pointing people to Svelte over React. Have you actually used Svelte? I have, and it is absolutely not better than React. If you’re talking over-hyped, Svelte is the prime example. It is an interesting take, but they are already running into the limits of their no-virtual-dom approach (for example, they cannot start rendering in the background while loading data, which makes for a faster and better user experience). Also, these ‘overhead’ issues of Virtual DOM are long debunked. And when going past contrived examples, Svelte bundles are often larger in size than React bundles for the same application.

I agree that client-side React rendering is overkill for a static website, but that’s why SSR/SSG can offer a solution. These pages are sent as HTML, from the server, to the client. So is this not exactly what you are asking for?

Anyway, this wasn’t even the original question. To address the OP’s question: if you need an accounts system, reactive data etc, Meteor will be a lot easier to get started with, as Next.js doesn’t offer anything in this area. So you would need to use something like Firebase services for authentication, reactivity etc, which is of course a dependency to Google (up to you but I’d rather not go there :slightly_smiling_face:). You wouldn’t own your data, users, etc.

1 Like
10

Yes I’m aware of Svelte limitation with large reusable code and that is why I’m using React for large applications.

But I don’t ever see Gatsby or NextJS outperforming Svelte or plain JS for static simple pages, again that is not logical. The whole idea is that you want to minimize the JS code executed (CPU load) at the clients (especially on low-end mobile devices) and React (v-dom) is just good enough but not the best framework for that, you can split the pages, render server-side, cache client-side, incrementally load static pages and even stream the pages from the server, but at the end, you’re still executing React JS code and this will never be smoother and more performant than pure JS, so their entire selling point is moot.

Agreed. And I also prefer React over Svelte personally for rich apps (I’m a big fan of React), and it wasn’t my intention to point people to Svelte over React, but for simple and performance-sensitive static sites, yeah perhaps.

image
image1200×816 125 KB

This is a file size benchmark which is an indication of how much JS being shipped to the client, the less JS, the less CPU usage, the smoother is the experience. (benchmark source),
you can clearly see Svelte outperforming everything out there by far, there in no hype here, just facts.

1 Like
11

I think meteor is really a modern app.
But I’ve always had a problem with that.

  1. ssr
    Thank you very much, friends, for sharing their experiences with me about ssr.
    It’s really hard for me.
    Follow the example.
  • For example, getting information from an article from the collection
  • and transfer it to react
  • With react-router router
  • with ssr
    Please help me too.
12

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.

1 Like
13

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.

3 Likes
14

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. :grimacing:
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.

4 Likes
15

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.

3 Likes
16

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.

2 Likes
17

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.

2 Likes
18

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.

19

At this point I’m not even sure if you’re serious or just trolling anymore. :joy:

1 Like
20

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)… :man_shrugging:

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 :).

21

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.

2 Likes
22

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.

23

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.

3 Likes
24

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.

1 Like
25

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.

1 Like
26

This I agree with. FUD is too often used to describe legitimate issues.

27

Why compare it? these are incomparable things! NEXT for websites but a Meteor for the coolest web applications!
That’s all!

3 Likes