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.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist



More information about the tb-planning mailing list