Show HN: A JavaScript library for data visualization in both SVG and Canvas

The readme needs some SVGs (you can embed graphics on github's readme)

edit: actually the web page too https://ripl-alpha.vercel.app/ - if your project render things to the screen, I want to see it!

Thanks for the tip :) I've added some screenshots to the readme now.

Can't you make the screenshots svg themselves?

What would be the benefit of that?

Displaying a vector image rather than an inferior raster? In truth I meant having the examples be svgs rather than screenshots of those svgs

I've updated the readme to use vector screenshots as opposed to raster.

> DOM-like event bubbling

This does sound very interesting. I started playing with https://two.js.org/ for a browser game but the event system proved a challange. The typescript focus also looks promising. Will give it a try.

What did you find challenging about it?

Hey there,

If a focus is on performance, would you consider doing a side-by-side with other similar libs?

This benchmark was posted on HN a few years back, for example: https://benchmarks.slaylines.io/ (from https://news.ycombinator.com/item?id=23083730)

Or something like the bunnymarks for Pixi (https://www.goodboydigital.com/pixijs/bunnymark/) and Konva (https://konvajs.org/docs/sandbox/Jumping_Bunnies.html)

Your charts examples are kinda hard to compare with because the animations are so slow (not the fault of the lib, they're just slowly drawn to show the animations, I know, but it makes comparisons difficult.)

----------

In general, your lib reminds me a lot of Konva. I found their examples page to be really helpful in illustrating higher-level usage: https://konvajs.org/docs/sandbox/index.html

Maybe real-world use cases like that could be helpful for yours too? As it is, the readme doesn't make it super clear why it's preferable to any of the other existing libs yet. There are already so many, each with strengths and weaknesses... what sets yours apart?

For example, I don't know why "rendering to both Canvas and SVG" is a selling point in particular. Are there platform-specific reasons (native?) to prefer one over the other, as opposed to whatever a particular lib's implementation might be? Is there a use case where mixing and matching the two might be helpful?

Hey there :)

Sure, once the project is a bit more mature I'd be happy to do performance comparisons.

Ripl does share quite a few similarities with other rendering libraries like Konva and Two.JS. I suppose the main difference between Ripl and the aforementioned libraries is that Ripl is more focused towards data visualization as opposed to generalised shape rendering. Hence why there are features like scales and data joins.

That being said I wouldn't expect anyone to pick Ripl over other more mature libraries. In fact I would strongly caution against it. To be honest I wrote it because I moved from being in a engineering-focused role to a people management role at work and I wanted to keep my skillset sharp :) The primary reason I posted it publicly is to gauge whether others would find it useful so that I can determine how much time/effort I should dedicate towards it.

As for a use-case for rendering to both SVG and Canvas - here's one that I have had to overcome in my current work role: suppose you have a product that can view reports both in the browser and also render on the server (in PDF or similar). In the browser, you would ideally want canvas as it produces less DOM elements and remains performant for lots of elements. On the server you may want SVGs to produce higher fidelity images to embed for print.

Another use-case would be to interchangeably render charts to different contexts based on the size of the dataset as canvas is more suited to larger datasets but is lower fidelity.

Thanks for sharing. Code (especially core) with zero third-party dependencies is a refreshing sight. I have a custom canvas renderer for a project with zero animations so far and will take inspiration to implement some from your project. Looks pretty clean code-wise!

This is interesting to me. The first question which comes to my mind is: As a D3 user, is this something which I might prefer to D3, at least in some contexts? If so, when might it be preferable to D3?

That's obviously a controversial question, and I can understand that the OP might want to avoid it, but realistically that is what potential users will want to know.

Anyone here who knows both D3 and Ripl and is willing to dip their toes into controversy?

This is a great question.

At this point in the project my recommendation is to NOT pick Ripl over any other more mature library of similar feature-set, especially D3, Two.JS, Konva etc. These libraries, in particular D3, are written by very clever people and have been battle tested for all sorts of use-cases. Although the end goal is for Ripl to have feature/stability parity with a lot of these other libraries, at this point I can only recommend it for hobby projects or curiosity.

Mr. Courtice, your cautious and restrained assessment of the value of your own work is appreciated. I applaud your humility and like to think that I would take a similar approach in your position.

However, you have not really answered the big question which others who are interested in your work would like to understand. To mix metaphors, you are dancing around the elephant in the room.

You are welcome to keep dancing around that elephant if you wish. If you are ready to stop dancing, then:

In what ways, if any, do you aspire for Ripl to achieve (objective or subjective) superiority over other libraries "of similar feature-set"? Is it intended to offer better performance? An API which some users might prefer? A smaller deliverable code size? An implementation which is easier to understand? Or something else?

You stated that your goal is to achieve "feature/stability parity", but is that really it? Or is there something else?

I am such a university kid because when you said canvas I thought you made something that I could use with the canvas API. It is a Learning Management System.

Excellent work!

Like you said, there exists many chart libs out there already... Hope you find a way to sell and keep working on your product!

The demo needs some work on mobile phones. Doesn't even show up unless I put my phone in landscape mode.

I'm in the process of moving the sidebar in the docs examples to the top so it can render properly in portrait on mobile. Should be fixed in the near future.

How does it compare to Apex Charts? https://github.com/apexcharts/apexcharts.js/

It doesn't – they're completely different things. Ripl isn't a charting library, as is apparent from its description. The charts examples are just that - examples of using Ripl.

As much as I appreciate this (sakes me the time of doing mind-bending D3, etc.), I would very much rather have an off-screen renderer that could generate SVGs server-side.

Somehow we’ve almost completely lost the art of offscreen rendering, which is so much more useful for things like mail, documents, etc.

Ideally in the future Ripl could support features like server-rendered SVGs and Offscreen Canvas. I already have a plan on how to go about tackling these two, I just sadly don't have the time...

> mind-bending D3

That's something that bugs me too. D3 is pretty amazing but is only accessible to coders.

> we’ve almost completely lost the art of offscreen rendering

markdown2.com is something I'm working on to address that. It lets you design markdown documents containing charts & diagrams, and then Save As HTML/PDF or SVG/JPG. There's also an API for generating them in bulk.

…with a headless browser, I suppose. Which is not ideal.

There are plenty of options to render SVG serverside, no idea why you think “we’ve almost completely lost the art”. For instance, with Apache Echarts: https://apache.github.io/echarts-handbook/en/how-to/cross-pl... Plus you can always use browser automation like playwright, though that’s more resource heavy.

there are quite literally at least 20 JavaScript data visualization libraries, many with years of maturity. Are there any particular reasons I should stake my personal usage on your library going forward over any of the others besides the "modern API"?

you mentioned you wish you could go full-time on this… How do you foresee this becoming competitive or differentiated from all of the others?

tbf OP said

> I am aware there are already libraries that can draw to multiple contexts interchangeably, but I've added a few little niceties to Ripl that (as far as I know) some other libraries don't have such as CSS-like query selectors, DOM-like event bubbling, and keyframe animation support.

i'm more curious about the future of it because he said he wants to go full-time on it.

I should stake my personal usage

Nobody is asking you to do that, you can assess that for yourself if you're interested in looking at the project, if not, there's not much point subjecting the author to this sort of interrogation.

Consider it rephrased in a way that doesn’t upset you, like “what do you think the advantages of your new library are that outweigh the years of development behind existing libraries?”

Its not (just) the phrasing, its that you’re asking a loaded question the author already addressed in the OP. Your question is loaded because it presumes years of development means anything, and the author already wrote in the OP “im aware there are other libraries, but…”

Consider it rephrased in a way that doesn’t upset you

Consider not projecting emotional states on people you expect to reply to you.

“what do you think the advantages of your new library are that outweigh the years of development behind existing libraries?”

Like the sibling comment says, that's an obviously loaded question. But more importantly - Show HN is for all kinds of projects - from polished commercial offerings to learning projects or scratch-an-itch projects in their early stages of development. It doesn't make sense (nor is it particularly respectful of the author or inviting to new authors) to treat the posts of personal projects like a sales call and present them a list of generic, reflexive checkmarks and requirements questions. A Show HN of that sort is an invitation to take a look at something, provide feedback, chitchat with the developer if you have an interest in the particular topic. If fully-baked things are more your speed, you can just find a Show HN that showhns that.

Why would I expect a reply? I think you have confused me with the earlier commenter.

Cause you're asking me to consider something? Plus it's a forum. So I considered it and also asked you not to be a presumptuous jerk (intentionally or otherwise). That's all.

Posting a "Show HN" takes a lot of guts. It's not a product a company is pitching to you, it's something cool that someone made and wants to show.