đŸȘ§ Community Survey: THE RESULTS ARE IN! (What's Your Progress Migrating to MeteorJS 3.0 (Fibers to Async transition)?)

community
1

Hello dear Meteor-Enthusiast and/or -User! :smile:

As the MeteorJS project is in the process of upgrading the Meteor Platform to Async & 3.0 I wanted to generate some insight on how far we as a community are with upgrading our existing apps to Meteor 3.0 and start tracking feedback and issues on this topic.

I’ve created a quick survey to evaluate how far everybody has gotten with the transitioning to ASYNC & Meteor until now.

Goals would be to a) find out where we are in general and b) which challenges you found, if any, and c) to enable us - all of us - to work together on getting the migration process on the straight and narrow where it isn’t already.

Please help us out by filling this in (should only take like 2 minutes, for realzies!) to help us organize & work on the next steps to make the migration easier for all of us who may not yet be where we’d like to be.

I’ll post the results, anonymized, here in a week or so!

Please fill this out & share it with as many MeteorJS developers as possible!

Thanks, :heart: and :peace_symbol: !

5 Likes
2

Hooray! :smiley:

I’ve got 13 results so far! :smiley:

Please continue to submit your infos, I’ll post some result soon.

SOME SNEAK TEASE RESULT - Frontend Packes used (primarily):

Total replies: 13

React: 9 projects
Blaze: 3 projects
Jade: 1 project (!)

1 Like
3

Meteor Software has around 6 customer-facing projects with user interfaces. Among these projects, there are 3 React projects and 3 Blaze projects.

2 Likes
4
5

Thank you for everyone interested and especially you guys who filled out the form!

We’re at 25 submissions so far, which I think is probably only a small fraction of all the Meteor projects in the wild.

But I think it’s really interesting as it is and I’ll start tallying up & summarizing the results any day now.

Thank you once again & see you soon everyone!

6

Survey Results

Hello everyone!

The survey Results are in! :partying_face:

It took me some time to get through this but now I think it’s done, and maybe we can repeat this next spring to see what has changed in the meantime?

Over 30 project maintainers contributed, and actually many of them reported to support more than just one project, so this should represent a significant fraction of the Meteor ecosystem, even if it’s of course neither complete nor scientific. I hope it’s still interesting!

Many thanks to all of you who have participated in this survey!

These are the results plotted in a hopefully-understandable chart:

chart-meteor-survey-final
chart-meteor-survey-final1920×1092 52.3 KB

I drew the chart like this:

  • I grouped the different submissions by framework, color-coded them and grouped them from left to right in order of “age” (antiquity → modernity) so to speak. Blue: Jade, Blaze, Red: React, Svelte.
  • I plotted the size of the project as “Balloon sizes”, either Small, Medium or Large
  • The Y axis (“how high the Balloon has risen”) shows how far the along the migration the project maintainers think their project(s) have progressed.

Summary:

  • React & Svelte Projects seem to a) be further along & b) seem to feel, in general, as having less work to do for the transition in general

  • Progress for different project sizes are mixed and not really indicative of progress I think; except maybe they do (a little)?:

    • most medium & big projects (which have replied) have at least made first strides towards the migration. I think that’s to be expected, most bigger & active projects have people actively maintaining them & these are already working on the transition in some shape or form.
    • “survivorship bias” might play a role here, people who wouldn’t have cared or noticed the transition coming up so far probably wouldn’t have answered the survey either :smile:

  • Blaze and Jade (:heart:!) projects seem to be lagging & also perceiving more issues coming up, as they are also more strongly based in things like Isometrical code.
    I think that’s because they’re more dependent on
    - Autoruns & Tracker to invalidate their views
    - May be leaning more heavy on Isometric code (?)
    - May also lean stronger on “classic” meteor packages with less support

  • The React-ors seem to be further along and generally in a better place, conversion wide, probably because of (my speculation):

    • stronger separation between Backend and Frontend
    • Less dependence on isometric code
    • the Component / Data models in their apps being less dependent on fine-grained reactive changes, as most seem to use a model of component-based subscription & invalidation: as soon as the results of a subscription / query change, the state is updated & the entire component & its children will be redrawn
      (Is this correct? Please tell me if i’m wrong.)
    • Built on more modern / recent packages & npm packages / community supported React components & libraries in general?

  • I kind of love that there is still a Jade project out there, I didn’t know / think of that :slight_smile: How is that going, anonymous Jade-Project-People? :smile: I guess maybe you’re lucky in the data model you’re using with Jade not being as intertwined with Tracker as Blaze is?

  • One Participant is currently leaving the Meteor Platform for good :cry:. Thank you for still contribution to the survey, and with that, helping the community.

