Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).
Nice to hear from you! Yes it was a very reasonable choice back then, before (enormous) asm.js and Wasm functions.
The compiler wasn't really designed for these huge graphs, but fortunately a lot of the issues can be fixed incrementally and it's still holding up well.
I think part of this is just time to get used to something new? You might notice some improvements too, for instance only after I started using Fastmail I realized the Gmail UI can be pretty slow and heavyweight although I never noticed this before.
> With Fastmail or another provider, you're trusting another corp.
You're trusting a corp that offers customer support, a service you pay them for. With Gmail you're completely on your own because you're only a small cog in the massive data mining machine. That's a pretty big difference.
That said, it's a good idea to set up a custom domain with a trusted registrar.
I migrated to Fastmail a few weeks ago. I'm really happy with it and I wish I had done it years ago. Many features. The web interface and apps feel a lot faster than Gmail.
Pro-tip: use a custom domain so that you can easily switch e-mail providers in the future without vendor lock-in. It's also very easy to add aliases in Fastmail.
> Plus after the import is finished, it will still periodically bring over any new emails received to the Gmail account.
Another option is to let Gmail forward your email to the new address.
Another protip: fastmail lets you alias yourname@yourdomain.com as anything@yourname.yourdomain.com. You can use this feature to create a unique email address for every service you sign up for. This is really handy for filtering to folders, or blocking marketing spam.
Still on the G-Train. While I am thinking about migration back to my own hosted versions, I currently do this with Google Groups. I have many groups (amazon@..., newsletter@..., spam@...) for many different use cases. Though I have not yet created a catch all...
This thread prompted me to dig into it and I found a blog posting describing the process [1]. Will try this - while still digging deeper into the migration topic.
> It’s a big deal and everyone who contributed should be super proud.
Thanks! We actually haven't really analyzed Speedometer (and most other benchmarks) yet with Warp so I expect this number to improve the coming months. The design seems to be holding up well and we're really excited about building on this.
Happy hacking! It’s good to see another JS compiler get brought up. I strongly suspect that our community hasn’t yet found the perfect kind of combo of tiers for JS; the more we try stuff the closer we will get.
SpiderMonkey dev here. Does this reproduce for you with a clean profile? Because I just tried this with 78.0b9 too and for the first one, Local (original), I get 6.7 ms in the Web Console, very similar to what I see in Chrome. I didn't look at the other ones.
Hello! Many apologies for having taken a while to reply, I finally found some time to sit down and do some tests because > 200 ms vs. < 10 ms is too big of a difference, and also because of what london_explore said:
> and if that performs badly, open a bug with V8 or other JavaScript engines to optimize it.
Anyhow! Just to clarify before moving on, I also did the tests in the Web Console. All numbers noted below are for the same (first) test I initially mentioned.
What I have done in exactly the same order as follows:
1. I first tested with a clean profile as you suggested and the times haven't changed. ~240 ms was observed.
2. I downloaded Firefox and tested with a clean installation of 77.0.1. ~240 ms was observed.
3. I removed both Firefox (77.0.1) and Firefox Developer edition (78.09b), and manually removed the ~/Library/Application Support/Firefox folder. I then reinstalled Firefox Developer edition (78.09b) and, without restoring my profiles, I tested again. ~240 ms was observed.
4. I re-ran exactly the same tests on NodeJS and Chrome. ~6 ms was observed.
Assuming that it's just me, I can't immediately think of what is causing this.
Otherwise, if it's not just my setup, could it be related to the operating system? I'm currently running macOS 10.15.5. I don't have a machine with a different OS that I can test on at the moment, I should be able to try this in the next 2 hours and will update this post.
Edit: I have tested on Windows 10 as well and the issue is the same!
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).