8 ms·

Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.

em-bee 2y ago
good point. in a sense webassembly is that minimal very performant language. let javascript and typescript compile to webassembly, and you essentially got what is being proposed here
- sshine 2y ago
  WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity. But there's still far to go. Large parts of the browser API are still not directly available in WASM. I very much look forward to WASM reaching stability. It's very enjoyable to run Rust code in the browser.
  - em-bee 2y ago
    right, making those APIs accessible from WASM is something i am also waiting for.
    - croes 2y ago
      So you want more rights for code that’s harder to read than obfuscated JS?
  - xscott 2y ago
    What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.
    - em-bee 2y ago
      direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
      - peutetre 2y ago
        Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
        emseetech 2y ago
        Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.
        xscott 2y ago
        What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
        anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
- hn_throwaway_99 2y ago
  I commented this elsewhere, but the funny thing is that asm.js was the precursor to WebAssembly, and this proposal is essentially asking for asm.js back again.
fny 2y ago
Assembly is not a language runtime. Even if you had WebAssembly as the core, you'd still need to compile JavaScript to WebAssembly, manage the GC, etc which all would still suffer from the performance implications mentioned in the article. Also... do you really think its wise to rewrite v8 to target WebAssembly?
- peutetre 2y ago
  It already supports WebAssembly. All browsers do. Here's a demo of Dart and Flutter compiled to WebAssembly: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript? Google has started migrating parts of Google Sheets to WebAssembly. They're compiling Java to WebAssembly and seeing a 100% performance increase: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc Amazon has been migrating its Prime Video app from JavaScript to WebAssembly. They're compiling Rust to WebAssembly and they've seen increased performance and lower memory usage: https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-...
  - wiseowise 2y ago
    [flagged]
    - a57721 2y ago
      Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.
      - wiseowise 2y ago
        Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle. It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd. Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while. Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS. > designed much later and not so hastily, so they have less warts than JavaScript as a result. That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.
rafaelmn 2y ago
Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it. Keep the single threaded event loop approach but kill the JS semantics.
- peutetre 2y ago
  Garbage collection is solved to the extent that host garbage collection is now available via WasmGC: https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting But languages like C# want more features in WasmGC: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420 No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.
  - singularity2001 2y ago
    The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.
- nikeee 2y ago
  Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages. I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView. There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well. [1]: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
  - rafaelmn 2y ago
    Problem with AST is that it still kind of forces JS semantics which we should be working away from if we're doing this big leap.
RandomThoughts3 2y ago
Then you add capability to hide the browser chrome and build close to native user experience and we will have truly looped the loop. Think about that: the browser as an intermediation ensuring resources are properly shared and each application is shielded from the others. Everything that’s old is new again. /s On a serious note I don’t see the point in turning browsers into an OS on top of the OS. I know it’s some kind of Google wet dream so they can suck up even more data than they already do but still. If you want to ship applications, just do that. The sandboxing should be done at the OS level where it belongs.
- anonzzzies 2y ago
  I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.
jokethrowaway 2y ago
Yes and no, there is a significant bundle size problem with wasm which is hard to fix. I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications. What's more likely is that all of this will probably be eclipsed by LLM and virtual assistants - which could be controlled by native apps with a dynamically generated GUI or voice. I think APIs exposing data and executing functions will fundamentally change what we think the web is.
- peutetre 2y ago
  > I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications Here you go. Do both native and wasm: https://avaloniaui.net/ https://avaloniaui.net/ https://platform.uno/ https://platform.uno/ https://flutter.dev/ https://flutter.dev/ Flutter example: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/
  - ec109685 2y ago
    Not that please. The flutter example took 20 seconds to load and the scroll is super choppy. It’s unfortunate there isn’t a more native “app like” UI toolkit. Especially on mobile, web apps generally are bad and a lot of the reason is trying to shoehorn an app experience onto the dom.
    - peutetre 2y ago
      It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly. If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
- akira2501 2y ago
  > I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications. Go back to garbage "cross platform" UI toolkits and having to help users manage software dependencies on their machine? No thanks.

