Thank you for upgrading Apollo package.
In this page: Apollo Server Integrations - Apollo GraphQL Docs, they said you can submit an Apollo Server integration. If you can submit one, that would be great.
I’m still using apollo server v3 at this moment, but I will update v4 soon.
Here is the PR:
2 Likes
Definitely some interesting thoughts. Thanks for sharing. I’ll summarize into 3 main points and give you my take on each:
- Why Meteor lost its momentum
- The write once, run everywhere dream
- Version naming / branding
Why Meteor lost its momentum
I think the biggest reason was the “it can’t scale” refrain. With regard to realtime – a core differentiating feature and its primary initial draw – the naysayers aren’t wrong, this is still true. Otherwise it’ll scale just like any other Node app.
Out of the box, realtime will run into problems with low-to-mid thousands of concurrent users (possibly even less). Sure there are ways to increase the number of concurrent users, but historically it’s meant
- bringing in something like
redis-oplogwhich lacks someone dedicated to improving / maintaining it - give up realtime all together by switching to fetching via
Meteor.methodswhich brings a host of other issues to solve
Neither of which are very satisfying answers and both dilute Meteor’s realtime promise. Meteor needs a core-maintained solution here. I hope that all or some ideas from jam:pub-sub make their way into core. For many apps, they may be all that is needed to scale beyond the current limitations. For the small percentage of apps that require the highest levels of scale or have complex publication requirements, it’s likely a different solution will be required (unless Mongo removes some of its current limitations on change streams) – perhaps something along the lines of a service like ElectricSQL that sits between your app and mongodb (it could even be built with Elixir).
Can Meteor scale to millions of real-time users someday? Hard to say but the vast majority of web apps don’t come close to requiring that. My belief is that a better solution could 10 - 100x the current limitation on number of concurrent users, making it suitable for a wide range of apps – possibly something on the order of 90%+ of apps. One thing I am certain of: oplog tailing must go.
If Meteor had a better realtime scaling story, it would be much more sought after, especially with the current trend of syncing over fetching and collaborative, local-first apps. Meteor is poised to be a go-to solution here when an authoritative server is needed (which is basically all B2B apps and non personal-use apps).
Beyond realtime scaling issues, my sense is that there was a lot of confusion back in the day sparked by the move away from Blaze and the focus switch from DDP to Apollo graphql — that pushed people away at the time. These days, allowing people to bring their own frontend framework is a strength. And funnily enough we’ve seen the shift away from graphql to rpc as people have come to realize graphql is unnecessary for most apps and teams and the simplicity of rpc is wonderful.
I also think the proprietary bundler, which was amazing at the time but now few understand the inner workings of, has hindered Meteor. The move to Vite will be a big benefit — it’ll make integration with any frontend easier, bring tree shaking (finally), and I assume allow for using things like vittest which should help a bit with the testing story.
Lastly, it would have been miraculous if Meteor sustained its early momentum. The fact that it’s still used and loved by many is a testament to it, especially in the world of JS frameworks which pop up every year and then fade away.
I still believe Meteor is the most productive JS framework and would love to see it double down on its strengths and unique capabilities.
The write once, run everywhere dream
As you’ve said, this is another compelling and unique feature of Meteor. Unfortunately Cordova has gone down hill but there are replacement options. Capacitor could fit the bill. There’s also Tauri, which seems very promising. As I understand it, the Meteor core team is investigating both of these so hopefully there will be a better solution in the near-ish future. For apps that don’t need access to specific mobile OS APIs, PWAs have come a long way.
Version naming / branding
Generally I like this idea. Could be fun if the frequency is right. (But definitely not anything with “Phoenix”, that’ll lead to confusion with the Elixir framework 
)
Major releases 3, 4, 5 etc. make sense for this kind of thing. The only issue is, at least traditionally, these have been far and few between for Meteor. From a backwards compatibility story, that is amazing. From a marketing standpoint, not so great.
IMO, Meteor could benefit from the Apple-style major yearly release (even if it remains backward compatible) mainly for marketing buzz. It’d also be cool to see it coupled with a conference, ideally in person and streamed live.
I think, to fulfill its true potential, Meteor needs to figure out how to fund big improvements (or get a new capital infusion from a white knight / benefactor ). Imagine a lean, mean completely modernized Meteor to take advantage of the current state of JS with a sync engine that “just worked” and could scale. It would be truly glorious.
I have more thoughts but this is getting long in the tooth. If you made it this far, I commend and appreciate you for reading.
14 Likes
Life’s gotten pretty rough for me lately, but I promise, if none does it, I will eventually do a Nats Jetstream + KV Pub/Sub and it will get much better. Literally difference between “toy” and “could use in production and get approval” in my eyes.
I basically grown up with Meteor, but I’m Highload engineer. Years ago, implementing React support when there was none, implementing SSR when there was none, NPM when there was none, SSL-HTTP2, etc, it was all worth it and not exactly complicated, especially since community was very active and helped with new ideas and implementations.
I know dozens of ways to overcome any issue in Meteor besides performance and stability. So idk, I’ve seen many features in latest versions implemented or planned for benefit of newbies that dont know how to setup a REST-API server and stuff like that. I feel for them, but its not one of things that hinder Meteor rebirth.
I remember myself wanting stuff like writing API requests in Meteor codebase. But I think we all grew up, - Its ok to have multiple containers for different things. Its ok to tinker around to get new feature like package-manager, encryption, etc. We just have to love and rely on thing that we tinker for.
I feel that for Meteor to be reborn, we must take on most important thing, - real time stuff. And just imagine how Meteor’s paradigm fits into LLM/Generative AI stuff. We could be “THE ONE” framework that solves collab- and time-constrained generation.
Sorry again, I really appreciate everything Meteor team does
3 Likes
A lot of the input is actually based on an underlying issue: Leadership. Currently the strategy seems to be a thing like “not enough capacity”, “talking with capacitor”, “who knows what will happen with react”, etc.
In the same line more voices from the team are added in roles like developer evangelist/communicator and so on. Also developers communicate (great!!) about the pieces they are involved in.
But there is no Bold statement.
What is Meteor?
Announcement of Meteor 1.0
Meteor is an open source platform for building modern web and mobile apps in pure JavaScript. These apps have live-updating interfaces that let people see information and collaborate with each other in real time, have subtle but essential touches like dialog boxes and popups that feel more like desktop apps than websites, and most importantly, can be run in a browser or installed on any mobile device from the app store.
Announcement of Meteor 3.0
We are thrilled to announce the release of Meteor.js 3.0, a milestone in our journey to create a powerful and versatile platform for modern web development.
This release marks a significant leap forward, and we couldn’t have achieved it without the unwavering support of our incredible community and partners.
What does Meteor 3.0 bring to the table?
In short, Meteor 3.0 brings Node.js 20, Express integration, Fibers removal, async server methods, ARM support, package updates, and new documentation.
The, in my opinion, core value of the Meteor platform is to get valuable user experience to our users.
And exactly that core piece is not being told anymore. Everything goes about tech, performance and other stuff.
The dev time spent seems to be on the behind the scenes improvements. Which are noteworthy, things are getting better. But the real Meteor experience does not get the attention anymore. And it seems that isn’t really where the focus is internally. It’s still visible in marketing text on the website though which is the strange part.
Gotta love the initial experience when you made your login page as an example:
Then simply add the
{{> loginButtons}}helper to an HTML file. This will place a login widget on the page.
It did. It did work. It did delight users. No other platform ever got that good. That simple. If that level would be possible in react without searching for external stuff. Just in the manual, do this, do that, login works. That’s where you really achieve:
Stop fighting with frameworks and start shipping real apps.
1 Like
Agreed. A strong example app will be needed here, once we get there, that can attract people on sites like HackerNews, etc.
Yes, that was the immediate issue which then lead that the real-time scaling issue wasn’t really resolved. The idea was that Apollo will be the solution, but when that became more lucrative than Meteor (thanks to people pealing off due to the Blaze v React issue), it never got resolved.
I believe we should mirror Node’s releases. It is predictable and well known, plus we depend on them as well.
I think Meteor Impact is the best we can do now. We will need to grow community and the money going into it to expand further (though there are some options coming up for the live part).
I think this might be a good idea for a talk for Impact.
Very much agree, but there is a split in community between returning to that paradigm where we had {{> loginButtons}} and being more open and flexible. The issue is how to resolve the front-end splintering. One possible solution is here:
Thanks!
I read that thread with the Blaze-Component idea. I get it, might be a good idea or not I don’t know.
But if you look at the thread it is again about technical implementation. That’s the point I made.
I do see the value in being open and flexible. But I think it has become a black and white discussion and that is not what I think the leadership strategy of Meteor should be:
Very much agree, but there is a split in community between returning to that paradigm where we had
{{> loginButtons}}and being more open and flexible.
I think that is the thinking / communication issue. It is not like supply all tools, custom template language, full blown app building environment etc. I think there is a baseline of the tools we all need to get our first prototype of an app or a new feature out to test with users.
That’s the start of the magical Meteor experience we had the honor to experience.
The great experience was:
- meteor create (no template)
- create projects collection
- autopublish did it instantly, no need to understand the technology behind publish-subscribe to show a demo
- Show the data with some scaffolds, add data via de console Projects.insert({name: ‘Project X’})
- meteor deploy myapp.meteor.com
- Magic, client could see something which looks and feels like an app
For comparison: Making a login now:
You get a manual like: Meteor.js 3 + React | Docs where you are building your forms by hand.
So every developer has to go through those steps. Why not just supply them as a tool to get started. Basic level, customization can always be done. Like scaffolding.
I do understand that the open and flexible paradigm should exists, that there should not be too much maintenance for the team etc. But I think you do can supply the basics and communicate in that way to get user to quicker real world results with Meteor as a tool.
We had apps surviving more than a year with loginButtons before we started building our custom ones. So we could really dedicated focus on the user.
1 Like
First off, thank you @wreiske for sharing your thoughts. You’re one of the very few people in this community who’ve put actual effort where their words are. So I’m always glad to hear from you. I’m also glad to be reading @jam’s opinions since he likes to stay in disguise most of the time. With introductions out of the way, I think it’s important to differentiate between two things: the first is Meteor marketing and the second is actual Meteor problems. Let me discuss the two separately. I’ll start with the easy one.
Meteor Problems
The big ones and most common amongst your comments here guys are:
- Build Times
- Cordova
- Scaling
I think the pendulum is swinging back to Meteor’s favor this time. After clearing out fibers, the core team is hyper-focused on improving the build problems, and @nachocodoner has been putting out amazing effort. Don’t take my word for it. Try it out yourself now! Release 3.3 (beta.0 available 🔥) by nachocodoner · Pull Request #13681 · meteor/meteor · GitHub
I’ve spoken to @nachocodoner in private and the work is far from stopping; it’s merely the beginning. Once they’re done with build problems, they’ll move onto Cordova. It’s listed clearly in the roadmap.
I’m super pumped about this as it has alleviated multiple problems in one go:
- Dispersing knowledge about the build process. After many years, we now have someone who has dabbled with the build process other than @benjamn & @zodern - something which I’ve been calling for for an eternity. Perserve reify in SWC compilation by nachocodoner · Pull Request #13675 · meteor/meteor · GitHub
Side note: I really appreciate @zodern’s input
. One of Meteor’s challenges is the limited shared knowledge. I’m still learning how all the parts fit together, and his guidance has been very helpful in pointing out what matters. With that, we can better ensure the things that make Meteor unique are preserved. With modern bundlers on the app’s code, it’s uncertain how long that will stay true, but at least now we have the understanding to try.
- Off-loading problems to other libraries. One of the biggest issues that Meteor has suffered from is biting more than it could chew and taking on more and more responsibilities. No longer custom solutions for problems that the community has already tackled. Meteor core team has always suffered from manpower problems, and the more we can free ourselves, the better. This also aligns Meteor more with the broader Node.js community and allows Meteor to piggy-back without expending any effort.
As for scaling, I believe experimentations done by community members like @jam and @radekmie, along with advancements in MongoDB itself, will solve these issues. Also, it’s better to give it some time to mature while the focus remains on build problems for now.
And I believe the core team has had enough battle scars to know, how to tie Meteor to a mobile library now 
@nachocodoner
Meteor Marketing
This is my biggest pet peeve and partially why I saved it for last. Articles like these keep coming and going on the forums and, while they’re well-intentioned, it begs the question: Why?
I hope you won’t call me a DHH fanboy, but this piece struck a nerve. Why should we bother convincing others of how great Meteor is? Why should we go on Hacker News and Reddit fighting and trying to dispel Meteor FUD? If Meteor is working out alright for us, then that’s all we need. If someone doesn’t see the use of Meteor, so be it. If someone chose to migrate out of Meteor, fine. At best, we can learn from them and understand, but never change their minds.
I know this energy is coming from a good place and hardcore Meteor enthusiasts like me, but I believe it’s better channeled into more constructive efforts. Don’t argue educate. Never compare Meteor to any other tool nor try to convince people that Meteor has changed or how it can be used with different front ends. These people made up their minds about Meteor a long time ago, and it’s time we make ours too!
3 Likes
Here’s an example of an issue I had today. An employee was looking to learn more about meteor test and how it works. I googled it, and no matter what I tried I got the meteor 2 docs.
After landing on the meteor 2 docs, there was nothing that told me there is a newer version of meteor available. Maybe a full width banner could be useful to direct to the new version?
I can’t even find any information about testing on the new docs.
This is painful!
1 Like
I made two pull requests:
13 Likes
Real time and several lines of Blaze code made the magic, which attracted me here. Today, both are gone. But I still come back every once a while to see if that simple magic comes back. Maybe one day.
Abandoning Blaze is a mistake. People who come here naturally are anti-mainstream, and think simplicity as a more important factor. I have many app ideas but couldn’t make it because it became too complicated in the past 10 years. I’m going back to html+css+vanilla js when I have any impulse to do web projects. I don’t have time to learn newest tech and don’t want to spend time on those things that may become obsolete one year later.
Without real-time and simplicity, I don’t know how Meteor js differentiate itself from others.
2 Likes
Agree on real-time and simplicity. Those should absolutely remain as core tenets of Meteor. I don’t think either are gone though. What makes you think that?
Regarding Blaze, I think it was great and it’s kind of amazing that you can still use it if you want. But allowing other frontends is both a strength and a necessity so that brainpower can focus on the more critical pieces of the stack.
If you like Blaze, then you’ll like Svelte. In many ways Svelte is its spiritual successor and is much closer than any other framework to writing vanilla html, js, and css. I was reluctant to give up Blaze back in the day but I found Svelte quick to pick up. Unfortunately herd mentality has promoted React which imo is legacy tech at this point. Ranking by DX, it’s Svelte > Blaze > the rest > React. Svelte also happens to have best in class performance too. Maybe one day everyone will just use web components, but the way things have trended so far makes me doubt it.
6 Likes
I don’t object to using other front end libraries, especially now when Blaze has been abandoned for many years. The reason I miss Blaze so much is that it’s so intuitive and simple to understand/copy.
Meteor js 1.0 was amazing because of its real time and simplicity, which attracted newbies like me. Attracting newbies or non-professionals is important because it’ll make itself popular.
Think about Python! Python is not great in many areas if you really want to compare(the only greatness is probably its simplicity), but it attracted many non-programmers to it and became a mainstream language eventually.
As a newbie, I want to spend least amount of time to develop an app. no more new front end tech, since I have no time for that. In the old days, just plain meteor/blaze+html+css+js. Now I’m confused.
If you are a professional, welcome to spending time re-invent the wheels. But, according to past experience, most of those efforts are not going to get you too far.
For Meteor js itself, I think the most important thing is its ability to do things. The development focus should be task-oriented. Can it connect to SQL? I mean, easily(one line of code, like {{> loginButtons}}) or built in. Experts might say they have many ways and many line of codes to do it, but those are intimidating for newbies.
If the core team can solve one problem a year, it’ll definitely rise from ashes. If one line of code can do the job, it means you solved the problem. Otherwise, it’s one time patch.
Also, be realistic. Tell people frankly: it can’t manage many users, etc.
For the tutorial, it doesn’t tell much about the internal process of Meteor code. I’d recommend adding one chapter of internal mechanisms right before ‘next step’.
1 Like
@htchd7 just want to add that Blaze is not abandoned and @radekmie added Promise support during Meteor 3 development in 2023/2024 It still integrates well with many UI libraries and it also works with tailwind etc. However, I agree that development slowed down a lot for Blaze.
2 Likes
Thanks for mentioning it. I agree that it’s definitely slower than it was, but I’d personally consider it done. There are some bugs and/or things that could be improved, but it works and there are many projects sticking to it silently.
4 Likes
I got an itch based on the above conversation about blaze.
Added a GitHub action workflow to replace the CircleCI runner & also a draft change at possibly improving the performance of dom updates. This pull request optimizes the way DOM attribute updates are handled in Blaze by introducing a caching mechanism that tracks the last set values for each attribute. By storing previous values and comparing them before applying updates, the code now avoids redundant DOM changes when attributes haven’t actually changed. This reduces unnecessary re-rendering and can lead to improved rendering performance, especially in dynamic templates where attributes are frequently updated but often remain the same. Additionally, the change ensures that the cache is cleaned up when attributes are removed, helping maintain memory efficiency. Overall, this update should make Blaze apps more efficient by minimizing needless DOM operations.
Anyone have any good tests for blaze performance?
5 Likes
@wreiske I normally refer to this (as a user) to see how speed + memory improvements are coming along in different frameworks, though it’s essentially a sort of microbenchmark.
(Snapshot results: Interactive Results)
I tend to compare:
- vanillajs
- solid
- svelte
- vue
- react-hooks
- lit / lit-html
- and sometimes ember, elm, blazor, one of the Rust WASM frameworks etc
Which gets you a pretty good idea of performance characteristics.
Here’s another example of bad first impressions.
I feel like every time I find a meteorapp.com link it is never actually working. This is another thing that causes some headache from new interested developers.
My boss sent me this: https://youtube.com/shorts/GO7XFiQB02Y?si=zKZV-zvk63AY-yPu
I asked if I could share and he said to preface it with he’s not normally an a-hole 
Here’s a PR that fixes it:
I really liked the honesty in this guy’s video. This is the type of honesty that push Meteor forward.
Thank you for unveiling these shortcomings and even taking the initiative to better improve Meteor 