[Bug 27310] Virtual DOM and DOM diff

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27310

winchestro@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |winchestro@gmail.com

--- Comment #7 from winchestro@gmail.com ---
After a short conversation on Twitter Marcos asked me to write down my ideas
here, and I'm doing that. I don't know if I'm qualified to have an opinion /
participate in the discussion, but I try my best.

I come primarily from a canvas2d / webgl background, and am really interested
in web components and their potential to make the DOM usable for applications
that are traditionally inaccessible. I spent the last ~ 6 months working on
what started out as an attempt to wrap all of WebGL into Web Components, which
was actually successful but just incredibly inefficient and difficult to use,
despite a many attempts to make it work somehow. Eventually I decided to focus
on the js part and not add web component bindings until I reach a much higher
level of abstraction.

In my experience many people don't bother with the DOM at all or at most use it
to easily create a GUI, but people already successfully built even that
completely in WebGL =>
http://www.reddit.com/r/gamedev/comments/1a0yv5/a_webgl_terrain_engine_and_gui/
  So it's not just canvas2d that has been for that. The main selling points of
the DOM, in my opinion, aren't the rendering or layout, both of which don't
really satisfy current and future needs, and are, if you believe the rumors,
especially alienating for programmers coming from desktop development. 

The main reason for using the DOM is providing an accessible, and descriptive
structure of an application not just for users, but also for the majority,
mostly hobbyist web developers to build their sites and applications from.

I think those are two worlds...not colliding...but rather coexisting with
little exchange. One world, traditional web development uses the DOM way too
much and is usually mocked for how extremely slow and inefficient their
applications are. In this world everything, from structure, to layout to
rendering is achieved with the DOM, which is huge and slow. And that's
obviously not good but has been the only way to do things for ages. Not only is
the performance spectacularly bad, the accessibility suffers because all the
rendering and layout elements obscure the structure with noise and cryptic
class names. Far away from being a descriptive representation!

The other world are people who loathe all the specific ( mostly legacy )
knowledge, and hacks and polyfills required to achieve anything, because
apparently it's so far off from what people are used to. Learning all that is
widely considered a waste of time, as it doesn't really transfer to any other
areas. So those people often don't bother with the DOM at all, and just keep
everything in the canvas, or develop their own solutions, because hey even if
they fail, at least they got a huge boost in personal experience out of it they
wouldn't get out of spending years learning all the specific legacy bullshit.

But that's not good either, because it invalidates not only the work to make
the web accessible for all users, but also to developers with non-expert
knowledge. Based on how few people actually picked up technologies like WebGL
or even just canvas in the recent years I assume that's just way beyond the
scope of the majority of content of authors on the web and will probably
forever be.

I think web components could become a middle ground between those worlds. It
would be possible to encapsulate those concepts in web components, and not only
make those accessible to the web developer community, but to users who suddenly
have a perfectly fine DOM focused purely on the basic elements of an
application they can interact with, with zero layout / rendering noise in
between.

So that's where I believe the web is headed, and we already have almost all
APIs needed to accomplish most of it already, both in the standards and
implemented in browsers, we just need to wrap our heads around it. But of
course there's also room for improvement, even though it's not strictly needed,
it would be greatly appreciated:

* a compile / transpile to js standard for vendors to build compile / transpile
tools into the browsers, optimally just allowing people to supply their code in
any version of ecma or any programming language and have the browser do the
compiling / transpiling, allowing the vendor to apply any optimization and
ensure compatibility ( and give feedback about it ) for their own
implementation and deliver optimized builds ( or web components ) with one
common interface but different code depending on user agent.
* extensible CSS, similar to custom Elements. There's no reason to hardcode for
example material properties in JS, when CSS is ideal, and specifically made for
this purpose. It's currently tightly coupled with the DOM, and close to useless
for anything that doesn't use the DOM for layout and rendering. Optimally
separate layout and rendering properties in CSS entirely. There's no reason for
example to have the overhead of 2d ( text ) layout properties on the material
of a 3d mesh.
* also a slimmer Element / HTMLElement if it should be the base class for all
web components. Currently you have to *delete* 90% of the properties on the
HTMLElement prototype, to prepare it to be extended for anything you want to
use for non-rendering non-layout purely structural purposes. 
* Completely sealed shadow DOM, alternatives for styling. There's no point in
having a shadow DOM if you can and *have to* penetrate it ( that part isn't
about webgl, but for the rendering / layout use case of components ). It goes
hand in hand with the custom CSS. You don't want to ever penetrate into shadow
dom, but instead apply custom, designed style rules, or, if it doesn't help -
use another custom element or fork / improve the source code.
* Redesign / extend the DOM and CSSOM to work with its own Data Types or at
least enums rather than DOMStrings in 99% of the cases. Not only for
performance but just for sanity and usability. There's no reason why you can
just construct, for example, a CSSColor, and just using it in itself. Being
able to actually set the color of an element from that should go without
saying. And all those cases where you have to go back to the documentation to
see the exact string expected by an attribute, rather than just looking up the
flag and using it. That's what hobbyist developers struggle with and waste a
lot of time on and it's mostly avoidable.


I'm not entirely sure how on topic all that is, or if this is the proper place
to address those issues / ideas.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 16 February 2015 14:14:14 UTC