Should you switch to Takumi?
Trial Takumi when you control the template and can check the resulting image or PDF before migration. Keep Puppeteer when your output depends on page scripts or browser layout. The README at the measured commit recommends that boundary. Our sandbox did not test a replacement workload.
Takumi's matching README documents browserless image and PDF generation from JSX, HTML, and CSS. That makes controlled templates a reasonable evaluation target, but documented capability and verified output are separate questions.
What the sandbox established
The October 9, 2026 run used commit 5e2a56c, whose full SHA is 5e2a56cb343d3dfb36b1965d341aeb71c39dbc8d. Installation succeeded in 13 seconds; the root build failed in 5 seconds and the test command failed in 9 seconds. Both failures returned exit code 1 without timing out.
The build tail reports Script "run" not found in 22 packages matching "*" after bun --filter '*' run build. It does not establish why that command failed or whether a particular rendering workload would succeed.
The test excerpts report three errors for takumi-js and failed integration tests associated with build failures for Waku SSR and TanStack Start. The Cloudflare Workers example reports a failed test file after a build error, with its test skipped. That skipped test does not establish a failed rendering assertion or a deployed Worker.
The stored aggregate tests field is null. Partial suite footers do not establish a unique, exhaustive test total, so this review does not sum them. Audit data is also null, and scan coverage is unknown.
The recorded workspace contains 2,307 files, 206,851 source lines, and 56.3 MB of repository data. Its dependency inventory is 935 packages occupying 1,746 MB. These describe the repository checkout and its dependencies, not the installation footprint of an individual consumer package.
No new execution took place for this correction. The stored run did not independently validate image appearance, multilingual rendering, PDF accessibility or archival conformance, rendering throughput, or deployment across native and WASM targets. The MrKeyoor testing methodology explains the limits of a single sandbox run; its current text does not establish which procedure version governed this October run.
What the matching README documents
The pinned README describes takumi-js for images and animations and takumi-pdf for documents. It lists JSX, HTML, and node-tree inputs, along with image, SVG, animation, and paged PDF outputs. These remain project-documented capabilities rather than outputs verified by this run.
For PDF evaluation, the documented features include selectable and searchable text, subset font embedding, repeating headers and footers, page-break controls, and tagged output. The README directs readers to conformance options and validation. Those feature descriptions do not establish that a particular document meets PDF/A or PDF/UA requirements.
The constraints affect migration directly. Remote assets must be preloaded when replacing Puppeteer or Playwright for PDFs. Multilingual text requires loaded fonts that cover the content. The matching README says Takumi supports a subset of browser CSS and rejects blur(), drop-shadow(), and backdrop-filter for PDF output.
The current repository README describes a different architecture from the pinned snapshot. This review uses the pinned README for snapshot-specific behavior and does not apply current implementation details to the recorded checkout.
Which alternative fits your template?
Satori converts HTML and CSS to SVG. Its README documents JSX input and a limited HTML and CSS subset. Keep an existing Satori pipeline when SVG meets the output requirement and its supported features cover the template. Takumi's documented PDF and animation outputs justify a trial when those outputs are needed; they do not establish a reason to replace a working SVG pipeline.
Puppeteer provides a JavaScript API to control Chrome or Firefox. Keep it for browser-dependent output, as Takumi's matching README recommends. Separate template workloads can be evaluated independently.
@react-pdf/renderer creates PDFs using React in browser and server environments. Its supplied example uses Document, Page, Text, and View. Consider it when those PDF primitives suit the document better than HTML elements and CSS. Its README demonstrates PDFViewer, while Takumi's matching migration notes state that browser viewers and some text controls have no equivalent.
What to check before migrating
Choose one real template and the package documented for its output. Supply the required fonts and assets, then compare the result with an accepted reference in the intended runtime. For images, inspect layout and text shaping. For PDFs, check page breaks, text selection, links, and the accessibility or conformance requirements that apply to the document.
For contributor setup, reproduce the root command failure and inspect complete integration logs before proposing a fix. The supplied excerpts establish failures but do not identify a safe correction.
How to read the scores
These scores are editorial judgments about the supplied evidence, not benchmark results. The rubric is: 1 means substantial documented obstacles; 2 means a limited basis for assessment; 3 means useful capability with material unresolved limits; 4 means broad supporting evidence with verification gaps; and 5 means comprehensive evidence within the stated dimension.
Setup ease is 3/5: installation succeeded, but root build and test failures leave contributor setup unresolved. Standalone consumer setup was not tested.
Documentation is 5/5 for the supplied README's breadth of output examples, runtime descriptions, migration guidance, font instructions, and explicit limitations. This assesses coverage, not successful execution or the correctness of every documented feature.
Community is 2/5 because the evidence is limited to project-reported users and integrations plus contribution guidance. Community health was not independently assessed. Named users do not establish support responsiveness, contributor activity, or independent adoption scale.
Maturity is 3/5: the documented output and migration scope supports a focused evaluation, while failed root commands and absent rendering validation leave material uncertainty. This is not a verified production-readiness assessment.