6 ms·
Show HN: A JavaScript library for data visualization in both SVG and Canvas
Here's a project I've been working on for a little while now. Ripl is a JS library that provides a unified API for rendering shapes on both canvas and SVG interchangeably. Over the years I've used D3 extensively to create data visualisations so I figured I'd have a go at making my own version with a slightly more modern API and stricter TypeScript support.
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.
The project is far from done and not published to NPM yet, but there are a few demos and source that you can look at in the repo.
I'm happy with how it has come along and the things I've learnt along the way, especially the math. My dream would be to one day work on this full-time and build out a full data-viz library.
- robbiejs 2y agoExcellent 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!
- Solvency 2y agothere 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?
- airstrike 2y agotbf 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.
- Solvency 2y agoi'm more curious about the future of it because he said he wants to go full-time on it.
- deleted 2y ago[deleted]
- pvg 2y agoI 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.
- lazyasciiart 2y agoConsider 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?”
- joshribakoff 2y agoIts 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…”
- pvg 2y agoConsider 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.
- lazyasciiart 2y agoWhy would I expect a reply? I think you have confused me with the earlier commenter.
- graypegg 2y agoPosting 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.
- mrbluecoat 2y agoHow does it compare to Apex Charts? https://github.com/apexcharts/apexcharts.js/ https://github.com/apexcharts/apexcharts.js/
- scoot 2y agoIt 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.
- WA 2y agoThanks 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!
- realaleris149 2y ago> DOM-like event bubbling This does sound very interesting. I started playing with https://two.js.org/ 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.
- lloydatkinson 2y agoWhat did you find challenging about it?
- nextaccountic 2y agoThe readme needs some SVGs (you can embed graphics on github's readme) edit: actually the web page too https://ripl-alpha.vercel.app/ https://ripl-alpha.vercel.app/ - if your project render things to the screen, I want to see it!
- andrewcourtice 2y agoThanks for the tip :) I've added some screenshots to the readme now.
- airstrike 2y agoCan't you make the screenshots svg themselves?
- cal85 2y agoWhat would be the benefit of that?
- deleted 2y ago[deleted]
- airstrike 2y agoDisplaying a vector image rather than an inferior raster? In truth I meant having the examples be svgs rather than screenshots of those svgs
- andrewcourtice 2y agoI've updated the readme to use vector screenshots as opposed to raster.
- mfkp 2y agoThe demo needs some work on mobile phones. Doesn't even show up unless I put my phone in landscape mode.
- deleted 2y ago[deleted]
- andrewcourtice 2y agoI'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.
- solardev 2y agoHey 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/ https://benchmarks.slaylines.io/ (from https://news.ycombinator.com/item?id=23083730 https://news.ycombinator.com/item?id=23083730) Or something like the bunnymarks for Pixi (https://www.goodboydigital.com/pixijs/bunnymark/ https://www.goodboydigital.com/pixijs/bunnymark/) and Konva (https://konvajs.org/docs/sandbox/Jumping_Bunnies.html 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 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?
- deleted 2y ago[deleted]
- andrewcourtice 2y agoHey 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.
- rcarmo 2y agoAs 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.
- andrewcourtice 2y agoIdeally 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...
- garspin 2y ago> 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.
- rcarmo 2y ago…with a headless browser, I suppose. Which is not ideal.
- oefrha 2y agoThere 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-platform/server/ 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.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- dabrez 2y agoI 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.
- alexdowad 2y agoThis 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?
- andrewcourtice 2y agoThis 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.
- alexdowad 2y agoMr. 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?