4 ms·

They re-implement everything in canvas I assume? If so, wow, that’s pretty awful.

dvdkon 5y ago
Why? At this point, the browser is mostly an app runtime, so I don't think avoiding HTML and CSS is necessarily a bad thing. With some tuning it could even be faster, although I don't think any project has gotten to that point yet.
- tenaciousDaniel 5y ago
  Because of the sheer amount of effort that browsers have put into solving all sorts of tricky problems, such as internationalization and accessibility. Once you try to render your own text inputs, you're committing to replicating a mountain of functionality. HTML is deceptively simple.
  - vbsteven 5y ago
    HTML, the dom, css and JS in browsers are far from simple. IMHO we’ve been tacking on more and more “application stuff” on top of a document viewer since the mid 90s. The whole reason React and other virtual dom frameworks exist is to wrangle the original document viewer into an application platform. Yes, after all those years browsers are top notch when it comes to accessibility, but it comes with lots of additional complexity. I am hopeful that with things like WASM and Canvas we are finally starting to move away from this document-based paradigm towards more app-focused paradigms. Although there is still lots of work to be done to make approaches like this work with accessibility tools. Sometimes i think that we are deliberately not adding dom support to wasm in order to not make the same mistakes we did when trying to make html/css/js suitable for apps.
    - tenaciousDaniel 5y ago
      That framing makes sense. I've always thought the document model was poorly suited for modern applications. I'm still not sold on canvas itself being the solution - I'd rather open up the underlying accessibility/i18n tech so that developers don't have to reinvent the wheel. But yes, otherwise agree with you.
      - vbsteven 5y ago
        My ideal solution would be that we can add accessibility apis to canvas. That means we can write GUI toolkits in any language compiling to wasm using canvas apis. Those toolkits gain accessibility support through canvas. edit: some toolkits already have wasm/canvas support (like Flutter and Gtk I think). The missing link is the ability to integrate accessibility.
        dathinab 5y ago
        Not just that. There is quite a bunch of thinks you simple can't do (in reasonable high quality) with canvas rendering without it undermining the users privacy. E.g. you can do a lot to reduce the fingerprint-ability of canvas (Google doesn't care) but doing so will lead to potentially slightly slower rendering and in turn potentially less fluid animations. You can't have links as in a website without getting access the the whole browser history. You can't take advantage of the GPU in the same way the browsers can. You always have quite a bit of size and (potentially) load time overhead (I mean just look a Pangolin UI for a good example for this). And "everyone" potentially ships their own copy of a whole UI framework (not just some layers on top of it like it's common in the web). So if there is a rendering but normally it get's fixed by you browser but now it needs to be fixed by library authors and then the fix needs to be used by the website which had a problem. I think a non document based base would be nice, but it needs to be browser native, standardized, not vendor specific and with first class accessibility. At least at the core. And let's be honest flutter is non of this. And given some decisions like making text non selecteable by default I don't see it ever coming to that point tbh.
    - dathinab 5y ago
      I can understand you, but IMHO for most websites a document focused paradigm is just the right fit. I mean e.g. a news site is just a collection of documents in the end, blogs are just documents, so is wikipedia. Search machines are basically like external indices, which fit well as documents and even things like booking sites are in the end just fancy formulars. Sure there are a lot of more "app" like usage, and for them having a different base is very important. But I'm not the biggest fan of "turning" document use cases into apps (as many sites already try to do today), as this in my experience adds a lot of overhead and includes a massive bucket of behavioral differences which can make it very hard for some people to use the internet. If everyone would agree of how roughly apps should behave for the roughly same UX aspect it would be fine. But people don't I mean look at the massive UX divergence which slowly creeped in between Android(Stock) and iOs. Worst this is a very subtitle creep at many places and it often seems as many designer doesn't realize that what they think is innovative (and might be innovative for e.g. a iOs) user isn't necessarily innovative for a lot of other people (e.g. all the Android users). Or in other words the whole concept of what is innovative diverged between different grubs of people even if they belong in the same "culture"/country/etc.. Anyway still for the places where it does make sense having a alternative to HTML/CSS is nice but I believe it must be browser native, non vendor specific, standardized and have first class accessibility support. Non of which applies to Flutter (web) in the way it currently is.
      - vbsteven 5y ago
        Yes, we definitely want similar things. Maybe it was not clear from my original reply but I’m not saying the document paradigm is bad and we should move away from it. The document paradigm has evolved for 25 years and it is the right fit for most “websites”. The problem is that we’re trying to build apps on the same base as well and that is where the mismatch is. If you look at cross platform GUI toolkits like Gtk, Qt, Flutter and Druid, what most of them have in common is that they are typically abstractions on top of a graphics rendering library (cairo, skia, canvas) with integration into platform accessibility and window APIs. That makes them easily portable to Linux, Windows, Android, iOS etc. The problem with the web browser as a target platform for these toolkits is that the accessibility support is currently coupled too tightly with dom/html/css. The graphics drawing toolkit is there (canvas) and most of the above toolkits have abstracted over it already. The missing link is standardised accessibility APIs in browsers that can be used with canvas instead of dom.
  - dvdkon 5y ago
    Yes, it's a lot of work to create a good GUI toolkit. But it's not impossible either, and Flutter developers have already put in a lot of work into getting things just right on mobile, so I think they have a good shot at doing the same on the web.
    - EvilEy3 5y ago
      > just right on mobile If by "just right" you mean sticking out like a sore thumb on iOS, then sure.
    - miohtama 5y ago
      It is impossible because on web you do not get access to low level UI primitives like input controls as you would on mobile. They cannot e.g. read clipboad, access native context sentive menus and such. Flutter on web can do Flash applications of 2020, but for most web use cases it is not possible to ”get it right”.
      - dvdkon 5y ago
        I don't think Flutter uses native UI primitives anywhere, but you're right that web APIs have been designed for HTML documents/apps and will need modification for non-HTML apps. We aren't there yet, but I'm convinced we'll get there at some point.
- EvilEy3 5y ago
  Good luck with accessibility and compatibility with browser plugins.
- dathinab 5y ago
  The main reason: Accessibility in many variants. E.g. I need to change font's/font colors/background colors from time to time because they are extremely exhausting for me to read, I can't do so with Flutter. Screen readers know how to process HTML, CSS. But how are they supposed to know what some "arbitrary" painted pixel are supposed to mean. And yes they already have to do a awful amount of trick due to people incorrectly (one higher semantic level) use HTML & CSS. Many of the defaults of Flutter (Web) are horrible, at least the last time I checked. E.g. text is unselectable by default instead of it being an opt in some site which have problems with stolen text content have use (and you still can steal it anyway just screenshot + OCR, duh). Lastly (some) browsers optimized for good (e.g. fast or battery friendly) HTML/CSS rendering, non of this applies to Flutter. E.g. Firefox has a pretty need parallelization of layout and rendering allowing quite awesome usages of CSS animations, non of this will ever be possible in Flutter without replacing DOM with Flutter natively, at which point we have then a Google web instead of an internet. (Through tbh. replacing HTML+CSS with some proper abstracted API of flutters inner workings is tempting, it has some quite need aspects, that is if Accessibility works by then.)
  - dvdkon 5y ago
    A lot of work has been put into accessibility on the web, and the "semantic HTML" document model that works so poorly for apps helped too. There's no reason accessibility needs to be bad for anything non-HTML, at least not with supporting screen readers. I also think text not being selectable by default is an OK default for apps (actual desktop-grade apps, not websites with interactive elements). Right now, in 2021, it's probably a bad idea to create a web app with Flutter or any other non-DOM-based toolkit, but I don't think that will be the case forever. The native apps I use are all as good as or even better than browsers at being fast and battery-friendly. They might achieve that by being more limited and not supporting all the features and usecases of HTML5, and that's perfectly fine. It's not impossible that we'll see similar high-quality GUI frameworks inside browser runtimes.
    - dathinab 5y ago
      The problem is they forcefully replacing HTML in a "inside-out" fashion without there being anything in place to allow browser accessibility tools to reasonably handle it. Sure there is no reason non HTML can't work at some point in the future if browsers and/or accessibility tools accept a new API as (a) standard for handling accessibility. But the way it currently is it is a accessibility nightmare and often even trivial things like text selection don't work because flutter defaults to not allow text selection if the programmer doesn't go out of the way to explicitly enable it. IMHO before you push something like flutter web onto people you first need to push a way to handle accessibility with it or you will hurt a bunch of people. And yes the whole semantic HTML document thing didn't work out well, but that is less so because of technical reasons but more so because: - companies just not caring, even potentially going as far as intentionally obfuscating HTML - a lot of the semantic parts not having been there from the get to go but bolted on later on. So a lot of people and material are still used to not using it. A mistake flutter is repeating just now - and wrt. non-document based applications it just doesn't fit that well, but a lot of web-apps could be done in a document based fashion, if companies and (not affected) people would care more.
- ridethebike 5y ago
  Flash and Silverlight were unavailable to comment

Why? At this point, the browser is mostly an app runtime, so I don't think avoiding HTML and CSS is necessarily a bad thing. With some tuning it could even be faster, although I don't think any project has gotten to that point yet.

tenaciousDaniel 5y ago
Because of the sheer amount of effort that browsers have put into solving all sorts of tricky problems, such as internationalization and accessibility. Once you try to render your own text inputs, you're committing to replicating a mountain of functionality. HTML is deceptively simple.
- vbsteven 5y ago
  HTML, the dom, css and JS in browsers are far from simple. IMHO we’ve been tacking on more and more “application stuff” on top of a document viewer since the mid 90s. The whole reason React and other virtual dom frameworks exist is to wrangle the original document viewer into an application platform. Yes, after all those years browsers are top notch when it comes to accessibility, but it comes with lots of additional complexity. I am hopeful that with things like WASM and Canvas we are finally starting to move away from this document-based paradigm towards more app-focused paradigms. Although there is still lots of work to be done to make approaches like this work with accessibility tools. Sometimes i think that we are deliberately not adding dom support to wasm in order to not make the same mistakes we did when trying to make html/css/js suitable for apps.
  - tenaciousDaniel 5y ago
    That framing makes sense. I've always thought the document model was poorly suited for modern applications. I'm still not sold on canvas itself being the solution - I'd rather open up the underlying accessibility/i18n tech so that developers don't have to reinvent the wheel. But yes, otherwise agree with you.
    - vbsteven 5y ago
      My ideal solution would be that we can add accessibility apis to canvas. That means we can write GUI toolkits in any language compiling to wasm using canvas apis. Those toolkits gain accessibility support through canvas. edit: some toolkits already have wasm/canvas support (like Flutter and Gtk I think). The missing link is the ability to integrate accessibility.
      - dathinab 5y ago
        Not just that. There is quite a bunch of thinks you simple can't do (in reasonable high quality) with canvas rendering without it undermining the users privacy. E.g. you can do a lot to reduce the fingerprint-ability of canvas (Google doesn't care) but doing so will lead to potentially slightly slower rendering and in turn potentially less fluid animations. You can't have links as in a website without getting access the the whole browser history. You can't take advantage of the GPU in the same way the browsers can. You always have quite a bit of size and (potentially) load time overhead (I mean just look a Pangolin UI for a good example for this). And "everyone" potentially ships their own copy of a whole UI framework (not just some layers on top of it like it's common in the web). So if there is a rendering but normally it get's fixed by you browser but now it needs to be fixed by library authors and then the fix needs to be used by the website which had a problem. I think a non document based base would be nice, but it needs to be browser native, standardized, not vendor specific and with first class accessibility. At least at the core. And let's be honest flutter is non of this. And given some decisions like making text non selecteable by default I don't see it ever coming to that point tbh.
  - dathinab 5y ago
    I can understand you, but IMHO for most websites a document focused paradigm is just the right fit. I mean e.g. a news site is just a collection of documents in the end, blogs are just documents, so is wikipedia. Search machines are basically like external indices, which fit well as documents and even things like booking sites are in the end just fancy formulars. Sure there are a lot of more "app" like usage, and for them having a different base is very important. But I'm not the biggest fan of "turning" document use cases into apps (as many sites already try to do today), as this in my experience adds a lot of overhead and includes a massive bucket of behavioral differences which can make it very hard for some people to use the internet. If everyone would agree of how roughly apps should behave for the roughly same UX aspect it would be fine. But people don't I mean look at the massive UX divergence which slowly creeped in between Android(Stock) and iOs. Worst this is a very subtitle creep at many places and it often seems as many designer doesn't realize that what they think is innovative (and might be innovative for e.g. a iOs) user isn't necessarily innovative for a lot of other people (e.g. all the Android users). Or in other words the whole concept of what is innovative diverged between different grubs of people even if they belong in the same "culture"/country/etc.. Anyway still for the places where it does make sense having a alternative to HTML/CSS is nice but I believe it must be browser native, non vendor specific, standardized and have first class accessibility support. Non of which applies to Flutter (web) in the way it currently is.
    - vbsteven 5y ago
      Yes, we definitely want similar things. Maybe it was not clear from my original reply but I’m not saying the document paradigm is bad and we should move away from it. The document paradigm has evolved for 25 years and it is the right fit for most “websites”. The problem is that we’re trying to build apps on the same base as well and that is where the mismatch is. If you look at cross platform GUI toolkits like Gtk, Qt, Flutter and Druid, what most of them have in common is that they are typically abstractions on top of a graphics rendering library (cairo, skia, canvas) with integration into platform accessibility and window APIs. That makes them easily portable to Linux, Windows, Android, iOS etc. The problem with the web browser as a target platform for these toolkits is that the accessibility support is currently coupled too tightly with dom/html/css. The graphics drawing toolkit is there (canvas) and most of the above toolkits have abstracted over it already. The missing link is standardised accessibility APIs in browsers that can be used with canvas instead of dom.
- dvdkon 5y ago
  Yes, it's a lot of work to create a good GUI toolkit. But it's not impossible either, and Flutter developers have already put in a lot of work into getting things just right on mobile, so I think they have a good shot at doing the same on the web.
  - EvilEy3 5y ago
    > just right on mobile If by "just right" you mean sticking out like a sore thumb on iOS, then sure.
  - miohtama 5y ago
    It is impossible because on web you do not get access to low level UI primitives like input controls as you would on mobile. They cannot e.g. read clipboad, access native context sentive menus and such. Flutter on web can do Flash applications of 2020, but for most web use cases it is not possible to ”get it right”.
    - dvdkon 5y ago
      I don't think Flutter uses native UI primitives anywhere, but you're right that web APIs have been designed for HTML documents/apps and will need modification for non-HTML apps. We aren't there yet, but I'm convinced we'll get there at some point.
EvilEy3 5y ago
Good luck with accessibility and compatibility with browser plugins.
dathinab 5y ago
The main reason: Accessibility in many variants. E.g. I need to change font's/font colors/background colors from time to time because they are extremely exhausting for me to read, I can't do so with Flutter. Screen readers know how to process HTML, CSS. But how are they supposed to know what some "arbitrary" painted pixel are supposed to mean. And yes they already have to do a awful amount of trick due to people incorrectly (one higher semantic level) use HTML & CSS. Many of the defaults of Flutter (Web) are horrible, at least the last time I checked. E.g. text is unselectable by default instead of it being an opt in some site which have problems with stolen text content have use (and you still can steal it anyway just screenshot + OCR, duh). Lastly (some) browsers optimized for good (e.g. fast or battery friendly) HTML/CSS rendering, non of this applies to Flutter. E.g. Firefox has a pretty need parallelization of layout and rendering allowing quite awesome usages of CSS animations, non of this will ever be possible in Flutter without replacing DOM with Flutter natively, at which point we have then a Google web instead of an internet. (Through tbh. replacing HTML+CSS with some proper abstracted API of flutters inner workings is tempting, it has some quite need aspects, that is if Accessibility works by then.)
- dvdkon 5y ago
  A lot of work has been put into accessibility on the web, and the "semantic HTML" document model that works so poorly for apps helped too. There's no reason accessibility needs to be bad for anything non-HTML, at least not with supporting screen readers. I also think text not being selectable by default is an OK default for apps (actual desktop-grade apps, not websites with interactive elements). Right now, in 2021, it's probably a bad idea to create a web app with Flutter or any other non-DOM-based toolkit, but I don't think that will be the case forever. The native apps I use are all as good as or even better than browsers at being fast and battery-friendly. They might achieve that by being more limited and not supporting all the features and usecases of HTML5, and that's perfectly fine. It's not impossible that we'll see similar high-quality GUI frameworks inside browser runtimes.
  - dathinab 5y ago
    The problem is they forcefully replacing HTML in a "inside-out" fashion without there being anything in place to allow browser accessibility tools to reasonably handle it. Sure there is no reason non HTML can't work at some point in the future if browsers and/or accessibility tools accept a new API as (a) standard for handling accessibility. But the way it currently is it is a accessibility nightmare and often even trivial things like text selection don't work because flutter defaults to not allow text selection if the programmer doesn't go out of the way to explicitly enable it. IMHO before you push something like flutter web onto people you first need to push a way to handle accessibility with it or you will hurt a bunch of people. And yes the whole semantic HTML document thing didn't work out well, but that is less so because of technical reasons but more so because: - companies just not caring, even potentially going as far as intentionally obfuscating HTML - a lot of the semantic parts not having been there from the get to go but bolted on later on. So a lot of people and material are still used to not using it. A mistake flutter is repeating just now - and wrt. non-document based applications it just doesn't fit that well, but a lot of web-apps could be done in a document based fashion, if companies and (not affected) people would care more.
ridethebike 5y ago
Flash and Silverlight were unavailable to comment