Blaze Components

announce
1

After seeing some discusions around the struggles novices have with certain aspects of blaze (mostly around reactivity and “style”) and having those reasons resonate with my own experiences of training junior developers, I decided to stick some of the boilerplate code we’ve found really helpful into a package: https://atmospherejs.com/znewsham/blaze-component

It wraps a template with a class and provides some helper methods:

  1. setTimeout and setInterval - for deferred functionality that should die with the component
  2. on for event listeners that can’t be bound to a template, but still need to unbind when the template is destroyed.
  3. Simplified state and fine-grained data management
  4. Consistent usage of this
  5. Extendab component functionality
  6. Testable (as it de-couples the functionality from the event handlers/helpers)

While https://github.com/peerlibrary/meteor-blaze-components is awesome, it hijacks the blaze build system, meaning you can’t easily apply it to some components and not others. Would be interested to know what you think, and if there are other functions you find you often need to implement on a per template basis.

6 Likes
2

Thanks for publishing this :raised_hands: Have you tried running Blaze Component in meteor-web-rendering-framework-benchmark to see the impact on performance compared to “vanilla” Blaze? Would be interesting to see the results.

3

I’m not entirey sure how I’d approach this, I’ll take a look though. That being said, I’d expect the performance to be very similar, ulitmately this class just wraps the helpers and events with context, BlazeComponent.register does most of this work, and its a oneoff cost. There will be a small amount of overhead (dependant on the size of the data) when using stateChanged dataChanged and reactiveData and passing in a fieldlist, this is due to the need to serialize the data for comparison.

4

It really is quite straightforward. You can follow the changes I made in this PR to include ViewModel in the benchmark and replicate the steps for Blaze Component.

5

A negligable overhead in 3 of the tests, a more significant (~20%) overhead in the others (note: blaze component, not blaze components, really wish I’d picked a different name!) - I’m not sure what’s causing this - I think it might be binding the created/rendered/destroyed methods even when no class member is defined. Created we can do nothing about as it is necessary for the constructor, but I suspect there would be reasonable improvements from detecting the absense of rendered/destroyed and skipping those bindings.

For me what was more interesting was seeing how much worse blaze is than react or vue - what are the reasons for this?

image
image1816×540 54.8 KB

6

I’d say one of the reasons is, both Vue and React have received massive amounts of improvements, optimizations, care and love. Blaze has not, at least in the same magnitude. Blaze also internally uses jQuery, which I suspect brings it’s own overhead.

However, in a real life scenario, Blaze often outperforms React in my experience (if properly used: Automagic reactivity can be a massive footgun if used carelessly). Micro benchmarks should not be your only source of truth.

Blaze apps are plenty snappy and at least our users have always been praising how fast the app feels. Some of that praise might also owe credit to the optimistic UI that Meteor and Blaze bring for free.