This seems like a weirdly combative comment. This certainly isn't the primary technical (or emotional) argument against Dart.
To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access.
I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.
It's not just that expanding support for the DOM memory model to support multiple VMs is a lot of work, it's that it's a lot of work that is totally unnecessary unless you want to add multiple languages to the Web, which is a problem that the other browser manufacturers don't want to solve. In other words: the lack of support for multiple languages in the DOM is not a drawback of browser engines; rather it's a drawback of the Dart VM. This is much of the reason behind the objections that were raised on webkit-dev.
Having suboptimal GC performance in the DOM can be solved in other ways: for example, the cycle collector that Gecko uses. (That said, Servo [full disclosure: I'm a Servo core team member] is pursuing a more Oilpan-like approach, but not to support multiple languages.)
Yes, the design of browsers requires a lot of work to integrate any second VM, which is what I said. The objections that were raised on webkit-dev were that that work had to be justified by proven gains (e.g. developers will actually use added languages) and proven lack of regressions caused by the new bindings[1]. These were the same objections raised when upstreaming the V8 bindings happened, as well, btw and are exactly correct.
As for DOM GC performance, yes, it could be solved in other ways, or you could move it to the same GC-able heap as the language manipulating it. I'm still not seeing the connection to Dart, but, again, maybe I'm just out of the Dart loop (some simple searches haven't revealed much beyond the blink-dev list and associated code reviews). AFAIK oilpan is coming out of long-time work by haraken et al in webkit and now blink to bring huge performance improvements to the V8/browser bindings, which have historically been much slower relative to other browsers and their javascript engines.
To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access.
I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.