Some additional remarks & general impressions the surveys’ contributors gave

Most of this stuff is taken verbatim from the survey, “From the horses mouth”, so to speak. Sometimes I’ve edited things a bit for readability and clarity.

From the more general to the most specific, in ascending order:

Packages, Packages, Packages

Confusion about packages in general

  • Atmosphere - not sure what’s updated, what not

  • Also the same for core packages, actually

  • Progress on big packages like redisoplog, tabular and autoform not clear

    • (May I add here: Blaze? :smile:)
    • Redis package update is blocking

  • Community Packages

  • Concern: When will meteor packages updated (if at all)? We use packages that haven’t been maintained for multiple years.
    (Comment Me / @daniel: I don’t think all packages will ever be updated, some old packages will just stay as they are, others might get updated / fixed when people need them)

Code Transformations & Strategies:

  • Someone removed the isomorphic code from his app
  • Our project/me, myself (@daniel) is moving away from Client-Side simulations / stubs in Methods ourselves because of the complexity in handling async stubs too

Concerns:

(Quoted in verbatim from the original survey:)

Duration

  • Progress is slow
  • It seems to take very long. We are getting more and more pressure to use modern node versions
  • Still not sure MDG can pull off the migration (not my words, sorry!)
  • Concerns about Node EOL - We are already 6 months past node 14 EOL, it looks like at least a few more months before a 3.0.0 is released.

Concerns about future-proofed-ness

  • Scared about stability and/or performance after migration. We use method, pub/sub, etc
 and it’s important for us nothing should break or lose in term of perf.
  • Concern: Is Meteor a future proof technology (e.g. for the next 10 years)? Meteor is far away form today’s standard node environment (custom build tool, custom package manager, fibers instead of async, 
).
  • Concern that we have to do much more of these transitions in the next years.

In General

  • Blaze, classic Meteor Stack getting left behind
  • MDG putting too much burden on community and not doing enough themselves
  • Update is going to take A LOT of code; basically this feels like an App Rewrite.

Wishes

  • Hire a full time coordinator that just keeps track of things and helps with communication

Migration Issues / Factors

Unclear API Changes

  • Concerned that implementation might change so we are not proceeding with any preparation
  • Being unhappy that there are currently 2 different sets of APIs, basically, Meteor 2 and Meteor 3
  • Unclear what the new async APIs are (emphasis mine) and which existing functions without an “async” equivalent are going to be deprecated, especially regarding accounts. Some uncertainty regarding how Client side method simulation will turn out due to conflicting or limited information.
  • Unclear how the Meteor 3.0 API will end up looking re: *Async

Migration Organization

  • Need a thorough migration guide, especially for non-core packages and popular community packages. It’s unclear right now if we’re using features that won’t be supported moving forwards (especially with various account hooks etc)

  • Biggest challenges for a specific Project: rewrite of the code base to use only React function components and hooks, rewrite of the code base to make everything transactional, rewrite of the code base to have all methods and publications type-safe, etc.

  • long code paths that need conversion to async

