8 ms·
JQuery to React: How we rewrote the HelloSign editor
- veenusav 6y agoAppreciate the effort for writing it. The last section has got an important message.
- bartq 6y agoRemember 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.
- nikitaga 6y agoWhat 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.
- noodlesUK 6y agoI 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. ;)
- franckl 6y agoYes, the price is quite high for just 1 template too
- deleted 6y ago[deleted]
- bluedevil2k 6y agoThis 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.
- babuskov 6y ago> 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.
- joosters 6y agoThe '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!
- throw7332 6y agoAh, it seems you're either unfamiliar with the culture at HelloSign, or a proponent of it. With that lot, the assumption isn't much of a stretch.
- summitsummit 6y ago> 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
- babuskov 6y ago> The 'proper approach' would presumably be to report this bug to them directly, to ensure that the right people see it I do that for products where I'm a customer and I actually care about using. I got to sign that HelloSign document because one of my business partners requested it, so if anyone should report bugs, it would be them. This was my first time using HelloSign, and it left a bad first impression. I just find it amusing that they are bragging on top of HN about a product feature that doesn't even work properly. > rather than assuming that downvotes are coming from the company! Who else then?
- lifeisstillgood 6y agoI 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
- BHSPitMonkey 6y agoYou're referring to Digital Signatures, as opposed to Electronic Signatures. It's an admittedly annoying/confusing distinction, but a legally-recognized one.
- lifeisstillgood 6y agoOh thank you !
- deleted 6y ago[deleted]
- baxtr 6y agoNext up: React to Vue
- faitswulff 6y agoThen Vue to WASM
- gimboland 6y agoVia rust, obviously.
- dirtnugget 6y agoI have yet to see any enterprise grade software written in vue. I believe Vue is just kind of Angular for React developers who don't like angular (usually due to fact that it involves reading docs on RxJS and angular modules)
- manigandham 6y agoGitlab and thousands of other project use Vue, it's probably more common in enterprise than React because it's progressive enhancement abilities.
- dominicl 6y agoHaving 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.
- tchaffee 6y agoWe 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.
- notsuoh 6y agoSame 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.
- andyhmltn 6y agoWe'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.
- dyeje 6y agoI 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.
- clon 6y agoFrom 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.
- austincheney 6y agoI 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.
- shawnz 6y agoI 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.
- breck 6y agoI like the quote "Anyone can build a bridge that stands. It takes an engineer to build a bridge that barely stands".
- deleted 6y ago[deleted]
- jmull 6y agoI 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?
- vips7L 6y agoI'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.
- dntrkv 6y agoYou 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.
- tracker1 6y agoReact 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.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- duhha 6y agoReact is a complete pig. I honestly laugh when I hear people using it as their 'solution'. It's a bloated nightmare, fueled by young devs that literally know only one way to develop. It's a crutch that needs to go away and privately I hear a lot of senior devs talking about how it's just a matter of time until the whole thing implodes on itself. Seriously in 5 years the entire industry is going to shift away from this nonsense and I can't wait to see it happen. The entire front-end is a wasteland of resource consuming bloat. The tool chaining is a nightmare, the entire approach just shifts a huge ton of unnecessary baggage to the front-end. If any of these so called developers were worth their salt they'd be writing in vanilla JS, React is an even worse crutch than Jquery ever was.
- duhha 6y agoAh getting downvoted by the overpaid 'JS engineers'. Music to my karma, that means I'm right and hitting a nerve. Love it. Plus no appreciable comments as to why I'm wrong cause there is none. My point is right on the money. Typical gutless move of the classic downvoters of HN.