Thingking about Meteor 2.0 🤔

[awatson1978]

I haven’t seen anything suggested in this thread so far that would require a breaking change so fundamental as to require a 2.0 version.

[cloudspider]

Versions are not only technical. To the outside world its also about marketing. I think Meteor is misunderstood by a lot of developers.

[awatson1978]

There’s a whole lot of enterprises out there in the world that would prefer a Meteor 1.78 over a Meteor 2.0. Marketing wise, the former says the stack has been stable and improved over N versions. The latter says that something was broken and needed overhauling and there are bugs to be worked out and the entire system is unstable.

[cloudspider]

When I look at the operating system of my phone, I don’t really care about the version, I care about its features. 2.0 means stable. Also, Meteor has improved so much over time with both Features (frontend framework support, npm support etc) and performance… Will you notice it as a client when Meteor gets rewritten entirely? Not really. Will there be a bussiness case to do it then? Not really! Only if new features are added and development slows down.

I feel that Meteor combined with Galaxy is a cashcow for MDG at the moment. It feels clear that Apollo gets much more attention. This makes it even less desireable to build any 2.0 version.

Look at all the bigger companies like samsung, apple, google and microsoft. Even if the new phone has some more features (no major stuff), its still the same, but they still make it a major version upgrade, they even name their versions. Do you think that’s a technical decision? No thats marketing.

MDG needs to be much more bold in its marketing techniques. Not only on the technical part. Its how the world works (unfortunatly)

[awatson1978]

Moving away from semver would mean everybody’s tooling would break; deployment pipelines would break; etc. Doesn’t seem you’re thinking through the implications of what you’re suggesting.

[cloudspider]

I’m not suggesting that Meteor should move away from semver, I’m suggesting that they should reconsider the definition of a major change. Personally I found the added support for React and Angular quite major.

[mostafiz93]

All I want is better APIs for MongoDB(obviously MongoDB 4 support) and a fully fledged router

[cloudspider]

This topic feels a bit like a nagging topic, but I think we are still here for a reason right? We all feel that it would be a shame to let a platform like this fade away, while it’s actually a really good platform and still (opinion here) much better then most alternatives.

[gaurav7]

Two things must-do for Meteor 2.0 imo:

1. Get rid of fibers and convert all core APIs and popular packages (hopefully community chimes in for this) to be promise-based.

   • The use of fibers has brought with it a lot of overhead like Meteor having to implement its own version of Promise and bugs like the infamous Fiber bomb.
   • It also messes up with how a developer normally thinks about the execution model on Node.js.
   • async / await is now a well accepted solution to callback hell, so we no longer have to inherit all the known and unknown problems associated with fibers, just so that we can pretend writing “synchronous code”.

2. Expose core functionality as NPM packages

These changes will truly open the door for inter-operability with the rest of the Node/JS ecosystem, including alternate build tools, eventually broadening the reach and expanding the community

[storyteller]

So going through things so far here is a summary of things that stood out to me:

What community can do right now

• Create a tutorial for Vue
• PRs for Vue integration

Things to improve in general or before 2.0

• first class support to Hot Module Replacement (it’s already working in many situations using meteor-webpack )
• first load time for Meteor Cordova Native apps (currently around 8 seconds in an almost empty application)

Ensure Meteor supports Vue at the same level as React or Angular!

Integration with Apollo as a first class citizen

Though this is already on the official roadmap. I would like to see some old faces that went to Apollo to come visit and make this amazing.

I would like to add to this improving the accounts system with things like linking multiple social accounts to one account.

More from the official roadmap on Github:

• Out of the box support for advanced React features (better SSR, better CSS-in-js)
• Page load performance improvements (modernization of packages and removal of big things like jQuery, more aggressive client caching, better dead code elimination)

Meteor 2.0

Meteor 2.0 to be the defacto fullstack platform

Very strong focus on CI. Stuff like testing, reporting and deployments should be a breeze.

Move to mongo change streams and stop watching the entire oplog.

Get rid of fibers and convert all core APIs (including core packages) to be promise-based.

I think this would also fall under complete modernization that is already underway.

From the roadmap:

• Full transition to npm
  ^^ Which is why I said I don’t want to hear about things like that. It has already been acknowledged.

@awatson1978 I know what you mean about semantic versioning, but Meteor really isn’t following it now. If I remember correctly MDG has stated in the past that the 1 at the front is for marketing purposes, so it is the second number that actually indicated major version/breaking changes. So in that regard Meteor is already at version 8. Yet given Meteor’s amazing history of backward compatibility and update instructions barely anyone noticed.
Hence doing stuff like Meteor 2.0 is an opportunity to stop supporting the oldest stuff (what ever that reason might be), but even more importantly it is about marketing as @cloudspider pointed out.
I remember few years back that someone released a major version because they had to break one function and even though except that there wasn’t any change from previous version they got news articles and other free PR stuff. I agree that it is BS, but it sadly works.

[gaurav7]