em-bee 2y ago

good point. in a sense webassembly is that minimal very performant language. let javascript and typescript compile to webassembly, and you essentially got what is being proposed here

sshine 2y ago
WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity. But there's still far to go. Large parts of the browser API are still not directly available in WASM. I very much look forward to WASM reaching stability. It's very enjoyable to run Rust code in the browser.
- em-bee 2y ago
  right, making those APIs accessible from WASM is something i am also waiting for.
  - croes 2y ago
    So you want more rights for code that’s harder to read than obfuscated JS?
- xscott 2y ago
  What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.
  - em-bee 2y ago
    direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
    - peutetre 2y ago
      Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
      - emseetech 2y ago
        Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.
        xscott 2y ago
        What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
        anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
hn_throwaway_99 2y ago
I commented this elsewhere, but the funny thing is that asm.js was the precursor to WebAssembly, and this proposal is essentially asking for asm.js back again.

fny 2y ago

Assembly is not a language runtime. Even if you had WebAssembly as the core, you'd still need to compile JavaScript to WebAssembly, manage the GC, etc which all would still suffer from the performance implications mentioned in the article. Also... do you really think its wise to rewrite v8 to target WebAssembly?

peutetre 2y ago
It already supports WebAssembly. All browsers do. Here's a demo of Dart and Flutter compiled to WebAssembly: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript? Google has started migrating parts of Google Sheets to WebAssembly. They're compiling Java to WebAssembly and seeing a 100% performance increase: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc Amazon has been migrating its Prime Video app from JavaScript to WebAssembly. They're compiling Rust to WebAssembly and they've seen increased performance and lower memory usage: https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-...
- wiseowise 2y ago
  [flagged]
  - a57721 2y ago
    Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.
    - wiseowise 2y ago
      Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle. It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd. Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while. Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS. > designed much later and not so hastily, so they have less warts than JavaScript as a result. That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.

rafaelmn 2y ago

Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it. Keep the single threaded event loop approach but kill the JS semantics.

peutetre 2y ago
Garbage collection is solved to the extent that host garbage collection is now available via WasmGC: https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting But languages like C# want more features in WasmGC: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420 No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.
- singularity2001 2y ago
  The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.
nikeee 2y ago
Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages. I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView. There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well. [1]: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
- rafaelmn 2y ago
  Problem with AST is that it still kind of forces JS semantics which we should be working away from if we're doing this big leap.

RandomThoughts3 2y ago

Then you add capability to hide the browser chrome and build close to native user experience and we will have truly looped the loop. Think about that: the browser as an intermediation ensuring resources are properly shared and each application is shielded from the others. Everything that’s old is new again. /s On a serious note I don’t see the point in turning browsers into an OS on top of the OS. I know it’s some kind of Google wet dream so they can suck up even more data than they already do but still. If you want to ship applications, just do that. The sandboxing should be done at the OS level where it belongs.

anonzzzies 2y ago
I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.

jokethrowaway 2y ago

Yes and no, there is a significant bundle size problem with wasm which is hard to fix. I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications. What's more likely is that all of this will probably be eclipsed by LLM and virtual assistants - which could be controlled by native apps with a dynamically generated GUI or voice. I think APIs exposing data and executing functions will fundamentally change what we think the web is.

peutetre 2y ago
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications Here you go. Do both native and wasm: https://avaloniaui.net/ https://avaloniaui.net/ https://platform.uno/ https://platform.uno/ https://flutter.dev/ https://flutter.dev/ Flutter example: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/
- ec109685 2y ago
  Not that please. The flutter example took 20 seconds to load and the scroll is super choppy. It’s unfortunate there isn’t a more native “app like” UI toolkit. Especially on mobile, web apps generally are bad and a lot of the reason is trying to shoehorn an app experience onto the dom.
  - peutetre 2y ago
    It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly. If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
akira2501 2y ago
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications. Go back to garbage "cross platform" UI toolkits and having to help users manage software dependencies on their machine? No thanks.