Meteor Phoenix: Rising from the Ashes to Spark New Developer Passion

community
15

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.

2 Likes
16

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:

17

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:

  1. meteor create (no template)
  2. create projects collection
  3. autopublish did it instantly, no need to understand the technology behind publish-subscribe to show a demo
  4. Show the data with some scaffolds, add data via de console Projects.insert({name: ‘Project X’})
  5. meteor deploy myapp.meteor.com
  6. 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.

2 Likes
18

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:

  1. 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 :pray:. 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.

  1. 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 :wink: @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!

4 Likes
19

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.

image
image2755×1216 363 KB

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?

image
image1335×784 75.1 KB

I can’t even find any information about testing on the new docs.

image
image2143×939 203 KB

This is painful!

1 Like
20

I made two pull requests:

image
image2015×1453 268 KB

15 Likes
21

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.

3 Likes
22

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.

7 Likes
23

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
24

@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
25

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
26

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
27

@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.

28

Here’s another example of bad first impressions.

Screenshot 2025-06-22 at 6.21.29 PM
Screenshot 2025-06-22 at 6.21.29 PM2210×1270 318 KB

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.

1 Like
29

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 :rofl:

Here’s a PR that fixes it:

2 Likes
30

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 :clap:

4 Likes
31

It’s wild that the skeletons, as simple as they are, don’t get updated with the tech/changes of new releases.

{{> loginButtons }} and that simplicity is the reason we chose Meteor back in 2015 for our app.

I think anyone who built a Meteor app and did well (especially if the app is still active) should think about donating to something like this. I’d be happy to be involved in this. DM me.

Long time Blaze user. When I finally saw React and how well and easy it passes data through components, scope, etc. and in a single file compared to the wacky things Blaze does (like putting all passed down parameters into child.data) I was happy to embrace React. React was such a breath of fresh air to me compared to Blaze. Will have to learn more about Svelte.

6 Likes
32

In no offensive intent, Blaze is abandoned by Meteor.

Now that the tutorials have been removed, and the only two that remain are React and Vue with React coming first, Blaze is pretty much dead to Meteor.

Ironically React is a minefield for beginners, and even experienced devs, who will get their legs blown off by the problems that are so common in React. This makes Meteor more difficult to learn.

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.

Styling being done with Tailwind in the now-limited tutorials is detrimental to code quality. Beginners are going to make ultra ugly messy code with Tailwind.

I would like to educate people on the best tech stack (Meteor with a signals-based custom element UI layer), but Meteor is making it more difficult lately. I can’t imagine beginners landing on the Meteor site and having as good of a time as they did back then.

If Meteor prioritized Signals and Effects frameworks in its tutorials, rather than overhyped frameworks like React, or better yet 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.

React is a bad option to prioritize. At least there’s a Vue tutorial remaining but it having Tailwind is going to educate people a good way to quickly make a mess.

2 Likes
33

Thank you for chiming in, Joseph. I really appreciate your insights.

Why are you so anti-tailwind? It makes writing CSS more concise and maintainable.

I kind of agree on the docs/guide point since they’re long overdue for some changes as I had noticed a couple of days ago

Lastly, what’s up with “signals” frameworks you speak of? I remembered the whole JS fatigue when you brought up a front-end library that I’m still not up to date about.

34

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.

2 Likes