That hasn’t been true for half a decade. The 2019 JavaScript developer survey says in 2016 Meteor was relevant to 60% of respondents.
Meteor wasn’t even included in the 2021 survey.
Think and do what you want.
The only thing interesting to me about the past is identifying opportunities possible in the future.
I have wanted Meteor to take open-source seriously, with a front-end in-core data-client, since 2016.
I don’t think this is a failing of the Meteor functionality, as much as people have made their opinions based on earlier versions of Meteor. Before it had NPM/react support/dynamic imports/ and no solutions to scaling issues/etc. Deployment at times was annoying, and Galaxy was seen as expensive, but that’s improved as well. The biggest issues Meteor had are long gone. But people already wrote it off and likely don’t know the status of how things work now.
This is something a change in advertising or rebranding could solve. As I do think Meteor is an amazing tool. Most recently, I find it great to work with Vue, only complaint being that Vue 3 wasn’t yet supported when I started my project (I don’t know if that has changed). I’d argue that it’s easily one of the top ways to use Vue.
In general as a Meteor user, the primary place I think could be improved is I hope the top packages could be officially integrated in to Meteor. I see in the roadmap that this is being looked at for Redis Oplog and that would be great. Grapher I think is a huge improvement (and would likely win many over who are reluctant to try to try Meteor for relational issues) and it’d be great to see package like those integrates as well. The community has done a good job in most cases, but packages like these would be very powerful to integrate at Meteor’s core, and to be able to use them without worry of not being maintained would solve any issues I have with Meteor.
I have released a new version of Grapher recently. More and redis-oplog are on the way, but currently my time is limited to work on this, so I’m dependent on other people’s making the PRs.
This was identified as the main problem several years ago. Despite efforts by the new owner and team, it still has fallen short (for many reasons).
What is “not true”? Having worked on a Meteor app for the last 6 years, as well as many other frameworks over that time, I’m still in 100% agreement with @paulishca. The merits of Meteor that he outlines are still true.
Those JS surveys are a great indicator of contemporary hype and buzz. That Meteor doesn’t appear there has a ton to do with marketing and social media (dev.to included), not true business utility.
it was suggested by sasha to remove it after further decline in popularity, see this thread Well ... interesting Meteor numbers in the State of JS - #96 by waldgeist
Great to hear. The Meteor community has done some wonderful things, I just think it’d be better for all if they were officially recognized as a part of Meteor. After all, if the developers took the time to create a strong Meteor package, they’re already donating a large amount of their work and time to the better of Meteor.
I remember when reading through the Grapher thread, it sounded like much of the reason cultofcoders moved on from Meteor was a failing of this. It’d be great for the future if the Meteor team would be quick to try to hold on to developers willing to put in work. This seems to be one approach Meteor has failed to utilize for many years, even going back to the authors of some of the earliest Meteor packages - a focus on keeping developers here, rather than stopping them from moving on (or having to move on).
Now may be a time to not only focus on stopping developers from moving on, but maybe try to bring developers back. Especially those who tried it 5+ years ago and wrote it off. If they only knew not only what a basic Meteor tutorial looked like, but also had an idea of what working with Meteor was like when utilizing the most popular packages, how to properly utilize scalability, it’s strengths for those who develop in React/Vue/etc, and that it plays nicely with NPM nowadays. As those were most of the negative publicity I saw Meteor getting - aside from NoSQL complaints. But there’s solutions to SQL nowadays, and Grapher can help make Mongo relational, so that issue is in a much better place nowadays as well.
I very much disagree with this. To keep Meteor maintainable, secure and free of excessive technical debt, it is necessary to keep Meteor core as small and lean as possible. Meteor has a functioning data layer with methods and pub/sub. It is quite simple and works well for the majority of cases. And keeping things simple and maintainable in the long run is much more important than solving edge cases. Right now the main task for Meteor core developers should be to quickly start solving the fibers and async/await issue. Anything that can reasonably be used as a community maintained package, should remain a community maintained package. Especially packages such as Grapher that are likely used by only a small percentage of Meteor developers.
I think the community packages repo is a very good idea. Not officially in Meteor core, but gathered in a central place and receiving some basic maintenance. A good compromise.
I keep reading this. What exactly (in short) are the issues? I and probably a lot more developers have Meteor apps running perfect for years.
The only issues I have are some, very irregular errors with sockjs:
Fibers + NodeJS 16 !== LOVE
Thanks Paul, I’m not on Node 16 (not even on 14) hence I didn’t experience such problems
The issue is that currently Meteor relies on fibers extensively in core code and newer versions of node, starting with node 16, do not support fibers any more. Yes, right now, node 14 is in maintenance mode and works with meteor. But in April 2023 node will drop support for version 14. Sticking to an unmaintained node version is not an option. So there’s a year to make meteor work with node 16. That’s a major task and there’s no time to lose.
Support for Node 12 is ending at the end of this month:
So people should be upgrading at least to Meteor v2.3 which has Node 14:
I think in the future things will have LTS will have to be considered and will probably have to coincide with the Node schedule to some degree.
node support is not the only problem with fibers.
It basically makes meteor a non-standard javascript environment. While it initially was a bless for isomorphic apps (frontend and backend share code), its now a big problem. If you use fiber code in your frontend, you will get problems with server side rendering, because many frameworks like react are not built for non-standard javascript runtimes.
other libraries also suffer from that in a very unexpected and inconsistent way. One example I had was with memoizee which basically memoize functions (store its result so further invocations return a cached result). It breaks with fiber code. Even worse, it breaks very inconsitently.
It may also be confusing for newer devs, because async/await is now the way to deal with that.
Its a challenging situation, because removing fibers means breaking of the classic meteor collections and pub/sub mechanism. It will break nearly every meteor app there is. I think its the better idea to just try to keep it like this, which means maintaining fibers.
I’m on version 13.8 - not ideal but not ending (yet)
I’m on Meteor version 2.2 which works. I haven’t spend time on checking if there are still some old packages that break but once I have the next big release out I will surely look at it.
Do we have a recommended, stable version of node 14?
Each version of Meteor targets a specific version of node. That is the version you should be using. See here: Changelog | Meteor API Docs
Install it automatically with your CI meteor node -v
This version is already unsupported (yes, earlier than version 12 which is under LTS). Never use odd-numbered node version in production.
Thanks RJ, this is actually my locally installed node version. CodeBuild uses version 12 (Docker image 12.18.0 to be precise). So I’ve got some work to do.
Thanks also to @vooteles for your helpful comments, I see that node 14.19.1 is now the latest as per Meteor version 2.7
Its a challenging situation, because removing fibers means breaking of the classic meteor collections and pub/sub mechanism. It will break nearly every meteor app there is. I think its the better idea to just try to keep it like this, which means maintaining fibers.
I think maintaining fibers will be required anyway until the full migration to async hooks is completed and many major projects have migrated, too.
I think this was already proposed in the async hooks roadmap on GitHub in some way.
I am pro moving to async hooks and getting rid of fibers but I totally support your point in the way that the transitions needs to be as smooth as possible for projects relying on fibers.
