4 ms·

well, WASM is going to change things a lot I think over the next 5 or so years. Things like https://blazor.net/ https://blazor.net/ (though not necessarily the

well, WASM is going to change things a lot I think over the next 5 or so years. Things like https://blazor.net/ https://blazor.net/ (though not necessarily the first wave of these frameworks) are going to become more popular, and there are various variants in other languages. I think there will be a slow (very very slow) decline of js

slightlyoff 8y ago
The "hello world" demo app appears to require ~1.3MB of transfer, nearly all of it critical-path: https://blazor-demo.github.io/ https://blazor-demo.github.io/ This future isn't better.
- pjmlp 8y ago
  Most images on the modern Web are bigger than that and pages are full of them. Also that is still WIP and doesn't yet make use of .NET linker.
  - slightlyoff 8y ago
    Images aren't as expensive as critical-path code as we (the browser) parse and raster them off-thread. Outlined some of the costs here: https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... Excited to see how much smaller a good linker can make this.
    - pjmlp 8y ago
      JavaScript JIT compilers also don't compile everything on one go. I can easily imagine asynchronous compilation of Web Assembly modules in background threads as its use increases.
      - slightlyoff 8y ago
        WASM streaming compilation is possible today and runtimes are adding tiered compilers: https://v8project.blogspot.com/2018/08/liftoff.html https://v8project.blogspot.com/2018/08/liftoff.html Regardless, as long as you're network-bound in the critical-path, that will only help to the extent that partial execution works well. That is baked into HTML/CSS/JS; not so much with WASM.
        dikaiosune 8y ago
        How is partial execution baked into JS? IIUC, my whole JS file is fully parsed an resolved before it is evaluated. If you're referring to the use of multiple files for parallelism here, then the obstacle there is not wasm itself but the work that's still in progress to define a dynamic linking story for it. I'd point out that the need for better dynamic linking to enable lower TTI is also a problem faced in the bundling/tooling heavy JS community.
        slightlyoff 8y ago
        JavaScript can be evaluated top-level function by top-level function and file-by-file, modulo variable hoisting. You can create situations where everything is blocked, but that's not the norm.
        dikaiosune 8y ago
        Do you have numbers for how much of the web avoids variable hoisting? How much of the web has more than one top-level fn per file? Do these numbers shift significantly between different toolchains or methods of delivering JS?
    - dikaiosune 8y ago
      It would be interesting to try for some apples-to-apples comparisons for the parse and initial exec time of js vs wasm. The latter was designed with the goal of streaming validation and compilation, js needs to have a lot of work done before it can load. Which strongly suggests to me that intuitions about KBs-of-JS vs KBs-of-Wasm are likely to be wrong, especially as the state of wasm implementations improves.
btrettel 8y ago
WebAssembly could make things worse. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
- Animats 8y ago
  Much worse. Hostile code you can't block.
jillesvangurp 8y ago
Agreed, once the final missing pieces are in place (mainly garbage collection at this point) javascript will be an opt in kind of thing rather than the only available choice. Personally, I might get my hands dirty with Kotlin on the frontend. I'm using it on the backend currently so the transition should be relatively smooth for me and I have some crappy JS code that I would love to get rid of at the earliest convenient moment. I imagine there are also a lot of Android developers that might be willing to work on Kotlin based web apps that like me would prefer to not deal with Javascript. I imagine short term things will be a bit rough as tooling and frameworks are still evolving. But as that improves, there will be a very sharp increase in the amount of non JS code running in browsers. Currently the big milestones for Kotlin would be the 1.0 release of the native compiler (0.8 is the latest, I believe), related work on WASM support, and the finalization of things like garbage collection in WASM. Looks like that should all be happening over the next 6-12 months.
mr_toad 8y ago
Embedding an language runtime for something like C# is never going to improve performance. You’re still bound by the speed of the browser engine, and now you’re layering an extra interpreter on top. Projects like this are exactly what the author was complaining about - good for .Net developers who don’t want to learn JS and Rust, bad for user experience.

slightlyoff 8y ago

The "hello world" demo app appears to require ~1.3MB of transfer, nearly all of it critical-path: https://blazor-demo.github.io/ https://blazor-demo.github.io/ This future isn't better.

pjmlp 8y ago
Most images on the modern Web are bigger than that and pages are full of them. Also that is still WIP and doesn't yet make use of .NET linker.
- slightlyoff 8y ago
  Images aren't as expensive as critical-path code as we (the browser) parse and raster them off-thread. Outlined some of the costs here: https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... Excited to see how much smaller a good linker can make this.
  - pjmlp 8y ago
    JavaScript JIT compilers also don't compile everything on one go. I can easily imagine asynchronous compilation of Web Assembly modules in background threads as its use increases.
    - slightlyoff 8y ago
      WASM streaming compilation is possible today and runtimes are adding tiered compilers: https://v8project.blogspot.com/2018/08/liftoff.html https://v8project.blogspot.com/2018/08/liftoff.html Regardless, as long as you're network-bound in the critical-path, that will only help to the extent that partial execution works well. That is baked into HTML/CSS/JS; not so much with WASM.
      - dikaiosune 8y ago
        How is partial execution baked into JS? IIUC, my whole JS file is fully parsed an resolved before it is evaluated. If you're referring to the use of multiple files for parallelism here, then the obstacle there is not wasm itself but the work that's still in progress to define a dynamic linking story for it. I'd point out that the need for better dynamic linking to enable lower TTI is also a problem faced in the bundling/tooling heavy JS community.
        slightlyoff 8y ago
        JavaScript can be evaluated top-level function by top-level function and file-by-file, modulo variable hoisting. You can create situations where everything is blocked, but that's not the norm.
        dikaiosune 8y ago
        Do you have numbers for how much of the web avoids variable hoisting? How much of the web has more than one top-level fn per file? Do these numbers shift significantly between different toolchains or methods of delivering JS?
  - dikaiosune 8y ago
    It would be interesting to try for some apples-to-apples comparisons for the parse and initial exec time of js vs wasm. The latter was designed with the goal of streaming validation and compilation, js needs to have a lot of work done before it can load. Which strongly suggests to me that intuitions about KBs-of-JS vs KBs-of-Wasm are likely to be wrong, especially as the state of wasm implementations improves.

btrettel 8y ago

WebAssembly could make things worse. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox

Animats 8y ago
Much worse. Hostile code you can't block.

jillesvangurp 8y ago

Agreed, once the final missing pieces are in place (mainly garbage collection at this point) javascript will be an opt in kind of thing rather than the only available choice. Personally, I might get my hands dirty with Kotlin on the frontend. I'm using it on the backend currently so the transition should be relatively smooth for me and I have some crappy JS code that I would love to get rid of at the earliest convenient moment. I imagine there are also a lot of Android developers that might be willing to work on Kotlin based web apps that like me would prefer to not deal with Javascript. I imagine short term things will be a bit rough as tooling and frameworks are still evolving. But as that improves, there will be a very sharp increase in the amount of non JS code running in browsers. Currently the big milestones for Kotlin would be the 1.0 release of the native compiler (0.8 is the latest, I believe), related work on WASM support, and the finalization of things like garbage collection in WASM. Looks like that should all be happening over the next 6-12 months.

mr_toad 8y ago

Embedding an language runtime for something like C# is never going to improve performance. You’re still bound by the speed of the browser engine, and now you’re layering an extra interpreter on top. Projects like this are exactly what the author was complaining about - good for .Net developers who don’t want to learn JS and Rust, bad for user experience.