Yes. I think the problem is that you have to learn to author with it before you program with it, and the learning curve is actually fairly steep. OTOH the feedback is immediate and satisfying.
Personally, I've ignored SVG's built-in animation capabilities in favor of pumping DOM modifications into the scenegraph with a (requestAnimationFrame) timer. This gives you exquisite control requiring very little code.
> Yes. I think the problem is that you have to learn to author with it before you program with it, and the learning curve is actually fairly steep.
Good point.
This simple iOS app helps me play with path changes, sort of a unit-test use case for me:
It all makes sense from a technical perspective when you dig into it, but it's totally counterintuitive in surprising ways, sometimes.
What was especially annoying was that different representations of the exact same SVG would behave differently (inline-svg vs img+src vs object)
Most of drawing works fine as markup. However, animations and simple state changes are awful. CSS is much easier to use for some of those purposes.
I’d very much forgive SVG for its clunkiness, after all it’s old yet very powerful today. It’s a prime candidate for a revamp.
https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
I feel like many people use "sparkline" to mean "pretty graph." Those, frankly, lack the punch of a sparkline.
<svg class="natural-units"
width="200px" height="200px"
viewBox="-1 -1 2 2"
>
<desc>A static svg unit circle</desc>
<g transform="scale(1,-1)">
<circle class='unit-circle' r="1" fill="none" stroke-width=".001 "/>
</g>
</svg>Example adapted from: https://simpatico.io/svg.md#naturalunits
In this way you can use the intuition about the coordinate system that you built in school.
For those who don't know, there's a font called Sparks that uses glyphs to create sparklines: https://github.com/aftertheflood/sparks
Very neat idea, though! I did find this example: https://observablehq.com/@tomgp/sparks-with-live-data
For those examples to work (which they still do), the URL references to the font data in the stylesheet should ostensibly still be valid: https://tools.aftertheflood.com/sparks/styles/font-faces.css
Backing out from the CSS file (many thanks!), turns out the top-level web page is still up -- BUT the links to download the zip file font collections DONT WORK.
So you still need to scrape the CSS file to get working links to the individual fonts... (I was going to post those URLs here, but there are 84 of them. Use a command like this to scrape the CSS file:
grep -o "http[^']*" < sparks.css
However, this GitHub Pages site still hosts web pages that show some great examples and links to ObservableHQ notebooks (which also still work, hosted at observablehq.com).I just created a new issue and uploaded a zip file of their fonts to their Github: https://github.com/aftertheflood/sparks/files/12009401/AtF.S...
(Finally a justification for my font hoarding)
Datalegreya Font https://news.ycombinator.com/item?id=25832196
[1]: https://hntrends.net/api/og?word=twitter [2]: https://github.com/lovell/sharp
Though in any case if you have thousands of sparklines in cells I'd question if the display is actually useful to anyone.
Unless it is a large table of data you are presenting in which case thousands of rows has display time issues in my experience anyway. I have in mind a CSV preview on one of our support dashboards which takes a noticeable time to render when given a client import of ~8,000 rows and ~15 columns and that is not a lot more than a plain HTML table.
Of course these tools have different use cases. Handling scaling events and interactivity with Canvas is far, far more laborious.
The great thing about SVG (and to a lesser extent JPEGs) is that you can produce them anywhere, not just in a browser with a JavaScript VM.
Is that true? Isn't canvas a bitmap whereas JPEG requires decoding?
Instead of using svg files, just include them in the html, and make them simple. Each svg sparkline only needs to be two elements (the <svg> tag and one <path>), which is crazy efficient.
Canvas uses one element, instead of two, but you have to create a custom implementation of path rendering and do all that work in JavaScript instead of native browser APIs.
Canvas pulls ahead with drawing complex images where you have a single pixel buffer representing thousands of individual “shapes” because the DOM itself is optimized for interaction, not just drawing pixels, but I think that’s a different use-case from sparklines.
I don't even mention the fact that article suggests to return each SVG sparkline in a separate request.
In the end, I think it’s down to the complexity of the graph and the dimensions (in pixels, because images need memory, too).
Says who? Citation?
For context, here's the 22 lines of code it took to create a simple svg graph: https://github.com/jjcm/soci-frontend/blob/master/components...
And here's the final output: https://non.io/Animation-example
First I did the opposite of this post and used all the libraries (react, htm, and react-sparkline): https://www.val.town/v/stevekrouse.sparklineEx
Then I found a comment below that does it in vanilla js, so I ported that over to Val Town as well: https://www.val.town/v/stevekrouse.sparklineEx2
While its obviously not the solution to any and all visualizations in the browser its a remarkable addition to html and the dom. It should not really be considered a foreign format but the natural native one.
SVG can go a long way on its own or together with server side templates (as this post nicely demonstrates) but imho its pairing with js libraries such as d3 or vega is (still) out of this world in terms of the user experience they create.
[1] https://github.com/mindok/contex/blob/master/lib/chart/spark...
I didn't realize the syntax was so straightforward. It looks like you could even build the final SVG with some clever SQL queries if all you need to do is produce a time series visual (i.e. string aggregation over Path).
> One of my favourite things about creating sparklines like this is that I can create the SVGs entirely on the backend. I don’t need to worry about using a JavaScript charting library, or sending the “points” data to the frontend. The browser requests an SVG. The server returns it. Simple!
Me, I don't care where I create the SVGs. Most of my Clojure code is shared between backend and frontend (compiled and running on the JVM in the backend and compiled to JavaScript in the frontend). So I can generate SVGs wherever, it doesn't matter, the code is only written once. Or rather, it might matter, because my website uses server-side rendering, so the same thing must be generated on both sides.
I'll see myself out now.
https://news.ycombinator.com/user?id=kennytilton sure does. :D
(That's why for example Python works well on WebAssembly - it comes with its own interpreter written in portable C that compiles nicely to WebAssembly, and uses reference counting for GC instead of a fancy GC).
Since Clojure is mainly a hosted language, a more likely avenue would be one of its current platforms gaining WebAssembly support. A Wasm JVM, or Wasm GraalVM target, for example.
I've been running a massive SaaS app for the last several years. JavaScript is not a performance problem, especially after compiling using the Google Closure compiler "advanced" mode. Rendering is a performance problem: think large tables. WASM would bring me no significant advantages.
And it's often interesting to see trends or cycles emerge as people in different geographical regions wake up and log on. Some comments play much better in the US than in Asia or the EU and vice versa, and sparklines would be a good way to observe that.
https://en.wikipedia.org/wiki/Logo_%28programming_language%2...
a sparkline with 100 datapoints is very realistic. and having a couple columns in a table with 100 rows filled with these svg sparklines will have ui lag that you'll definitely feel.
sadly, svg is not a great performer in these 1k+ datapoints cases and you gotta switch to canvas.
Why do you think this is going to be a problem?
(Disc: ContEx author)