In terms of free tools, ones like jsPDF that run client-side typically give inconsistent results. It's a better idea to use something server-side like Puppeteer, which gives more control over how it renders.
The issue is running it in prod, since using Puppeteer requires browsers to interact with. You typically end up running Puppeteer in your front end, and a bunch of Chrome browsers chewing through a separate server.
Browserless is there to provide the browsers for those free libraries to work with. Sure, you can manage them yourself, but it's a PITA.
In the spirit of open source, we want to share the process as well as the product. Here's the story of our full rewrite for v2 of Browserless, down to building our own custom libraries and routing.
Cheers, I'm glad my post resonated, although sorry to hear you're in a tough spot!
The bit in your welcome blog about local tests being unfeasible is interesting. Maybe there's a pain point around pushing untested code? Like wasting reviewers time.
Drop me a line if you want to chat it through, sounds like an interesting challenge.
It's for anyone working with browser automation, whether it's e2e testing, web scraping or AI agents.
Talks include:
> Next Gen Protocols - Looking to the Future With WebDriver BiDi
> AI-Driven Testing - Using Advanced Tools to Accelerate Development
> AI Autonomous Agents and Browser Interactions
> Web Scraping Patterns and Anti-Patterns
You can register for free to attend the live streams or to access the replays.
https://www.browserconference.com/