3 ms·
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 doe
by piker 1y ago
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’s shaping and layout engines.
There are issues solved by the DOM for sure, but it requires shipping an entire web browser, and this product is a dedicated word processor. I’d rather face those issues head-on than defer to someone else’s implementation of such a core aspect. I know IME is broken, and Tritium’s really only able to address the needs of the happy path at the moment, but if can do that well, then there’s a business model to fund solving the edge cases to bring a real Word competitor to the desktop for lawyers.
- wiseowise 1y ago> but it requires shipping an entire web browser That’s a moot point and completely irrelevant for 99.99% people.
- piker 1y agoPerhaps 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.
- lionkor 1y agoIsn't word really slow and also implemented as a web browser currently?
- cAtte_ 1y agoVS Code, the aforementioned very performant Electron-based IDE, would like to differ
- piker 1y agoI'm not sure I agree it's "very performant", but nonetheless I do love it. (Compare it to Zed, for example.) In any event, VS code is only required to render text in a single font, with very few layout concerns, styling, run-level formatting, etc. that require re-flowing across multiple of pages, etc. And each of those is text files measuring in the bytes. Tritium, by contrast, has to hold and operate on PDFs and Word documents each with very complicated layout and rendering logic and measuring in the kbs.
- cosmic_cheese 1y agoVS Code is very much a special case and not the least bit representative of the typical Electron app. It benefits from having some of the best talent available working on it and has multiple bits that drop down to lower-level solutions to improve performance, both of which Microsoft is willing to pay for because VS Code entrenches them in the software development world in ways it wouldn’t be otherwise.
- wiseowise 1y ago> has multiple bits that drop down to lower-level solutions to improve performance Such as? > VS Code is very much a special case and not the least bit representative of the typical Electron app. And Obsidian, and Discord, and Logseq, and Notion, and Figma, and Slack, and Postman, and Insomnia, and so on, and so. Oh wait, so it's not only VS Code?
- cosmic_cheese 1y ago> Such as? At minimum it uses ripgrep for file searching, which is written in Rust but I thought I read blog posts about other parts in the past. > And Obsidian, and Discord, and Logseq, and Notion, and Figma, and Slack, and Postman, and Insomnia, and so on, and so. Out of the mentions in that list I’ve used, only Obsidian feels comparatively responsive to VS Code. Notion and Slack in particular are slow and can get super bogged down. Discord and Figma sit somewhere in between.
- fl0id 1y agoWord has the worst performance ever. So I don't think competing with Word on performance should be hard.
- trinix912 1y agoNot necessarily. You can have dozens of Word instances open and it still doesn't bog the system down nearly as much as 5 Notions with the Chromium renderer. Word might not seem fast, but it's lightweight enough to work on the crappiest PCs you (or the IT dept) can find.
- miki123211 1y ago> thus we should be limited to the set of applications that can run on the DOM and leverage the web browser’s shaping and layout engines. 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.
- piker 1y agoVery true! That's why this is just a "web preview". It's not intended to be used as the primary application. As mentioned elsewhere, the primary application is a desktop application that does look to leverage native APIs that aren't available on the web.
- rapnie 1y agoBuild it on Makepad, who are building the UI framework (blew me away first time I saw it in action). Leaves you to build the app. https://makepad.nl https://makepad.nl https://github.com/makepad/makepad https://github.com/makepad/makepad
- chrismorgan 1y agoMakepad is pure-canvas. It’s similarly entirely unsuitable on the web, and probably still not yet great on desktop, though it’s heading in the right direction.
- gwbas1c 1y agoI for one appreciate the "no html" approach. That being said, if this is truly a desktop application, why waste time making it run in a browser? If the point is to have a preview, put the time into making some good short videos that can go into a preview page.
- piker 1y agoBecause it's cool to get your hands on something before diving in. Also it allows users in walled off corporate environments to preview it without having to jump through thousands of hours of infosec hurdles.
- connicpu 1y agoConsidering it's just the desktop application being rendered to a canvas, I imagine not a ton of effort even needed to be put in and the UI framework is handling most of it.
- cryptonector 1y ago> Your main contention seems to be that nobody other than web browser implementers can render and edit text, I took it as a claim that using the canvas you can't implement _inputs_ correctly. The example given was about compose sequences, but I'm sure there's much more to it.
- hitekker 1y agoYeah the GP’s reply was a little misleading/ambiguous. It begins by saying “great point” but then it distorts & argues against that point. Better just to disagree directly, I think.
- cryptonector 1y agoMaybe u/piker misunderstood u/chrismorgan's point.