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

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.

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

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