Meteor or NextJS: What's more viable today?

1

So I have been using Meteor to build applications years ago. I think 2016 was the last time I built a production app with Meteor and it was a blast and never had an issue with it. But as I started working in industry full time, I didn’t have time to work on my own projects and kind of left the community behind.

Now, I have time on my hands and have several product ideas that I want to build and Meteor was naturally my first choice since I have experience with it. But NextJS seems just as good, if not better, than Meteor.

So my question is (be as unbiased as possible): Which framework would be the best to use in 2020? Everything counts: SSR, scalability, etc.

Thanks for your input.

1 Like
2

easy :slight_smile: … Meteor, because of your interest in Next.js, I assume you would pair React w/ Meteor today

Here is what Next.js won’t have without your extra effort and ongoing maintenance:

  • Websockets (Pub/Sub) (Meteor’s DDP), you will have to add your own
  • A database, yeah there is lots of options, but MongoDB is just the best
  • Method calls from client to server
  • A built in secure accounts package
  • A heavily tested client/server/database bundle

Basically Next.js probably looks a little more attractive than Meteor because it’s newer and yeah it’s SSR is tightly integrated because that is the main focus, but you can have SSR with Meteor too.

Meteor can do everything Next can do, but Next can’t do everything Meteor can do.

If you’re building a really serious app, go with Meteor.

If you are building an app where you may not even need a full-stack (backend or database) then you might want to go with Next. But if your app grows in complexity, you’ll probably wish you had picked Meteor.

I made a similar investigation and decision about 1.5 yrs ago when I picked Meteor + Vue and I did look into Nuxt.js (Vue’s Next.js). The app I’ve got now would have eventually been really limited if I had picked Nuxt.js. And I would have done tons more coding to rebuild things that Meteor already does out of the box.

Meteor & Mongo DB are better than they have ever been, so while not getting loads of hype these days, they will make your life very happy. :smiley: There is much more that could be discussed on this, but we could probably provide more if you want to talk about the kind of app you might be making.

Also it should be noted that since you built on Meteor, there is free hosting on Mongo DBs Atlas service and Galaxy hosts for as low as $7 a month. So you can run you app in the early release phase for much cheaper & with about zero effort on a deploy.

Galaxy & Atlas are designed for scale effortlessly, so as long as you use good design, you’re Meteor app could scale to the moon :full_moon_with_face: :rocket:

7 Likes
3

I agree with what @mullojo is saying, and it’s an easy and a good question

NextJS is a static site generator with out-of-box opinionated SSR implementation. It is very opinionated and coupled with the view layer (React) and has zero opinions about your backend. Thus, it’s good for specific cases but I don’t think it’s a good fit for full-stack apps since you are left to figure the backend yourself and you’ll be locked-in to a specific view layer.

I’m a Meteor fan and this is a Meteor forum, yes. But I honestly think NextJS is an overly-hyped tech (it’s probably 1 year away from the peak of its hype), it’s neither the best React static site generator nor a full-stack solution. I’d use CRA for React only (more flexible), Gatsby (or even better plain HTML) for static sites (better defaults/performance), Razzle for SSR (more flexible SSR solution), and MeteorJS for full-stack/backends (battle-tested and the most mature and stable NodeJS full-stack platform out there, you will pretty much find a solution for every problem you might encounter, someone on this form has probably already solved it).

Thus, NextJS is a no-go tech for us because it’s the best at nothing. But you can also perform your own research and opinion and let us know.

2 Likes
4

I’ll leave it to the seasoned professionals to give the deep dive, but if I can add my perspective as a novice.

Over the past several months I’ve tried to make the same project on Meteor, NextJS and Gatsby with various different backends and databases (Headless CMS’, MongoDB, Postgres with Hasura, Firebase, Apollo, I don’t even know anymore). I eventually gave up on NextJS. I got Gatsby working but not nearly as easily as with Meteor.

