In no offensive intent, Blaze is abandoned by Meteor.
It’s not just that Blaze is considered “dead”. It’s more that Meteor, as an open source project, doesn’t have the same contributor activity or Core team capacity to fully maintain all areas, implementation, documentation, innovation and more.
As stated in a previous post, Blaze has received some updates recently, which helps keep it usable for those who still rely on it. In my upcoming work on the modern bundler, I’m also considering Blaze compatibility, since many developers are still using it in active projects and businesses.
The disconnect between the old docs and the new docs makes learning meteor more difficult to teach. The AI helped a lot, but then that was removed.
AI is now everywhere and has helped many, including myself, to continue working with Meteor. I agree that an internal AI tool looked promising and would be helpful. Some developers already created a GPT to assist with Meteor. Maybe we could add links to this and similar tools in the docs via a PR?
React is one of the most outdated frameworks these days, and does not align with modern standards. Choosing React today will leave your code base in a poor state for the future.
You mentioned this in another post. This depends on each developer and company preference and goals. React is still widely used and continues to evolve. It offers a solid production experience with many tools and resources available, and in Meteor we have specific packages to empower React app development with reactivity. React still brings many benefits. By the same reasoning, some might argue that Meteor is outdated, less popular than other frameworks, not fully aligned with standards yet, has still a slow bundler, could lead to a poor codebase in the future. Yet, we’re not giving up on Meteor, we’re modernizing it. The same can be said for React and its ecosystem.
make its own (or adopt a) signals-based standards-aligned custom elements lib, Meteor would position itself much better for the future and for simplicity, and we’d be able to educate people on how to make apps more easily.
I’d like to better understand the approach you suggest. Are you referring to SolidJS? I’m somewhat familiar from conferences, but would appreciate more detail. There’s already a Solid example in Meteor’s sample apps. With the upcoming Rspack integration, support will improve further through a stable, modern bundler.
I’m always interested in how others build their stacks and the reasons behind their choices. There’s a lot of fatigue around UI libraries and sometimes hidden agendas behind switching. Strategy is important, but without experimentation and practical proof, strategy alone doesn’t go far. I’d love to see a working repo with the ideas you have been proposing across several posts, maybe even a PR with an example we can include in the CLI. If it gains traction, it could be tested and possibly included in the core for the next modern times.
As a reference, I’ve been working with Webpack and Rspack in Meteor using SWC in private projects for almost 3 years, including one full year of independent work without any income. I’ve also used for long and plan to also refresh native capabilities in Meteor with CapacitorJS, the most promising succesor of CordovaJS, and reviving reactive-publish, Tracker.autorun, and ReactiveVar to support async on both client and server. I’ve prepared more things, many of them based on independent beliefs and developed outside my part-time role in the core. I believe in these tools because I’ve seen their real impact. I’m trying to share the results of that deep study and practical work so everyone can benefit. With Meteor 3.3, we can already see that through SWC adoption, and soon with Rspack. There are also contributors actively improving the framework and submitting PRs frequently these days. This is really good.
I see too often in tech, we spend more time aligning on strategy than actually building and testing ideas to validate their viability. I hope more devs and companies that believe in Meteor take these thoughts into actions, and invest resources and time to make Meteor modern and great. That’s what will make a difference.
Not trying to be offensive, this is just an honest take on how I see the different views we all have on perfect stack or future Meteor. Having a view is easy, proving it’s viable is the hardest. So beyond sharing a specific view, I want to encourage action, to shape it and help improve our future through contributions.
. 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.