Advanced & specific Issues

  • concern: lack of support for ESM-formatted NPM packages
  • concern: lack of parallel e2e/integration testing implementation
  • Meteor.callAsync situation
  • Promises, accounts infrastructure, OAuth integration, security, bearer tokens
  • Package management system compiles functional React methods onto Components
    • This one I hadn’t heard, what’s the story?:
      “When compiling react code from an Atmosphere package, the package management system creates a stateful component at the base of the package, and attaches functional components onto the stateful component. That stateful component breaks the Rule of Hooks, meaning that functional React components created in a package don’t receive props correctly and will throw Rule of Hook errors.”

Some happy thoughts:

  • Excited to have a newer Node version!

So, thank you everyone.

This is my attempt to foster further communication across the community and also with Meteor Software of course!

Let me know whether this took much too long and you’re all on Meteor 3 already maybe?

Or if you have any good ideas in how to improve the migration process, how to improve communication inside the community itself as well as with the Meteor Software team etc etc.

I think Meteor Software did a good job recently updating / summarizing outstanding issues and wanting to reach out to the community going forward!

I’m really looking forward to the shape of things to come,

Thank you for coming too, see you all out there!

9 Likes
7

PS: Next time i’ll poll for some positive feedback as well, in order to keep the good vibes rolling!

This is just a list of feedback and open issues, unfiltered, but it of course doesn’t indicate a judgement on Meteor itself, it’s still the greatest Framework since sliced :birthday: of course!

4 Likes
8

The result is speaking most real case. the slowness is real. because of the slowness that things are not clear dificult to get help when in need of them and materials are not out there to search and help yourself. If the team can speed up little, yes they are doing great job but if possible to spead up.

1 Like
9

The packages should be listed for those that are updated so that we can know which to use or not. And the creation of the packages if they can be available helps solve some of the challenges newbies will help much. thanks.

10

Appreciate your efforts @DanielDornhardt. This is a big help summarizing the concerns of the community. It does help a lot in many ways, including (1) highlighting areas that need attention and (2) making us feel that we are not alone with these challenges.

In my view, this is the biggest letdown as of now. Releasing the new API for Meteor 2.x with the possibility of changes for Meteor 3.x does not project any confidence. This is one reason why we are holding off on any changes towards Meteor 3.x until the API has been finalized.

And we are also considering moving away from stubs completely because of this.

2 Likes
11

Yes
 I think a central document with a comparison of the APIs for 2.x and 3.x, as planned, would be valuable at this point.

I also think it’d be important to strive for API compatibility between 2.x and 3.x - So people can migrate their apps as good as possible. I am not sure how much that is currently being taken into account when working on 3.x?

On the other hand, I’m not so worried about whether something is called abcSync or abcAsync or abc in the end / in 3.0, as long as it’s clear and definitive. It should just be a global search and replace, right?

→ But it occurs to me right now: Any renaming of functions in Meteor 3.0 would automatically make all existing plugins break for either 2.x or 3.x if there wouldn’t be a provision to support both APIs at once, right?

So maybe the *Async funcs should still be pointing to the regular named funcs for example and the sync ones become *async after all.

And/or Meteor 2.x would need to be deprecated in the medium term for plugins to continue to support only one API?

12

Who was actually the ones already running on 3.0? @filipenevola is it you by any chance? :sweat_smile: I’d like to do a short interview with the person about how they achieved it etc.

13

Yes but no.

Our code in https://codeftw.dev is 100% migrated but we are having issues with meteor build as you can see here.

So yes, it’s 100% migrated but it’s not running in production yet.

1 Like
14

Hi @jkuester ,

a final update for this round:

I checked back with the community member I thought had reported already being on Meteor 3.0, unfortunately there seems to have been a misunderstanding and his project(s) are actually ready for Meteor 3.0, but not yet on Meteor 3.0


So unfortunately nobody has reported a full migration to Meteor 3.0 yet.

Updated Diagram:

chart-meteor-survey-final-updated
chart-meteor-survey-final-updated1920×1092 52.4 KB

1 Like