1. 23

  2. 6

    Can you please, please stop using web browser as an UI renderer?

    1. 13

      No. It solves distribution and sandboxing; it’s (very serious) deficiencies are unimportant compared to that.

      1. 4

        Sad but true. There currently is no better solution for a secure, network-distributed client side UI with medium level graphics primitives, scripting language and a lightweight-ish networked RPC system.

        I’d love to make a better solution though.

        1. 1

          Arcan is pretty cool and could do most or all of that.

          I don’t know what 9front’s story is like for security, but it ticks all the other boxes.

          Both experimental (at least for this purpose) and neither are as easy to write UIs for as the web.

        2. 2

          With a half-decent DOM semantics you also get accessibility for free. Custom toolkits that draw their own widgets need to implement that themselves.

          In terms of performance and flexibility DOM is the lowest common denominator, so it’s a good benchmark. If DOM can be made to work, integration with native UI toolkits is likely to be possible too.

        3. 6

          Using the DOM as a common platform allows us to write addons and scrapers and etc. much more easily than if every application used one of the N UI libraries.

          Instead of advocating against the web APIs, how about you advocate for something better?

          1. 1

            Not in this case. I still can’t even realize that some people are taking that “browser-as-application” meme seriously, I suppose it’s just a giant joke (or, as people recently call it, a “prank”) which teenagers thought it would be fun to do on IT industry.

            Just because something can be done, doesn’t mean it should be – that’s what we call responsibility.

        4. 3

          See also Azul, also targeting WebRender.