Plotly and stack.gl

[Max Goldstein]

Since it's always good to know what else is out there in the software ecosystem...

Today Plotly was open sourced. It's not the first wrapper around D3 trying to work at the chart level rather than the DOM level (see: nvd3, c3.js) but it seems to be much more mature by virtue of its closed-source roots. In particular, it has extensive documentation and compatibility with Python, R, and a few other languages commonly used for data science. It also has a WebGL backend, allowing it to do 3D scatter plots and such.

Compared with D3 and MathBox, I'd expect that Plotly provides a lot less control over the less common cases. For example, you might not be able to position arbitrary HTML or LaTeX (it seems you can use LaTeX for labels not not over points?). And of course it doesn't have the RTT pipeline so you can't make WinAmp-style visualizations.

Plotly's WebGL backend is stack.gl, which appears to be a community of many node modules that one can use. The centerpiece seems to be glslify, which I imagine serves a similar function to ShaderGraph in that it ties all the components together. It seems like even a small project would need dozens of packages. Stack.gl seems to be independent of Three.js, which MathBox2 is built on, and uses for cameras, colors, linear algebra, etc. MathBox2 provides one with the DOM to work with, and all of those primitives, data generators, and operators (not to mention the animation system). Writing GLSL by hand is permitted but not the first choice. It seems that stack.gl has no such abstraction and requires that one become very comfortable writing shaders.

I haven't heard of either Plotly or stack.gl until today, so I'd really like some clarity on how these pieces of the client-side 3D and dataviz ecosystem fit together, and why someone would pick one project over another.

[Steven Wittens]

I've looked at stack.gl, but I decided to stick to Three.js mainly because it's the more mature ecosystem and it requires less shader fu from the end-user. Stack.gl seems more suitable for experimentation and appears to favor idiomatic JS over raw performance, whereas Three.js is pretty much the opposite.

The problem with vanilla GL, be it stack.gl or Three.js, is that the OpenGL model is simply horribly obsolete, and it is incredibly tedious to do certain things. For example, drawing lines > 1px wide is unsupported on Windows, and even deprecated in official OpenGL. Meanwhile MathBox's line shader is over 300 lines and highly specialized. It's the kind of thing that's easy in theory but hard in practice. I think it's fair to say nothing quite looks like MathBox2, and that's because it's designed to generate 3D geometry in 3D space rather than just 2D geometry on a 2D image.

Jaume Sanchez has made e.g. THREE.MeshLine which lets you do something similar with vanilla Three.js. But without a specialized shader, the degenerate cases can't be handled elegantly:

https://github.com/spite/THREE.MeshLine