There are rather substantive differences. For starters, the CLR doesn't have to be the IL anymore; since Roslyn and the WinRT framework, you can compile down to native code. However, the most important things are what the CLR gives to the developer that Javascript doesn't.
Syntax-wise, the CLR's threading is much more flexible -- you can have your workers talk to each other directly when that's the most convenient way of doing things, instead of the Web Workers model where everything has to pass through the main thread. The CLR also supports more than two number types, which is useful in a number of situations, such as art programs, where most if not all of your actions are going to be against smaller types. Web Assembly fixes some of these problems, like providing reasonable number types, but at the same time, ignores other flaws that still exist, like a lack of vector types, which is something nearly every modern processor has and uses for improved performance.
The problem with Javascript, and its various extensions and adjuncts is that it still suffers from the same walled-off mindset that it has for the past fifteen years. Numbers are numbers and you're crazy if you want anything other than these beautiful 64 bit floats, a compact, easy to parse bytecode format is an affront to the open web, even if the alternative is a hack that is just as unreadable, and threading will just lead to programs crashing. Javascript may be fine if you're delivering a web page, but the tools it gives make it woefully unusable for near anything else.
Nope. asm.js as implemented in Firefox supports native integers and SIMD. SharedArrayBuffer gives you threads--but honestly this is a red herring, with apps barely making any use of multicore and iPhones being limited to 2 cores anyway. Web Assembly gives you 64 bit ints.
"Compact, easy to parse bytecode" is also irrelevant. JS is easy to parse. And the parser is such a tiny part of a JS engine it doesn't matter at all in practice for complexity. It's an aesthetic concern.
The actual performance problems Web apps hit have nothing at all to do with any of the areas you describe anyway. You think the Facebook app is making heavy use of custom SIMD or multicore? The SIMD support in Firefox gets barely any use because apps can't find a use for it. Apple isn't adding cores to their phones because apps aren't using them. And so on.
Apps barely making use of multicore? Maybe in your web world.
We would not have been able to ship the apps we've shipped were it not for being able to exploit shared state concurrency.
... and yes, I think the Facebook app is making heavy use of multicore and SIMD; multicore directly, and SIMD by way of the heavily optimized native frameworks shipped with the device.
I've previously made of NEON to get ideal performance out of critical path file decoding on lower end devices, where having those additional CPU cycles available made the difference between stuttering and smooth UI.
Stop trying to fit native apps into a box you've defined to match your web-centric experience, where low expectations are simply the norm.
If apps were using multicore all over the place, the hardware vendors would have responded by increasing the number of cores on the CPU as they planned to. Instead, they didn't, because people aren't using it.
I don't see any particular use the Facebook app would possibly have for multicore. Image and video decoding perhaps, but browsers already multithread those.
The point about native frameworks making use of SIMD applies equally to the SIMD that the browser engine components internally use.
Finally, I've been writing native code almost exclusively for the past five years.
In this context threading is less about making maximum use of multiple cores and more about "never blocking the main/UI thread". Even on a single core device you usually need to start offloading heavy computation to a background thread to keep the UI responsive.
Even today I'll run into websites that lock up a browser tab because they're running a whole mess of Javascript soup (typically jQuery). I know we were promised WebWorkers like 5 years ago but does anyone actually use them?
Yes, I fully agree that this is one of the biggest problems. Web developers don't treat Web Workers like they treat Blocks in Objective-C, and this is causing performance problems. On the engine side, we have to figure out how to make workers and off-main-thread work just as easy to use as in Objective-C and Java--I believe this is doable with effort.
Multicore isn't free in a battery constrained device, and yet devices are multicore. The fact that you don't have an 8 core phone doesn't mean multicore concurrency isn't used.
There are all sorts of things that benefit from multicore concurrency; a simple example is keeping data handling (including SQLite query execution, which has a non-zero cost) off of the UI thread that's responsible for keeping table scrolling glossy smooth.
You may have been writing native code, but you clearly haven't been shipping high gloss end-user applications on mobile devices.
Concurrency is not parallelism, and you're conflating the two. Multicore is for parallelism: literally doing multiple tasks at the same time. Apps are not making good use of parallelism. Apps certainly do make good use of concurrency--your example of moving background work off the UI thread is an example of that--and the Web needs to support that better. But that's not a parallelism problem, and it's not related to multicore: note that what you describe is a good idea even with only one CPU.
> but you clearly haven't been shipping high gloss end-user applications on mobile devices.
Yes, I have. Can I suggest you stop inserting these random jabs into your posts?
Syntax-wise, the CLR's threading is much more flexible -- you can have your workers talk to each other directly when that's the most convenient way of doing things, instead of the Web Workers model where everything has to pass through the main thread. The CLR also supports more than two number types, which is useful in a number of situations, such as art programs, where most if not all of your actions are going to be against smaller types. Web Assembly fixes some of these problems, like providing reasonable number types, but at the same time, ignores other flaws that still exist, like a lack of vector types, which is something nearly every modern processor has and uses for improved performance.
The problem with Javascript, and its various extensions and adjuncts is that it still suffers from the same walled-off mindset that it has for the past fifteen years. Numbers are numbers and you're crazy if you want anything other than these beautiful 64 bit floats, a compact, easy to parse bytecode format is an affront to the open web, even if the alternative is a hack that is just as unreadable, and threading will just lead to programs crashing. Javascript may be fine if you're delivering a web page, but the tools it gives make it woefully unusable for near anything else.