5 ms·

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

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.

pcwalton 11y ago
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.
- teacup50 11y ago
  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.
  - pcwalton 11y ago
    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.
    - nodamage 11y ago
      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?
      - pcwalton 11y ago
        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.

pcwalton 11y ago

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.

teacup50 11y ago
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.
- pcwalton 11y ago
  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.
  - nodamage 11y ago
    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?
    - pcwalton 11y ago
      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.