This is cool! One use case is generating a Mermaid diagram as an image. For example, you can use the following HTML[^1]:

  <!doctype html>
  <html lang="en">
    <body>
      <pre class="mermaid">
    graph LR
        A --- B
        B-->C[fa:fa-ban forbidden]
        B-->D(fa:fa-spinner);
      </pre>
      <script type="module">
        import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs';
      </script>
    </body>
  </html>

Then html2png.dev will serve you:

  https://html2png.dev/api/blob/oTVGhhCc6rDZYQFDIE3EGkcKs-KO6J9-_DHs-jO2OJc-d23fb4f2.png

[^1]: https://mermaid.js.org/config/usage.html#simple-full-example

▲ JimDabell 6 hours ago | parent [-]

Why wouldn’t you just use Mermaid to generate the PNG directly?

▲

Garlef 5 hours ago | parent [-]

One reason I could think of: Fewer dependencies that need integration

▲

JimDabell 4 hours ago | parent [-]

By introducing a dependency on a third-party service with no SLA? This seems to make the dependency situation worse.

	▲	mcny 24 minutes ago \| parent [-]
		Ah haha. I love this conversation of trying to find a product market fit in public. What if the input to the JavaScript (mermaid in this case) is not trusted to run on the end client machines but by running untrusted input on a sandbox (this service, or self hosted idk) is somehow acceptable and the output a blob of an image is acceptable to display on the actual client machines. Takes the planets to align just right and need us to squint just enough but I think we can find something if we look hard enough. But then mermaid can simply output PNG so you could run it as a worker... Thinking...