Saying goodbye to asm.js
30 points by jmillikin
30 points by jmillikin
This is reasonable, though I’m not sure it it needed to be deliberately and completely “turned off” so much as just isolated and effectively frozen. But I suppose just the theoretical possibility of maintenance issues, the siren call of stripping out code, and the reduction in potential surface area for attacks can all act as mighty motivators.
the theoretical possibility of maintenance issues
reduction in potential surface area for attacks
From experience, these are not just theoretical possibilities :)
At $work we had 0.1% of our traffic using a legacy API that was 10-20% of our codebase, so we literally forked the repo (we wanted to do this for other reasons), stripped the old version out, then removed the "new" code from the original and stood it up as a separate service. It was immensely satisfying. We also already knew ahead of time who would be the one to send out the mass code deletion PRs (the guy who had suffered the most at the hands of the old code :D )
(We want to kill the old service, but converting the 0.1% of callers to the new API isn't worth it since the callers are also being deprecated.)
Of course, but I meant it from the perspective of “it’s hard to say without seeing how the code is structured because it could (and it would be nice if it were) already self-contained enough that you could just leave it be” and as for security, I left that open ended as I’m not sure how sandboxed the asm.js interpreter/pipeline was such that maybe the only concern is if we get another Spectre-like incident where supported primitive like performance.now() need to be neutered.