Why is this only .nim files? Is this actually related to https://plotly.com/ in any way?

[mavavilj]

Is this actually related to https://plotly.com/ in any way?

I am confused because I only see .nim files.

[Vindaar]

The Nim library part of this only generates the JSON required to draw a plot with plotly.js. That part is this file here:

https://github.com/SciNim/nim-plotly/blob/master/src/plotly/api.nim

When viewing such a plot, for example with show, an HTML file is generated, which includes a <script> tag that loads the JS library. This is done here:

https://github.com/SciNim/nim-plotly/blob/master/src/plotly/tmpl_html.nim#L26

So yes, this library is related to the actual plotly. We're just not in any way an "official" plotly binding.

Does this clear up the confusion?

[mavavilj]

This is not specifically for the javascript nim target (but the javascript target is supported!).

Will this have some more native-ish performance then?

[Vindaar]

This is not specifically for the javascript nim target (but the javascript target is supported!).

Will this have some more native-ish performance then?

https://cpplot.readthedocs.io/en/latest/about.html

Sorry, can you clarify what you're asking / what the link is supposed to tell me?

The performance of this library is essentially the performance of plotly.js.

Generating the JSON is usually not the bottleneck. Yeah, Nim's stdlib JSON module isn't the fastest around, but compared to everything else it literally doesn't matter. Opening a browser and displaying the plot is much more expensive.

The note about Nim's C/C++ backends vs. the JS backend is only in the README to explain that the library was written with the C/C++ backend in mind. It can be used using the JS backend as well though, which gives you the benefit that you can natively call plotly.js API functions and e.g. update the plot in realtime etc.

Not sure if this answers any of your questions though..

[mavavilj]

I'm not sure why people want to use JavaScript for native plotting. Isn't it supposed to be slow as JS?

Or perhaps this was meant to be used for the JS use cases of Nim?

[Vindaar]

I'm not sure why people want to use JavaScript for native plotting. Isn't it supposed to be slow as JS?

I'm sorry I don't understand what you're saying. Of course if you use the JS backend both the JSON generation as well as plotly.js is "as slow as JS".

No one uses plotly because they want fast plots. Use something like ggplotnim in case it's important to generate many plots relatively quickly.

[mavavilj]

I think my main confusion is because this is listed under:

https://github.com/SciNim

Suggesting that it should be a fast library.

[Clonkk]

Suggesting that it should be a fast library.

It's a plotting library which is used in scientific applications all the time.

Scientific computing isn't only about having fast library otherwise nobody would use Python.

[mavavilj]

Yes, but since Nim is in syntax like it, then wouldn't it make more sense to also use the native performance in Nim?

Or maybe this complements ggplot2? Not really sure, since it's not discussed in the documentation.

[Vindaar]

Not sure when our marketing department ever said every library under the SciNim org is "fast". 😎

Or maybe this complements ggplot2? Not really sure, since it's not discussed in the documentation.

ggplot2? ggplotnim?
nim-plotly and ggplotnim are simply two different plotting libraries with different goals and tradeoffs.

[Clonkk]

Yes, but since Nim is in syntax like it, then wouldn't it make more sense to also use the native performance in Nim?

This library, as Vindaar already explained, generated a JSON compatible with plotly.js.

The Json is generated using Nim C/C++ backend with "native performance" but it's only the json generation and not the actual plot (which isn't the bottleneck anyway so optimizing it would be pointless)

The plot is then displayed in a browser by calling plotly.js with the generated json as input.

If you want an os native plotting library, you be interested in using ggplotnim.

That said, I've never encountered a case where a plot was part of the optimization path. So really as long as plotting time is within reasonable bounds worrying about it is useless