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.

Very well written answer, thank you for taking the time to answer my question. I completely understand the undertaking it would be for MDG to improve upon Blaze when you have Google & Facebook behind Angular & React. I'm glad you mentioned Vue.js as I believe it's author works for MDG. I have nothing but pleasant things to say about Vue, it's API is simple to learn and it can easily grow with you. Laracasts ran a fantastic (free) course on it too. Perhaps if MDG cannot see themselves investing deeply into Blaze's future then the community should be advised that alternatives x, y, z are better options for the long-term.

I'd be amiss to not mention Ractive.js - it is very similar in many ways to Spacebar's syntax, seems to be well supported and I think integration with Meteor would provide the same simple, easy to learn experience people are used to when using Blaze without placing the development burden on MDG themselves.

Would love to hear your opinions on the above, thanks.

Niall.

Rich from Ractive is one of our favorite people here at MDG; it's definitely a great library!

"Ride the wave to see native UI"? Are there plans for react native support from MDG?

Great answer @stubailo

Off-topic ish:
@elie222 It is already possible to use React Native with Meteor. I don't know if some official support is necessary, but it all depends on what is all needed to achieve a good development flow between Meteor and React Native.

I know there are some people at Differential that have worked with it - http://blog.differential.com/meteor-react-native-learning-from-experience/

On Topic:
Although I love using Blaze and prefer it over React, it makes more sense to me that MDG should focus on the other components of the platform that can have a bigger impact on the development process. It already works well with other front end frameworks and at that point, why should it be focused on more when there are bigger issues that people are hounding about like SQL support.

I would prefer that MDG spends their time on improving the rest of the platform rather than spend more time on Blaze when there are viable alternatives out there.

Thanks @stubailo for writing this answer and giving the community a sense of where we're at. As Sashko points out, it would take a lot of investment in Blaze to get it "up to snuff" with React (say) when you think about making it a competitive library in its own right. Think of developer tools; patterns for loading data and integrating with other frameworks and libraries; components; patterns for animation; server-side rendering; a road to native mobile support (like React Native, which many of us feel is the future, or part of it). I realize that with Blaze being open source software, the community can contribute many of these things, but it also requires dedicated leadership.

As the main author of Blaze, I think Blaze is great -- or it could be great, with a little more work. If I didn't work at MDG, I'd probably work on it, or maybe I would just use React, I don't know at this point. The UI framework inventor in me thinks React and Angular have made some pretty weird decisions -- and some great ones as well, of course -- but they really doubled down on them and did a lot right that we did wrong as far as encouraging adoption and community, while moving fast and breaking things when necessary.

Blaze basically did get de-prioritized at MDG, one way or another, due to a combination of factors. Two years ago, with a very small engineering team, we set out to build our own package system, and we also started some of the very early work on Galaxy. (By the way, I think the Galaxy product we've launched is amazing!) Hardening the framework for Meteor 1.0 took the whole engineering team many months of hard work. Fast forward to 2015, and Meteor users were already experimenting with React and Angular with great results, so making sure we had good integration was a no-brainer.

There's one thing here that could use more attention (this is Sashko's idea, which he will emphasize in an edit to the post): the idea of using something like React to power Blaze. They can leverage React's power as a rendering engine, while giving us the ease and familiarity of Blaze. And since Facebook is investing a lot in React, it would be practical for the long term and from a resources standpoint. I hope this happens!

Yeah I guess a lot of people don't read to the end, so I added a TL;DR to the beginning.

@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)