Is Chrome the New IE? (2023)

We don't have float:right;zoom1: but our "necessities" nowadays are even crazier. Babel, vdom, frameworks provided by browser-vendors. Those are several orders of magnitude more complex than previous "workaround" approaches to the web, all unstandardized.

How about Electron? Do we see any Firefox-based desktop apps around or is that market completely dominated by the Chrome runtime? Are app developers happy having only Chromium as the viable solution? (my guess: they're not, but they have no choice).

Where we're going is even nastier than clearfixes and table layouts.

It helps if your company uses the embedded stuff in other products. Like Microsoft used the Trident engine from IE6 all over Windows components. In that way, allocating resources for developing an embeddable engine is justifiable. Can Mozilla do that? I don'know. Google can (and does it! why wouldn't they?).

Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.

Would normalize.css exist if the standards were more specific around default styles?

Would jQuery/sizzle exist if CSS selectors were available as a DOM API in the first place?

Would vdom exist if DOM was faster?

On desktop, it used to be available as an ActiveX component and a GTK widget, at least: https://www-archive.mozilla.org/projects/embedding/embedding...

Wine still uses WineGecko as a replacement for IE engine – might also be worth looking into.

The answer is that the DOM inherently has state. It could be a textbox's text input and its cursor state, or the focus state, or whatever. But developers don't want to think about this DOM-managed state to simplify their mental model.

Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used.

So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state).

Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls).

It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?

No, when was that? Because it was always possible to `eval(jsonString)` and get the parsed result. Indeed, that was the whole point.

We're oldschool, not savages!

But sadly on Android the alternative is simply using a Chrome/Blink-powered webview, which is capable enough for most people and importantly comes at a zero APK size hit. So you need to have pretty special needs before including a complete custom browser engine inside your app becomes an attractive proposition.

(Whereas on Windows for example for a very long time the only OS-provided browser engine was IE, so if you needed more advanced web features, you couldn't avoid shipping your own browser engine in your application anyway.)

> However, Android’s WebView is not really intended for building browsers, and hence, many advanced Web APIs are disabled. Furthermore, it is also a moving target: different phones might have different versions of WebView, all of which your app has to support.

It might still be an okay choice for an application shell sometimes (e.g. if you use a web API that is not supported by WebView and no polyfill is readily available for Cordova/Capacitor).