Hello collea
*gue,*
On Tuesday, February 24, 2015 at 11:17:44 AM UTC+1, Eric Forgy wrote:
>
> On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote:
>>
>> (and saying someone mildly antagonistic to kick off some debate, sorry).
>>
>
> Hehe. I can't resist :)
>
> One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it
>> uses canvas not SVG for it's plots which makes it way faster.
>
>
> I looked at the whole canvas vs SVG thing and went with d3 for my
> visualizations. Depending on your application, SVG can also be fast. Here
> is a nice comparison: When to Use <canvas> and when to Use SVG: The
> Scenarios
> <https://msdn.microsoft.com/en-us/library/ie/gg193983(v=vs.85).aspx#Using_Canvas_AndOr_SVG>
> .
>
> Particularly for web-based visualizations, I really want things to come
> alive, i.e. be dynamic and interactive. And as Tim was looking for, it is
> very simple to have an interaction with d3 launch some Julia code
> asynchronously.
>
> PS: TIm, if you ever have some free time to play around with javascript, I
> think you may like it. I come from 20+ years of Matlab with a bit of Java
> thrown in here and there, but have been learning javascript since August
> and love it. The old perceptions of it being slow are... well... old :)
> Even the Julia benchmark shows javascript approaching Julia speeds.
> Javascript is also fun because with little clue, you can hack something
> together easily, but the deeper you go, the more satisfying it can be.
>
> Well the point isn't that JS is still an inferior langauage or that SVG
cannot be considered a drawing API (which is true in some sense), the
problem is, you are creating a large dependency as you assume an engine
that can execute JS AND at the same time has access to a rendering engine.
Yes i agree on recent systems a browser is usually available, but even in
browser-world they come in different flavours.