Get rid of fibers and convert all core APIs (including core packages) to be promise-based.

I think this would also fall under complete modernization that is already underway.

From what I know, the “modernization” currently being done is only around using the latest ES6+ syntax. I fear that removing fibers would be quite a fundamental change. Hope it’s at least feasible for a 2.0 release

[coagmano]

Get rid of fibers and convert all core APIs (including core packages) to be promise-based.

I really like this idea!

As helpful as fibers have been, with async/await they’re now more of a hindrance than a help

Training new hires to understand and think in fibers is a serious overhead, and trips up experienced nodejs devs

[amerzad]

What about deno?

I think it can revolutionize the hell out of revolution

[storyteller]

@benjamn described things that are coming next in the 1.8 release article:

Meteor 1.8 erases the debts of 1.7 – Meteor Blog

In summary:

• Official typescript support (probably a good opportunity to make the push for Vue as well).
• meteor create --apollo and others. (Would this satisfy our desire for first class apollo integration?)
• Compiling compiler plugins after installation
• A slimmer version of the** autoupdate **package for minimal Meteor apps
• Installing Meteor packages from npm? <- this looks pretty amazing

[smeijer]

• meteor create --apollo and others. (Would this satisfy our desire for first class apollo integration?)

I think that depends on how it’s integrated.

You don’t need to setup mongo anywhere with connectionStrings etc, it just works. If apolloServer also “just works”, then yes. If you still need to have a config file; then IMO it’s not “first class”.

For me a config file is fine, but if you just get started with Meteor, it’s so awesome that all you need is a index.html, without any config.js.

Installing Meteor packages from npm? <- this looks pretty amazing

Sounds awesome, if the npm install is then also automatically being run when meteor detects changes in package.json. Meteor packages are udpated / reinstalled when I switch between branches. npm modules are not.

[coagmano]

Installing Meteor packages from npm

This would be awesome for me. Managing submodules between projects is a PITA.

Currently have 18 local packages using git submodules shared between 12+ meteor apps.
I’d much rather have them on a private npm registry, so the only one step is needed to install or update

[serkandurusoy]

@coagmano maybe give https://github.com/sebakerckhof/stratosphere a shot?

[smeijer]

I’m surprised it hasn’t been mentioned yet. I would love to have an “official docker image”;

FROM mdg/meteor:1.8
RUN meteor build .

---

Another thing I thought of a couple of days ago, is this feature request

Basically; I think that it would be quite possible to have a meteor.bundle.js and a app.bundle.js now that Meteor has dynamic imports. This meteor.bundle.js doesn’t need to be recompiled on every app change. Not even on every app update.

Benefith 1, the user can have a more aggresive cache
Benefith 2, meteor builder can treat this meteor.bundle.js as a single, static file. And have way faster build times. (package recompiling / scanning still takes a lot of time here)

I know you can manage the client-cache benefith yourself already, by using an import() as early as possible. But, I think this can be stretched, by hosting the meteor.bundle.js on a CDN, allowing all meteor apps to share some cache.

<body>
  <script src="https://cdn.meteor.com/meteor-1.8.min.js" />
  <script src="/e58e...3d8.js" />
</body>

Yes, that does mean that you would possibly have some packages loaded that you don’t use. But…, if looking on the bigger picture. The more sites use Meteor, the bigger the chance that your visitor already has this bundle in it’s cache any way.

---

Stretching the idea bove, using precompiled bundles that are slightly “over complete”, could perhaps be used to build the official meteor docker images.

Imagine building FROM a base container with the meteor assets already precompiled, and only need to compile my own additions and node_modules.

My top layer could be under 10mb, where as the base layer is a simple download from docker hub.

[sacha]

Integration with Apollo as a first class citizen would be great, but I wonder how it would replace minimongo and all the things we are used to (optimistic UI) seamlessly. So, not sure about it.

Realistically, I think a Meteor 2.0 would be a lot more front-end agnostic, meaning no Minimongo, DDP, etc. And Apollo would be the recommended solution. That does mean no automatic optimistic UI, store updates, etc. out of the box.

I also think Meteor will have a hard time competing with things like Next.js unless it implements key features like hot module reloading and SSR. They might not be that important in the grand scheme of things, but they are very visible to any new developer (while some of Meteor’s more “hidden” advantages are not).

[alawi]

I strongly agree with your statement on being more front-agnostic and provide better integration with Apollo.

Do you think it would make sense to have special meteor react package that can provide SSR/HMR?

Aside from those two, does Next.js have any other notable techinical advantages over today’s Meteor?

Also does Next.js have any packaging system similar to Meteor? In fact, is there any mature other Node JS framework with packaging system similar to what Meteor has? I wonder becauae we have hard dependcy on the packaging system. Next.js looks very opinionated to me and its usage has been limited to websites as far as I can see, are you aware of any enterprise like app using Next.js? I think Meteor history shows clearly that it easy to lure new developers with shiny new features but it’s hard to win over enterprises and advanced users in the long-run.