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 had such a poor experience that I briefly considered building a digital signature product because the bar appears to be pretty low between them and DocuSign.

Same experience, and it's actually quite unnerving for this to happen when you're doing something like signing equity grant letters and equally important documents where the effects of something not working won't be known for a long time.

We've found this as well. So much so that a plan is in place to move providers soon. It often just fails for no good reason at all. During testing I found that the UI completely breaks when a signature is below a certain size. I reported this, but still seems to be a problem.

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?

I'm half surprised that this isn't utilizing canvas + wasm. I know it wouldn't work for all web clients, but would really be a good way forward to shift the processing to the browser/client for many devices.

As to variations in rendering, for some things like this, there isn't that much different. A project I work on at work does similar overlays with scanned images for marking up manual verifications and creates a final composite document in a similar way (react fe, .net core be).

I've thought about this alot. I know how to protect my backend from frameworks and to make the framework/database a detail, but how do I do this for front end applications? Especially when things like React abandon the dom/web platform.

React isn't really a framework, though it's very close and a pretty flushed out DOM abstraction.

I'm not really sure what you're trying to "protect" from React in this case? It renders what you tell it to. From a component perspective, whatever the output of your component is, that's what gets rendered/updated on screen. There are a few escape hatches in place, depending on what you're trying to do though.

From TFA examples, when faced with similar issues (though not quite the same), I found directly writing SVG markup over a document background to be extremely straight forward with React.

For the most part, the problem you are describing is when you are actively trying to NOT use the tool you're using. I've been developing web based applications since the mid 90's and React is hands down the best tool I've used in that timeframe for web applications. That said, if you're mostly delivering static content, then it may not be the best fit. In those cases using something like Vue, or another option for enhancements (even jQuery-like) may be a better option.

If you're going to use React, you are best off understanding and embracing it... if you aren't, then don't use it. I don't intend to be mean, it just seems your perspective is off. It's much like asking how you use a SQL oriented database without the inconvenience of SQL or data types.

You can't avoid that when using a framework, since the main differentiation between a library and framework is inversion of control. Writing some kind of abstraction on top of the framework is a pointless endeavor since at the end of the day, all of your code will be structured in a way that adheres to the contract defined by that framework.

Databases don't dictate the structure of your entire application like a framework does, so that comparison is not useful.

From the article:

> A software engineer’s job is not to write code, it’s to solve problems, by writing code when necessary.

This is a good litmus test to detect the presence of a senior developer.

I disagree because it suggests, at least to me, not writing code. I would fully agree if it said something like: Solving problems regardless of writing code.

The user doesn’t care who wrote what code but they sure as hell care about quality of product. If you want to differentiate a developer is going to have to get their hands dirty with an original solution as the situation demands.

I think your interpretation is right but I actually agree with the idea that you should avoid writing code if it's not necessary to solve the problem.

It has nothing to do with letting the user know who wrote what code. It is all about quality of product like you say. For example, less code means less opportunity for bugs. And, using off-the-shelf solutions means more support resources will exist. Off-the-shelf solutions also let you draw on the knowledge of experts in that space rather than reinventing the wheel.

I like the quote "Anyone can build a bridge that stands. It takes an engineer to build a bridge that barely stands".

Appreciate the effort for writing it. The last section has got an important message.

  Remember what I said earlier: UI is a functional representation of state.

Hmm, in React, true. But in general case it's not true. I expect new way of (better) two way bingings to emerge.

What about two way bindings would make a difference? In most libraries it's already very easy to update the DOM based on the model and also update the same model in response to the same DOM value changing. Maybe not in one line but still easy. Talking about things like input.value etc.

I don't really see how making that particular pattern more convenient would be a radical game changer.

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.

I just wanted to say how much I like hellosign as a product, and to keep up the good work! I do wish it were included in my Dropbox subscription though. ;)

Yes, the price is quite high for just 1 template too

This is an understatement, it’s extremely high! I don’t know why HelloSign uses this business model of charging a monthly fee and severely limiting the number of templates. I assume it’s because DocuSign does as well. We use HelloSign and think a per-signature fee would make so much more sense.

> All three components—the Editor, Signer, and completed document—must display accurately

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 downvoted you because your first comment was "Hellosign is a joke." solely due to the aforementioned bug. Then you edited your comment.

