> As others have pointed out, Mozilla has been less than receptive when similar situations were reversed.
That's a long conversation, and I likely know nothing of the non-public aspects of it. From what I know of the public stuff, I don't think it is the same in reverse. I do see the general similarity you refer to, I just think there are some fundamental differences that explain the different responses.
Happy to discuss this more if you want.
> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention.
I still don't know what you mean, can you please say what concretely in the spec you are referring to?
>> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention.
>I still don't know what you mean, can you please say what concretely in the spec you are referring to?
You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at. To make that performant you have to hack in things like manual memory management and use type coercions to game existing engine behavior. To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler. And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense.
And I happily admit that type coercions and similar tricks are a very clever way to structure your IR while simultaneously maintaining compatibility and improving performance in existing JS engines. However, in doing so you're already relying heavily on unspecced implementation details of existing engines.
So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved.
> You're using a subset of JS as an IR, which is something the language was never designed for and not inherently good at
I agree it was not designed for it. However I a not sure what "inherently good at" means - after v8 showed up in 2008, for example, many types of code suddenly became very fast. Were they always inherently fast?
> To get full performance you need significant engine changes including a mode switch, validation step, and special purpose compiler.
I disagree. Firefox did pick that option because it seemed best, but I believe it is possible to achieve similar speeds with other approaches. As the slide here shows,
on many benchmarks, even without any new optimizations modern JS engines are already fast on asm.js code. And with new optimizations, even without things you just mentioned, they should be able to get fast on the rest. I saw some activity on the v8 bug tracker indicating possible work in that direction, which I am very curious and hopeful about.
> And of course, the JS as IR doesn't really qualify as human readable in any meaningful sense.
Yes, it is not intended to be - like the output of closure compiler, etc. Note though that emscripten can generate asm.js in debug mode, which is not minified, and actually quite readable - you can recognize function and variable names, for example. It looks a little quirky to be sure ;) but it is more readable than compiler IRs like LLVM for example, in my opinion (and certainly far more readable than x86 or ARM assembly).
> However, in doing so you're already relying heavily on unspecced implementation details of existing engines.
Performance is not specced at all for JavaScript. Again, when v8, nitro and tracemonkey came out in 2008-2009, many types of JS code suddenly got fast. There wasn't a spec for any of that. No one says modern JS engines should use int32 when a value never goes out of the int32 range, but all modern JS engines do that (in hot functions).
> So, my point is that it's a hack... a really brilliant hack that might actually be the best path forward for a universal IR on the Web. But it's still a hack, and it brings with it some serious pain points that still need to be resolved.
I fully agree it is a hack, and it has various pain points. It's a compromise, not a clean solution from scratch. I hope we can resolve many of those pain points in time, and that we can do that in collaboration with all browser vendors together.
That's a long conversation, and I likely know nothing of the non-public aspects of it. From what I know of the public stuff, I don't think it is the same in reverse. I do see the general similarity you refer to, I just think there are some fundamental differences that explain the different responses.
Happy to discuss this more if you want.
> Perhaps "quirks" isn't the right word for things that are idiosyncratic but legal either by standard or de facto convention.
I still don't know what you mean, can you please say what concretely in the spec you are referring to?