I’m the author of the Rotativa library for ASP.NET. It’s been almost 14 years since I started that project and 10 years since I launched the SaaS version: rotativa.io, and while it served its purpose for the .NET ecosystem, PDF generation has evolved (and so have the headaches).
I’ve spent the last few months building a new capability for rotativa.io that moves away from the old library pattern. I wanted to create something platform-agnostic that solves the "edit-deploy-test" cycle that makes PDF styling so slow.
The New Approach: Instead of rendering views from your web framework, you use a dedicated web editor to build Liquid templates.
The Editor: Monaco-based with autocomplete for Liquid tags and JSON data, validation, and a real-time side-by-side preview.
The Tech: It uses a modern rendering engine with deep CSS Print support (paging, headers/footers, etc.).
The Workflow: Your backend sends a JSON POST to the API; the API merges it with your stored template and returns a secure download link.
Why the change? > I wanted to decouple the design from the application code. This allows non-developers (or just you, in a different tab) to tweak a layout without a full deployment cycle.
I'd love to hear what you think about the Liquid template workflow vs. the traditional "HTML-to-PDF" library approach.
I’m the author of the Rotativa library for ASP.NET. It’s been almost 14 years since I started that project and 10 years since I launched the SaaS version: rotativa.io, and while it served its purpose for the .NET ecosystem, PDF generation has evolved (and so have the headaches).
I’ve spent the last few months building a new capability for rotativa.io that moves away from the old library pattern. I wanted to create something platform-agnostic that solves the "edit-deploy-test" cycle that makes PDF styling so slow.
The New Approach: Instead of rendering views from your web framework, you use a dedicated web editor to build Liquid templates.
The Editor: Monaco-based with autocomplete for Liquid tags and JSON data, validation, and a real-time side-by-side preview.
The Tech: It uses a modern rendering engine with deep CSS Print support (paging, headers/footers, etc.).
The Workflow: Your backend sends a JSON POST to the API; the API merges it with your stored template and returns a secure download link.
Why the change? > I wanted to decouple the design from the application code. This allows non-developers (or just you, in a different tab) to tweak a layout without a full deployment cycle.
I'd love to hear what you think about the Liquid template workflow vs. the traditional "HTML-to-PDF" library approach.
Thanks, webgio