6 ms·

That's the dream. Render to WebGL/Canvas. Bypass CSS + HTML. Make web actually open to other languages by putting them on a very common ground.

_lvbh 3y ago
I would rather not have JS replaced. It would really hurt the ability of users to poke through the code and tweak stuff as they like.
- ravenstine 3y ago
  There isn't anything actually wrong with JavaScript in 2023, either. The idea that it needs to be replaced stems from countless failed attempts to shove a bunch of crap into the client with a bunch of frameworks and without a shred of actual engineering discipline. Trust me when I say that, if web apps become commonly written mainly in other "scalable" or "type-safe" languages, your average software developers will find a way to screw that up as much as they have with today's web, if not worse than that. WASM is cool, but I don't see any reason to get rid of JS. There's value to having a lingua franca of JIT interpreted code with a standard UI toolkit, and I think those who point out how "insufficient" the DOM is and how "slow" and "unsafe" JavaScript is are simply wrong. They both do their jobs exceedingly well when idiotic and theological ideas are not simply thrown at them by software developers obsessed by convenience over soundness of design.
  - QwertyPi 3y ago
    > There isn't anything actually wrong with JavaScript in 2023, either. The semantics of the language can be quite complex and it took decades for browsers to agree on them for most use cases. WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. > The idea that it needs to be replaced stems from countless failed attempts to shove a bunch of crap into the client with a bunch of frameworks and without a shred of actual engineering discipline. The same can be said about the implementation of javascript in browsers as well. We're stuck with it regardless, but our reliance on javascript and its myriad interactions with html and css functions much the same way for large browser vendors as regulatory capture does for large corporations at the state level.
    - fabrice_d 3y ago
      > WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. No, WASM arose out of the work done by Alon Zakai on asm.js at Mozilla which was in good part motivated to show that the web didn't need Google's PNaCl.
    - ravenstine 3y ago
      > The semantics of the language can be quite complex and it took decades for browsers to agree on them for most use cases. That's ancient history. JavaScript has its quirks, but it's not a difficult language to learn or use. Frankly, I don't know where you get this idea that the semantics of the language are hard. In contrast to what? Maybe if you shared some examples I could understand what you're talking about. JavaScript was challenging in decades past not because it was complex but because it was way too simple. Using it on a webpage to do more than very rudimentary things with the browser API meant doing a lot of whacky stuff and using libraries for operations we take for granted today. > WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. As someone else mentioned, no it didn't. WASM came from the same desire as Java applets and browser plugins for Shockwave and Flash, which was to develop applications that run in the browser using entirely different languages and authoring tools. > The same can be said about the implementation of javascript in browsers as well. No idea what you are basing this on. Nobody (as in the vast majority) thinks that modern web development is a failure because JavaScript the language is too complex. Everyone is complaining about web development because of all the tools that have been added between the keyboard and the code running in the client, and said tools failing to live up to their promise while encouraging patterns that commonly backfire. > our reliance on javascript and its myriad interactions with html and css functions What does that even mean? JavaScript only has as much interaction with the DOM as is demanded of it. If there's a myriad of ways that JavaScript can interact with the DOM, well, that's by design... how else would you have it? CSS functions have nothing to do with JavaScript, if that's what you're actually referring to. At most, JavaScript can listen for some events that are emitted by things like CSS animations.
QwertyPi 3y ago
That seems to remove the advantage of using the browser in the first place—leveraging native controls and integrations, giving the user control over how things are renderered, and accessibility concerns. Of course, I can see how this is mostly irrelevant for some applications like games, but that's still rather niche compared to, you know, useful and wide-spread apps that people actually want to use.
- modeless 3y ago
  You forgot about the most important advantages. True write once run anywhere cross platform support, and one click zero install distribution with no gatekeepers. The latter in particular is key and impossible to replicate any other way because device gatekeepers like Apple or Nintendo will never allow any other app platform to bypass their distribution monopoly.
  - QwertyPi 3y ago
    > True write once run anywhere cross platform support, and one click zero install distribution with no gatekeepers. We had (have) that, and the apps were miserable to use for the same reasons enumerated above. The place where it has come closest to succeeding? Video games. Unfortunately, platforms are too diverse to target as a generic platform without making major sacrifices as to either consistency or usability.
