Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@stubailo
Last active July 12, 2016 06:46
Show Gist options
  • Star 12 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save stubailo/9296dbd39fad0d6bbf58 to your computer and use it in GitHub Desktop.
Save stubailo/9296dbd39fad0d6bbf58 to your computer and use it in GitHub Desktop.
Answer to Blaze question on Crater.io

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.

@vchigne
Copy link

vchigne commented Oct 20, 2015

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.

@dbackeus
Copy link

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

@mitar
Copy link

mitar commented Oct 23, 2015

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.

@TimeBandit
Copy link

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.

@zjjt
Copy link

zjjt commented Nov 26, 2015

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment