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

[Mousy]

@wreiske

Meteor’s default real‐time data sync (DDP + pub/sub) can strain apps at scale

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

[lucfranken]

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

Meteor.js 3 is officially here!

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.

[storyteller]

@jam

If Meteor had a better realtime scaling story, it would be much more sought after,

Agreed. A strong example app will be needed here, once we get there, that can attract people on sites like HackerNews, etc.

@jam

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.

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.

@jam

IMO, Meteor could benefit from the Apple-style major yearly release

I believe we should mirror Node’s releases. It is predictable and well known, plus we depend on them as well.

@jam

It’d also be cool to see it coupled with a conference, ideally in person and streamed live.

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

@jam

I have more thoughts but this is getting long in the tooth.

I think this might be a good idea for a talk for Impact.

Submit a Talk - MeteorJS Impact Conference

@lucfranken

And exactly that core piece is not being told anymore. Everything goes about tech, performance and other stuff.

@lucfranken

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.

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:

Modernizing Meteor ideas: `<blaze-component>` Custom Element (Web Component)

We’re trying to “make Meteor great again”: I think Meteor is still great! But! It is in need of modernization. So, let’s build get there one step at a time: One problem Meteor has is that accounts-ui is built with Blaze, and therefore is not compatible with template systems of React, Vue, Angular, Svelte, Solid, etc. Solution: a <blaze-component> Custom Element Custom Elements are native HTML elements defined in JavaScript. I have a custom element I made locally called <blaze-component> t…

[lucfranken]

@storyteller

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:

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.

[harry97]

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

2. 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!

[wreiske]

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!

[wreiske]

I made two pull requests:

• Added new Meteor 3 banner to v2 docs and sidebar call to action. by wreiske · Pull Request #99 · meteor/meteor-theme-hexo · GitHub
• Update v3-docs to point to docs to reduce confusion by wreiske · Pull Request #13714 · meteor/meteor · GitHub

[htchd7]

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.

[jam]

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.

[htchd7]

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

[jkuester]

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

[radekmie]

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.

[wreiske]

I got an itch based on the above conversation about blaze.

DRAFT: Blazing!

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?

[ceigey]

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

GitHub - krausest/js-framework-benchmark: A comparison of the performance of...

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

[wreiske]

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.

[wreiske]

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:

Upgrade skeleton to support Meteor 3 async method changes

[harry97]

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

[evolross]

@wreiske

Here’s a PR that fixes it:

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

@lucfranken

Then simply add the {{> loginButtons}}helper to an HTML file. This will place a login widget on the page.

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

@jam

Meteor needs to figure out how to fund big improvements (or get a new capital infusion from a white knight / benefactor )

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.

@jam

Ranking by DX, it’s Svelte > Blaze > the rest > React

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.

[trusktr]

@jkuester

Blaze is not abandoned

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.

@harry97

Don’t argue educate

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.

[harry97]

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

Is guide up to date?

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.