Doesn’t Vulcan already fit this bill?
3 Likes
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 
3 Likes
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.
3 Likes
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.
4 Likes
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
5 Likes
I have done a small project with HMR and Meteor using https://github.com/ardatan/meteor-webpack
It’s not for production usage, just for teaching https://github.com/filipenevola/wantch
The stack is pretty simple, MongoDB, Meteor Methods (instead of GraphQL or pub/sub) and React.
3 Likes
Hey there Chris, ive been trying to find an email to get ahold of you… is it possible to send me a message at admin@chosenmasters.com. I wanted to chat about working on something with you, i have a angular js/meteor app and i want to migrate to React but im having trouble figuring out if i go next js or just keep my meteor backend and upgrade it so i can do SSR, curious about your thoughts and if your a free to hire for some help on this?
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
15 Likes
This could be a great dev.to article!
2 Likes
Going to make a bit more too 
2 Likes
Excellent write-up! @vikr00001 This alone really solidifies my love for Meteor, and a good fit for Dev.to as you mentioned.
2 Likes
Hi, note that Vulcan is transitioning from Meteor toward Next. Meteor is awesome but most of its magic, especially the build system, ended up hindering us in making highly scalable app with a very low budget (by this I mean without tons of additional development and doc digging). The tools are difficult to compare though, it’s kind of like switching from English to Chinese. Both languages are great and can express mostly the same things, yet there are strong cultural differences and you will never be able to translate a book word by word. For instance, in Next, you would tend to think build time, Babel, Webpack, lambdas and code splitting, while in Meteor a lot of stuff would happen at runtime.
1 Like
Can you please elaborate further? Meteor != Next [And I’m 100% sure you’re aware of this] Next is an abstraction on top of React and well Meteor is an abstraction on top of Node. I’m interested in what ways was Meteor holding you back. Can you mention some of the problems that required extra effort with Meteor vs without it? Thank you!
Regarding problems we hit with Meteor, the most representative is this ticket: https://github.com/VulcanJS/Vulcan/issues/2580
Basically, importing a Material UI icon server side results in an empty object instead of the actual export. The problem is not the bug in itself, it’s that I lost trust in the Meteor build system. I work only with small dev teams and I can’t afford random stuff like that to happen. When you have a similar issue in Webpack, first it doesn’t happen a lot, and then it breaks the Internet => the issue is fixed within hours if not minutes.
Tooling was also a blocker. The impossibility to use extremely powerful modern tools like Storybook or Jest is problematic, especially for the frontend. Productivity is the main selling point of Meteor, but nowadays with the right tooling you may end up being more productive without it. Testing experience was poor, I also hit random bugs like the impossibility to drop collections in tests.
Another argument would be Apollo, that we use in Vulcan. It’s not an issue per se, but my experience with Vulcan lead me to conclude that if you are going to use GraphQL, you don’t need anything more than Express. Next API routes are a rather good fit since most of the business logic becomes tied to a single endpoint and thus a single file api/graphql.js.
If you use Meteor, that’s awesome, but embrace the whole thing, use DDP, pub/sub system, Mongo, etc. etc. You can still plug Apollo (remember Meteor provides a Connect server through the “WebApp” package) but it maybe better to keep it sever side if you need to open your API to 3rd party and keep using Meteor for your own frontend.
TypeScript also took a whole lot of time to be correctly supported. We already started the switch when official support was announced.
Note that I am aware that Tiny is bringing a new positive dynamic, with impressive results. I am thrilled that Meteor keeps evolving, that’s really a great, inspiring technology. It’s just that nowadays it evolves in a more competitive landscape, in which Next is in my opinion the most promising framework (other than Meteor itself).
2 Likes
That looks like far more of a Vulcan problem than a Meteor or Material UI problem.
For what it’s worth, I solved a bunch of problems with Material UI (not really problems, more like lack of optimizations) with this bit of config in package.json:
{
"meteor": {
"mainModule": {
"client": "client/main.jsx",
"server": "server/main.ts"
},
"testModule": "tests/main.ts",
"nodeModules": {
"recompile": {
"simpl-schema": "legacy",
"uniforms": true,
"uniforms-material": true
}
}
},
"babel": {
"plugins": [
[
"transform-imports",
{
"@material-ui/core": {
"transform": "@material-ui/core/${member}",
"preventFullImport": true
},
"@material-ui/icons": {
"transform": "@material-ui/icons/${member}",
"preventFullImport": true
},
"@material-ui/styles": {
"transform": "@material-ui/styles/${member}",
"preventFullImport": true
},
"uniforms": {
"transform": "uniforms/src/${member}",
"preventFullImport": true
},
"uniforms-material": {
"transform": "uniforms-material/src/${member}",
"preventFullImport": true
}
}
],
"lodash",
"npdev-react-loadable-babel"
]
}
}
(That’s using babel-plugin-transform-imports)
4 Likes