101–110 of 171 posts
One thought regarding footnotes. I often find myself searching in the reverse direction, i.e. I have a footnote, where is the superscript to which it belongs?. This is quite difficult to do by eye, so perhaps some goto reference type functionality could be useful in this case.
If you want people to use it on the web: do not under any circumstances use the pure-canvas approach. You must use real DOM, or it will be an endless frustration that turns many people away. I’ve written about the problems quite a few times, look through https://hn.algolia.com/?type=comment&query=chrismorgan+pure+... if you’re interested. If you’re not intending it to be used via the web, don’t worry. But it’s a gene…
> "Finally got sick of diffing contracts in Word and emailing PDFs back and forth" this is the actual iceberg. forget ai clause generators and buzzwords, 99 percent of the pain is version chaos. localfirst editor is cool and imagine pairing that with proper gitstyle branching across teams. redlines you can merge without manually eyeball.
Word has offered redline merging for over several decades... There's a reason it's still the standard in the legal industry. The funny thing is that Word has tons of functionality that techies aren't aware of because they don't actually use it so they keep building products around features Word has had for years. And then they wonder why their startup failed to get any traction.
Spent 15 seconds waiting for the spinner to resolve before I gave up.
Apologies for that. I thing the pipe is getting hugged a bit here. Unfortunately it's a bit lean so no GCP outages to blame it on!
Earlier quoted context omitted.
> but it requires shipping an entire web browser That’s a moot point and completely irrelevant for 99.99% people.
Perhaps that is an accurate percentage, but lawyers are in that .01%. If you're competing with Microsoft Word on performance you'd better be stupid fast and lightweight. Transactional lawyers routinely have dozens of Word documents and PDFs open at a time. Not long-term viable with something like Electron.
Earlier quoted context omitted.
Apologies for that. I thing the pipe is getting hugged a bit here. Unfortunately it's a bit lean so no GCP outages to blame it on!
I too waited for the preview to load, but looking in the browser console I saw a file was in 404 ( /static/tritium-c69b2fe84b82a0da.js ) (so it silently failed as soon as "import init, * as bindings from '/static/tritium-c69b2fe84b82a0da.js';")
Earlier quoted context omitted.
Perhaps that is an accurate percentage, but lawyers are in that .01%. If you're competing with Microsoft Word on performance you'd better be stupid fast and lightweight. Transactional lawyers routinely have dozens of Word documents and PDFs open at a time. Not long-term viable with something like Electron.
Isn't word really slow and also implemented as a web browser currently?
I can't speak to the future, but let's say I hope so!
If you want people to use it on the web: do not under any circumstances use the pure-canvas approach. You must use real DOM, or it will be an endless frustration that turns many people away. I’ve written about the problems quite a few times, look through https://hn.algolia.com/?type=comment&query=chrismorgan+pure+... if you’re interested. If you’re not intending it to be used via the web, don’t worry. But it’s a gene…
It’s a great point. This uses the canvas element only because it’s rendering in the browser. But this is really a desktop application, so the canvas element doesn't come up as a concept outside of WASM. Your main contention seems to be that nobody other than web browser implementers can render and edit text, and thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’…
Yes, if you want to run in the web browser, use the APIs the browser gives you. If you want to go wild, run directly on desktop OSes.
Web browsers just straight up don't have some of the APIs you will need for a working app. Accessibility is a major example. If you want to stay compliant with legislation (probably something to care about when selling to lawyers), you'll end up poorly re-implementing an inferrior version of your GUI framework as a DOM tree for accessibility.
Sometimes your use case is just so uncommon and esoteric that's genuinely what you need to do (see Google Docs), but keep in mind that it requires Google-like levels of engineering investments to do it at least somewhat well.
I bet this is a WASM limitation, I work with WASM and with Rust every day (though sadly not related lol), so I know the pain to some extent. Just please but a banner at the top saying "This preview has limited performance and responsiveness. The native app doesn't have these limitations and can be downloaded here: ", or similar (assuming you are aware of serious performance limitations in the browser. If not, and if your native app performs the same, please use profilers to figure out whats wrong).