Hey. It’s been a while, but I seem to be back now. 
. Though this is the Meteor forum, I’m going to be brutally honest with you.
Meteor is Awesome. Next is Awesome. I love both frameworks, but they cannot be compared. It’s not even apples compared to oranges. One is an apple and the other is a basket full of apples. The risk of this basket is that there is always this rotten apple that you might want to throw away even though you’ve now paid for it. The real question you should ask is does the price of buying the apples separately outweigh the price of buying 1 basket and throwing away some of them. Even more so, if you consider that the apples of the basket were picked by real apple experts, do you really want to take the risk of picking the wrong apples yourself?
Both Next and Meteor have their purpose and what you should look at is what they give you vs what you have to build or throw away.
Next.js is your apple. It’s an amazing view layer and it provides you with all the tooling needed to easily integrate your React frontend. Not only that, it follows some nice patterns to allow plug-ability which keeps your code-base nice and tidy. Some of the things where Next.js really shines is pre-rendering, serverside rendering + hydration, routing and optimized hot module replacement capabilities. In other words, it takes care of all the complex render related stuff and provides convenient functionalities to hydrate your components using getServerSideProps and getStaticProps and also a nice CLI tool to help you build and pre-render it for serverless purposes.
One HUGE thing that Next.js doesn’t have though is the state layer. With state layer I mean UI state and domain state. The Meteor guide used to have an excellent explanation about the difference between the two, but I can’t find it atm. It might still be there. Just to be sure that the difference is clear: UI state is essentially the internal state of your components and layout. For example a dropdown that is open or a collapsed menu View state is unique to an app. Domain state however is business related. For a webshop these are products, for a blog this would be articles and the categories of those articles. The real downside of Next.js is on the domain state side, because there is none, except for the hydration helpers that I’ve just mentioned.
Of course you could use Apollo, but that means that you need to create another application for its server and you need to install its client into the next project, provide it with all the boilerplate and create mechanisms to provide serverside rendering.
I’ve seen most developers do Apollo Integrations or in fact any API integration VERY wrong, creating a fundamentally broken project that requires months of refactoring to get it in good shape. Its exactly this practice that developers in companies never get time for. Its simply not feasible. Another downside is it’s reliance on React. But I would also call it a positive point, because it allows ‘proper’ integration using React best practices.
I’m very experienced in React, but I need to admit that React is a moving target. I would consider it a low level UI component abstraction with powerful state management tools like hooks and providers, but besides basic documentation for its tools, it does not promote many best practices with the result of having a very scattered community. That React is a low level API also reflects back on the number of breaking changes. React is atm on version 17/18. Any project (that includes the Next based ones) that has been there for a couple of versions has had to go trough quite some refactor rounds just keep everything up to date.
It does enforce the best practice of continuous refactoring, but it also makes people focus on the wrong things.
Meteor is your basket of apples. It has mostly awesome stuff. Especially on the server. The server by default is typically THE frontender’s weekpoint. Since the introduction of so called BFF’s (Backend for frontends) - which promised to provide a proper abstraction over existing frontends I’ve seen people doing Express.js integrations that make me cringe. Even worse, without them knowing it, they are essentially reinventing something that Meteor OWNS to the core from when it first appeared 8 years ago (2012).
It’s a paradox. People were shooting at Meteor, because it “was hard to make it work with existing backends”, but now we are introducing “BFF’s” that should provide the exact level of abstraction that Meteor gives us, but most devs fail to build an efficient toolkit that even closely matches that of Meteor. Even worse, I found myself diving into existing projects of just 2 years old and it unfortunately had to become my sole purpose to maintain parts of the API that I would never even have to touch in Meteor.
Meteor works with, but also without Mongo. Most people dont realize this, but is very easy to NOT use Mongo, but still Minimongo. Minimongo is the number 1 type of library that I always miss when building big UI interfaces. I get optimistic UI and server sync for free. In Apollo this is still very complex. Unfortunately Minimongo has been originally built to work closely with Mongo (hence the name) and that’s why people get confused by it. Best way to look at Minimongo is by looking at it as a full-stack domain data layer for the UI with powerful query and sync mechanisms. It’s NOT Mongo, but it does use similar powerful features. You can use ANY backend as has been proven by the Redis Oplog package and the SQL integration layer. I’ve been using Meteor mostly on top of existing Rest backends.
Funny enough, I see many big companies still create a BFF with Apollo Server on top of a refactored backend that also uses GraphQL?
So why do people want to use Apollo Server then? Well… GraphQL is awesome. Complex, but awesome. It’s complex, because it has a high learning curve. It forces standards and introduces a different paradigm, but I do feel that it’s the way to go. Meteor’s EJSON actually provides similar capabilities and together with DDP and Minimongo it provides all the tools you need. You could also use DDP without Minimongo and have your own UI state manager.
Meteor has a couple of “first class UI citizens” like Blaze, React and Svelte (Not tried Svelte, but it’s a cool new UI lib). It also provides Vue integration - though 3th party - but it illustrates that integrations are doable, though admitted not that simple - especially on the HMR part.
Another huge advantage of Meteor is its backwards compatibility and history of baby bottom smooth transitions to major version upgrades. That’s in contrast with Next. Given that Next works on top of React, I must say that the Next team does a good job of simplifying the transitions though.
IMHO. Meteor’s biggest downside used to be its greatest asset, which is its built system. I love Meteor’s build-system, its very efficient in bundling for targeted clients. Old browser? Here’s a special build for you! I challenge you to try and configure that with Webpack! The problem however is that most of the community has shifted towards Webpack, because of its plug-ability (Like WHY?! I just want my darn frontend to load magically, because build tools are boring… aint nobody got time for that? No offence brilliant gods that maintain these things! I truly need and endorse you!). Somehow developers love doing things themselves, because they think they are doing something really special - It’s horrifying. However a new trend is emerging. Vite is an emerging tool that relies on just the basic stuff. It’s VERY fast and simple to setup. Meteor might benefit from this new trend - though there are many directions and options on how to benefit from it.
Another downside (not sure if its solved) is SSR and hydration for Minimongo. If your app requires it, you might not want to use Minimongo. However you could of course just integrate Apollo Server and Client with Meteor and have the best of both worlds: https://www.apollographql.com/docs/react/integrations/meteor/
In conclusion
Admitted. Both frameworks are awesome, but they work on different levels. Next.js, Nuxt.js, Gridsome and many other UI frameworks focus on JUST the render layer. They have excellent documentations and I love the communities (big mention to the Vue and Nuxt communities and of course @evanyou and @akryum who has given us the Vue integration package for Meteor). Meteor is still a league of its own. It works with other tools like Apollo and the different UI libraries. You could even use Meteor’s server and integrate it with Next.js or Nuxt.js! Many devs do this. There are just a few frameworks that sort-of approach parts of Meteor’s API layer functionalities. One of them is Feathers.js, but it’s mainly focused on ‘just’ the API client / server part. Another one is RxDB, but I see that one more as a replacement for Meteor’s DDP, Methods and Minimongo integration. Again, just 1 part of the total picture.
The choice is up to you, but if your focus needs to be on features, I would choose Meteor. If you simply require a UI framework with very powerful features and things like static rendering, use Next. (That is if you decided that React is your tool of choice)
Also if you are working on a large React only project and are considering Meteor, maybe its better that you migrate to Next. However if its going to be an app that requires a BFF, then consider Meteor
, but if the experience of building a Next.js -clone with Meteor is going to be more like a space trip with Laika the dog, then I’ll pass and just go with either Next.js or Nuxt which claim to provide what I’m looking for “out of the box”.