Blaze is dead of self-sufficient?


The funny thing is: React actually taught me how to setup my Blaze templates right.

Just one example I encountered today: In Blaze, templates inherit the data context of the parent template automatically. This is cool when you start building the template, since you don’t have to pass the context explicitly. But you get into trouble once you have to enhance the data context for the child template at a later point of time. In this case, you will have to change the template’s API, which will force you to change every spot where the template is being used. In the React props concept, you just can’t access the parent component’s data context (props) if it isn’t passed explicitly. And that’s just one example where React forces you to program in a modular manner.

Another sample is passing callbacks as props. In React, this is common practice, to de-couple a UI component from the business logic in a container. Since I was missing this in Blaze dearly when extending my Blaze templates, I tried to figure out how I could do it there. And you can in fact do this by defining a helper in the parent template that returns the callback functions as an object and then pass this object as a parameter to the child template. It’s a bit weird, but it works. I would have never come up with this idea if I hadn’t known the decoupling concept from React.


))) Can it be outlined in 1-2 paragraphs, perhaps with example?


Added it above before seeing your comment :slight_smile:


Even when required, spiderable or other solutions that serialize a DOM are decently acceptable in many cases, I’m hard pressed to think of cases where spiderable/DOM serialization + caching isn’t enough.


Have been playing in the last couple of weeks with Meteor Vue ( and I’m loving it. For those used to Blaze (specially if using ViewModel, but not necessarily) it is a very natural move. The React model never “fitted” naturally into my thought patterns (not straight a React problem, of course…), but with Vue, after a few hours reading the great documentation to get the basics, wow!

I cant understand why everyone is so thrilled about React… MDG should ensure that Meteor support for Vue is at least at a level-field to React.


Reading the Meteor road map today I found this at the very end of the document:

“We’ll make essential fixes to Blaze but most likely won’t be adding new features ourselves.”

It’s not prominent, but apparently it’s been there all along :wink:


I’d just like to say that this has been an outstanding thread. Given its title, it could have descended into a pit of despair, but instead pros and cons of Blaze, React, etc. have all been discussed with great professionalism.



And again, this is venture capitalism world. Why make Meteor Developer Edition plan and do long way of gathering annual USD100*10000 developers, do all the chores like billing, accounting, etc. and be obliged to balance between the different needs of developers (because they are clients now). It is better to make some newsworthy features, and hope for VC to come and grant several millions at once.

It is not meant to be an offense, it is just like observing the facts ))) We are not clients, we are fellows )))

But this does not diminish greatness of both Meteor and folks behind it.


Ha, now that you show it to me, I remember seeing it. Somehow I forgot about it


From that Meteor view layer roadmap:

Our plans around the view layer are to maintain strong integrations (along with guidance) with React, Angular and Blaze.

Would be great if it read like this instead:

Our plans around the view layer are to maintain strong integrations (along with guidance) with React, Vue, Angular and Blaze.


That would be great, since Vue has essentially been broken on Meteor since 1.7. This is the risk of anything “community” provided where the the “community” is typically just one guy, who now happens to be busy elsewhere. I do agree that if React gets a special treatment, it feels discriminating towards Vue :wink:, given the two seem to be quite equal rivals in terms of popularity.

But, having Meteor provide an integration for Blaze, React, Angular and now Vue is a slippery slope. We have tens/hundreds of frameworks already and new ones are appearing out of nowhere on a daily basis.

I’d argue MDG would be wise to craft a solution that works for any framework, in similar spirit to razzle. I have no idea how hard that problem is, though.

How far off are we? The compiler plugin for Svelte was really easy to grok, it pretty much just calls for Svelte’s compiler, transpiles with Babel and pushes the JS down the build pipeline. Then, when you take a look at the akryum:vue-component plugin, it’s quite a beast with all sorts of sorcery going on, which now have ended up breaking with the newest Meteor release.

So maybe there’s some room for abstracting that complexity away, since almost all frontend frameworks probably want those similar features from the build plugin, but the implementation is not entirely trivial, such as HMR.

That said, I have to mention, last night I got HyperApp running with Meteor v1.7.1-beta in a few minutes with routing and SSR included. All that was needed was a .babelrc file with one line of config.


I’ve debated switching to another frontend framework for a while now, but decided to hold out and see where things pan out. My feeling about the situation is we’re all fraying out into the frameworks we like best and are best for the job - not necessarily the most popular, but the ones that help us work the best. To some degree, ongoing support is important, but on the other hand, there are many key frameworks out there that continue to be used by thousands that are seldom updated. Because it already does everything it needs to do and it does it well (underscore.js comes to mind). Blaze is one of these frameworks. It’s solid and reliable. It may not be the most performant, but unless you are rendering hundreds of thousands of DOM elements, the difference is negligible in 99% of cases. And in two and a half years of using it, I have only run into one bug which I reported, and even that was minor and not functionality breaking.

If there were any other framework I’d be interested in, it would be Vue. But one of the reasons why I’ve stuck with Blaze is because it integrates so nicely with the core of Meteor. Everything just works. We are using Blaze heavily in our current code base that is over three years old. Over 36,000 lines worth just in Blaze-related code. But it’s slick and clean. We have even developed lightbox, popup, and tooltip plugins just for Blaze and they all work great. A lot of code cleanliness does have to do with the developer. We don’t have much spaghetti. And Blaze can do a lot of cool things I think most developers just don’t take advantage of.

I use the same rule for choosing a framework as I do choosing relationships. They have to add value to my life versus take from it. Doesn’t matter how pretty or popular they are. The list of workarounds needed to change frameworks makes it enough to tip the other way. And I don’t mean just in our project, but in general to get the framework to work with the same feature set I have been used to. If I was building mobile apps or using a lot of framework-based plugins, it might be different. There’s also the argument for hiring. You can find more React developers than you can Meteor. But where I live, there’s not a lot of people who know either. Meteor is much easier to learn (and by extension Blaze). So in our particular situation, the job learning that would be necessary anyway is easier to do with Blaze. I’d go further to say understanding Blaze before learning React is more advantageous because it’s a great way to learn the principles of reactive programming first without jumping into the shark tank.

We might change over one day, and it may or may not come soon. I do wish Meteor would have official Vue support. That might tip me the other way.