I love Javascript, but in general it still feels like the wild west out there. Meteor is an invaluable asset to somebody like me who can’t keep up with all the different libraries and dependencies and how to make them all work together. MongoDB (or any DB) + Accounts + Methods/Pub/Sub + React is a combination I haven’t been able to execute as well or as quickly on any other backend framework or combination of libraries.

I’m afraid that this requirement to be trendy in the javascript ecosystem kills or discourages ongoing maintenance on frameworks and libraries that javascript programmers in novice and intermediate skill levels like me depend on. It feels like people are continuously reinventing the wheel rather than patching up the wheels built a year or two before. I shouldn’t complain though, I’m a hobbyist that contributes very little to the community at large. But I think it can be a bummer for people like me (plebs?). Feels a little bit like gatekeeping sometimes, even if it’s unintentional. Maybe I’m just bitter? But it doesn’t feel like that with Meteor!! It would be a bummer if after a (relatively) long life it finally fizzled out now. It has so much more to offer, especially with Galaxy!

7 Likes
5

I agree with @juan’s assessment.

Our stack (when using NodeJS) is either MeteorJS when it’s an Application or GatsbyJS when it is a static website. Gatsby is really cool as it is a static website, we host on S3 with cloudfront. Can’t get any easier. But for real-time apps, love Meteor.

We made some changes though to support larger traffic and improve performance:

  • Redis-oplog
  • We disabled mergebox (which monitors what data was sent and sends only what is new) in favor of smarter clients which do their best not to ask for the same data twice
  • Using a service worker to store assets (e.g. meteor JS and CSS, language files, images)

And I have to say, I am impressed at how a t3.micro can handle so much load!

1 Like
6

@juan it was informative to see your perspective/research, thanks for sharing.

Frankly, I think GatsbyJS is yet another overly-hyped JS framework that is the best at nothing (maybe only blogs), it has been marketed as a highly performant static site generator and it’s not.

If all you want is a static page with some interactivity then why not use plain HTML with little JS? Netflix removed React from their landing pages back in 2017 because it was slowing it down. Thus, it’s really mind-boggling to see folks refactoring their simple HTML static pages to React (NextJS or Gatsby), but that’s what hype does to reason.

If you still want to use the front-end framework and truly care about performance, then I think Svelte approach is the only one that makes sense, since it compiles to highly optimized JS (without virtual dom) at build time and ships pure/lean HTML/JS to the clients. So Svelte is a go-to-tech since it is the best at something (highly-performant lean clients), I think even Blaze is better than React for this task since it has no virtual dom.

React was not designed to be used for simple landing pages and websites. It is an implementation of re-usable web components for large and complex rich internet applications (and not simple HTML pages), you’ll be shipping tons of useless heavy JS code to the clients.

But don’t take my words for it, here is Dan Abramov (core React maintainer) making similar observations recently.

1 Like
7

Counterpoint:

vanilla static sites are not an ambitious enough goal. Take transitions for example. Web developers are currently trapped in a mindset of discrete pages with jarring transitions — click a link, see the entire page get replaced whether through client-side routing or a page reload — while native app developers are thinking on another level

Also, I haven’t used it yet (will for an upcoming project) but I personally think Next.js is not over-hyped and actually looks really interesting. Especially with the last two releases (9.3 and 9.4) it has gotten some amazing capabilities. It is not ‘just’ an SSR option; it can also do SSG (fully static):

Next.js 9.0 introduced the concept of Automatic Static Optimization. When a page does not have blocking data fetching requirements like getInitialProps , it will be automatically rendered to HTML at build time.

and can even (automatically) switch between SSG and SSR on a per-page basis. There is no other framework that does this as far as I know.

The latest demo for Incremental Static Regeneration really blew my mind: https://static-tweet.now.sh. The speed it delivers is really amazing. Static pages, but with the benefits of a JS framework (component based source code, smooth transitions, automatic prefetching, etc).

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