Like the idea, but would love more information about the difference to performing the following steps:

- use a React SSG, obviously without client-side code

- use an existing "print to PDF" engine to render the resulting HTML+CSS

At first glance, this seems to be using JSX only. Ain't it possible to use JSX and fully static components without even using React? Is that what Astro is doing?

I'm a bit underinformed here, but it would be nice if the landing page would outline a bit more clearly what parts of React are used here and how (it also mentions fetching data dynamically to feed the components).

The PDFs hopefully don't contain JS interactivity and the data fetching is done at the top level of the component tree, before rendering the result to HTML (or does this skip HTML+CSS as an intermediate completely?), right?

The landing page looks great, would just love some more thorough explanation on what parts of React this uses and how.

Also, is there a JSX-based SSG that completely excludes client-side JS and is not made by Facebook? Would be interesting.

All that being said, it's truly interesting how much appeal JSX still has as a templating language focusing on JSON-serializable data structures, completely ignoring React's original value proposition of reactivity.

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!

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.

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!

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.

What are you using to generate the PDFs? Are you doing something like PrinceXML (or weasyprint) which directly convert HTML+CSS to PDF? Or are you converting HTML+CSS to something else?

Are there any demo pages where it is possible to view the generated PDFs? I would imagine this would be easier to do since this is all based on Javascript.

Good question !

For the generation we have an API that you can use npm @onedoc/client which allows you to do unlimited rendering with watermark, and some without the watermark to a certain limit. But you are also free to use any other software or API allowing this (PrinceXML is one of them. In our case we directly convert the bundle HTML/CSS to PDF and have 100% accuracy over the layout conversion (compare to chrome solution for example) as the open-source library react-print-pdf has been design to do that.

About the demo page, 2 choices if you use Onedoc API. 1. you can render your PDF and write it directly in you local machine --> so you can open it on your editor (VScode or whatever) and have side by side the code and the preview 2. you can render the PDF and host it on our cloud platform. You'll get a link to share it with others and you will also be able to preview it directly from our webapp.

Here is some links: API: https://www.npmjs.com/package/@onedoc/client Onedoc App: https://app.onedoclabs.com/login Documentation: 1) react-print-pdf https://react.onedoclabs.com/introduction 2) onedoc API: https://docs.onedoclabs.com/introduction

I hope it helps. let me know

Thanks - that helps!

We are using a wrapper around PrinceXML until we can move into a separate rendering engine. We want to be able to offer the same layout features of such an engine, hopefully much faster.

You can have a look at our (WIP) set of templates at https://react.onedoclabs.com/ui/templates where the images are automatically built from the PDFs themselves.

We are trying things out to see how we can make a live preview for development purposes but the challenges of pagination are quite hard to solve in an elegant way at the moment. We are experimenting with Taffy to see how it could fit our use case but this is still a very early tentative.

Thanks for your answer! I imagined you would be using PrinceXML behind the scenes since that is probably the gold standard in HTML+CSS rendering.

The only open source alternative I know of is WeasyPrint at https://weasyprint.org/. I'm not sure how well it fares against PrinceXML, though.

And thanks for the pointer to Taffy - I didn't know it before!