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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
@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!
This reminds me a bit of the Thunderbird guys saying they stopped development “because it is done”. But in principle, you’re right. Blaze is amazing and allows for insanely fast development. I still love it. However, its performance on mobile devices is not really good, at least to my experience. And if you combine this with the slow development pace, this is still a valid reason to give it up and move on to other frameworks, if you’re a mobile-focused developer. This may be different for people developing web apps, of course.
My experience with Blaze resulted in a lot of spaghetti code. I don’t blame Blaze for that, I blame myself. However, the tooling around React actively promotes good practices and I do think that is something that Blaze never had. You could play fast and loose with contexts and never see a warning in the console.
Also, you still see posts here questioning the use of Session vs reactiveVar vs reactiveDict. I certainly agree with the sentiment that Redux isn’t for every project, but the lack of a true state management tool I think also hurt Blaze.
I was a big proponent of Blaze, and I still really enjoy how close to the html it allows the code to be. But I’m not sure it lives in an ecosystem where it can make developers (and the code they write) better.
I had similar experience with a growing Blaze code base. However, as you stated, those issues could have been avoided with good engineering practices but those practices are built-in something like ReactJS from the get go. This is not surprising, Blaze was created from the handlebars/jQuery era before font-end components took over. I’ve mixed feeling about Redux, I think it’s an overkill for most react projects and React17 is heading toward making async calls within the components.
With that said I still think Blaze is the fastest way to get a web app built and I still use it heavily.
and dive head first into the repo.
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.
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!