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:
- 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
- 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.
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:
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}}
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).Yup, this is where the community could have helped out more, but I think they/we didn't two main reasons:
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.