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.
> 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.
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).
By that logic it was a waste of time for Firefox to exist -- there was already IE, or it was a waste of time for webkit to exist as there was already khtml, or blink because webkit, etc, etc
People only caring about one browser is exactly what caused ie6 to become such a problem - everyone had to reverse engineer whatever it was doing because nothing was specified.
> By that logic it was a waste of time for Firefox to exist -- there was already IE,
No, IE would need be to be open source for that logic to be applicable there, since the idea is to use a well-developed open source code base instead of rolling your own thing.
> or it was a waste of time for webkit to exist as there was already khtml, or blink because webkit,
You actually undercut your own point with these examples: WebKit was a fork of KHTML, Blink was a fork of WebKit. The developers in question believed that it would have been a waste of time to start from scratch, and so they didn't!
Maybe, but they were only possible because web developers had started considering Firefox in addition to IE. Even then the amount of time spent reverse engineering IE behavior was absurd - when webkit forked khtml it could not render yahoo.om correctly (it mattered then ;) ).
This post is saying you only need to test chrome because it’s 80% of the market. Back in the day IE was more than 90% of the market.
If all you do is test on chrome you force every competitor to reverse engineer chrome (you can’t fork chrome to make a gpl browser). Alternatively you give up and just use chrome (skinned or not), and that dictates the features you get (I don’t see chrome getting built in tracker blocking any time soon).
You can’t use alternative browsers because the web is filled with sites that are only tested on chrome.
No, it's not like IE at all because IE was closed source. This was what I was trying to say earlier: the whole reason IE was "bad" was because it stagnated, which would not have been possible if it was open source. In this case, it's more like Linux.
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.
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.
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.