As a newbie I totally LOVE the simplicity of BLAZE!
Keep it stupid simple!
Plus one for Blaze! 
15 Likes
No worries at all, thanks for adapting your response then.
I agree that 5 years is a bit of a stretch to try to predict anything. And it’s true that either Angular or React may be deprecated again two years from now, for all we know.
I suppose I see that trend with Blaze right now and don’t want to be stuck with it down the line when the writing’s on the wall already.
I absolutely agree with you here. It’s probably one of the reasons Meteor rose so quickly in popularity, even and especially for beginners.
But I am trying to get a feel for whether or not it’s still going to be useful for more complex and long-term applications (as opposed to quick prototyping or playground experiments that won’t stay in Production for the next few years).
@batjko have you read that? https://gist.github.com/stubailo/9296dbd39fad0d6bbf58
Personally I’d be all up for an idea of Blaze 2 being based on React as a rendering system, as it would solve few important problems with Blaze. All the rest of them are more or less solved by community packages already.
2 Likes
Interesting, thanks for the link @brajt!
So that sounds a bit like React is definitely here to stay for a while and perhaps Blaze has a future alongside it.
Makes me wonder about Angular, which @Urigo has put so much work into.
It was quite a hard call, but I decided to switch to React for all my projects moving forward.
Personally, I prefer Blaze, and think are a number of things which I think it handles a lot better (or intended to, per the roadmap). But I need to be realistic moving forward, and make smart long term choices. Blaze is still officially supported/maintained, but is not being actively developed.
In the 1.5 years since Blaze launched, there’s been only one major update, the subquery and each..in code which took 8 months to land and whose author is no longer with Meteor (although he’s surprisingly and appreciatively still involved in Meteor stuff :)). The Blaze 2 discussion from 8 months ago led nowhere (officially at least), although did spur the creation of some awesome community projects.
So on that note, there are some amazing community contributions (which you should consider using if you keep using Blaze), e.g. @mitar’s blaze-components, @arunoda’s blaze-plus, template-caching and ssr, @seeekr’s magic-events, @frozeman’s template-var and my started-but-probably-abandoned virtual DOM for Blaze.
But React has community packages too, in fact, many more and a much bigger community around it that’s growing exponentially (from amongst Meteor users too!). More importantly, it’s being very actively developed, officially, by it’s own team at Facebook. So, those two things together give me a lot more faith in it as a long term bet. Ultimately, the leads Blaze has over React (including w.r.t. Meteor) will be addressed, while I don’t believe the reverse is true.
For rapid prototyping however, Blaze is still a clear winner, although it looks like @timbrandin’s sideburns project solves this. Also, although React is a bit of a learning curve, I’m starting to really appreciate a lot of it’s feature, especially the freedom to use more JavaScript in my rendering functions (which breaks some separation principles but I mean more like simple transformations at the beginning of a render rather than needing helpers for everything, and more flexibility in expressions).
And then of course, there’s still Angular 
12 Likes
With Angular it all depends on what framework will Angular 2 actually turn out to be. I started to look at Meteor mainly because I’ve lost my confidence in Angular 1 and wanted to learn something different before Angular 2 comes. Now I don’t even want to go back, Meteor is too much of a fun.
I have tried React (and ES6 modules) for a new side project, and while i get that it probably allow you to write more reusable code, so far i have been far less productive with it than with blaze. There is probably quite a learning curve i didn’t get yet, but while i understand the need to use “dumb” components to make them more generic and reusable, i find it makes you code no so easy to follow, with lot of indirection where you have trouble to find the component responsible for the logic. I also find that the way meteor is integrated with react makes it feel hacky and less at home than with blaze.
Last week i added a new feature to my main (blaze) app, and while i was feeling the god of spaghetti code behind my back, it was so much easier, and i was so much more productive that i don’t want blaze to die for now. Perhaps it should take some inspiration from React, but it got many things right.
13 Likes
Hey wow, this is a super important read, thanks for posting. There’s a comment there from David Greenspan too (the main author of Blaze). I think everyone should read this in full, including the comments (at least up to David’s comment), before posting further.
3 Likes
@gadicc Yes, like I said above, the whole discussion (but particularly David’s status rundown) points at React being the future of Meteor for the foreseeable future, at the expense of further Blaze development.
Now, as pointed out in that thread as well, Blaze still has a lot going for it and great popularity among Meteor devs of the first hour (who have gotten used to it and/or currently run apps with it), mainly due to its ease of entry.
But for major projects (other than quick prototypes or small side-projects), Blaze does appear to be on the way out, as far as I can see.
That leaves me with either Angular or React, with React clearly being favored at the moment.
personally, I have zero experience with React (though a bit turned off by JSX, which is just weird to me). And while I have some experience with Angular 1, it is quite a complex framework to use.
As of this writing, I am leaning towards biting into the sour apple and learn React. hm… 
Yeah, that’s what I did, for the same reasons. It’s a rough start but it does get better. It will help when we have an official pattern for mixing in existing packages written for Blaze. You’re not going to like integrating accounts management :> But obviously all these things are going to get better, and a lot better.
I like your use of “obviously” here. Gives me hope. 
1 Like
I guess it’s a reference to callback hell, meaning a whole lot of classes and ids in templates simply for the purpose of being able to address them in events.
I don’t see the problem, personally. It’s more a matter of preferences and code organisation.
I don’t have much of a problem with a lot of class selectors, as long as they are being addressed efficiently behind the scenes. Of course if you’re using a semantic css framework or custom class system, you’ll have to really start watching out for spaghetti and coordinate your class structure in a readable way.
Exactly. I find it nicer to call an event function on the actual element. If wanted it’s still possible to define the eventlisteners via id’s but it makes it easier to swap out stuff this way at least for me. But in general I really like how databinding and building components in Polymer works in general.
The basic Blaze/Spacebars API will stick around… HTML isn’t going anywhere, and will need to be pried out of the cold, dead hands of an entire generation of programmers. But the technology it’s based on… that’s totally subject to change. Sideburns is the most promising attempt to rewrite the Blaze/Spacebars API over React. That seems to be the future of Blaze, imho.
2 Likes
To be fair, Spacebars does the same thing under the covers that React does. In the end it all turns into compiled javascript that is run and inflates HTML into the DOM. Spacebars just does it in a way that some humans like more…
3 Likes
It was definitely a joke! I updated the post a long time ago to have a TLDR saying as much.
Be sure to read that for sure! ^^
1 Like