itslennysfault 3y ago
Nah, that is a nightmare. Don't forget your WebGL/Canvas based UI has to be responsive to screens ranging from a 3" phone up to a 8K ultrawide monitor. Nothing beats html/css for achieving that. Also, good luck with ADA compliance when your page is a pixel drawing on canvas.
- Jyaif 3y ago
  > Nothing beats html/css for achieving that Many people would argue that the native iOS and Android UI toolkits beat HTML/css. 6dc610bc2d7c1ba9b6783c61bf8c79897c733964e845d574990b120954428d69
  - kaba0 3y ago
    They don’t run on the web, though.
    - pjmlp 3y ago
      ChromeOS you mean.
    - Jyaif 3y ago
      The website can use the toolkit by shipping it in webasm. ae0f36b12c0a363dd4eaf94fb65b33bd7c7f55e879a85c24394d6d06d02af4d5
- recursive 3y ago
  Why must all apps support all scenarios? Is the latest triple-A big-budget video game ADA compliant? Does it run on a 3" phone?
- cantSpellSober 3y ago
  My understanding is that devs are "supposed" to use WASM as a compliment to a11y-friendly tech. From https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r... > HTML/CSS/JavaScript UI around a main WASM-controlled center canvas, allowing developers to build accessible experiences I can easily see that not happening obviously (plenty of non-WASM sites with poor a11y exist already). If anyone has any useful articles regarding accessibility and WASM please share.
frou_dh 3y ago
Maybe for web games that's the dream. But for user interfaces that will mean dodgy homegrown text rendering, text selection, caret movement, etc on a site-by-site (or at least framework-by-framework) basis.
kaba0 3y ago
> Make web actually open to other languages And closed for humans? I am lucky enough that I haven’t yet met an unblockable canvas ad, but they are coming. You also won’t get any support from the browser, no text select, no right click, no accessibility whatsoever, no reader mode, probably not even have proper mobile support, because it just happened to react to clicks, and not touches.. Unless it is some specific simulation/game/ultra-complex gui (think photoshop), I explicitly don’t want to see any canvas rendering, even though I really dislike JS as a language/platform.

_lvbh 3y ago

I would rather not have JS replaced. It would really hurt the ability of users to poke through the code and tweak stuff as they like.

ravenstine 3y ago
There isn't anything actually wrong with JavaScript in 2023, either. The idea that it needs to be replaced stems from countless failed attempts to shove a bunch of crap into the client with a bunch of frameworks and without a shred of actual engineering discipline. Trust me when I say that, if web apps become commonly written mainly in other "scalable" or "type-safe" languages, your average software developers will find a way to screw that up as much as they have with today's web, if not worse than that. WASM is cool, but I don't see any reason to get rid of JS. There's value to having a lingua franca of JIT interpreted code with a standard UI toolkit, and I think those who point out how "insufficient" the DOM is and how "slow" and "unsafe" JavaScript is are simply wrong. They both do their jobs exceedingly well when idiotic and theological ideas are not simply thrown at them by software developers obsessed by convenience over soundness of design.
- QwertyPi 3y ago
  > There isn't anything actually wrong with JavaScript in 2023, either. The semantics of the language can be quite complex and it took decades for browsers to agree on them for most use cases. WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. > The idea that it needs to be replaced stems from countless failed attempts to shove a bunch of crap into the client with a bunch of frameworks and without a shred of actual engineering discipline. The same can be said about the implementation of javascript in browsers as well. We're stuck with it regardless, but our reliance on javascript and its myriad interactions with html and css functions much the same way for large browser vendors as regulatory capture does for large corporations at the state level.
  - fabrice_d 3y ago
    > WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. No, WASM arose out of the work done by Alon Zakai on asm.js at Mozilla which was in good part motivated to show that the web didn't need Google's PNaCl.
  - ravenstine 3y ago
    > The semantics of the language can be quite complex and it took decades for browsers to agree on them for most use cases. That's ancient history. JavaScript has its quirks, but it's not a difficult language to learn or use. Frankly, I don't know where you get this idea that the semantics of the language are hard. In contrast to what? Maybe if you shared some examples I could understand what you're talking about. JavaScript was challenging in decades past not because it was complex but because it was way too simple. Using it on a webpage to do more than very rudimentary things with the browser API meant doing a lot of whacky stuff and using libraries for operations we take for granted today. > WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity. As someone else mentioned, no it didn't. WASM came from the same desire as Java applets and browser plugins for Shockwave and Flash, which was to develop applications that run in the browser using entirely different languages and authoring tools. > The same can be said about the implementation of javascript in browsers as well. No idea what you are basing this on. Nobody (as in the vast majority) thinks that modern web development is a failure because JavaScript the language is too complex. Everyone is complaining about web development because of all the tools that have been added between the keyboard and the code running in the client, and said tools failing to live up to their promise while encouraging patterns that commonly backfire. > our reliance on javascript and its myriad interactions with html and css functions What does that even mean? JavaScript only has as much interaction with the DOM as is demanded of it. If there's a myriad of ways that JavaScript can interact with the DOM, well, that's by design... how else would you have it? CSS functions have nothing to do with JavaScript, if that's what you're actually referring to. At most, JavaScript can listen for some events that are emitted by things like CSS animations.

