[HN Gopher] An SVG is all you need
       ___________________________________________________________________
        
       An SVG is all you need
        
       Author : sadiq
       Score  : 85 points
       Date   : 2025-12-11 19:25 UTC (3 hours ago)
        
 (HTM) web link (jon.recoil.org)
 (TXT) w3m dump (jon.recoil.org)
        
       | WorldPeas wrote:
       | all we need is keyboard input and audio output and we have (most
       | of) flash back. I may have to look into this in my idle hours
        
         | fragmede wrote:
         | JavaScript to catch keypress events and edit the SVG in situ
         | maybe?
        
         | zamadatix wrote:
         | The magic here is happening via the <script> tags, where you
         | have access to the browser APIs like you would an <canvas>
         | instead of <svg>. E.g. here's a sample I forked following the
         | mouse using <svg> with <script> inside
         | https://codepen.io/zamadatix/pen/emZXZKx?css-preprocessor=sc...
         | 
         | Libraries like three.js had SVG rendering as an option but it
         | got deprecated as <canvas> with more direct GPU APIs was a lot
         | more efficient and flexible.
        
       | sturbes wrote:
       | I just went down the same rabbit hole, it is totally fun!
       | https://turbek.com/Designing-Interactive-SVGs-with-AI/
       | 
       | TLDR:
       | 
       | - SVG image files: powerful like HTML
       | 
       | - Supported widely in browsers
       | 
       | - Designer tools make SVGs
       | 
       | - SVGs are written in a language
       | 
       | - LLMs are great at manipulating language
       | 
       | - Designers can collaborate interaction into life
        
         | psygn89 wrote:
         | I don't think LLM's are that great at manipulating SVG unless
         | you mean like small edits like rotation and font size. Cool
         | article though, I'll have to think how I can leverage it.
        
       | lucid-dev wrote:
       | This is going to really transform some data visualization things
       | I've been thinking about. I've always loved SVG since working
       | with Illustrator and Inkscape back in the day, but I didn't
       | realize how much it could tie in with the modern web and
       | interactivity. Thank you!
        
         | tetris11 wrote:
         | Surely D3 is what you're referring to
        
         | some_guy_nobel wrote:
         | SVG has been transforming web-experiences (particularly for
         | viz) for quite some time now, see:
         | 
         | - https://mlu-explain.github.io/neural-networks/
         | 
         | - https://www.nytimes.com/spotlight/graphics
         | 
         | - https://pudding.cool/
        
       | ludwigschubert wrote:
       | The first Distill publication[0] made tasteful use of minimal
       | interactivity through JavaScript/d3.js[1] on top of SVGs. Many of
       | the illustrations were initially drawn in GUI editors.
       | 
       | (Outstanding work by Shan Carter; it's what I first saw of his
       | style and it's what made me want to join his team.)
       | 
       | [0] https://distill.pub/2016/augmented-rnns/ [1]
       | https://github.com/distillpub/post--augmented-rnns/blob/mast...
        
       | WillAdams wrote:
       | Ages ago, when doing the instructions for the opensource CNC
       | Shapeoko v2 it became necessary (after the project was featured
       | w/ a full page in _Popular Mechanics_ magazine to cater to users
       | who could not visualize as well as the early adopters were able
       | to, so the diagrams were made interactive:
       | 
       | https://github.com/shapeoko/Docs/blob/gh-pages/content/tPict...
       | 
       | Used to be if that was opened in a web browser one could click on
       | the parts list to show/hide or highlight/unhighlight the matching
       | items in the diagram.
       | 
       | Done using Inkscape if memory serves.
        
         | sedatk wrote:
         | That looks cool!
        
       | martijn_himself wrote:
       | >They are supported on just about every device and platform
       | 
       | Except they aren't. I recently used a simple SVG in a background
       | and Safari wasn't able to render it properly so after trying lots
       | of different things I gave up and used different sizes of raster
       | images instead.
        
         | avsm wrote:
         | What was the SVG that didn't work? In Jon's example in the
         | original post, the SVG he embeds there was one he wrote in
         | around 2005. That's a pretty impressive run for it to render 20
         | years on...
        
         | stanac wrote:
         | SVGs also are mostly unsupported for og:image tags (dependents
         | on the app/browser). I know it's supper specific and I am not
         | even sure if open graph is standardized protocol or not, but
         | it's used everywhere.
        
           | airstrike wrote:
           | yeah, I was super disappointed to find that out when I built
           | previews for https://hexrgb.pages.dev
        
         | SoKamil wrote:
         | They are also not supported on iOS native apps. We use pdfs for
         | vectors.
        
       | tracerbulletx wrote:
       | This feels a little bit like discovering frontend software
       | development? I guess we're done with the trend of being scared of
       | bundling features and running them in the browser close to the
       | user with JavaScript.
        
       | xxmarkuski wrote:
       | I use ChatGPT to compress SVGs, in particular QR codes. Many QR
       | code SVG generators produce inefficient SVGs, and conventional
       | SVG compressors often lack the understanding required for some
       | compression techniques. ChatGPT can replace alignment indicators
       | with <use> elements.
       | 
       | Is there a way to embed the data encoded in the QR code directly
       | within the image? This would allow the data to be parsed directly
       | by the browser, eliminating the need for computer vision to
       | decode it again. Going further, for web images QR codes could be
       | efficiently encoded and rendered by the browser.
        
         | ktpsns wrote:
         | I am not sure about your use case. There exist many JS
         | libraries which will generate client side QR codes. How many of
         | them do you handle that you optimize for file size? Or is it
         | just an academic interest?
         | 
         | SVGs are XML so technically, yes, you can just embed your
         | visually encoded payload data with namespaces attributes and
         | elements. If you don't want to use namespaces, you can use off-
         | canvas texts, hidden/opacity=0 texts or even XML comments. You
         | can even use the regular metadata section of SVGs. You can make
         | the whole QR code within the SVG a clickable link.
        
         | paularmstrong wrote:
         | > I use ChatGPT to compress SVGs, in particular QR codes
         | 
         | Why? svgomg.net exists, uses far fewer resources, and is going
         | to give you much better results.
        
       | jonludlam wrote:
       | Author here: I've just made a ninja edit of the post as it didn't
       | really make clear a quite important point - the SVG is literally
       | 20 years old, and still works, astonishingly. I'm not sure much
       | else I wrote around the time would still work without _some_
       | editing!
        
         | ianbooker wrote:
         | The reverse is kind of true: In the beginning, SVGs were not
         | really an option since it lacked adoption across all major
         | browsers, or more specifically its integration was very
         | heterogenous.
         | 
         | So a SVG you authored 20 years ago for some browser will likely
         | work everywhere today.
        
       | morshu9001 wrote:
       | An SVG and JS, right? It's not interactive on its own.
        
         | avsm wrote:
         | The JS is embedded within the SVG file and not exposed outside
         | it
        
           | strickinato wrote:
           | Sort of... the SVG is referencing `svgscript.js` which is
           | being fetched from the server
           | (https://jon.recoil.org/blog/2025/12/svgscript.js)
        
       | orliesaurus wrote:
       | My day job involves building dashboards, and SVGs have been
       | invaluable for crisp icons and graphs... the portability across
       | sizes is a blessing, but some of the more exotic filter effects
       | still fail in certain browsers.
       | 
       | ALSO I've run into security reviews that flag inline SVGs because
       | they can embed scripts... would love to see more tooling to lint
       | and sanitize them before deployment.
       | 
       | BUT seeing a two-decade-old vector still render correctly gives
       | me confidence that the core spec is solid.
        
         | greazy wrote:
         | what dashboard software do you recommend?
        
         | lucgommans wrote:
         | > would love to see more tooling to lint and sanitize them
         | before deployment
         | 
         | Sanitisation is one of two possible defences, the other being
         | script execution controls or sandboxing. E.g., if you serve
         | vector images on a web server, set a Content Security Policy
         | header1 for all your images that simply denies all scripting.
         | You can also run it from a dummy domain ('origin') with nothing
         | valuable on it (like how domains such as googleusercontent.com
         | and githubusercontent.com are being used)
         | 
         | For sanitisation, DOMPurify2 is the only widely used and tested
         | library that I know of. It could use more bindings for other
         | languages but, if you can call into it, it can go in your
         | deployment pipeline. (Disclosure: I've worked with some of the
         | people at Cure53, but not on this project)
         | 
         | You can also combine the approaches for defence in depth
         | 
         | 1 https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
         | 
         | 2 https://github.com/cure53/DOMPurify
        
       | drewg123 wrote:
       | I hate that slack doesn't support svg. So we end up taking
       | screenshots of svg flame graphs when discussing things.
        
       | mogoh wrote:
       | > vector graphics in a simple XML format.
       | 
       | Simple? No. SVGs are not simple. If they were simple they weren't
       | so capable.
        
       | tanx16 wrote:
       | Here's a fun older thread on a similar topic - SVG is Turing
       | Complete:
       | 
       | https://news.ycombinator.com/item?id=20980837
        
       | _ache_ wrote:
       | I really like SVG, I did a lot of things with it and some
       | interesting ones. The only blame I have is that it is sometime
       | slow.
       | 
       | Like for QR Code, precise maps or +100 pixels wide squares. More
       | than 100 "DOM" elements and it will take multiple seconds to
       | show.
       | 
       | The animations also are slow too, compared to canvas, plain CSS
       | or Lottie but nothing very cursed, it's mostly fine.
        
       | some_guy_nobel wrote:
       | I agree with the author when they write:
       | 
       | """ In my idealistic vision of how scientific publishing should
       | work, each paper would be accompanied by a fully interactive
       | environment where the reader could explore the data, rerun the
       | experiments, tweak the parameters, and see how the results
       | changed. """
       | 
       | I do like seeing larger labs/companies releasing research full of
       | SVGs. In recent memory, I quite liked this from NVIDIA:
       | 
       | https://research.nvidia.com/labs/dbr/blog/illustrated-evo2/
        
       | nanolith wrote:
       | Around 15 years ago, I built a barbecue controller. This
       | controller had four temperature probes that could be used to
       | check the temperature of the inner cooking chamber as well as
       | various cuts of meat. It controlled servos that opened and closed
       | vents and had a custom derived PID algorithm that could infer the
       | delayed effects of oxygen to charcoal.
       | 
       | Anyway, of relevance to this thread is that the controller
       | connected to the local wireless network and provided an embedded
       | HTTP server with an SVG based web UI that would graph
       | temperatures and provided actual knobs and dials so that the
       | controller could be tweaked. SVG in the browser works nicely with
       | Javascript.
        
       ___________________________________________________________________
       (page generated 2025-12-11 23:00 UTC)