Answer to Blaze question on Crater.io

answer.md

Answer to Blaze question on crater.io

https://crater.io/comments/ucDz7fibgDcJqHtFu

Many of us want Blaze 2.0 and not Angular or React. Is MDG committed to continuing the development of Blaze? If so, how? Thanks!

TL;DR: I think the best thing to do is probably build Blaze 2.0 on top of the React rendering system to get a nice developer experience while taking advantage of new tech like React Native and the React component ecosystem.

Blaze is a very interesting part of the Meteor platform, from a platform point of view. Let's look at where we are now. Here are some of the benefits of Blaze:

• Blaze is super easy to develop with - you get templates that look just like normal HTML, but behave reactively
• Blaze integrates seamlessly with Tracker-enabled data sources like Minimongo, ReactiveVar, etc
• Blaze works well with external JavaScript libraries, like jQuery UI or basically anything you pull off of the internet

These are all awesome benefits to have out of a frontend framework. I personally had a super tough time becoming productive with Angular, and Blaze was much smoother. However, even after a few hours of development I discovered that Blaze has some issues as well:

• Data context instead of a more sane scoping model or control over inheritance, like Angular, React, and Vue.js have
• Difficulty in operating on higher-dimensional data because of the way #each interacts with the data context (we have somewhat improved this with the new 'each-in' and 'let' block helpers in 1.2, but it's still not ideal)
• Performance issues when too much stuff bunches up into one Tracker flush cycle (you can see this in many issues on GitHub)
• A fair amount of boilerplate to achieve encapsulated or extensible components (this can be mostly fixed by using Mitar's Blaze Components package, which is similar to what I would have built to solve these issues)

Now we've established where we are. The question is, what should we do from here? One option is to invest more in Blaze to fix the above issues - some of them are harder to fix than others, though; I haven't yet heard any great ideas for tackling performance since all of Blaze is built on top of Tracker.

However, even if we spend time investing in fixing all of the present issues and bugs with Blaze, we still aren't in an optimal place because we haven't even considered the things we could add. Let's think of some of those:

• Decoupling the refresh and render engine from the DOM, to achieve something like “Blaze Native” - given new technologies like NativeScript, React Native, and Angular 2.0's integrations with them
• Making Blaze a standalone thing so that we can expand the ecosystem of Blaze components beyond that of Meteor developers. Given that Meteor requires a buy-in into the whole data stack, the usage of a framework that is not tied to a specific data system will always be higher than one that is; so if we want Blaze to be a sustainable thing then we need to push on this angle more
• Creating build integrations or NPM packages for compiling Spacebars, the templating language

So when we consider what needs to be done with Blaze, we also need to consider the long term implications of the above points.

The question for me is - how can we get the most of the benefits above, with the least amount of work? I can't imagine a world where that answer includes building every single one of the above things from scratch here at MDG.

If you look at the points above in detail, then squint a little, and consider the resources we have available, I think you'll come to the same conclusion that I have:

1. Blaze as it exists now works for some variety of apps, and there might be small improvements and bug fixes we can make for long term support
2. If we can combine the awesome developer experience of Blaze with the ever-improving technology of Angular 2.0 or React, we'll be in a really really good spot

If we can spend time building a great developer experience, integration with Tracker/Meteor data, and a seamless build system, and just ride the wave to get native UI, a huge ecosystem of available components, improved performance, and more, I think we'll end up with something better than what we have in pretty much all respects, with much less work.

I wonder how Blaze being the core of Meteor got lost and MDG prioritised React and Angular over Blaze.

A lot of this stuff has been mentioned above, but the way I like to look at it is - what's the most important thing that Meteor brings to the table? I don't think it's the underlying rendering engine of Blaze. It's the user experience and developer tools around it, the data system, one-step deployment, mobile builds, and a single tool to combine them all. So let's focus on those.

---

Let me add a disclaimer: This is mostly my own personal opinion and analysis. Let's have some more discussion about it.

@stubailo
Something to look at:
https://github.com/timbrandin/meteor-sideburns
timbrandin/blaze-react#20 (comment)

That package has the same goal as what you are describing above.

Yep, I've seen that one. I'd love to see what they come up with! I agree that the best idea is to not stick to the current Spacebars/Blaze API and to try to achieve something better that doesn't inherit the same issues as before.

Hm, I think you should consider how adoption happens:

The issue is that for Blaze we are already somewhere in the phase of early majority. While those who are requesting React in Meteor are those who like to experiment, innovators which created packages, and then some early adopters using them.

So what is important to have in mind is that for early and late majority it is not so important that they use the latest and shiniest, but that they use something which is supported and has backing. What is currently the issue with Blaze is that MDG is not providing that backing and are openly backing off. What this means is that all early and late majority is panicking because they do not want to be forced into adopting a new technology (which is even not made), but they (we) feel unease in current vacuum. I would even claim that people are now reluctant to use Meteor at all because it is unclear what MDG stands behind. Because for majority of people it is not so important what exactly it is, just that it is something. So that we can count that in few years our work we invested into ecosystem will not go in vain.

With this line of thought I think you should consider investing resources in Blaze and keep it moving. Because there are already people who bet on MDG to be supporting it at least for few years. And it is not really a good feeling knowing that our trust was misplaced. So again, I do not think current users do require high improvements to Blaze. If somebody wants those big changes they can use React and stuff. But those who are already invested in using Blaze because of our existing codebase would really love for it to be kept supported. And there are quite some pull requests which are already prepared and would just need merging in, more or less. So such things, bug fixes, small fixes for inconsistencies, etc.

You can then in parallel develop something new, but leaving Blaze in a vacuum is really bad. It feels abandoned and with that the whole project feels abandoned (but OK, that is because of Galaxy development as well).

@mitar
I'm completely agree with you.
for most of developers keeping blaze and improving it (with more innovation we can keep and improve to best practices) is the best choice.
Most of people are using meteor for long term product support, so MDG signals and decisions could have very big impact on their business. MDG should keep them ;-)

