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.
5 Likes
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.
2 Likes
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
3 Likes
Right - to get those issues fixed and PR’s dealt with, we need the community to step in and help. I’m sure Mitar will welcome any help. I was just saying that I don’t think we need to find someone else to take point, unless of course Mitar thinks we should. Anyone can step in and help at any point, and if someone is dedicated enough to get 1 or 2 PR’s merged (and shows a willingness to help triage issues and generally move the project forward), we’ll give them commit access.
Regarding having someone on the payroll maintain Blaze, that would be awesome! But at the same time it would also be awesome to have someone on the payroll maintaining an official Vue integration, Svelte integration, update the Angular integration, etc. As great as this would all be, MDG’s team is small, and is focused in other areas right now. The good news is that view layer integrations can almost entirely be designed, built and maintained outside of core, and wired in to work well with Meteor.
Stepping back and thinking about this a bit - many people are still using Blaze successfully in production, including large companies. Some of those companies have large budgets, and are active open source contributors across many projects. The thing is that even though they could afford the time and resources to help contribute back to Blaze, and help take it to a new level, they don’t. This isn’t because they don’t believe in contributing back to the community, it’s because they honestly don’t see the need. Blaze is doing exactly what it’s supposed to do - help them successfully meet their business requirements and deliver awesome products. Honestly, I think this speaks volumes about the ingenuity and amazing forethought that went into Blaze’s design/development.
But again - if anyone is interested in taking Blaze to a new place, please just raise your 
and dive head first into the repo.
6 Likes
I kind of thought that’s what Mitar thinks we should do, based on our conversation:
Besides my suspicion that Mitar’s lack of time does negatively impact the progress of existing PR’s being reviewed and merged, I feel you kind of missed my point. Sorry if I wasn’t making sense!
I was merely trying to suggest how to turn all this negativity around Blaze into something positive for Meteor:
Instead of figuratively throwing Blaze into the junkyard of abandoned software, Meteor could (proudly) support Blaze with minimal effort, because, like you said:
This is actually very true, we have currently 144k lines of code total, all front-end code written in Blaze. We don’t really have any problems with Blaze and I very much agree with your sentiment:
I couldn’t agree more and I’ve been somewhat vocal about it here. Then, when something really rare happened a few months ago – we encountered an issue with Blaze – it was Meteor’s lead deveoper @benjamn who fixed it and submitted a PR for Blaze (for which I’m very grateful).
To me it seems Blaze is getting the minimal support required (severe bugs fixed) by MDG while the Meteor forum is filled with “BLAZE IS DEAD!!!” -posts, like this current thread.
Out of those two, I would pick the second option! I understand that it’s not sensible for MDG to develop and maintain integrations for all possible front-end libraries, but Blaze was built by MDG, it’s used by quite many Meteor projects, it works great with Meteor’s reactivity system and it really doesn’t seem to need much maintaining, like you said!
5 Likes
Yes, this is accurate. If it helps bring peace to any current Blaze users, I’ll go on record and say this: MDG will continue to address critical bugs that arise with Blaze, that are caused by changes made to the Meteor core. I’m not really going out on a limb (or risking my job) by saying this, as this is what we’re doing now, and we don’t have any plans to change this. We don’t want to leave Blaze users in the dark (especially since Blaze is currently dependent on Meteor), and bugs caused by core changes are likely easiest addressed by those making the core changes. Please note though that this is for bugs caused by Meteor core changes, not long outstanding usage bugs or bugs that are introduced as new features / bug fixes are introduced into Blaze (which we’re leaning on the community to help out with).
Thanks for driving this Blaze discussion forward @arggh.
8 Likes
Just as an FYI, Arunoda has left the Meteor community for a long time now.
Anyways, I still use Blaze. It’s just so quick and easy to use, and that’s a big feature for me. It works really well with Meteor.
Every now and then I think of forcing myself to use React but I just don’t think it’s a step forward in terms of usability. Something about JSX just rubs me the wrong way. Plus I do not like facebook the organization.
Meteor pioneered / popularized a lot of the stuff we see in modern reactive frameworks, back when Angular was the hotness. Blaze is the templating engine that made Meteor a compelling choice. It might have been part of what sold many people Meteor. Then React came, etc. Who is to say that in 3 more years some other front-end framework won’t rise up and be the new hotness? I think last month Vue surpassed React in the number of GitHub stars. Is Vue the new hotness?
I think, for me, what matters is not how often it’s developed but how stable it is. Am I experiencing any bugs? I’ve had no show-stopping Blaze failures.
Anyways if I were to use something other than Blaze it would probably be Vue. Vue was actually created by someone who was on Meteor’s core team. He left Meteor to work on Vue. Since I like Meteor and he was a part of making Meteor what it is, I’d probably like Vue. I actually think Meteor missed out by not having first-class integration with Vue when Vue was taking off. I know that vue’s core devs released packages for Meteor, but it would have been great if Meteor the organization released those packages officially.
But since I’ve had no issues with Blaze (aside from it now being an obscure language) the only reason I’d switch would probably be if I wanted to use SSR in an app or if I wanted to do something with native mobile app development.
4 Likes
I’d rather have MDG focuses on core Meteor, the packaging, server and build system. This is the foundation for the Meteor’s ecosystem so the energy/money should be invested in those areas in my opinion.
For Blaze, if there is a need I think companies/open source should step-in. Blaze, in my opinion, is the fastest way to get an app going due to it’s simplicity, maturity and tight integration with Meteor’s backend, so it’ll probably always have a place in the Meteor/JS ecosystem.
I can’t speak for everyone, but if this is all that Meteor was when I first found it, I probably would have passed. IMO the front end is just as important. The tight integration that their view framework had with their backend, in addition to minimingo, was what made Meteor exceptional.
2 Likes
The biggest problem with Blaze development is that it does not have wow-factor. It is just good working horse and not ‘the next hot thing’. Venture capitalism is built on news, hype and masses of fans and followers (not necessarily adopting it for profit or for real projects). There is nothing wrong with it.
Correct me if am wrong but ‘hero developers’ like @arunoda are also attracted by the possibility of making some wow-things especially in the post-Javascript-fatigue-times. There is nothing wrong with it as well.
So, the question is - do we need just minimal Blaze support or can someone suggest some wow-features for Blaze 2.0 which can attract both venture capitalists and hero developers? And as Blaze is really tied to meteor it can in turn help meteor development as well.
2 Likes
Although it would be same on my side probably (would not use meteor if there wasn’t so good reactive integration with Blaze front at the beginning - in my case something like in 2015), IMHO the ecosystem evolved from those days.
Neither I can speak for everyone but nowadays what I really appreciate are new core features (we are on latest beta now in production, really great job MDG!, so many great new features) and good integration with major frontend frameworks - so more projects can decide to use Meteor which is good for everyone. Integrations nowadays might be not so good yet in some cases but we are happily using Blaze/Materialize in 90% of app and on top of that few React components and now transitioning to Vue/Vuetify - I can’t say there wasn’t problem but no showstopper (we go on with Vue slowly, there is no need to rush, Blaze simply works).
From my perspective, in case of Blaze/React/Vue/Angular/etc, mentioned spaghetti code problem is mostly problem of a developer or a team leader, not the framework. In every of those, beautiful, structured code can be written, but the exact opposite too.
Blaze is a great library and I would recommend it still to everyone, but in the same time I would recommend to look at Vue and probably React and current Angular too, they are all quite good already, and imho its more about team subjective preferences.
Thus I think its good for Meteor to be great at the core and have good integrations with major frameworks. Which frontend framework will have faster development should be community driven fact. I fully understand that MDG have some size of team and they can’t do everything (or sponsor everything) and good frontend framework is project on its own.
2 Likes
I think you’re underestimating what that all means. From a business perspective, it make no sense to invest in another view layer when there are many competing open source packages, back when Meteor started, there was no React or VueJS so Blaze made a lot of sense, but today having the view layer flexibility is much more preferable. The choice of view layers seems very subjective, just look at the vue versus react debates.
However having a build system that favours convention over configuration with a solid packaging system and integration with a popular view layers is very much needed in the JS ecosystem.
And I did say Blaze is good to have, but in my opinion, should not be the priority for MDG.
2 Likes
It’s great to have choices, and the ability to easily add third party packages has been one of Meteor’s defining characteristics. But nothing wrong with a tightly-integrated view layer from a technology standpoint. No third-party view layer can be as tightly integrated with Meteor as something built specifically for it.
What does the argument that Blaze made more sense back before React and Vue existed do for Meteor? Meteor had the leg up. What Meteor should have done back then was release a fully stand-alone version of Blaze (with minimongo!), asap, keeping the tight Meteor integration as benefits to using Meteor with it. Even to this day it’s still very much Meteor-only. If Meteor plays the “let’s be super visionary and pioneer everything, and then depreciate it piece by piece when someone becomes the-new-hotness-for-x” game… then what will it be left with when next month AirBnB or Netflix or somebody with a giant tech budget releases a more trendy build system and backend that works with vue/react? What will Meteor have to offer besides the same third-party packages and pricey hosting?
The tightly integrated, wholistic, end-to-end framework, with the option of using third party packages, is what made Meteor a compelling body of work.
1 Like
I hear you, but once again, I think I see way more value and appreciation to what Meteor is providing beyond the view layer which I think you’re underestimating. A lot of effort has been put on the core features such as dynamic import, latest node support, SSR, ability to create two bundles (legacy/modern), faster build times, the ability to create minimal meteor project etc. are all features that made Meteor more appealing to us, if the effort went into the view layer (Blaze) while neglecting the core, I’m sure lot of people won’t be happy now.
I’ve nothing again Blaze/Mini-mono I’ve used it and still use it several projects but I just think something like React is more suited for more complex project and I don’t want to be restricted to Blaze. I hope we’re not arguing past each other, I’m just stating the given the tight resources/constrain for MDG, focusing on the build/core Meteor, in my opinion, is the right thing to do, I’m just being pragmatic here.
IMHO, abandoned Blaze is only a symptom here, not a cause. And if we search for a true cause of where resources are directed it is not the one ‘hot thing’ being React but 2 at once: React and GraphQL, and the fact that these hot things were achieved at the expense of features, unique to Meteor.
Blaze is still alive but meteor hosting is not. It was deleted in favor of GraphQL. But I guess the expected effect is not achieved. If you look at https://search.packtpub.com/?query=meteor&refinementList[released][0]=Available you see 12 books about Meteor, with most in pre-React/GraphQL era but no book about Apollo or post-hosting-deleted features despite their intended coolness like evergreen browsers etc. Maybe because they are not exactly core cool things like one line deployment but just ‘nice to haves’ or ‘external standard compliancy’ categories.
As someone who prefers to develop everything from scratch, I’ve found Blaze to be beyond sufficient. It’s just three things: templates, events, and helpers, and that’s all you need. Everything else, you can get from third party libraries or add in yourself.
I think Blaze works really well as a default view layer. It’s kind of like with Rails or other frameworks - they have really simple view frameworks in place and then you can layer in whatever you would like.
If there’s one thing that could help Blaze significantly, its updating the data layer or getting people to think about it differently. I suspect that’s where most of the performance problems are coming from.
4 Likes
Could you elaborate on that, you are sure to have great insight as a pro tools developer? Viemodel and Blaze components plugins do not solve that?
I wish this can be pinned somewhere. It’s what most of those with production apps written in Blaze want to hear.
4 Likes
Second this, it might make lots of people happy.
3 Likes
@hwillson Your post simply made our day. It would be great if this can be made prominent somewhere. It has huge significance for Meteor users like us, who rely on Blaze for their production apps!
3 Likes