1. 20
  1. 16

    i noticed that none of the text on the webassembly demo was selectable; i hope this is not the wave of the future :(

    1. 8

      From an accessibility point of view, the current state of this whole thing is entirely broken.

      The demos draw pixels onto a single <canvas>. None of the UI elements are visible to assistive technology. You can’t highlight or interact with any of the UI elements with a keyboard. The buttons are not <button>s, nor are they <a href="...">s, nor are they even <div>s with ARIA markup or tabIndex. There are no widgets. It’s just a picture with some mouse & keyboard event handlers on it. If you try all of the provided demos with NVDA, the content of the demo just doesn’t exist.

      The only notable a11y guideline the demos don’t fail is that the text sizes chosen are just about big enough. (Though text rendering is mysteriously blurry in random places in the UIs, and a few places have unreadably low contrast ratios.)

      1. 4

        Text in input fields is kind of selectable but you can’t even copy…

        1. 3

          To be fair, I think it’s designed for the desktop primarily?

          1. 4

            fair enough, but from a quick look at the docs i couldn’t get much sense of whether text will be treated properly for accessibility purposes. i think that for new UI toolkits a faq on accessibility is a must-have, even if it says “we don’t have it in v0.1 but here are our plans for it”. if it’s not even planned for then i do not want to invest in their toolkit.

        2. 5

          GPLv3 GUI toolkit from people who built Qt. They have a demo compiled to WebAssembly here.

          1. 2

            It will all be fun and games until they have market share, then the dual license becomes an issue because they don’t make any money…

            1. 3

              I assume you’re mostly referring to Qt’s problems pushing their licenses. Only time will tell how SixtyFPS fares, but there are some differences. There’s no LGPL offering, only GPL. This presumably means that commercial users who don’t want to share their code will have to buy a commercial licence. This may avoid the Qt situation where they amass a large number of non-paying corporate LGPL users then go round threatening them in the hope they’ll buy a licence which they don’t need because they’re already LGPL compliant. I also believe that in many ways Qt themselves are responsible for their failure to sell licenses, rather than the dual-licence model itself.

              When I first saw the headline about a new GUI toolkit, I thought, “Another one!?”. I think it’s clear that the current state of GUI toolkits is not ideal, so we have recently been seeing a number of attempts to do it better. However, it’s equally clear that Qt is a massive beast, almost unassailable if you want to compete on most of its features rather than offering a limited subset of platforms or use cases.

              However, now that I’ve read a little bit about this one and seen who’s behind it, I’m cautiously optimistic about it. It looks like they are trying to keep some of Qt’s strengths, such as the declarative language for describing GUIs, while avoiding some of its downsides, such as the use of dynamically-typed, interpreted, javascript in the frontend code and the garbage collector.

              The choice of Rust as the main implementation language, with the option to use Rust, C++, or javascript to write applications seems good. Qt has had a long and not always easy relationship with C++. Early versions of Qt tried to fills in some of the gaps in C++, but at times got carried away, with all manner of qThis, qThat and qTheOther types implementing Qt’s take on C++. While this was eventually reigned in and current Qt is largely compatible with std C++ containers and algorithms, the Qt API still uses raw pointers and implicitly-shared containers extensively, meaning that despite C++ ostensibly being Qt’s ‘native’ language, an existing user of ‘modern C++’ may not find Qt to their taste.

              I’ll definitely be giving this one a try later…

              1. 2

                the declarative language for describing GUIs, while avoiding some of its downsides, such as the use of dynamically-typed, interpreted, javascript in the frontend code and the garbage collector.

                Fantastic observation. I didn’t think of this similarity or this difference.

          2. 4

            Native : … Both the user and the developer should feel at home on each platform. The look and feel and experience should match the users’ expectations of a native application.

            … and yet, although the screenshots have macOS traffic light buttons, the UI look and feel is nothing like a native Mac app. Am I misunderstanding this goal?

            1. 6

              No, you aren’t misunderstanding. It’s a work in progress, that’s why.

              1. 3

                Thanks for being honest about that. It’s a pretty cool concept, however!

            2. 3

              I get that 60Hz is the current standard that you don’t want to drop below, but that doesn’t seem like it will be long lived. The top phones these days are able to do 120Hz. Will this name make sense to people as ‘fast’ even now?

              1. 2

                https://github.com/sixtyfpsui/sixtyfps/blob/master/FAQ.md#is-that-name-not-going-to-be-obsolete-soon

                While newer screens are able to provide higher refresh rates, 60 is still a well accepted threshold that has this historical value.

              2. 2

                Shame seeing all the hate here - this is looking really promising.

                It’s only at v0.0.4 and I get the feeling that people are judging the software (and website) against established businesses. This is super early stage pre-release level stuff!

                I’m impressed that it’s as usable and snappy as it is already and the fact that it’s open-source too is the icing on the cake for me! Going to be following this closely - has tons of potential!

                1. 0

                  I despise this.

                  1. 3

                    Care to elaborate?

                    1. 3

                      The supported languages are Rust, C++, and Node. The website has an extremely tacky corporate feel with web fonts and stock photos. The toolkit heavily features animations and transparency, even beyond what has ill-advisedly been done in existing toolkits. The name even appears to be a reference to this misdesign.

                  2. 1

                    Working for a company that uses the LGPL part of the Qt, I don’t see anything that would entice the company to shell out cash for the commercial license of SixtyFPS.

                    The concept is interesting but I fear its licensing options will impede adoption in commercial application.