Replace Next.js with Meteor?

For a long time I’ve been planning on using Next.js (or Nuxt if you fancy Vue more) over Meteor on this new project of mine because of two reasons:

  • SSR (+ caching) for SEO and snappy page loads
  • Dynamic imports for small bundles

Just so happens, Meteor has catched up and seems to support both. With v1.7, Meteor is passing the competition with support for building two different bundles, one for modern browsers and one for the legacy ones, which is a huge win for bundle sizes beyond just code splitting.

So, has anybody toyed with the idea of “build your own Next.js” with Meteor? Is it doable? What is missing and what’s only half-way-there? What is Next.js doing better or what Meteor cannot do?

When I think about it, Meteor already has:

  • It’s own node based server
  • DDP + Methods or Apollo
  • Dynamic imports / code splitting
  • SSR
  • React for view layer

I’d be more than happy to do some extra leg work in the beginning to stay in the comfort of my familiar spaceship :comet:, 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”.

Any ideas or tips before I dive into Next.js docs?


Would be happy to contribute to say the least. I’ve some experience with Next and am also building stuff with Nuxt. I think Meteor’s ecosystem combined with a proper structure would be a very powerfull combination.

1 Like

I have some experience with Meteor’s code-splitting and dynamic importing, but SSR to me is the scary part which I haven’t touched and have no idea how easy it is to accomplish.

The guide doesn’t say too much about it:

Server Rendering

The Blaze UI library does not have support for server-side rendering, so it’s not possible to render your pages on the server if you use Blaze. However, the React UI library does. This means it is possible to render HTML on the server if you use React as your rendering framework.

Although Flow Router can be used to render React components more or less as we’ve described above for Blaze, at the time of this writing Flow Router’s support for SSR is still experimental. However, it’s probably the best approach right now if you want to use SSR for Meteor.

Anybody had success implementing SSR?

1 Like

If you’re okay not using a folder based routing like next, you’re propably going to have fun with

1 Like

Thanks, very much relevant!

I did. I actually started writing about it in my blog:

Doesn’t Vulcan already fit this bill?


Meteor ssr settings quite simple, everything info is here in this forum, in particular works nice with react-router-config, light weight bundle size, crawlable by search bots excellent and green cards on page speed insight

Good to know, I guess I’ll have to gather all the bits and pieces from the forum and maybe try and curate it into the official guide.

This has completely slipped past me. Even though I’m not looking for a solution like Vulcan, it will surely come in handy when trying to figure out how to setup SSR properly :slight_smile:


After working almost three years on a Meteor app that’s become quite the beast, it’s really something to type

meteor create --minimal my-new-app

1 Like

@arggh I did it successfully a year ago (but only client side Meteor).

Take a look at this article I wrote, I hope it can be helpful to you.

1 Like

You can check out SSR working with React in Meteor in my starter:

I even have a branch for rendering to node streams - for even faster performance. Really this needs a front end cache on it, to super charge it, but that’s a bit beyond the scope of a standard Meteor app.


Cleverbeagle’s Pup does that as well:

1 Like

A major hinderance in performing full SSR using Meteor is the fact that Meteor does not use cookies by default in its authentication mechanisms. So basically when a Meteor powered node app renders the page for the first time (via onPageLoad function from server-rendering package), it really has no idea whether a user session exists or not, since that information (the token basically) is stored in browser local storage.

So if you would, lets say, login to a website that implements SSR (incorrectly) and afterwards refresh the page, the output from the server would render the DOM as ‘not logged in’ whereas the client would render the DOM as ‘logged in’ and react/vue whatever would complain due to mismatch of DOM between server/client renders.

This is not a show-stopper, but it basically means Meteor users are limited to implementing SSR for public facing routes only which do not require any authentication which isnt too bad (do authenticated users really need SSR anyway?) or having the client set a cookie on login that the server can then read (not good security wise) and render the page accordingly.

Its amazing how many tutorials/howto’s etc. miss this basic use case and its definitely something to be aware of.


Thanks for pointing this out!

My use-case would survive this hindrance though, since all that’s going to change is probably a small part in the header and maybe some buttons being enabled or disabled. So I’d be happy rendering the view as not-logged-in on the server, then doing the authentication dance after hydration, but I can see why that’s not the case for everyone.

Have you made an issue about this in the Meteor repository on Github? Maybe it’s worth talking about.

I think Meteor just needs HMR at this point - its like the top the thing Webpack users shout about


I have done a small project with HMR and Meteor using

It’s not for production usage, just for teaching

The stack is pretty simple, MongoDB, Meteor Methods (instead of GraphQL or pub/sub) and React.