A point of reference
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Wed Mar 7 20:27:55 UTC 2018
On 3/7/2018 3:19 PM, Ben Bucksch wrote:
> Most of these are in the form of webapps replacing older native apps.
> Most users use Gmail instead of Thunderbird and Outlook. That includes
> power users that are speed-sensitive. In fact, that's Thunderbird's
> main competitor: webmail.
That's an apples-to-oranges comparison. An email client (to a first
approximation) is centered around a core database, and it's the database
operations that are performance sensitive. In the case of Gmail, the
performance-sensitive code is likely written in C++. It's certainly not
in JS, since it's not running on the user's side.
> See asm.js <https://en.wikipedia.org/wiki/Asm.js>. They've even
> compiled 3D game engines in JS and ran them at usable speeds, and a
> number of other applications.
> That proves that JS is suitable both for
> a) UI, including a mail client UI (see Gmail), and
> b) performance-sensitive core code (see asm.js-based projects).
Uh. You're misunderstanding asm.js. The point of asm.js was to say "we
can't build a good enough JIT for regular JS. We can use a subset of JS
instead to implement a language that we can implement a much better JIT
for." This concept was extended to WebAssembly, where the language drops
the ability to fallback to JS for VMs that don't support it. Note that
Chakra and SpiderMonkey explicitly uses different JITs for asm.js, and I
believe V8 and WebCore have asm.js-specific hooks in their JIT.
The point is: asm.js is not idiomatic JS. You cannot get asm.js
performance on regular JS code. You do not write asm.js code by hand.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning