4 ms·

We did! WebAssembly! Most languages aren’t infinitely backwards-compatible so unless you want to be running Python 2.7 forever or whatever…

egeozcan 2y ago
But with WebAssembly, you need to DIY a lot and/or send a lot of runtime/stdlib code to the browser. It definitely has its place but something like Dart with excellent stdlib would be amazing (and I know that actually was the intent when Dart was being developed, I know, and I did oppose it at the time). Browsers then could ship different versions, and you can enable them, like "use strict" in js. On the other hand, I understand why not: You ship Dart and Python folk will be WTF, you ship Python and that would annoy the Java/.NET folk, and so on...
emseetech 2y ago
WebAssembly as a lower level abstraction is going to make web dev very interesting once the tech finally pays off, but it's been almost 10 years since it was announced and there's still no viable alternative to javascript to come out of it. It would have been nice if a cleaner, stricter and more "designed" alternative with full access to browser features had emerged in the meantime. I'd even accept Dart if it had managed to get broad browser support. Instead we're in a waiting game where we're all forced to use Javascript for any real work until the horizon is crossed and we can finally use a dozen of wasm-targeted languages.
- flohofwoe 2y ago
  > but it's been almost 10 years since it was announced and there's still no viable alternative to javascript to come out of it Are you aware if AssemblyScript? https://www.assemblyscript.org/ https://www.assemblyscript.org/ But arguably, the main purpose of WebAssembly is to use existing languages on the web, not necessarily invent new ones or even to replace Javascript.
  - throwitaway1123 2y ago
    I've been following AssemblyScript for years but I can't recommend it until they figure out closures: https://github.com/AssemblyScript/assemblyscript/issues/798 https://github.com/AssemblyScript/assemblyscript/issues/798
  - emseetech 2y ago
    AssemblyScript can't access the dom without interfacing with Javascript which is a major piece that needs to be solved with wasm generally. I'm arguing we should have invented a new native language to replace javascript, which could have provided a stop-gap solution until wasm targeted languages are viable.
    - deleted 2y ago
      [deleted]
    - flohofwoe 2y ago
      > which is a major piece that needs to be solved with wasm generally. I use WASM everyday and I don't agree that this is anywhere near the top of the things that need to be fixed. The DOM is inherently slow by design, accessing it through a JS shim or "directly" from WASM really wouldn't make any difference in performance. And on the language level, the DOM is just another web API accessed through a wrapper library like https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html. Also the "fixed" Javascript is called Typescript (maybe combined with a very strict linter).
baq 2y ago
Until browsers ship with a standard distribution it’s going to be a pain to download <insert my favorite language> toolchain for each site. Not that it’d help much. Browsers aren’t 100% compatible between even their own releases with the one runtime they ship.
mjevans 2y ago
I guess we could all try to write things in WebAssembly hosted forth... however that sounds like a giant nightmare once I consider any project of scale and how it would be more like trying to mod a modern JIT program at runtime with reflection. https://www.google.com/search?q=web+assembly+forth https://www.google.com/search?q=web+assembly+forth I think the parent post wanted a more easily composed, modular sources of a whole, but better than JavaScript / ECMAScript. Intended to also have something similar to modern dev consoles attached with ease.
throwitaway1123 2y ago
> Most languages aren’t infinitely backwards-compatible so unless you want to be running Python 2.7 forever or whatever… This is an important point that I think gets overlooked quite a bit in these discussions. Web tech is essentially append only — you can add things but it's incredibly difficult for a browser vendor to make a breaking change because no vendor wants to be perceived as the one that "breaks the Web". Even technologies that were never technically standardized like Web SQL end up sticking around for far too long. I'm not sure if many programming language communities would like to be constrained by this and the slow TC39 language proposal process.
- DemocracyFTW2 2y ago
  > Web tech is essentially append only not if you implement backwards-compatible opt-outs for which see my reply concerning pragmas a la `'use strict'`
  - throwitaway1123 2y ago
    This is mostly conceptual rather than technical, but I view pragmas like use strict as an append operation. If browsers dropped sloppy mode completely and made strict mode the default for all scripts, then that would be a true delete operation. I wouldn't be surprised if browsers still support sloppy mode cruft like the with operator in 2034.
    - DemocracyFTW2 2y ago
      > I wouldn't be surprised if browsers still support sloppy mode cruft like the with operator in 2034 And may they do it, I don't care except for the weight of the little-used lines of code that are carried forward indefinitely. And it's not only 'append'; appending stuff we can without breaking backwards compatibility, it's the 'update' operations that curiously many view as infeasible despite there already being `'use strict'`.
      - throwitaway1123 2y ago

egeozcan 2y ago

But with WebAssembly, you need to DIY a lot and/or send a lot of runtime/stdlib code to the browser. It definitely has its place but something like Dart with excellent stdlib would be amazing (and I know that actually was the intent when Dart was being developed, I know, and I did oppose it at the time). Browsers then could ship different versions, and you can enable them, like "use strict" in js. On the other hand, I understand why not: You ship Dart and Python folk will be WTF, you ship Python and that would annoy the Java/.NET folk, and so on...

emseetech 2y ago

WebAssembly as a lower level abstraction is going to make web dev very interesting once the tech finally pays off, but it's been almost 10 years since it was announced and there's still no viable alternative to javascript to come out of it. It would have been nice if a cleaner, stricter and more "designed" alternative with full access to browser features had emerged in the meantime. I'd even accept Dart if it had managed to get broad browser support. Instead we're in a waiting game where we're all forced to use Javascript for any real work until the horizon is crossed and we can finally use a dozen of wasm-targeted languages.

flohofwoe 2y ago
> but it's been almost 10 years since it was announced and there's still no viable alternative to javascript to come out of it Are you aware if AssemblyScript? https://www.assemblyscript.org/ https://www.assemblyscript.org/ But arguably, the main purpose of WebAssembly is to use existing languages on the web, not necessarily invent new ones or even to replace Javascript.
- throwitaway1123 2y ago
  I've been following AssemblyScript for years but I can't recommend it until they figure out closures: https://github.com/AssemblyScript/assemblyscript/issues/798 https://github.com/AssemblyScript/assemblyscript/issues/798
- emseetech 2y ago
  AssemblyScript can't access the dom without interfacing with Javascript which is a major piece that needs to be solved with wasm generally. I'm arguing we should have invented a new native language to replace javascript, which could have provided a stop-gap solution until wasm targeted languages are viable.
  - deleted 2y ago
    [deleted]
  - flohofwoe 2y ago
    > which is a major piece that needs to be solved with wasm generally. I use WASM everyday and I don't agree that this is anywhere near the top of the things that need to be fixed. The DOM is inherently slow by design, accessing it through a JS shim or "directly" from WASM really wouldn't make any difference in performance. And on the language level, the DOM is just another web API accessed through a wrapper library like https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html. Also the "fixed" Javascript is called Typescript (maybe combined with a very strict linter).

baq 2y ago

Until browsers ship with a standard distribution it’s going to be a pain to download <insert my favorite language> toolchain for each site. Not that it’d help much. Browsers aren’t 100% compatible between even their own releases with the one runtime they ship.

mjevans 2y ago

I guess we could all try to write things in WebAssembly hosted forth... however that sounds like a giant nightmare once I consider any project of scale and how it would be more like trying to mod a modern JIT program at runtime with reflection. https://www.google.com/search?q=web+assembly+forth https://www.google.com/search?q=web+assembly+forth I think the parent post wanted a more easily composed, modular sources of a whole, but better than JavaScript / ECMAScript. Intended to also have something similar to modern dev consoles attached with ease.

throwitaway1123 2y ago

> Most languages aren’t infinitely backwards-compatible so unless you want to be running Python 2.7 forever or whatever… This is an important point that I think gets overlooked quite a bit in these discussions. Web tech is essentially append only — you can add things but it's incredibly difficult for a browser vendor to make a breaking change because no vendor wants to be perceived as the one that "breaks the Web". Even technologies that were never technically standardized like Web SQL end up sticking around for far too long. I'm not sure if many programming language communities would like to be constrained by this and the slow TC39 language proposal process.

DemocracyFTW2 2y ago
> Web tech is essentially append only not if you implement backwards-compatible opt-outs for which see my reply concerning pragmas a la `'use strict'`
- throwitaway1123 2y ago
  This is mostly conceptual rather than technical, but I view pragmas like use strict as an append operation. If browsers dropped sloppy mode completely and made strict mode the default for all scripts, then that would be a true delete operation. I wouldn't be surprised if browsers still support sloppy mode cruft like the with operator in 2034.
  - DemocracyFTW2 2y ago
    > I wouldn't be surprised if browsers still support sloppy mode cruft like the with operator in 2034 And may they do it, I don't care except for the weight of the little-used lines of code that are carried forward indefinitely. And it's not only 'append'; appending stuff we can without breaking backwards compatibility, it's the 'update' operations that curiously many view as infeasible despite there already being `'use strict'`.
    - throwitaway1123 2y ago