[Titou325]

Hey, Titouan part of the Onedoc team.

You are absolutely correct and most existing tools do leverage a browser (sometimes headless) to convert HTML to PDF. However, browser's CSS print specification implementation is severely lacking and layout options are poor to say the least.

There is a second option using libraries that abstract part of the layout process such as react-pdf but although it uses the JSX syntax, you can't port existing HTML components easily.

Onedoc is able to take HTML + CSS as well, quite similarly to what you can do with Resend. React is mostly an abstraction layer that allows you to take advantage of all the existing SSG toolset (e.g. charts, existing frontend components, ...) without having to write things from scratch. The process is thus indeed similar to Astro if you omit any client: directives.

We have put up a small comparison at onedoclabs.com/why-onedoc to show a bit better what capabilities this opens.

Hope this clarifies things!

[moritzwarhier]

Thanks for the detailed reply, much appreciates.

Sounds like React JSX rendering while omitting any client-side JS could benefit from forking off React itself, no?

OTOH it's up to the user of course to choose components that do not require client JS and diagnose problems caused by components relying on it.

[Titou325]

It could probably but I believe maintaining these two would probably be more work than accepting the drawbacks. Another advantage of supporting full-fledged React is that (in the near future) we can allow Javascript in the rendering engine, meaning that components can recompute themselves and pull their own data in. We will see where that goes!

[moritzwarhier]

Yes, that sounds interesting, and I sincerely hope that a future release of React manages to simplify use cases such as SSG with build-time JS.