Thingking about Meteor 2.0 🤔

core
25

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.

1 Like
26

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.

27

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

28

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.

1 Like
29

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

5 Likes
30

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

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

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.

3 Likes
31

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

3 Likes
32

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

3 Likes
33

What about deno?

I think it can revolutionize the hell out of revolution :smiley:

1 Like
34

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

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
5 Likes
35
  • 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.

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.

36

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

1 Like
37

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

2 Likes
38

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.

5 Likes
39

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

3 Likes
40

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.

41

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

Yes, I think providing more features to handle this out of the box would always be good.

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

Momentum is probably the biggest advantage, the project seems a lot more dynamic than Meteor in terms of contributors, frequent updates, feature announcements, etc. (at least from the outside).

Next.js looks very opinionated to me and its usage has been limited to websites as far as I can see

Typically you’d use Next.js to render your React front-end and run something else (such as Meteor, or more likely Node) on the back-end for your API server.

1 Like
42

So aside from HMR & out of the box SSR for React no other differentiation in term of technical capabilities as of now, in fact it’s lacking relative to Meteor (no support for multiple views, no packaging system, no build-in accounts, no dual bundle system, no optimistic UI, no built-in RPC/methods, no pub/sub etc.). But I think what Next.js got going for it is that they made it dead simple to start react project with SSR and routing.

Momentum is understandable given it’s young and still climbing the hype cycle, what I personally look for is real innovation/differentiation once the framework plateau and the dust settles. If all it focuses on is SSR then that’s easily achievable with plain react/express/webpack or even gatsbyjs nowadays.

Ok maybe I’m little biased :slight_smile: .

1 Like
43

Love this discussion!

My 2c based on what I’ve read and my use over the last 3ish years - this being not so much about what new features would make Meteor head and shoulders above the rest of the ecosystem, but rather what common features is it lacking that are likely preventing uptake/experimentation with Meteor:

  • I agree about Fibers being changed to ES6 promises/async-await. I’ve become relatively comfortable with it (as I imagine all the regulars would have), but I can entirely see it being a sticking point/a source of frustrations and quitting for someone new as well as a point of difficulty on boarding someone unfamiliar into the team.
  • Hasn’t been mentioned yet - but SOURCEMAPS. It is my number one front-of-mind ‘want’ for Meteor and I imagine anyone who is used to having source-maps, if they no longer have them as an option when they deploy a sample production app, may well be put off by Meteor.

Beyond that, I’m personally really happy with Meteor. I think it has a fantastic balance between being opinionated (allows getting a new full stack project up and running extremely quickly) yet flexible enough to do whatever customisations are needed.

3 Likes
44

Unfortunately it’s not just an overhead in onboarding, but also a source of potential incompatibility with other libraries.

A recent example:

This issue was also raised on React’s repo, and the note from React’s team member is an indication of how the use of node-fibers is still keeping Meteor from becoming a part of the “mainstream”:

React supports standard-compliant JavaScript environments, so using an environment with non-compliant concurrency primitives is going to cause problems.

3 Likes