Hacker News Reader

If I'm understanding correctly, isn't this introducing a critical dependency on JavaScript during rendering? I get that people might want to draw stuff with code, but why would people use this (and introduce render performance problems inadvertently) instead of using the HTML5 Canvas API?

View on HN

The HTML5 Canvas API can only be used in the main javascript thread, so whenever the page's javascript thread is busy with anything then the browser has to wait on that to finish before being able to have it update anything it rendered. The Paint Worklets allow the browser to run some page javascript just for rendering in one or more separate threads.

But why can the canvas still only be accessed in the main thread? Why introduce a whole other API as a workaround for this?

Also, as far as I have seen, people have been using WebAssembly for complex stuff and marshalling it to the main thread for the canvas.

The worklet API gives the browser the ability to spawn as many threads for the task as it wants when it wants, without needing to communicate and wait on the page's code in the main javascript thread each time.

It doesn’t refute your point, because a worklet is a worker and thus not in the main thread, but the canvas API is usable outside of the main thread as well, via OffscreenCanvas or something like transferring to a worker.

Reply on news.ycombinator.com