Meteor vs Next? A brutally honest answer

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.

Where Next.js shines

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.

What Next.js lacks

One HUGE thing that Next.js doesn’t have though a solid thought trough state layer with best practices in how to use it. With state layer I mean both UI state and domain state. Luckily Next.js is React which means that you can be assured of powerful UI state capabilities using React hooks and the context API.

UI State is not domain state

It should be clear that there is a huge difference between the UI state and domain state. Even more so, the way you manage domain state is totally different than UI state. There's an article with an excellent explanation about the difference between the two.

In short: 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 and is unique to a business. For example in a webshop domain state would be the products and product categories, 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 a tool like ApolloJS, but that means that you need to create another API 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.

React's history of breaking changes

Next.js is React. 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 at time of writing 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.

Where Meteor shines

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

The Unfortunate Meteor Paradox

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.

Microservices - The biggest argument against Meteor

As some of you might know. Meteor has and still markets itself as a full-stack platform. This is the official guide catch-phrase: "Meteor is a full-stack JavaScript platform for developing modern web and mobile applications.".

Somehow developers can't see the difference between a micro-service architecture and the term full-stack. Because of that they wrongly put Meteor into a corner of "not working as part of a large ecosystem". Did you know that micro-services themselves are "stacks"? Just look at ANY application that runs with SSR enabled. There is a server involved. Even more so, bigger sites often introduce the concept of BFF's to act as an API purely designed for 1 specific frontend. Meteor IS the ideal BFF AND your frontend. But what about Mongo and Minimongo? You don't 'have' to use it, but even for this there are some good reasons to do so - even if you don't have a Mongo database.

Minimongo is a undervalued domain state library

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. Here's the guide which illustrates how easy it is:

https://guide.meteor.com/data-loading.html#loading-from-rest

Meteor VS Apollo

So what about 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 Meteor's DDP Protocol and Minimongo it provides all the tools you need. You could also use DDP without Minimongo and have your own UI state manager.

EJSON + Minimongo is likely what has inspired the MDG folks to build a tool like ApolloJS. MDG is the company that initially built Meteor and later sort-of left Meteor to its faith and continued with ApolloJS. Tiny has acquired Meteor and seems to be igniting a spark in many idle Meteor developers. One thing that Apollo doesn't really have though is a high level API. It leaves integration of different tools to the developers and frameworks - which is good, but the same thing applies as what you see in the React community. Scattered practices and a lot of people creating API implementations that make me cringe.

If you do like Apollo (Like me) then you might want to look at using Apollo with Meteor. This way you leverage Meteor's and Apollo's advantages

Meteor integrates well with Blaze, React, Vue, Angular and Svelte

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 for un-experienced people - especially doing the HMR part is difficult, but in all fairness, try to nail that with Webpack for the server side..

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.

Meteor's downsides

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 bundle for you! Again I challenge you to try and configure such a feature 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… ain't nobody got time for that? No offence brilliant gods that maintain these things! I truly need and endorse you!). Somehow developers love doing these 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.

SSR and hydration

Another downside is SSR and hydration for 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/ 1

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 are the shiny apples. They have excellent documentations and I love the communities (big mention to the Vue and Nuxt communities and of course @evanyou - once part of MDG - and @akryum who has given us the Vue integration package for Meteor). Meteor is still a league of its own, because it's much more than 1 apple. 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! In that case a package like SimpleDDP might be helpful to easily connect Next to Meteor's DDP API Many devs do this.

There are only 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 require only the UI part with very powerful features and things like static rendering, use Next. (That is if you decided that React is your tool of choice)