3 ms·
The problem is that you are giving full power for creating de-facto standards to the rendering engine. If Blink decides to support a feature, it becomes a de-f
by pjerem 4y ago
The problem is that you are giving full power for creating de-facto standards to the rendering engine.
If Blink decides to support a feature, it becomes a de-facto standard even if the feature solely serves Google (think FLoC, AMP ...) or is hard to replicate.
It's also an issue because now the web is at risk to become only usable from devices that are physically able to run Blink/Webkit which means nobody in the future will be able to create a new useful device/os that cannot run Blink or Webkit.
It's also an issue with the good ol' technical debt : what happens when Blink/Webkit become a total mess full of hard to patch vulnerabilities or google/chrome specific code ? You basically cannot rewrite it from scratch unless you have the engineering power of a GAFAM.
There are tons of reasons why having a monoculture of rendering engine is an issue.
- sneak 4y agoNeither FLoC nor AMP are part of the renderer. AMP isn't even clientside, it is a feature of the Google search webapp. If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked. Do we have the same concerns over type layout engine monoculture?
- grosswait 4y agoWe have the same concerns over any lower level components, yes. I don’t think a type layout engine is comparable to a web render.
- dmitriid 4y ago> If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked. Google has already asserted that. Brave and Edge are a footnote to a footnote to a distant appendix, and are almost entirely reliant on Google to provide the rendering engine.