Hacker News new | ask | show | jobs
by vonklaus 3681 days ago
I don't know this to be true, but my assumption as someone not building the interpreter/vms for JS is that if you eliminated all of that shit you could probably get a much better optimization from your engine. ALso, security was touched on above.
1 comments
moron4hire 3681 days ago
APIs have nothing to do with the interpreting of the language.
link
vonklaus 3681 days ago
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.
link
moron4hire 3681 days ago
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.

link
vonklaus 3681 days ago
> 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.

link