Hacker Newsnew | comments | show | ask | jobs | submit login

Preventing innovation: a gang of hackers makes a new browser that utilizes the 100 cores in 2018-era laptops perfectly evenly, unlike existing browsers that mostly burn one CPU per tab. It’s a ground-up rewrite, and they do heroic work to support 99% of the websites out there. Make that 98%; webkit just shipped a new feature and everybody immediately started using it in production websites (why not?).

Notwithstanding the other points made, how is rapid adoption of new features, and a competitor's ostensible inability to keep up, preventative of innovation?




Writing a browser engine takes time. While you write it, WebKit will be adding new features. By the time you get up to it, it would advance ahead, adding more and more quirks (keep in mind you need to implement bugs as well as features). Since WebKit isn't a standard, it moves quickly, so your own team must be better than all developers working actively on WebKit and then some.

-----


You're confusing innovation in features with innovation in basic architecture.

But the premise of the article doesn't even require innovation in features. It just requires changes that change behavior that sites then depend on and that you have to reverse-engineer.

And reverse-engineering is very time-consuming and slow. If all possible competitors have to reverse-engineer to become viable, that puts in place a huge barrier to competition.

Note that WebKit already behaves this way in various cases: their transitions draft proposal was very vague (as in, what they described could have been figured out in a few afternoons by someone playing with the functionality and their developer docs) and then the editors (Apple employees, note) did nothing to improve it for a few years, forcing everyone else to reverse-engineer WebKit to implement this "standard"...

-----


The issue here is not rapid adoption, it's an effective monopoly being used to lock competitors out of the marketplace by making fast, arbitrary changes and forcing people to keep up. This has already happened in a few scenarios despite WebKit having competition, so it will get worse if all the competition slowly dies off. webkit-only mobile websites are an obvious example but chrome-only audio code in HTML5 games is another great example (Chrome's HTML5 audio stack was so broken it caused crashes, so to have working sound in Chrome you had to use their special API. As a result, there are HTML5 games out there that only support Chrome's API or, if you're lucky, have a fallback based on a flash plugin).

EDIT: Another great example is the stunt Intel pulled with AVX to intentionally sabotage AMD's ability to compete in the market, as documented here: http://www.agner.org/optimize/blog/read.php?i=25

Essentially, Intel published a proposed new instruction format, and AMD said 'that looks great, we'll be compatible with it'. After AMD announced this and had started preparing to ship their new chips, Intel suddenly announced that they had changed their instruction format from what they published - after it was too late for AMD to adapt. The end result was AMD shipping chips that were incompatible with Intel's despite AMD's best effort. Intel knew that as the majority market share holder, developers would prioritize Intel compatibility over AMD compatibility, and AMD would lose.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: