5 ms·

The performance gain are so small , its not worth this setup overhead . The average user won’t see the difference. Hence , the simplicity of’this module . Just

by asien 8y ago

The performance gain are so small , its not worth this setup overhead . The average user won’t see the difference. Hence , the simplicity of’this module . Just do it in JS , chrome as 70% market share why would you ever bother ? V8 has received decades of optimizations and it can easily compete with compiled languages in terms of speed. I was hyped to death for WASM , but this is the tenth article I’m reading on this subject and I still ending on the same conclusion : there is no advantage for front end developers to use WASM. Only Rendering Engine ( Unity , Adobe Products, Autodesk ) can really benefits from this.

writepub 8y ago
The article sets out to prove the predictability of WASM's performance, and not necessarily a performance gain wrt js. > This confirms what we laid out at the start: WebAssembly gives you predictable performance. No matter which language we choose, the variance between browsers and languages is minimal If you're not hyped about WASM, it's probably because your app and customer base's browser preferences are on the js engine's JIT happy-path, which could hold true for most apps. There could very easily be a js path that is significantly worse in performance on chrome, just saying, 70% market share is both a blessing and a curse. Another major reason for WASM hype is for C#, Rust, C, C++, Go devs to reach parity with js in terms of web accessibility. Frameworks like Blazor (from MSFT) have taken all the best practices & advantages of React and made them available to C# devs.
- pjmlp 8y ago
  > have taken all the best practices & advantages of React and made them available to C# devs. The irony is that C# devs were the first to use reactive programming before React even existed.
news_to_me 8y ago
> chrome [h]as 70% market share why would you ever bother ? This view seriously needs to die. It's honestly not that hard to test in two or three browsers, and the differences are minor enough that it isn't a pain. But the only way that's possible is through Web standardization, which only happens when there are diverse options. As web developers, it's our duty to keep the web healthy, and that means not only optimizing for a single browser.
- outworlder 8y ago
  Agreed. This is IE 6.0 all over again.
  - shpx 8y ago
    With the exception that Chrome is a good browser.
    - L-four 8y ago
      I.E. 6 was a good browser when it was released too.
    - recursive 8y ago
      When IE6 was released it was much better than the nearest competitor. But stagnating for 6 years made it become basically one of the worst.
    - olliej 8y ago
      While msft did abuse their position to solidify an IE centric world, people need to realize that when ie4/5/6 were released they were dramatically better than the competitors. The problem is that post-domination they simply stagnated and so the design shortcomings start being a problem. It needs to be repeated: at the time IE /was/ a good browser. Just like chrome today. And similar to chrome played fast and loose with web exposed features. Sometimes for the better (XHR was an IE invention), sometimes for worse (so was activeX).
      - cesarb 8y ago
        > Sometimes for the better (XHR was an IE invention), sometimes for worse (so was activeX). Wasn't XMLHttpRequest an ActiveX object?
    - taf2 8y ago
      and an open source browser with at least 2 major browser vendors using it's core rendering engine... Edge and Opera
devwastaken 8y ago
Chrome hasn't optimized wasm very well yet. Wasm isn't and never was meant for frontend. It's meant for crunching data and making it possible to use the thousands of C libs computers run on to have a safe and efficient execution environment that is not restrained by the host software having implimented that C lib directly. For example there was this app in C# that would convert images into 512 color palette and use dithering to retain some quality. I made a version in the browser, but because of js being too slow it didn't work for large images. Thing is, mine was far safer and accessible than the C# program.

by asien 8y ago

writepub 8y ago

The article sets out to prove the predictability of WASM's performance, and not necessarily a performance gain wrt js. > This confirms what we laid out at the start: WebAssembly gives you predictable performance. No matter which language we choose, the variance between browsers and languages is minimal If you're not hyped about WASM, it's probably because your app and customer base's browser preferences are on the js engine's JIT happy-path, which could hold true for most apps. There could very easily be a js path that is significantly worse in performance on chrome, just saying, 70% market share is both a blessing and a curse. Another major reason for WASM hype is for C#, Rust, C, C++, Go devs to reach parity with js in terms of web accessibility. Frameworks like Blazor (from MSFT) have taken all the best practices & advantages of React and made them available to C# devs.

pjmlp 8y ago
> have taken all the best practices & advantages of React and made them available to C# devs. The irony is that C# devs were the first to use reactive programming before React even existed.

news_to_me 8y ago

> chrome [h]as 70% market share why would you ever bother ? This view seriously needs to die. It's honestly not that hard to test in two or three browsers, and the differences are minor enough that it isn't a pain. But the only way that's possible is through Web standardization, which only happens when there are diverse options. As web developers, it's our duty to keep the web healthy, and that means not only optimizing for a single browser.

outworlder 8y ago
Agreed. This is IE 6.0 all over again.
- shpx 8y ago
  With the exception that Chrome is a good browser.
  - L-four 8y ago
    I.E. 6 was a good browser when it was released too.
  - recursive 8y ago
    When IE6 was released it was much better than the nearest competitor. But stagnating for 6 years made it become basically one of the worst.
  - olliej 8y ago
    While msft did abuse their position to solidify an IE centric world, people need to realize that when ie4/5/6 were released they were dramatically better than the competitors. The problem is that post-domination they simply stagnated and so the design shortcomings start being a problem. It needs to be repeated: at the time IE /was/ a good browser. Just like chrome today. And similar to chrome played fast and loose with web exposed features. Sometimes for the better (XHR was an IE invention), sometimes for worse (so was activeX).
    - cesarb 8y ago
      > Sometimes for the better (XHR was an IE invention), sometimes for worse (so was activeX). Wasn't XMLHttpRequest an ActiveX object?
  - taf2 8y ago
    and an open source browser with at least 2 major browser vendors using it's core rendering engine... Edge and Opera

devwastaken 8y ago

Chrome hasn't optimized wasm very well yet. Wasm isn't and never was meant for frontend. It's meant for crunching data and making it possible to use the thousands of C libs computers run on to have a safe and efficient execution environment that is not restrained by the host software having implimented that C lib directly. For example there was this app in C# that would convert images into 512 color palette and use dithering to retain some quality. I made a version in the browser, but because of js being too slow it didn't work for large images. Thing is, mine was far safer and accessible than the C# program.