Why isn't Blaze the new d3.js?

blaze
1

I have been using d3.js inside of Meteor for a while and it is kind of annoying because d3 is very imperative oriented, and the recomputation concept is based on explicit declaration of changes. I have to slice the d3 code between declaration and update, put the former in an onCreated block, the latter in an onRendered one after wrapping it in an autorun()

Now, as far as I can tell, Blaze can manipulate SVG and is fully reactive. In other words I can just “draw” in SVG (even just paste a professionally done image), add locations where the data can be mutated via {{value}} and then just connect it to a backend to do the computations which could be a graph layout algorithm, a force field, etc.

As far as I can tell nobody manipulates SVG in Blaze besides a couple of demos from MDG.

Is there any reason besides raw speed - which could be addressed by compiling Blaze templates into low level JavaScript instead of interpreting it ?

3 Likes
2

Blaze templates are already compiled at build time, here’s a good article on it https://meteorhacks.com/how-blaze-works . I’ve done a few toy demos with reactive SVG animations with Blaze, you’re right it is really easy but d3 is quite a beast in itself, I don’t know if they’re directly comparable

3

Blaze templates are already compiled at build time, here’s a good article on it https://meteorhacks.com/how-blaze-works .

Actually the kind of code that is output by that example is what I was calling “interpreted”.
In the example you cite, there is still a lot of code to manage the “runtime” (templates, views, etc). Those abstractions could be replaced by lower level code (a crude loop reading the data and replacing it, embedded in a function) and in some cases even factored out.

For instance when you write a “completely static” website in Meteor because templates are a great abstraction mechanism, Meteor doesn’t output a straight html page when it could.

That said, I am happy to say that Blaze is compiled into JS + “reactivity” runtime.

4

I’m currently building a casual social game in Meteor which uses D3JS quite heavily. I once found it really difficult and tedious to manipulate SVG with pure Blaze approach. If you put update in autorun, it could be very unpredictable when the App becomes more complicated. What’s worse, there’s no easy way of inter-template or inter-helper communication. Then you end up using Sessions, then ReactiveXXX stuff etc.

The community seems to be moving to React, it’s quite a shift from the traditional Meteor/Blaze way, I’m not ready for that yet.

My recommendation is to use @manuel’s ViewModel , which allows you to code at a higher level than the traditional approach. It solves my said issues and simplify things elegantly. Not to mention the much code size cut, from 1/3 to 1/2.

1 Like
5

Because D3 wound up being a whole lot more than just data driven documents… it wound up being a data visualization layer. Where are the statistics functions for blaze? The graphing functions? Color space functions? Domain algorithms? Blaze could do the work of D3… if someone wanted to spend the time putting all the supporting pieces in place.

6

I can use svg with blaze without problem. What d3js cause troubles?

7

You can still replace all the d3js functions with … d3js.

What is broken / insufficient / annoying is the reactive part. You can still use all the functions.

8

Honestly, the question you’re asking is maybe simply at the forefront of the industry. Give it a try. If you can post a working example, I know of lots of people who might be interested in such an update to D3.

Also, Mike Bostock has been receptive to Meteor in the past and added some basic Meteor support to the D3 library. This might be candidate for upstream adoption.