2 years have passed since any significant movements in community-supported blaze at https://github.com/meteor/blaze so the question is:
is it just enough and does not require development (aka Blaze 2.0) or …
should we all gather and support it (though I am not sure who is the leader of the team and who collects all the money and how it is spent, so this may be question number 1) with donations?
We still use Blaze in our production app. We make use of Blaze’s template-level subscriptions. It works well. But the architecture of our app is still very Meteor 1.2.x - 1.3.x. And we’re still on Meteor 1.5.x. Probably when we upgrade to 1.6.x - 1.7.x, we’ll also look into a React overhaul.
But for now we have no real show-stopper Blaze bugs we’re dealing with. And our app is complex and large. It does seem slow sometimes though.
Thank you for feedback! Is it internal app or can it be seen on the web?
I think that React (or vue, or angular) are taking over due to continous development and the quantity of ready made components that are available and continue to be. I heard lot of good thinks about Blaze but developping in React I feel I can reach my goal way faster thanks to all this already made work.
I don’t think Blaze is dead, or bad but the lack of community around it make it a more complicated choice for newcomers. Not only to mention that newcomers to Meteor may already have React or Angular knowledge so rather go for that than take the time to check Blaze
I see. Everybody is talking about ready made components but quick search did not bring any revolutionary results. Can you list some examples of such components which make React more efficient in development than Blaze?
As I don’t use Blaze i do not know what exist for it but when I see things like semantic-ui-react for fast prototyping, I think it is a very big plus. Also all the redux/react combo is very popular and usefull. I can think of draftjs as well,
Just have a look at antd for example: https://ant.design/
I use their components really a lot throughout my apps. I know of no library with this many components with this level of polish which comes even close to antd in blaze. Just an example. There are many many more out there.
Still using Iron Router and Blaze…
Although, it is mainly because most freely available Meteor tutorials use Blaze/IR, and that is how I learned to program web apps. I don’t feel like it is worth learning React/Vue/Angular… mainly because Blaze is working fine so far in my first few apps, and I’ve already learned a lot about Blaze/IR, so I don’t really think it is worth the time and effort to switch. If you are new to Meteor, then I would probably suggest not using Blaze, because although it works fine for my applications so far, its development seems dead.
We have quite large app on Blaze (agdata.cz), but because of active development and overall better model we are switching to Vue and its nice and actively developed large set of components - Vuetify. We do not plan to rewrite Blaze parts in near future since its working well.
Just wanted to second this. Their components are well thought out, expose a really nice API and the documentation is really great also.
I lost my faith in the future of Blaze. It’s still a pretty cool technology and it’s perfect for rapid prototyping, so I am still using it, especially on Hackathons. But I can’t see any further development. And if your code base gets larger, it tends to turn into “spaghetti code”. Plus, it is pretty slow, which is significant if you run your code on mobiles. This is why I am currently rebuilding guzz.io (and also a second yet-to-be-released app using the same code-base) on React. At the moment, it’s still a mix of Blaze and React, but all new components are React, and the Blaze components will be replaced over time. It’s sad, but that’s just the way it is.
I’d rather go to Vue as well. BTW, I have tried to dive into React this weekend and have noticed some strange thing:
React is not immediately fully reactive but reactive according to schedule. Does this make Meteor.Tracker redundant?
I’m not sure what you meant by “according to schedule”
For full reactivity in React, we use withTracker HOC
Have been using Blaze continuously since our business got into Meteor in early 2015.
Blaze was one of the features that won us over to Meteor because of its ease of use and intrinsic support for reactivity. We have used it for recent projects and would continue to use it for new projects.
Having looked at the Github repository, I see that there have been a few small bugfixes and other commits over the last 2 years. I see this an an indication of its general stability and ability to meet the majority of use cases.
It is unfortunate that every now and then, a small but vocal number of ignorant people and sh*tstirrers with nothing better to do with their time than spread FUD on Internet forums and spruik other flavours-of-the-month. People have learnt to ignore them and carry on being productive with Meteor.
Another Blaze aficionado here! Especially when coupled with ViewModel by @manuel . I’ve been using Blaze since we jumped onboard with Meteor in 2015. In my honest opinion, Blaze works wonderfully with Meteor’s reactivity system and is a very capable frontend rendering system.
We have over 100k lines of code in our app. So far, our codebase has not turned into the feared evil spaghetti monster some people are talking about. I very much build stuff with components just like I would with React.
In the meantime, I’ve written an app with Gatsby (and therefore React) and one smaller app with Vue. I would still pick Blaze or Blaze+ViewModel over React or Vue for Meteor, unless SSR was a requirement.
Blaze might be slower in some benchmarks, but our users are crediting our app for being “snappy” and “fast”. I think most cases of Blaze being actually slow are related to abusing the reactivity system or just doing stupid things or using bad patterns for data loading.
This is where a larger community with a wider variety of tutorials repeating best practices would become very useful for Blaze.
I recently found an issue with Blaze and dynamic-imports that was caused by a bug in Safari browser itself. The problem is being fixed (or already has) in Blaze right now, so I wouldn’t go as far as saying Blaze is dead. I’d say it is quite stable and capable as it is, since this is the first real issue we’ve had with Blaze ever.
Unfortunately, when separating Blaze from the Meteor core the project was handed over to @mitar who hasn’t really been active in the project ever since. He himself has said he’s working on school stuff and has no time available for Blaze.
Might be a good idea for MDG to appoint a new project owner for the Blaze repo: it might revive the Blaze community or at least get the 1000$ of donations working for the benefit of Blaze users.
Sure, maybe @msavin and @arunoda or similar guys with their experience in product development can take the management of the project in his hands and make it work with it staying open-source but with some benefits for those who join paid plan?
I don’t think this is necessary. @mitar may be busy, but he still responds quickly to just about every issue opened in the Blaze repo. Alongside his deep understanding of Blaze internals, he also has a good sense for what would (and wouldn’t) be a good fit for Blaze. If anyone is interested in jumping in and helping take Blaze to the next level, then all they have to do is actually jump in and help take Blaze to the next level 
. Seriously, start closing bugs, start opening FR’s with your ideas, start pushing the discussion forward in the forums or in the repo, etc. I don’t think there is currently anything in the way of anyone who wants to help work on Blaze, other than the time/desire to do so.
This might be mostly my gut feeling, but the last time I checked the Blaze repo there was a bunch of issues and PR’s left dangling for months / years. I also asked @mitar himself a while back in Slack about his time allowance to guide the project and the usage of the donated money, to which he replied he is “sadly fully occupied at the moment” 
There’s also a PR that should fix a Safari JS engine specific bug in Blaze waiting to be merged, but @mitar didn’t have time to look into this. I tried helping by providing some benchmarks.
This PR would fix existing major issues we’ve had using dynamic imports with Blaze.
I’m also not trying to blame or shame @mitar here, we all have our lives, but just making a point that if someone else (probably a short list of candidates by now) could possibly replace @mitar in this case, it might be a good move.
Maybe it’s just me, but having someone on the payroll to be responsible for maintaining Blaze might be beneficial to Meteor.
It’s (probably?) a very low-effort task to keep Blaze running as it is, but it would bring peace of mind to current Meteor developers running Blaze code in production and it would be a nice way to preserve Blaze as a Meteor-specific, reactive frontend lib.
In my opinion it boils down to either sending this message:
“We had our custom frontend lib, but we deprecated it and left hundreds of developers stranded on this god forsaken island with no food or water. That’s how we roll.” (which obviously is not true all things considered)
or…
“Yep, we have our cool custom-made reactive rendering library called Blaze, like everyone does in 2018. It works, it’s a bit different and lots of people like it. You can also use React. Or Angular. Or Vue or litHtml or Polymer or…”
which could be achieved relatively easily, since there isn’t really that much to do about Blaze, except for the random bug fixes.
Just thinkin’ out loud
