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.