Comment by chrismorgan

Comment by chrismorgan 4 days ago

33 replies

View on Hacker News

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 general principle: the more you are implementing from scratch, the more of a mess you’re likely to be in. As one example, at IME is completely broken, completely preventing a lot of non-English usage. Even my Compose key is broken: the key sequence `Compose - >` should produce →, but instead produces “Compose->”. This is the first time I’ve seen the Compose key turn into the word “Compose”!

For serious desktop-style applications, I honestly recommend that you not use plain-Rust GUI just yet. It is definitely steadily getting there, and I’m very optimistic that there will be at least two reasonable choices available within three years, but it’s still not where I’d want it to be for an app like this yet. Web browsers are, unfortunately, typically the pragmatic choice, even for desktop-only apps.

piker 4 days 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.

Reply View 24 replies
  • miki123211 3 days 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.

    Reply View 1 reply
    • piker 3 days ago

      Very 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.

      Reply View 0 replies
  • cryptonector 3 days 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.

    Reply View 2 replies
    • hitekker 3 days ago

      Yeah 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.

      Reply View 1 reply
  • rapnie 3 days ago

    Build 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://github.com/makepad/makepad

    Reply View 1 reply
    • chrismorgan 3 days ago

      Makepad 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.

      Reply View 0 replies
  • gwbas1c 3 days ago

    I 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.

    Reply View 2 replies
    • piker 3 days ago

      Because 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.

      Reply View 0 replies
    • connicpu 3 days ago

      Considering 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.

      Reply View 0 replies
  • wiseowise 4 days ago

    > but it requires shipping an entire web browser

    That’s a moot point and completely irrelevant for 99.99% people.

    Reply View 13 replies
    • piker 4 days ago

      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.

      Reply View 12 replies
      • fl0id 3 days ago

        Word has the worst performance ever. So I don't think competing with Word on performance should be hard.

        Reply View 1 reply
        • trinix912 3 days ago

          Not 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.

          Reply View 0 replies
      • lionkor 3 days ago

        Isn't word really slow and also implemented as a web browser currently?

        Reply View 2 replies
      • cAtte_ 3 days ago

        VS Code, the aforementioned very performant Electron-based IDE, would like to differ

        Reply View 6 replies
ModernMech 3 days ago

The way this app is architected with Rust and egui, they can write code once and deploy a GPU accelerated app across all major operating systems and the browser, without having to ship a web browser with their application. That's a strong draw for developers. I think it's important to ship products like this, even if some users are frustrated, because that frustration will breed innovation. Since they said it's meant to be desktop only, I think what they're doing is fine, as the web is just an added bonus.

The approach they've taken can create frustration, but it can also be seamless for users and create joy. For instance, I got to try out their app without any setup on my part, and then I can download it and it works exactly the same on my Windows and my Mac machines, because it's the same codebase for all three platforms. That kind of story was the holy grail of UI tooling for many years, and I think we should keep going down that path to improve it, despite frustrations along the way.

Reply View 0 replies
z3t4 4 days ago

You do get a lot for free with the DOM, but it's messy, works differently between different browser and you have to constantly fight it. With your own rendering engine it's more work but you have much more freedom and can get better performance.

Reply View 3 replies
  • panzi 3 days ago

    With DOM you get accessibility integration. At least in the EU if you provide a web service you have to be accessible, otherwise you can get sued.

    Reply View 2 replies
    • z3t4 3 days ago

      IANAL,afaik the accessibility law is only for government monopoly services. But I don't think it matters, because if you use the DOM you still need to test if the app works in screen readers etc, even normal websites have trouble with accessibility.

      Reply View 1 reply
      • panzi 3 days ago

        AFAIK it applies to everyone. But you don't get automatically fined, someone has to sue first. Maybe there has to be a business relation between the user and the web site? And yes, with HTML you need to still use all the right tags and attributes to make it accessible. Firefox has a nice accessibility tree view in its dev tools that you can use for debugging. Is there something like that for this toolkit? Is it somehow exposing an accessibility tree? Replicating everything in DOM for accessibility?

        Reply View 0 replies
a_e_k 3 days ago

This is explicitly called out in the canvas spec's best practices section with a laundry list of things you'd have to re-implement [1].

> Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:

> [...]

> This is a huge amount of work, and authors are most strongly encouraged to avoid doing any of it by instead using the input element, the textarea element, or the contenteditable attribute.

[1] https://html.spec.whatwg.org/multipage/canvas.html#best-prac...

Reply View 0 replies
eviks 3 days ago

Wait, which 2 do you expect to become usable?

Reply View 1 reply
  • chrismorgan 3 days ago

    It might not be particularly visible from outside just yet, but we’ve reached the stage where a lot of the fundamentals (which are typically deplorable in quick-and-dirty libraries) really are being nailed down quite nicely; and, perhaps more importantly, where a lot of the different teams are sharing work and collaborating on libraries, rather than each project starting from scratch. The momentum around AccessKit is the most visible example of this.

    The Linebender community is a very promising venue for such collaboration, and there are at least four organisations investing quite a bit into this and related endeavours.

    I won’t name any specific two libraries. It also depends a little on whether you’re targeting web tech only, or web and desktop, or desktop. (Or mobile.)

    Reply View 0 replies