This is the second time that I have run this survey and hopefully it will become a common event in the Meteor community. Last year, there were 57 responses, this year it was 207! I believe this is thanks to the extended period of time that the survey was running and extended reach thanks to Meteor Community Newsletter.
Before I dive into the results, here is the anonymized data for you to pure over if you want to read individual responses or do some additional data analysis: https://docs.google.com/spreadsheets/d/1n0EDBAQiuBGQA29U9pDhvOWu8g81BRC_FUYEDWdcdbY/edit?usp=sharing
Questions
What front-end are you using with Meteor?
Most of us had probably already gotten used to the endless debates about front-end libraries. Originally Meteor had its own Blaze which was specifically build to work with Meteor and its reactive way of doing things, but with the coming of React that has changed as developers demanded an easy way to add their favorite library.
React is clearly the most used front-end library which mirrors its popularity across the general JS eco-system. Surprisingly for me Blaze is almost as same popular. This will mostly be legacy projects and smaller projects. It seems that switching from Blaze is not something that these would consider and that is fine as Blaze is stable and works well.
What surprised me was that Vue and Svelte did not do better in the survey as there is a considerable buzz around these lately.
Are you using GraphQL with Meteor?
One of the issues that Meteor faced with corporate customers was the data layer. Hence Apollo GraphQL was born. Sadly then MDG did no connect Meteor and Apollo well, at least from the marketing side. Still things are improving and Meteor 1.11 will include Apollo skeleton (by yours truly).
Overall the usage of GraphQL in Meteor is underwhelming showing that making Apollo standalone was not a bad decision and is to be sought after people who have advance data needs, want to have it as a part of a system, or as a replacement for any part of the pub/sub system of Meteor.
Are you using Redis Oplog?
Redis Oplog was made by Theodor Diaconu to address the most common scaling issues with MongoDB Oplog to use Redis instead. I see this as a one possible way on how to track the number of Meteor Apps that have reached a significant size of users.
Surprising is the similarity to the reported usage of GraphQL. It looks like that Redis Oplog is the first step when scaling for larger user bases.
Have you heard about Meteor Community Packages?
A bit self-serving question given that the survey was advertise through the community and hence most likely people finding it have at least some knowledge of the community.
Still 18% of respondents have not heard of this community effort. This is a good thing as it shows that there has been a word of mouth and/or people saw the forum topic advertising the survey.
Which of the following packages (maintained by Meteor Community Packages) are you using in your Meteor app?
It will soon be a year that Meteor Community Packages group started operating. Since then we have taken on maintaining some of the most sought after packages.
Clearly Collection2 and Roles are the most sought after to fill for common scenarios when using Meteor. Collection hooks and publish-composite don't trail much behind. Further notable is Autoforms which is where the focus of our Blaze team is.
Sometimes it is important to for us to maintain packages that don't have such a wide community adoption like the 5 above mentioned. These can be because they are in use by packages developers like tmeasday:check-npm-versions or because there is a dedicated team/person ready to take-up the torch (e.g. bozhao:link-accounts, seba:method-hooks).
What packages that you use are in dire need of an update?
Answers to this questions were varied and inconsistent. Last year this question was used to determine which packages should be first for the Meteor Community Packages to focus on.
This year respondents have taken a different approach and in addition to mentioning community packages voiced dissatisfaction with the state of some of the official packages. There were requests on further development of Blaze packages, modernization of the accounts suite (still uses underscore and is eagerly loaded, accounts suite is something that I personally am trying to improve, but I'm limited in time, so it is in small increments) and minimongo (which honestly could benefit from adding new MongoDB functionality). Last to mention in this category would be validated-method. There is a replacement for this package on its way, but there are still some minor points to resolve like migration path. Some additional features like Apple sign in were requested (I agree here that this should be an official package given the requirements from Apple).
Another section of requests was for a widely used packages that are finished (for the most part), but could benefit from a refresh and update. These most notably include the useraccounts suite, jagi:astronomy, percolate:migrations, meteorhacks:picker (I have an updated version which is most likely going to get adopted by MCP soon, I have written about it in the past), Meteor specific routers (iron:router and Flow router - there is a newer version of Flow router maintained by Ostrio) and tap:i18n (i18n is something that I have a strong interest in so it is on my list for MCP as well).
Again were repeated some of long lasting requests to update Meteor Hacks packages (please forward your request to Arunoda to transfer them to MCP, we'll be glad to take care of them) and features like allowing to deprecate packages which would then show in some way on Atmosphere.
Which packages have you forked locally since they are no longer maintained and you need them?
Pretty much identical question to the previous one, but in this case we are looking on packages that are desperately needed to be updated or adjusted for the project. Except mentions of some packages that were mentioned earlier (picker, useraccounts, tap:i18n, aldeed:tabular to name a few), there wasn't anything else that stood out or any larger pattern. The most positive thing I can say here is that compare to last year this question felt pretty empty and that is a great victory for MCP.
Would you be willing to financially support maintainers of community packages?
The question of financing is always a tough one. On one side for many of us FOSS is also a hobby, yet the demands for maintainers are increasing and we don't have more time in our lives. Over the past few years I was fortunate to get to know more some of the developers that make this community run and from what I can see of their private lives, unless there is an intensive to keep on going their contributions will be irregular or decreasing. After all someone needs to feed the family.
Yet at the same time we see that the biggest answer to this question was "Maybe". I don't have any answers, but from what I have gathered is, that there needs to be some value added or a guarantee that the money spend on supporting these developer is going to translate into something tangible.
To make things even more difficult recent recesion around the world has not helped unless you or your company is in the few markets that experienced a boom.
When it comes to corporate sponsors I was specifically told that it would be preferable to donate to an organization. For now MCP is a very loose group and there hasn't been much interest to establish things further. But we will see as this topic is inevitable as things continue to evolve.
To end this I would like to showcase two comments to the next question that fit here. First a negative one:
No: For the same reason I'd recommend everyone switch away from COBOL: It's not sustainable. The competition (some other stack, or creating something myself based on an npm package) is free, just more work to switch to.
And another longer one which higlights the problems with sponsoring community developers:
I'm mostly a hobbyist user, but would still be interested in contributing a small amount monthly. The details of funding something like that get complicated quickly, though:
- Do you just give cash to package maintainers?
- Do you give more cash to packages that are constantly breaking, or to packages that are implemented in a more future proof way?
- Do people contribute directly for each package they want to support, or is there a group that oversees the distribution?
- Who decides which packages deserve support?
- How much autonomy do package maintainers retain if they're funded?
And so on.
Part of me wonders about the big gap between enthusiast-supported and commercially-supported projects. It's tough to ease from one to the other.
But maybe there's a way to rebuild the enthusiasm around them instead (or as well). I'd love to see articles and video detailing the inner workings of some of these packages, for example, or the interesting problems that they've had to solve or that still need to be solved. Or the Meteor interfaces leveraged in interesting ways to accomplish the package goals.
This may not be a bad subject for a podcast, actually. I'd love to hear a couple of devs chat about the inner workings of an interesting package, maybe including some history, a few approaches tried, the evolution of the package as Meteor has changed, how it works together with or depends on other packages, and so on.
The upshot would be a much wider group of people who know how the package works, and that would feel comfortable making (and contributing) changes as necessary.
Another advantage of this approach is that it would publicize some of the cool stuff that's normally tucked away under the hood. Making developers aware of how cool their framework is makes it much easier and more fun for them to evangelize it. Ben wrote some great Medium articles about developing Reify and Dynamic Imports that did this beautifully, for example.
This answer in particular is something that I will dive in mroe deeply in my future articles.
If yes, what would be your preferred way. If no, why?
Since last year there has been the addition of GitHub Sponsor which shot-up to become the 3rd most popular option for support. From what I have seen it is a preferred method for developers. No fees, it is right where work is and has all the basic features one needs to set things up for sponsors.
Given the similarities to Patreon and Patreon's recent troubles I suspect that we will see the share grow further, especially if GitHub plans to expand on the features.
Still one time donations via PayPal remain popular and when it comes to companies more traditional methods like Direct Bank Transfer and/or Card payments were preferred.
Would you be interested in monthly hangout or remote meetup?
Humans are a social creature. Hangouts in the Meteor community have been tried on small scale and so far without much long term success. I would describe the interest as lukewarm. This has probably to do with lack of specificity of the question. So as of yet there are no plans to introduce this.
Would you be interested in a community podcast?
Once upon a time there was a Meteor podcast. Recently Meteor had an episode on Syntax.fm.
From last year, the interest had remained pretty much the same. Scott Tolinski has mentioned an interest in doing it, but it is a question of time. So we shall see if we can stitch something together.
Would you be interested in virtual conference about Meteor?
With the onset of restriction of AFK events the popularity of virtual conferences and gatherings have skyrocketed and the Meteor community is no different.
I would say that this is probably a matter of time. After all Pathable is a Meteor shop (quiet a few prominent community members work there - including me) and Hacktoberfest is approaching. Behind the scenes the first steps have been taken to make this happen, that is all that I can reveal.
Where are you located (country/time zone)?
While planning for virtual conference it is good to know where people are. Sadly I left the question too broad so the answers were a bit of a hassle to put properly on the map, still after cleaning of the data a bit more I've got this nice map:
Now, obviously this is not exhaustive. I know for a fact that there are more Meteor developers in most of the places (even in places like Africa and the middle east), but this will give a general overview and help us plan the times of the conference a bit better, but probably only a bit. As you can see Meteor devs are all around the world.
The strongest showing is in the USA, but if we took EU as a whole (even if excluding Russia) Europe would have more developers. Now this makes any global gathering almost impossible due to the time zone differences, on the other hand it is awesome to see that there are Meteor developers practically everywhere.
What are the things or misconceptions about Meteor in the market that makes people pass on a Meteor while choosing their next stack?
At this point the different reasons have become sort of a meme in the Meteor community as most of them can be disprooven or are out of date. Those related to scaling are most often an issue how you build your app, but some still remain true. Trying to categorize what is or is not true is pointless, but I would like to highlight that this question was about misconseptions, which means that those who have written these have disprooven them or know of someone that did. Though in some cases I would say that people took it also to voice their (or often heard) critique.
- Does not scale
- Monolithic / too tightly coupled
- Restrictive
- Out of date / It is old
- Must use subscriptions -> subscriptions are slow -> meteor is slow
- Outdated resources
- Not much appearance in other dev communities or established outlets
- Long build times
- High CPU usage
- Not able to run only front/back end code
- Only uses MongoDB which is terrible
- It is dead
- It is all or nothing
- Too rigid
- Only for side projects / prototyping
- Insecure
- Not integrated with NPM
- Too much magic / Fibers
- Not popular enough
- Unclear future
- Lock-in
- Not associated with a big corporation
- Just for real-time apps
- Expensive hosting
When it comes to actual critique the most accurate I have found is that there is no HMR or tree-shaking in the Meteor build tool. Well, that is only a matter of time till this becomes a misconception as both of these features are in development.
What is your go to place to consume content about Meteor?
Meteor Docs/Guide, Meteor Forums and GitHub are the holy trinity for Meteor content. This remains unchanged as pretty much everything else from last year. Meteor Docs / Guide though have risen above all other. I think this shows that the effort put into improving those resources has payed off.
When it comes to new ways of content for Meteor Dev.to and Slack have seen the largest rise. Articles on Blogs and Dev.to seem to be on the rise if we combine them. The community newsletter lacks behind most likely due to its irregularity which makes it a greate resource for people who don't have the time to follow the daily goings of the community.
Would you like to receive community newsletter?
In total we had 71 additions to the community newsletter list, topping at 201 people at the time of this writting. Not a bad start I think.
If you receive community newsletter, how would you rate it?
Meteor Community Newsletter is an irregular newsletter that goes out when a new version of Meteor is released compiled by yours truly with the help from the Meteor Community Slack members. It seems that most recipients are satisfied with it which humbles me.
If you want to receive the newsletter you can sign-up.
What would you like to see in the community newsletter?
Although most people are satisfied with the newsletter there are many requests for additional content:
- Meteor in the business world
- New Meteor features, packages, tips & tricks, tutorials
- meteor/vue
- Core updates, community packages updated, recent development in the community, recent development on Tiny, hot discussed stuff in the forum that resolved to things worth to be noticed
- Interview & articles
- Internal news and decisions from Meteor Software
- New packages, projects, updates
- Walkthrough for building basic Cordova App with most used features (push, camera, upload)
- Blogs & creator spotlight
- Made with Meteor showcase / Success stories
- New packages
- Tips & tricks
- Interesting resources
- NPM alternatives to packages
- Demos
- Recipes
- Security
- Plans
- Upcoming features
I will endeavor to include more content from areas where I'm not an active developer, like Vue and Cordova. As for the rest it will depend on opportunities. Given that the newsletter is an occasional newsletter it can get pretty tight with space if the releases are too much spaced.
On the other hand it allows me to focus on the other things in more regular newsletter which I send out to my sponsors, which means that the newsletter is behind a paywall, after all doing more of those things takes a lot more time, which is something that I increasingly don't have. There are also other newsletters in the work that will include some of the mentioned categories and even more will be subject for blog/Dev.to articles.
Feedback & ideas for the future
I have received feedback that some questions could be interpreted in different ways and had to fix few during the survey to allow wider range of answers or to be more (or less) specific. Something to improve even further for next year. Additional considerations will have to be added to allow for easier data processing.
Another area to improve will be reach. Posting on the Forums and in the newsletter might not be enough. Dedicated newsletter for the survey is a must, but other avenues will need to be explored. Maybe getting it advertised across official Meteor resource would be a way to go.
If time and finances permits I would like to build a dedicated site for the survey in style of State of JavaScript so that we can better compare developments in the Meteor community. Another feature of the comments I would like to add would be comments from prominent community members on specific topics. Maybe we can see their take this year in the comments here or on the Meteor forums.
If you like my work, please consider supporting me on GitHub Sponsors ❤️.
Oldest comments (2)
Hey Jan, thank you for this work.
A few comments:
Sign in with Apple: we have Meteor packages up-to-date, supported and working, you can find them here github.com/quavedev/apple-oauth github.com/quavedev/accounts-apple
HMR is coming, the working branch is here github.com/meteor/meteor/pull/11117, btw, I already use this in my projects :)
tree-shaking is also coming, not working yet branch is here (dead code is already working but tree-shaking itself is in progress) github.com/meteor/meteor/pull/11107
And thank you again.
For HMR and tree shaking I'm aware if it, but the fact is that when the article was written it was not available. Which means that I will have something more to praise next year.
As for login with Apple, yes there are about 3 community packages, but due to it being a major OAuth provider like the other officially supported makes that irrelevant as anyone evaluating Meteor without deep knowledge of how things work and of the ecosystem will not see and will not care. I'm looking at this from the marketing and consistency point of view. Apple login is required if you want to be part of the Apple ecosystem, hence it is on par with the other officially supported OAuth providers and should be part of the core Meteor systems. This missing from the docs and guide just encourages the perception that Meteor is outdated, which is my primary interest on this topic.