Sure, but presumably a browser and the codebase has to support all of the apis and the entire specification. Would it not be able to optimize a browser if say, as the article claims, olnly ~17% of the features/apis need to be supported? Or would this totally not matter.
There is no way to be certain without digging in to the particular code in question. But "optimization" isn't just some magic pixie dust that you sprinkle on to a project and it makes things faster. Some things can't be optimized because they are already optimal. Some things shouldn't be "optimized" (e.g. for speed) because it would make the code less optimal (e.g. for understanding, maintaining, etc.).
The number of APIs available should be orthogonal to the issue of system performance. If it is not in particular cases, it's via bad overall system design, not the existence of the API in general.
> But "optimization" isn't just some magic pixie dust that you sprinkle on to a project and it makes things faster.
Correct, however periodically adding features by committee and backwardly processing and parsing tags and internal api implementations that are unused certainly must hamper performance. To some extent, I would assume the v8 or chakraCore engines are developed around interpreting javascript which includes languages pieces that have developed because of its close ties with the dom. So between the underlying interpreter engines, and all of the parse tooling for dom rendering and tag identification and css applications, I can only assume if it had 80% less overhead to expect, it could be faster.
So to the point
> The number of APIs available should be orthogonal to the issue of system performance. If it is not in particular cases, it's via bad overall system design, not the existence of the API in general.
That was the question I was asking.
1) is it possible to design a better system with many less considerations.
2) is it a bad overall design?
Again, I have to assume that if we raieded the codebase and rewrote it minus 80% of the legacy shit, we could do a better job, but maybe not.