[HN Gopher] Show HN: A JavaScript library for data visualization...
       ___________________________________________________________________
        
       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.
        
       Author : andrewcourtice
       Score  : 93 points
       Date   : 2024-04-12 03:31 UTC (19 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Solvency wrote:
       | 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?
        
         | airstrike wrote:
         | 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._
        
           | Solvency wrote:
           | i'm more curious about the future of it because he said he
           | wants to go full-time on it.
        
         | pvg wrote:
         | _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.
        
           | lazyasciiart wrote:
           | 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?"
        
             | joshribakoff wrote:
             | 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..."
        
         | graypegg wrote:
         | 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.
        
       | mrbluecoat wrote:
       | How does it compare to Apex Charts?
       | https://github.com/apexcharts/apexcharts.js/
        
         | scoot wrote:
         | 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.
        
       | WA wrote:
       | 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!
        
       | realaleris149 wrote:
       | > 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.
        
       | nextaccountic wrote:
       | 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!
        
         | andrewcourtice wrote:
         | Thanks for the tip :) I've added some screenshots to the readme
         | now.
        
       | mfkp wrote:
       | The demo needs some work on mobile phones. Doesn't even show up
       | unless I put my phone in landscape mode.
        
       | solardev wrote:
       | 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?
        
         | andrewcourtice wrote:
         | 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.
        
       | rcarmo wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-04-12 23:00 UTC)