I also love the blaze and spacebars syntax very much, and think its one of the most easy to use frontend libraries out there.

The issue of scoping bothered me for a while in blaze, but is completely gone for me since i wrote frozeman:template-var a while back. Because i now have a reactive instance specific state and can even manipulate this state from the outside (using TemplateVar.getFrom() and TemplateVar.setTo()).

Though i also noticed interface lags due to the tracker life-cycle.

I would be happy to see blaze exchanging the under-the-hood render engine for something like react, as far as its syntax stays the same (Which is far more superior to the JSX mess imho)

But hearing that Blaze's future is unclear is kind of disappointing, as i see no more clean and easy to use templating engine out there.

I hope you decide to let Blaze evolve with the rest of the platform, instead of (more or less) abandoning it.

What is awesome about Blaze it's that I can mix it with React or/and Angular. We already have many awesome packages (form packages, admin panels etc.) for blaze, so I can use React only it those places where I need reusable components. I'm afraid that moving into React as base for Blaze 2.0 would make old and very popular packages incompatible with new Blaze and you'll need to support two UI frameworks (look on Angular example) :/

Maybe Blaze isn't most important part of Meteor and MDG shouldn't have big focus on it, but you should definitely keep your eyes on it, review and accept pull requests, fix bugs and add features which are easier to implement.

TL;DR: I get the resourcing issues and the inability to get the community to push low-level Blaze-tech forward alongside MDG. Regardless, Blaze provides a pretty good balance of "done for you" vs control.

Just for posterity:

Data context instead of a more sane scoping model or control over inheritance, like Angular, React, and Vue.js have

True, but, you another option. Use template instance autoruns/subscriptions. Passing data via the data context is really only useful for #each (mentioned next) and for configuration parameters that tell a template how to behave, instead of the actual data it should be rendering itself, e.g. {{> NiftyTemplate editable=true start=currentStartDate end=currentEndDate}}

