Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,480
- Баллы
- 155
A couple of days ago, we hit a real wall in one of our projects. If you’ve ever worked with client-side PDF/doc generation, you’ll know this pain 
.
With the latest Chrome update, some internal style and rendering changes came in. Sounds good for browsers… but for us?
Boom — all our client-side PDF generation went from a few seconds 
to a terrifying 10–15 minutes. The app froze, users got frustrated, and our docs feature was basically unusable.
The culprit: our trusted but aging library html2pdf.js, which relies on html2canvas to render HTML into a canvas and then stuff it into a PDF. Pretty cool stuff, but not so cool when Chrome breaks it.
Red flag reminder: Client-side doc generation was never ideal. Server-side is always the safer bet. But since the project was already built this way, we had to roll with it.
Now here’s where things got interesting:
I rolled up my sleeves, pulled down the HTML2PDF source code, and after hours of poking around, found the “hidden goblin”
— a single function where html2canvas was doing the heavy lifting. Swapped it out for Snapdom, did some param tweaking, bundled it back into Angular, and… VOILÀ 
.
With minimal changes to our existing code, docs were back to downloading in seconds. The fix took a day of focused work — way better than the wild goose chase with headless browsers.
Key Takeaways:
At the end of the day, sometimes the fastest way forward is not rewriting everything, but tweaking just the right piece in the puzzle
.
Have you ever patched a dependency yourself to save a project? Would love to hear your war stories!
Here is the code change comparion:
.With the latest Chrome update, some internal style and rendering changes came in. Sounds good for browsers… but for us?
Boom — all our client-side PDF generation went from a few seconds to a terrifying 10–15 minutes. The app froze, users got frustrated, and our docs feature was basically unusable.The culprit: our trusted but aging library html2pdf.js, which relies on html2canvas to render HTML into a canvas and then stuff it into a PDF. Pretty cool stuff, but not so cool when Chrome breaks it.
Red flag reminder: Client-side doc generation was never ideal. Server-side is always the safer bet. But since the project was already built this way, we had to roll with it.Now here’s where things got interesting:
Tried server-side generation with Puppeteer + templates — worked for simple docs
, broke for complex ones 
Dug through GitHub issues like a detective
.
Finally found a gem
: a library called Snapdom, which could step in for html2canvas.
I rolled up my sleeves, pulled down the HTML2PDF source code, and after hours of poking around, found the “hidden goblin”
— a single function where html2canvas was doing the heavy lifting. Swapped it out for Snapdom, did some param tweaking, bundled it back into Angular, and… VOILÀ . With minimal changes to our existing code, docs were back to downloading in seconds. The fix took a day of focused work — way better than the wild goose chase with headless browsers. Key Takeaways:
Always pay attention to NPM warnings
— ignoring them is like an ostrich burying its head in the sand.
Before diving headfirst into code, research 🧑
. Someone might’ve already hit (and solved) the same issue.
Temporary fixes are fine — they buy you time to work on the real, long-term solution.
At the end of the day, sometimes the fastest way forward is not rewriting everything, but tweaking just the right piece in the puzzle
. Have you ever patched a dependency yourself to save a project? Would love to hear your war stories!Here is the code change comparion: