As a member of the Mozilla JS team, let me tell you that we're working on optimizing our engine for real-world usage all the time.

Some optimizations are better in SpiderMonkey than in v8, some are worse. Unfortunately, whenever a web developer optimizes solely for v8/Chrome, this hurts Firefox.

This might be a lot to ask of a random internet comment, but is there anything common you tend to see in apps that make them look/feel overtuned to v8?

I'll freely admit that i'm guilty of the "develop for chrome, test in firefox" kind of workflow, and I really want to improve on that. I feel like I have built up a kind of "intuition" about what works well and what doesn't over the years in chrome, and i'd like to start building that up for other browsers.

I'd guess a lot of that sort of optimization happens at the framework/library level (React, Emscripten, etc) and less so in your typical application code.

I have never once "optimized solely for V8" (I honestly have no idea what runs better in Chrome vs. Firefox).

All I know is that I build an app as I think makes sense logically, and 100% of the time it runs faster / less hot in Chrome.

JS-heavy apps burn thru CPU cycles far more on FF than in Chrome.

I want to use FF as my daily driver, I really do. But it's real-world performance just doesn't cut it for me, and I don't think you can blame that on people "solely optimizing for Chrome", as V8 was a better engine at the moment of release, when nobody had had a chance to optimize for it.

Do you develop and test using Chrome, or Firefox, or both? If you aren't testing in Firefox beyond "it displays correctly" but you are using Chrome for your normal development, and testing, you are de-facto optimizing for Chrome, because you'll notice slowness in Chrome and work around if, but that same thing may have been fast in Firefox, but you never noticed. That's what being the market leading browser grants them.

Do you happen to have a link to a specific thing you built that runs faster in Chrome? I'd love to take a look at what's going on there...

Real-world JS is optimized for V8.

Except you're reversing the order of the chicken and egg.

Real-world JS was already in production when V8 was released, and it had orders of magnitude better performance at the time.

I don't disagree at all, V8 was and still is revolutionary. However, the second order effect of V8 having captured such a large portion of the market is that developers will code/tweak/optimize until their app/library is suitably performant on V8 and then stop. No value judgement, it's totally rational but the effect is that now a lot of JS code has an implicit dependency on the quirks of V8 in order to be fast.

There's really no good solution to this because the kind of performance tuning we're talking about explicitly pierces veil the VM is supposed to provide. You're pretty much always going to target the internals of one particular engine. So what this means is that anyone working on a competing engine not only has to provide the same behavior but also the same performance profile because it's something that JS devs expect to be there now.