You ran into a bug in some web software. It happens. Sounds like it was already fixed.

Meanwhile, the above blog post is a pretty amazing technical breakdown that is extremely detailed and well constructed. To reduce the entire company down to "a joke" because you ran into a bug once is just rude and dismissive. You might even agree because you changed your comment, although you still found a way to insult the blog post and the author.

And no, I don't work for Hellosign. I'm just a software engineer with some empathy for the hard work that has clearly gone into this. This is great knowledge sharing. Time and place.

Their job is not to make a best effort.

Their job is to provide an authoritative and trustworthy record.

This is quite serious if these documents are to be used in litigation. Generally I'm happy with best effort, but in the case of this situation where a reliable record is required, they've dropped the ball.

If you expect 100% bug free software, expect to pay literally hundreds of millions of dollars for it. It does exist but for some reason people prefer the mostly good stuff that costs $10.

What more effort can one give but best?

Maybe "best effort" is a misnomer, but it's often used to signify a general attempt without guarantee, rather than the absolute best effort possible. Like a delivery service making a "best effort" to complete delivery in 2 days, but there are no guarantees compared to the more expensive overnight service, or UDP vs TCP as far as packet guarantees.

In this case it seems they make a "best effort"(not guarantee) to offer uniform document display across browsers and OSes, which suggests they may only test the most popular browsers and OSes, and edge cases like Firefox on macOS may not get much love.

https://en.wikipedia.org/wiki/Best-effort_delivery

Just be perfect everytime.

>> To reduce the entire company down to "a joke" because you ran into a bug once is just rude and dismissive.

It depends on the software and its purpose. Signatures are very serious business. They carry with them enormous legal weight and not getting them 100% right can have massive repercussions. Therefore, it’s all about trust. So then the question becomes, if trivial bugs like this were not caught during QA, what else must have slipped through?

The 'proper approach' would presumably be to report this bug to them directly, to ensure that the right people see it, rather than assuming that downvotes are coming from the company!

> The 'proper approach' would presumably be to report this bug to them directly

That's rather presumptuous of you, as it implies your goals are more correct than anyone else's.

Perhaps next time the following would be more accurate:

> The 'proper approach' for me would presumably be to report this bug to them directly

I downvoted you because of your edit. Extremely obnoxious accusing employees of downvote brigades with no proof whatsoever.

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like.

> Please don't comment about the voting on comments.

https://news.ycombinator.com/newsguidelines.html

>Who else then?

Me.

> Also most tech people mostly turn off JS when they browse the web any way

any public stats that confirms this?

Yeah I really can't imagine that's true at all. I bet the rate of tech people turning off JS is like -- 1 in 100,000. But they _talk_ about it a lot, so it seems more like 1 in 100.

What Trump would sound like as a tech lead.

Seriously, there’s so many fake outlandish claims in this. Most tech people do not turn off JS because they know most of the web will break. They also know React projects scale really well and React is not a trendy project.

I think a lot of people here are running NoScript, more than you may realize. Yes, it breaks a ton of stuff. I give temporary whitelists to sites I actually want to run JS for and permanent whitelists are quite rare. Case in point: google only gets temporary whitelisting.

or ppl uses lynx2 also. Personally web site for informational purposes should always work on lynx2. JS is not needed for web page. Now if you are making SPA or an application on the web then that is something else.

> Why are you rewriting the browser rendering implantation in a JS engine?

Tree models.

Many developers have trouble understanding implicit relationships present in tree models. That is a cognitive barrier acting as a breaking force that eliminates any development. To solve for that frameworks provide an abstraction layer so that developers can envision the DOM more as a graph to be searched.

There are all kinds of performance penalties for superficially reinventing a technology like this, but the bigger limitation is lost creative potential. Instead of operating according to the capabilities of the language or API the developer is operating according to the limitations and most common approaches of the framework. For example templating is mostly easy. State management is ridiculously easy. But, the frameworks would have you think these are massive accomplishments requiring the titanic efforts of a super genius.

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

You're referring to Digital Signatures, as opposed to Electronic Signatures. It's an admittedly annoying/confusing distinction, but a legally-recognized one.

Oh thank you !

Gitlab and thousands of other project use Vue, it's probably more common in enterprise than React because it's progressive enhancement abilities.

Via rust, obviously.