
Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec - tptacek
https://github.com/w3c/dom/issues/175#issuecomment-380534425
======
qmarchi
For some clarity:

\- Mozilla's Objection:
[https://github.com/w3c/dom/issues/175#issuecomment-380771954](https://github.com/w3c/dom/issues/175#issuecomment-380771954)

\- Apple's Objection:
[https://github.com/w3c/dom/issues/175#issuecomment-380534425](https://github.com/w3c/dom/issues/175#issuecomment-380534425)

\- Microsoft's Objection:
[https://github.com/w3c/dom/issues/176](https://github.com/w3c/dom/issues/176)

\- Google's Objection:
[https://github.com/w3c/dom/issues/177](https://github.com/w3c/dom/issues/177)

~~~
colanderman
Thanks. The TL;DR seems to be that, instead of sticking to documenting what
_is_ , the W3C is (either deliberately or through incompetence) trying to push
their own "vision" for DOM 4.1 without browser buy-in.

~~~
c-smile
That does not mean that it is a good thing to put all bells and whistles from
different browser vendors under the same umbrella.

Let's say you are a) owning and b) managing a project that three competing
teams are working on in parallel.

If you will not curate the project you will have one team adding <marquee> and
another team adding <blink>...

In real world you would invite dedicated architect or team of architects to
define the spec that all 3 teams will implement.

All that WHATWG vs W3C flame is about bazaar vs cathedral management style I
think.

Origins of the mess: W3C itself has no architects on board - they are just
trying to moderate votes of others. Where each vote has an obvious weight
(weight(Google) > weight(JohnButSmart)).

In contrary WHATWG has professional architect on top of the construct - Ian
Hickson. In fact WHATWG was created by him. But Ian is associated with Google
and that makes WHATWG legitimacy a bit questionable.

~~~
make3
the formal complaints of all browser people seem to support the WHATWG

~~~
ttepasse
The browser people are the WHATWG. There are no other stakeholders in that.

~~~
domenicd
Not sure exactly what your comment is saying, but at least one reading is that
"browsers are the only stakeholders in the WHATWG", which is not accurate. The
WHATWG is a community organization open to participation by all; see
[https://whatwg.org/faq#process](https://whatwg.org/faq#process) for more. We
receive a lot of participation from users, web developers, and other
companies.

There is a formal group, the Steering Group, which represents the browsers
that implement WHATWG standards, and serves as the point of final appeal if
the community doesn't come to a consensus on its own. But this is similar to
the W3C appeals track where if all the paying member companies don't come to
consensus, they appeal to "The Director" as the ultimate decider. ("The
Director" is nominally Tim Berners-Lee, but recently all Director decisions
have been made by W3C management "on behalf of" The Director.)

~~~
hungryfoolish
Are there any non-browser members as part of the editors or steering committee
in the whatwg?

To me, this is giving browser makers even more power over HTML than they have
otherwise.

~~~
domenicd
The MIME Sniffing, Streams, Console, and Quirks Mode Standards are all edited
by people who are not working for the browser-engine-developer companies.
(Streams is co-edited by Googlers as well.) That's 4 out of the 15 standards
currently developed at the WHATWG; not so bad, given how few companies are
willing to pay people to work full time on web standards.

Of course, we have _lots_ of work to do, and if you or anyone else are able to
devote a good chunk of time to standards work, we'd love to have more editors
---no matter what company they work for.

Browser engine developers comprise the steering group, since ultimately we
want the specs to reflect what will be implemented in web browsers, so the
best way to resolve disputes about what should be in the spec is by asking the
people who will be spending their resources to implement it what they think. I
think this is probably the right way to go, instead of "The Director" having
the final voice.

~~~
hungryfoolish
> That's 4 out of the 15 standards currently developed at the WHATWG; not so
> bad, given how few companies are willing to pay people to work full time on
> web standards.

Thats actually nice to know, but specifically about HTML (which is one of the
most important specs the whatwg works on) it's all browser makers. (That too,
majority of them from one particular browser maker).

>I think this is probably the right way to go, instead of "The Director"
having the final voice.

I think having a better mix of people in the decision making process than just
browser makers would be the right way to go. I understand that browser makers
have to implement the specs, but the web community as a whole has to use the
specs to build the web of the future - and as such, people from non-browser
companies should have a greater say in the final voice.

~~~
domenicd
Oh, you're right, I forgot HTML! That is co-edited by someone from Bocoup too.
So make it 5 out of 15.

------
scarface74
_We know that Apple, Google, Microsoft, and Mozilla, consider the WHATWG to be
the canonical version. We don 't yet know whether the other 450+ W3C member
organisations that represent the wider web platform agree with this position
or not though._

Honestly, do the other 450+ W3C member organizations matter?
([https://www.w3.org/Consortium/Member/List](https://www.w3.org/Consortium/Member/List))

~~~
tptacek
No.

They could matter, if they built a browser with competing market share. It's
not a static equilibrium.

~~~
scarface74
Did you look at the list of members? Who on the list is going to be building
their own browser and what would the business case be? Out of the big four,
only two of them even thought it made sense to build a browser from scratch.
Apple and Google started off with KHTML.

EDIT:

To clarify. Who is going to be building their own _rendering engine_ instead
of taking an existing one - 3 of the 4 are open source - and building a
browser on top?

~~~
tptacek
The lineage of the _rendering engine_ doesn't matter. What gives Apple and
Google and Microsoft command of the standard is the fact that they mediate
access to web pages; they own th actual customers. _That 's_ what matters.

~~~
794CD01
Creating a browser isn't the only part of mediating access to web pages. In
different senses, Digicert, Comcast, Akamai, and Cisco do that as well.

~~~
chucksmash
Fair point, but I think it is somewhat orthogonal to the discussion. I don't
imagine Cisco cares which DOM spec is used in rendering the application layer
bytes of the packets it routes.

------
chrismorgan
Serious question: why are the W3C still publishing or trying to publish
standards for DOM and HTML and probably a few others, when no one that matters
cares about them? Why not rather throw in the towel on those particular
standards and acknowledge that the WHATWG has won on them?

~~~
dragonwriter
> Serious question: why are the W3C still publishing or trying to publish
> standards for DOM and HTML and probably a few others, when no one that
> matters cares about them?

There _is_ a potential legitimate role for the two-track approach, if WHATWG
represents a moving target of what browser vendors have agreed to implement
and essentially is the vehicle for documenting hmthe agreed future common web
platform, and W3C presents a versioned publication of the stable, widely
implemented, currently usable state at a particular point of time; the W3C
version would then be the target for conservative app developers that need
something that works everywhere today, the WHATWG standard would be what
people making browsers and other user agents would target, and what more
ambitious developers willing to deal with “can I use...?” pitfalls would be
guided by.

~~~
manigandham
Why cant people just use an older copy of the WHATWG standard as the new
"stable" documentation? This is basically how caniuse.com and browserslist
work today, allowing developers to precisely describe their compatibility
targets and even automate their builds.

It seems unnecessary to have an entirely separate organization to just
copy/paste/publish new "versions" of existing archives.

~~~
dragonwriter
> Why cant people just use an older copy of the WHATWG standard as the new
> "stable" documentation?

Because the order of incorporation into the standard and the order of
implementation and stabilization aren't the same, and some fesutres may be
implemented incompletely in some browsers, so that what is stable and usable
is a subset of features (and sometimes a subset of functionality within a
particular feature) that doesn't correspond to any particular version of the
LS. So you'd need manual curation.

> It seems unnecessary to have an entirely separate organization

Perhaps, though the audience and thus interested parties for the implementor-
focussed spec and the developer-focussed spec are different.

~~~
domenicd
The WHATWG is actually the only organization I know of that publishers a
developer-focused specification; see
[https://html.spec.whatwg.org/dev/](https://html.spec.whatwg.org/dev/). (We
only do it for HTML currently.)

Anyway, I agree with the grandparent poster that caniuse.com is a much better
approach to documenting the interoperable subset than copying and pasting
someone else's spec, and trying to delete the parts that are not interoperable
by some threshold. We actually have caniuse.com boxes in the margin of the
HTML Standard: see for example
[https://html.spec.whatwg.org/multipage/scripting.html#attr-s...](https://html.spec.whatwg.org/multipage/scripting.html#attr-
script-type)

Finally, it's worth noting that we only incorporate features into WHATWG
Living Standards if they have multiple implementer interest; see
[https://whatwg.org/working-mode#additions](https://whatwg.org/working-
mode#additions)

------
ChrisSD
It's sad to see the relationship between WHATWG and W3C has deteriorated to
this point. Trying to wrangle a standard from a "living" (i.e. constantly
changing) specification was always going to be tough but I'd have hoped both
WHATWG and W3C would be able to maintain a working relationship.

~~~
chrisseaton
Is there an article with the background on this? Why do we have both the W3C
and the WHATWG, and why do the W3C just copy and paste work from WHATWG, if
that is indeed what happens?

~~~
kuschku
The W3C was the original standardization organization for the web.

They wanted to create standards that allow easy implementation by others, and
were willing to make some tradeoffs with backwards compatibility for that (see
XHTML).

The browser vendors obviously oppose this, and want standards that just
formalize what they already implement. As result, the browser vendors created
their own standards committee, which standardizes whatever the browsers
already do (if existing). This is the WHATWG.

As result, the web standards situation has gone to insanity. The WHATWG URL
spec contains 4 pages of pseudocode and algorithm definitions for how Chrome
parses URLs, and how you should as well, and the W3C, still being relied on by
the other actors on the web that aren’t the 4 largest browsers, has to copy
the WHATWG spec as base for their own specs, because browsers will ignore
whatever the W3C says anyway.

But remember that the WHATWG proposed to the W3C that the W3C should copy the
WHATWG specs as base for their own specs:
[https://en.wikipedia.org/wiki/WHATWG#cite_note-9](https://en.wikipedia.org/wiki/WHATWG#cite_note-9)

~~~
Latty
To offer another perspective.

I'd say the W3C wasted a huge amount of time pursuing quests of purity (XHTML)
over actually making the web better for users. I see the value in what they
were trying to do, but it wasn't letting people do the things they wanted to
do on the web.

As browsers started just implementing features outside of standards in
completely disparate ways because everyone was desperate for them (leading to
plugin hell, apps rather than websites, etc...), WHATWG was created to try and
ensure that the web remained a single thing and not a mess of things that
would only work in one browser.

The web platform sprang forward massively as a result of this, with browsers
implementing much more consistently and with new features tending to be
implemented in compatible ways, with real progress being made.

This lead to the W3C specs becoming totally redundant and the only way for W3C
to keep up was to lamely try to copy from WHATWG into a "spec" at random
intervals and claim it was something people could work towards, when it
reality it offers no real advantages over working to the living standard,
because no browser offers better coverage of that spec than any other random
point of the living spec.

People want features. We saw what happens with a very slow moving, rigid
standard: plugins. Flash was popular because at the time you simply couldn't
do good video, animation, games on the web platform. Likewise, mobile phones
shifted to apps because websites couldn't do notifications or use location
information. You can bemoan a living spec, but _you get one anyway_ , because
people will work around the web if they can't do what they want. If you want
to use a subset of that living spec, use it, but at least keeping it together
and agreeing on roughly how to do these things is better than plugins or
abandoning the web entirely.

~~~
kuschku
> I'd say the W3C wasted a huge amount of time pursuing quests of purity
> (XHTML) over actually making the web better for users. I see the value in
> what they were trying to do, but it wasn't letting people do the things they
> wanted to do on the web.

Okay, let’s make a deal:

We both write a crawler that can fully reliably parse websites.

I implement XHTML1.1, you implement HTML5. We both get 1 month time.

What do you think is going to happen?

XHTML was a worthy goal – with it, we wouldn’t have a need to run headless
Chrome for tests. We could parse the web, and actually use the data. OpenGraph
tags would never have been necessary. We wouldn’t need to throw DNNs at
rendered output of a browser just to parse data.

HTML5 is amazing for existing browser vendors, developers, and in the short-
term, users. But everyone else loses. Horribly.

~~~
Latty
And if we were all using XHTML1.1 now instead, yes, your parser would be
easier, except all the richer content would be in flash, and all the web apps
would be desktop applications, and you wouldn't be able to parse that at all,
even with a full browser.

You are acting like everyone would just stop and wait for you to make your
dream implementation that's ideal - that's not how the world works.

WHATWG was an admission that we can't stop it, so we might as well embrace it.
Embracing it has resulted in browsers being _far_ more consistent, and new
features being a shared part of the web platform, and not siloed off in
plugins and other platforms. That's why W3C is irrelevant now.

~~~
kuschku
You’re assuming XHTML1.1 would never have evolved further, never have gotten
more content.

And Flash, despite its flaws, would have been a much better starting point for
rich content than the ecosystem we have today.

Many of the features Flash provided are only available in browsers today
through babel.js transpilation. As result, we’re stuck with a language without
stdlib and broken syntax.

We’re stuck with a document model that’s impossible to work with or parse, and
with impossible layout management.

If you want web applications, it’d make much more sense to port the Android
layout XML format to the web than to attempt to use HTML5 for it, because
HTML5 is insanity for building applications.

> and all the web apps would be desktop applications

I don’t see that as anything bad.

The web is for documents, and lightly interactive content. All the rich
applications on the web are opaque to any crawler I could write anyway, as I
just get "You need JS to view this React app". Desktop applications would be
just as parseable, except they would also be less of a resource hog.

~~~
tptacek
The idea that standards groups exist to push for top-down reconcepting of how
the world should work is a common one, and is also a good reason why standards
groups fail. Your idea of what the best outcome is won't be the same as every
other stakeholders, and no one stakeholder will have exactly the same idea of
the best outcome as the market will.

Ultimately, the market _will_ win, no matter what your standards group says.

The point of standards is interoperability, not rationalization. When
standards groups try to rationalize technologies real people work with, they
cease to provide value, and instead become obstacles that real engineers end
up laboriously working around.

~~~
kuschku
When I was a child in elementary school, a standards committee decided to
change my native language.

They replaced the spelling of most words, and many grammatical rules.

We were forced to obey these changes, any use of the old rules was counted as
mistake in school.

Back then, many older books were still using the old rules.

By the time I left high school, almost no books with the old rules were left.
All had been reprinted. All newspapers had switched. Autocorrect programs had
been updated with the new rules as well.

In a matter of 8 years, an entire language had changed its orthography and
parts of its grammar, top-down, and it worked out fine.

I’m sorry, if an entire human language with 120 million speakers can be
updated top-down like that, a web spec can as well.

~~~
tptacek
That sounds horrible.

~~~
kuschku
It was amazing. The new orthography is much simpler, and has far fewer insane
rules or exceptions. And most people that have seen the transition, but were
born after it, or went to school during it, agree.

I know it can work on this scale, I’ve seen it IRL. Many languages do stuff
like this, German has the council of German language, and French has their
Academy.

You can do the same on the web. You just need to have all vendors working
together to actually do it.

~~~
tptacek
The idea that a bunch of standards group officials can decide for the world
that web pages are simply lightweight content publishing mechanisms and that
real applications should be build exclusively in Flash and that that worldview
can be ratified and mandated by browser vendors does _not_ seem amazing to me.

At any rate: the Internet is a market system, not a top-down autocracy.

~~~
xg15
The alternative (and current reality) is that the same things are decided by
about four companies in an entirely intransparent manner.

At least the W3C had processes and a wide array of members.

~~~
tptacek
Isn't that just theater? None of them can tell Apple and Google what to put in
their browsers; in fact, if they can't convince _just one_ of the big 4
browser vendors to do something, their standards have no meaning at all.

~~~
jancsika
It's even more work than that-- check out caniuse for SVG fonts:

[https://caniuse.com/#feat=svg-fonts](https://caniuse.com/#feat=svg-fonts)

They had support in both Safari and Chrome, but never in FF or IE (nor Edge).
Chrome eventually dropped the support.

So I'd say if you can't get _all four_ to implement the feature then you might
as well call that part of your spec a "living standard." Those features are
going to get way fewer eyeballs, fewer bugfixes, fewer reviews, fewer pieces
of documentation, etc.

------
manigandham
What a monumental waste of time. Why not just ignore W3C entirely? Seriously,
what exactly are they going to do? Publish more?

Sometimes it's better to not be nice and just let reality finish the job. So
much effort taken from people who clearly have better things to do...

~~~
baybal2
W3C attempts to make proper web standards.

Apple Google MS break them and and try to push for substandard specs pushed
through W3C.

As a web developer for 11 years, I can state that web development is devolving
to chaos of IE6 era.

When W3C allowed itself to be subverted and let big dotcom browsermakers to
hijack the process.

A result of that is the continuous bloating of the acting web standard, when
you have dozens of new abandonware APIs being showed into the spec on a whim,
and no focus on things that should really matter.

It is 2018, and yet browser makers still have open CSS bugs from the previous
decade that are banal to fix, yet all they care is how to stuff yet another
API useless outside their own business setup.

~~~
manigandham
The only "standard" that matters is the one everyone uses. Everything else is
a nice wish list for discussion but eventually needs to get out of the way.

The WHATWG doc is a fine standard, backed up by real implementations. Beyond
that, W3C is just copy/pasting whatever WHATWG has every few months so what's
the point?

And you really think the web is in chaos? We're at an incredible era of
possibilities because browsers like Chrome constantly make progress instead of
devolving into a bike-shedding argument for years. What APIs do you find so
useless or abandoned and why can't you just not use them if so?

~~~
baybal2
> The WHATWG doc is a fine standard, backed up by real implementation.

It sucks badly. To begin with, it can't be called a proper standard. It is in
their terminology "a living standard" which means it being changed on a whim.
It is not being written as an "ideal prototype", but rather it is just a
codification of current behaviour of how Google's devs managed to write
Chrome's DOM Api, with with all bugs and workarounds.

From standpoint of a person capable of high technical reasoning, this approach
is bad.

And... I can't believe that whatWG specs are being written by people hired by
Google for 100k+ a year, they are not done on a level of what an any much
professional technical writer should work on.

~~~
manigandham
Ok, so why does it suck? Because you don't like it? Why isn't it a proper
standard when it's the only one implemented? Things definitely do not change
on a whim and there's great care taken in the process. The group is very
transparent and clearly state the objective is to keep the standard modern and
evolving. You can always refer to an archived snapshot or the numerous
compatibility tables for historic data if needed.

Chrome has bugs, like any other implementation, but has moved the web forward
greatly in the last decade and the vast majority of developers and end-users
would rather have modern working tech than some idealistic document that
doesn't go anywhere.

Again, since W3C just copies the WHATWG standard anyway, what is the value
that you claim is being added? And if you have better ideas, why not just
contribute them to WHATWG instead?

~~~
baybal2
How it should work:

A standard is written and set in stone at least for 1-1.5 years. Official test
suites are made.

Then, browsermakers make their stuff compliant.

APIs must support strict versioning. A user should not be bothered with "your
browsers supports version 1 of method b, version 2 of method c, and does not
support method d" it should either work with API version N or popup a big
error message "API version N not supported, update your browser"

~~~
manigandham
For the 3rd time, do you have an actual example of what's wrong?

In the 1.5 years of wait time you mention, the current process will have
standardized and released features across all browsers. The web has changed
and nobody wants to wait years discussing something. Compatibility is not a
major issue because features are rapidly updated and there are compatibility
tables that will automatically reference and even build your app for you with
the proper polyfills and transpilations.

Sure, sometimes there are bugs and partial features, but this is rare and
there's no evidence that W3C prevented this since implementations are not up
to them.

However the W3C has definitely failed to make any progress with HTML/XHTML.
They failed with SVG. They failed with DRM by completely ignoring the issues
raised and causing the EFF to leave. So please state exactly what the W3C has
done better and where they have added value because as far as I can tell, they
are just wasting time every few months from the very people who are trying to
move the web forward.

------
hacknat
That’s a flamey title. They’re objecting to them publishing their spec before
the negotiations with WHATWG are over.

~~~
tptacek
They're objecting to the simultaneous existence of two DOM standards, to the
procedure used by W3C to move forward on the W3C's standard, and to
substantive issues in the W3C's fork. Each of the objections refers to the
W3C's DOM spec as a "fork". The objectors are members of the WHATWG steering
group. The title seems about as neutral a description as can be written.

This is a hazard of posting into message threads rather than articles and blog
posts, but "all the mainstream browser vendors object to a W3C standard"
seemed interesting enough an event to override that concern.

~~~
PerryCox
I think it's perfectly fine to post message threads on HN. I would much rather
read the source then a summary written by someone else.

------
dooglius
I'm not too knowledgeable on the background here, or on how the politics of
standards organizations work, but my understanding is that the EU standards
bodies (presumably as well as similar organizations for other governments)
consider the W3C to be authoritative. Even if all the browsers prefer WHATWG's
spec, won't they be forced to adopt W3C in the same way phones have to support
USB charging[0]?

[0]
[https://en.wikipedia.org/wiki/Common_external_power_supply](https://en.wikipedia.org/wiki/Common_external_power_supply)

~~~
cptskippy
> in the same way Apple was forced to adopt USB Type-C?

What in the what now?

Apple adopted the latest USB standard as a way to reduce the BOM on it's
devices by consolidating ports. They did the same thing with the iMac almost
20 years ago. No one is twisting their arm on it, if anything people are
asking them to not jump whole hog on USB Type-C but instead take a gradual
approach to adopting it.

~~~
dooglius
Clarified; I had mistakenly thought this was the result of EU regulation, but
it looks like they were already considered in compliance before that[0]

[0]
[https://en.wikipedia.org/wiki/Common_external_power_supply#R...](https://en.wikipedia.org/wiki/Common_external_power_supply#Reception)

~~~
cptskippy
That legislation was specific to mobile phones and has since expired. It asked
that chargers either have USB Type A Female or USB Type Micro B Male
connectors, Apple already offered Type A Female and thus was always in
compliance.

It would not surprise me if there were similar legislation around Type C
however the industry is still coming to terms with Type C and so I don't
anticipate that happening for a few years.

------
ajnin
They're (W3C) actually citing the EME precedent as an example of when the W3C
went forward without consensus to justify their position on this. If this is
the direction the W3C is going then it has ceased to serve the interests of
the web and I'm guessing it is on a short path to irrelevance.

------
danielovichdk
I see this in another way, and I might not be right but my recollection of the
matter was around 2008 and the stale state of the (X)HTML spec(s).

WHATWG came along and was heavily (as I remember it( supported by Google due
to the Chrome browser and lack of evolution from W3C and particularly the sad
browser state of IE.

Back then Microsoft was sitting on the browser market as Google is today. But
Google needed to enforce something different than W3C so it could build a
better browser than IE, but with a different (and perhaps a more controlled)
spec.

Today, web standards is in a much worse state than they were 10 years ago. And
having been developing for the web the last 20 years, it is not easier than it
was "in the old days". It's perhaps more fun, but it's not easier.

And some of that frustration is partly due to the disruption of this
specification.

------
amelius
When is W3C going to formalize their standards?

It's one thing to write down "user agent should do such and such" and quite
another thing to formalize it.

~~~
Analemma_
Never, because there is no W3C-designed standard anymore. Today they just take
snapshots of the WHATWG standard every N months, slap their name on it, and
call that a standard. The browser vendors roll their eyes at this because they
couldn't care less about the W3C and what it publishes, but they've tolerated
it as long as it wasn't causing any problems.

The issue here is that now the W3C seems to want to actually make a real
standard of their own, and the vendors are going "No. Go away."

------
carwyn
Surely W3C and WHATWG would periodically branch and freeze a version of living
standard? Possibly defining some elements as optional or extensions much like
OpenGL or Vulkan? It seems crazy that they proposal introduced changes to what
was already established common practice.

~~~
kbrosnan
The problem is that it is not a fast freeze. It goes through the full W3C
process[1] WD > CR > PR > recommendation. When I looked at W3C html 5.2 there
had been 10k changes to the WHATWG spec from the date of the 5.2 branch to the
date of the 5.2 release.

The W3C allows changes that are incompatible with the WHATWG spec see DBaron's
comments in the GitHub issues.

[1]
[https://www.w3.org/Consortium/Process/Process-19991111/proce...](https://www.w3.org/Consortium/Process/Process-19991111/process.html#Reports)

------
thrillgore
Jesus Christ this is becoming a hot mess.

------
Endy
Anything they object to as a group, I like.

------
yuhong
I once suggested that W3C base its HTML snapshots on the web developer edition
of HTML. In retrospect the full version was probably not a good fit as a W3C
standard in the first place.

------
jlebrech
time to use WASM to render the whole thing, ditch W3C. and all the players are
there to make the change.

~~~
blablabla123
Yup, every page looks different anyway, calling megabytes of minified,
obfuscated JavaScript. There is probably more in for the user. I guess then
you only need <html>, <body>, <canvas> and a subset of DOM.

~~~
Klathmon
And you'd need to handle accessibility considerations, and font and encoding
support, and a flexible layout engine, and multiple input methods, and
scrolling, and search engine standardization, and more all yourself.

By the time you handle most of it, all you've done is make a wildly more
complicated version of the DOM.

~~~
blablabla123
Not sure about that. I mean a number of video games have been successfully
recompiled to JavaScript, e.g. Doom or Quake 3. I guess you one would need to
be able to target some sort of Framebuffer, Frameworks like Qt know how to do
that already.

Probably I prefer "native" Web Apps over recompiled "native apps" but like it
or not, this will come more and more as people ask for more performance and
more variety of programming languages.

~~~
Klathmon
Well you can already do that with Canvas, and as you said things like Doom or
Quake have already done so, but you are basically ignoring the entire DOM and
JUST using the canvas as a framebuffer.

And like you said Qt already knows that (somewhat, there have been tech demos
showing this but no real applications built on it), but it still means that
YOUR APPLICATION must handle all of that, meaning at best you are downloading
all the code for all of that at runtime, and at worst you just won't handle it
because most people don't want to spend the time.

