The survey Results are in!
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:
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.
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
Blaze and Jade (!) 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 How is that going, anonymous Jade-Project-People? 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 . 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? )
- Redis package update is blocking
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
(Quoted in verbatim from the original survey:)
- 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.
- 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.
- 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
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!