Replace Next.js with Meteor?

Going to make a bit more too :smiley:

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