Difficulty in operating on higher-dimensional data because of the way #each interacts with the data context (we have somewhat improved this with the new 'each-in' and 'let' block helpers in 1.2, but it's still not ideal)

Sort of the same deal here, pass what you need down the line as configuration to the template below. The really cool feature that was super-short lived (e.g. was never released to the public) that could've been awesome was "lookup or helper bubbling" up the template instance hierarchy in the same way that events bubble. E.g. Inner template could call a helper on an enclosing template at any level above it. Some scope issues to work out sure, but nifty nonetheless. The inner template could adapt based on its surrounding context without the need to explicitly pass the info down via {{> Some tag=parameters}} or explicitly reference the exact path {{ ../../../up}} the data context (which you really just shouldn't do, it's brittle).

Performance issues when too much stuff bunches up into one Tracker flush cycle (you can see this in many issues on GitHub)

Yup, this is where the community could have helped out more, but I think they/we didn't two main reasons:

1. MDG isn't really fun to play PR-games with; but more importantly
2. The codebase was a constantly shifting target up until like 1.0 which gave me the sense that a) things are happening and b) they will happen without me.

A fair amount of boilerplate to achieve encapsulated or extensible components (this can be mostly fixed by using Mitar's Blaze Components package, which is similar to what I would have built to solve these issues)

Blaze is light where it needs to be since it started supporting granular instead of template-level re-renders, a bit more control over that behavior and you could tune your own system. You don't honestly need to be building large inheritance trees of "standard components" unless you are creating a long-lived mega-dashboard style app someplace like IBM which you are then going to hand off to large numbers of devs to "drop-in" over the years so they all do things the same. "Mixin"-style composition should get you where you need to for an overwhelming majority of use-cases, features and apps. Flexible behaviors instead of shortcut components (which @mitar's package does have support for).

Finally, regarding making Blaze stand-alone, yeah... you're always going to be at a disadvantage here in regards to community assistance (part of Angular/Reacts strengths) because the fact is that in general people who use Meteor do not care about other frameworks/technologies, while people using React/Angular/et. al. must care about other frameworks and technologies because those technologies are not full stack.

That said, I don't begrudge MDG focusing on React and I would like to know sooner rather than later which basket to place our eggs in (to mitar's points above). But I would also be delighted if you raised another round of funding and deciding to give Blaze some legs to stand on again, I think @dgreensp did an awesome job.

I have been running this very idea through my mind this last couple of weeks and I agree completely. I really like the results I get from using React in my project, but it seems to take me longer to develop a project in React than it did before using Blaze templates. Putting the two together should get us the best of both worlds!

Something important is how easy and natural is to make a Blaze template, and how well integrated and easy to read is a project with it. It's very easy to learn, you can build non trivial stuff pretty soon and it's very easy to find where the action is happenning. The problems you are mentioning (lags and native support) could be solved with some more work and a compilation phase.
What I'm trying to say is that Blaze is one of the main reasons why newbies and javascript coders would look at Meteor.

Thanks for the writeup stubalio, makes perfect sense to me 👍

I wrote a longer forum post on this subject. TLDR: I think people are choosing Meteor because it is an opinionated framework and if you start changing your core opinions then people do not have a reason to stick with Meteor. Blaze is great and solves many issues, maybe not all, but you should stick with it.

I just started using Meteor, would be great if MDG would give a heads up early-on concerning the future of Blaze before people like myself invest too many lines of code in it.

As a beginner myself and coming directly from a LAMP stack...ive been brought to meteor due to its full stack flexibility after hanging for 2 days with the Mean stack(which is good but headache heavy) i did the first tutorial on meteor.com, the todo app using blaze and it was a blast...We surely cant stop the web from moving onward but i think you guys should maintain blaze to some extent and facilitate our migration overtime if you wish( i am planning to learn and produce apps with meteor using blaze.plus as i hear it has some pretty good addons too like reactive,blaze/react )...Please if you can still keep it in a corner and build on top of it without loosing that catchy effect do so...otherwise it would be a great deal breaker...(Now im confused as to why i started learning it to see it deprecated some times soon)