It was not rendering that killed other browsers. Rendering isn't the hard part. Getting most of rendering working gets you about 99% of the internet working.
The hard part, the thing that killed alternative browsers, was javascript.
React came out in 2012, and everyone was already knee-deep in earlier generation javascript frameworks by then. Shortly after, Google would release the V8 engine which was able to bring the sluggish web back to some sense of usable. Similarly, Mozilla had to spend that decade engineering their javascript engine to claw itself out of the "Firefox is slow" gutter that people insisted.
Which is funny because if you had adblock, I'm not convinced firefox was ever slow.
A modern web browser doesn't JUST need to deal with rendering complexity, which is manageable and doable.
A modern web browser has to do that AND spin up a JIT compiler engineering team to rival Google or Java's best. There's also no partial credit, as javascript is used for everything.
You can radically screw up rendering a page and it will probably still be somewhat usable to a person. If you get something wrong about javascript, the user cannot interact with most of the internet. If you get it 100% right and it's just kind of slow, it is "unusable".
Third party web browsers were still around when HTML5 was just an idea. They died when React was a necessity.
If you want to start a new browser project, and you're not interested in writing a JS engine from scratch, there are three off-the-shelf options there to choose from.
It’s the extend part of embrace, extend, extinguish. The extinguish part comes when smaller and independent players can’t keep up with the extend part.
A more direct way of saying it is: adopt, add complexity cost overhead, shake out competition.
A little bit can be very good, a lot can strangle everyone but the biggest players
I don’t know how many times I had to manually write <![CDATA[ … ]]>
I know all markup languages have their quirks, XML could be come impressively complex and inscrutable.
... but the legibility and hand-maintainability was colossally painful. Having to tag-match the closing tags even though the language semantics required that the next closing tag close the current context was an awful, awful amount of (on the keyboard) typing.
But even if you use one of those terrible technologies, your app still needs a manifest and some native resources.
Thing is you couldn't swing a dead cat in 00s without hitting XML. Nearly every job opening had XML listed in requirements. But since mid-2010s you can live your entire career without the need to work on anything XML-related.
COBOL code is also still there.
Sorry, web frontend is not the "whole XML tech stack", despite popular belief.
And yes all of the above are mainstream in their respective industry.