[jbob2000]

Kind of a silly article. Most top websites just serve static content with tons of ad-network crap, they would never need 83% of the features. This is like saying "the most sold vehicles in the world don't use 90% of the horsepower they have". No shit, the most sold vehicles in the world are Corollas and Civics, ie. "sit in traffic and commute" type cars.

It doesn't cost anything to keep these features around, why kill them off? Code is cheap, it doesn't cost you, the user, anything to have the features in your browser...

[ScottBurson]

It does cost you something if that code has security holes.

[captn3m0]

Most of these features also rely on user-approvals so it is not as if every website is going to jump on and start using GeoLocation APIs just because they can.

It is a nice study showing how far these niche new features have reached, but that shouldn't affect how we are working on the new ones (except perhaps improving the security models of these).

[jbob2000]

That's a big if. Anything could have security holes, seems pedantic to kill a feature because it might have a security hole at some point.

[creshal]

> That's a big if.

Reminder that we've been issuing so many CVEs last year we had to upgrade the numbering spec to allow for more than ten thousand a year.

[btrask]

With fewer features, new engines like Servo could be built faster.

[nwah1]

And features add attack surface. But since people seem to want web rendering engines to replace operating systems, there's no way around it. You need WebBluetooth, WebRTC, WebAssembly and every other feature.

There's some good reasons to want this, in fact.

[sliverstorm]

Don't forget WebBIOS and WebHPC

Edit: those were meant to be satirical, but apparently exist.

[nathancahill]

:/

[the8472]

Or stuff each origin into a container and provide access to libc.

[drzaiusapelord]

This is why the linux desktop failed to penetrate the market. You can't say, "Well it does 80% of what most people need." Most people just surf the web, view photos, and other basic functionality. That 20% it can't do is a deal breaker. Not to mention the things most people never do, but businesses rely on like legacy/proprietary software support.

>It doesn't cost anything to keep these features around, why kill them off?

This is also why the features list of a basic Windows or Office install is miles long. Once developed, there's no cost other than maintenance of those features (updates, security, etc).

I think its hard to argue against complexity in software. The ultra-complex usually win for rational market reasons.

[vonklaus]

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.

[moron4hire]

APIs have nothing to do with the interpreting of the language.

[vonklaus]

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.

[moron4hire]

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.

[vonklaus]

> 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.