JQuery to React: How we rewrote the HelloSign editor
In this technical retrospective (2020), @luord shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 149 points
TOTAL DISCUSSIONS 51 comments
Except they don't, so the whole blog post should be taken with a grain of salt.
I just signed a document a few days ago (on Sept 28th). I didn't like the default font for signature they offered, so I picked some other, script type of font. Everything was fine until I saved it. And suddenly, the signature switched to some completely different serif font.
The document wasn't really that important to me, so I let it go like that, but doesn't look like something I would trust currently.
EDIT: HelloSign people are obviously reading this. Instead of down-voting me, the proper approach would be to ask for details and fix your bugs. For example, I just tried another document on Windows and it worked properly. For the problematic one, I was using Firefox on macOS, so maybe you should look into that. I can also send you the document ID hash if you ask nice.
I think it’s important to note that jquery and react aren’t really the main point in the problem or solution.
The problem is they have three things that they want to be the same but aren’t, and the solution is to rewrite so the significant parts can, in fact, be the same. React and jquery are details... that is, you can have the same problem and same solution with different details.
I also wonder if this particular approach will end up being successful for them. Can’t the editor, signer and final pdf all be rendered by different browsers and different versions of browsers? IDK, maybe it’s close enough for their cases or there is a strong filter on input that limits this to elements that render consistently enough. Or maybe this is a “must use updated Chrome” app?
Having the same implementations on all layers seems like a reasonable approach. But I don't see how the choice of the framework helps getting pixel perfect matches especially between different browsers. It seems to me rather the right implementation counts. E.g. using canvas drawing would be one approach to guarantee pixel perfect matches. Also you could do then checksumming in test cases to ensure the images are always the same.
We use HelloSign a lot, and it is unreliable. Long waits for pages to load, and sometimes it cannot process a PDF that displays just fine in a variety of viewers. It just hangs with a message to the console every so often saying "Processing document". In our end to end tests Hellosign is often the part that fails, but that will work with enough retries.
I assumed that hellosign and it's like was about cryptographic "signing" - you know here is a unicode representation of the words you are signing, a hash and ... well probably something using a phones secure enclave
I would trust that more than various pdfs ....
I assume that's just me