6 ms·

There are at least two projects I know of that are using WASM to implement web applications without JavaScript. Personally I think that’s the future: https://v

There are at least two projects I know of that are using WASM to implement web applications without JavaScript. Personally I think that’s the future: https://vugu.org https://vugu.org https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

dathinab 5y ago
The problem is flutter (web) also doesn't use html/css...
- tenaciousDaniel 5y ago
  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
      - 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
- domano 5y ago
  There are 2 modes you can choose from, one is using html but is less performant.
zenlot 5y ago
Is Vugu still developed? Looks like stalled.

dathinab 5y ago

The problem is flutter (web) also doesn't use html/css...

tenaciousDaniel 5y ago
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
    - 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
domano 5y ago
There are 2 modes you can choose from, one is using html but is less performant.

zenlot 5y ago

Is Vugu still developed? Looks like stalled.