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

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

1 Like
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
35

There is only one thing I love more than Meteor. React.

4 Likes
36

I wouldn’t say I personally love it more than Meteor, but I have a lot of love for React as well. :man_shrugging:

1 Like