QwertyPi 3y ago

That seems to remove the advantage of using the browser in the first place—leveraging native controls and integrations, giving the user control over how things are renderered, and accessibility concerns. Of course, I can see how this is mostly irrelevant for some applications like games, but that's still rather niche compared to, you know, useful and wide-spread apps that people actually want to use.

modeless 3y ago
You forgot about the most important advantages. True write once run anywhere cross platform support, and one click zero install distribution with no gatekeepers. The latter in particular is key and impossible to replicate any other way because device gatekeepers like Apple or Nintendo will never allow any other app platform to bypass their distribution monopoly.
- QwertyPi 3y ago
  > True write once run anywhere cross platform support, and one click zero install distribution with no gatekeepers. We had (have) that, and the apps were miserable to use for the same reasons enumerated above. The place where it has come closest to succeeding? Video games. Unfortunately, platforms are too diverse to target as a generic platform without making major sacrifices as to either consistency or usability.

itslennysfault 3y ago

Nah, that is a nightmare. Don't forget your WebGL/Canvas based UI has to be responsive to screens ranging from a 3" phone up to a 8K ultrawide monitor. Nothing beats html/css for achieving that. Also, good luck with ADA compliance when your page is a pixel drawing on canvas.

Jyaif 3y ago
> Nothing beats html/css for achieving that Many people would argue that the native iOS and Android UI toolkits beat HTML/css. 6dc610bc2d7c1ba9b6783c61bf8c79897c733964e845d574990b120954428d69
- kaba0 3y ago
  They don’t run on the web, though.
  - pjmlp 3y ago
    ChromeOS you mean.
  - Jyaif 3y ago
    The website can use the toolkit by shipping it in webasm. ae0f36b12c0a363dd4eaf94fb65b33bd7c7f55e879a85c24394d6d06d02af4d5
recursive 3y ago
Why must all apps support all scenarios? Is the latest triple-A big-budget video game ADA compliant? Does it run on a 3" phone?
cantSpellSober 3y ago
My understanding is that devs are "supposed" to use WASM as a compliment to a11y-friendly tech. From https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r... > HTML/CSS/JavaScript UI around a main WASM-controlled center canvas, allowing developers to build accessible experiences I can easily see that not happening obviously (plenty of non-WASM sites with poor a11y exist already). If anyone has any useful articles regarding accessibility and WASM please share.

frou_dh 3y ago

Maybe for web games that's the dream. But for user interfaces that will mean dodgy homegrown text rendering, text selection, caret movement, etc on a site-by-site (or at least framework-by-framework) basis.

kaba0 3y ago

> Make web actually open to other languages And closed for humans? I am lucky enough that I haven’t yet met an unblockable canvas ad, but they are coming. You also won’t get any support from the browser, no text select, no right click, no accessibility whatsoever, no reader mode, probably not even have proper mobile support, because it just happened to react to clicks, and not touches.. Unless it is some specific simulation/game/ultra-complex gui (think photoshop), I explicitly don’t want to see any canvas rendering, even though I really dislike JS as a language/platform.