Hacker News Reader

You don't explain how you think Shadow DOM is too complex.

They're simple to me: basically just isolated tree of DOM attached to the document. The only slight complexity comes from projection, which really is just a way to plug in a child element into the shadow. Projection is absolutely necessary for composable widgets, you couldn't create containers without them.

One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore, and I won’t be able to use websites without JS anymore.

Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS.

There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages.

[1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...

> One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore

With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries.

https://drafts.csswg.org/css-scoping-1/#deep-combinator

> It’s currently disputed whether this combinator should exist.

Also, it breaks about every existing userstyle, ever.

And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">

I think the deep combinator is already deprecated in Chrome and unlikely to make it into the spec.

This is not an issue you have with WebComponents specifically but the direction the web has been taking for the last 10 years.

Solving the problem of composability of visual components on top of the existing DOM leads to chicken-or-egg problems like getComputedStyle/offsetTop mentioned in that Mozilla blog link someone else referenced. DOM is a crufty stateful beast, and enhancing it is hard which scares me away.

Beyond that, the Web Components spec seems geared for coarse-grained components - like a widget or a panel. I could be wrong about this, I admit, my experiments a year ago with Web Components were short lived when I saw how much got polyfilled on Firefox. Anyhow, React is a javascript library exercise rather than a retool-the-DOM exercise to me, and that's a big reason I appreciate it. It offers data binding, rendering, templating, and true-componentization all in one package - and it supports legacy systems. I think there's an answer in Web Components for all of those things, including legacy support up to a point with polyfills, but it wasn't cohesive nor easy to roll things.

I think with lots of tool support, perhaps a compiled language targeting the Web Components spec, it could be just as easy to roll Web Components as React Components.

(Speaking as someone who worked on the Polymer team for a year, and has been writing React at a separate job for roughly half that)

> The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components.

Web components have pretty much the same levels of composability as React, but have promise for even more. The main reason I say this is that the components specs attempt to formalize a surface area for all web webcomponents libraries to interoperate with each other - though we're not to that point yet.

Many of the Polymer core components are a great example of composed elements (sometimes overzealously so). Shadow DOM and insertion points (<content> or <slot>) do wonders for this. (Yes, Polymer 1.0+ backs off from this a little bit)

React really only composes well with elements written in React. It can talk out to native components (and custom elements), but it's awkward enough that you tend to build wrappers to expose a more React-y interface (value, onChange, etc).

---

> I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;)

Assuming that you want these inline frames on a per component basis, we're talking about a ton of overhead per component:

* A new JS VM context (for the sandboxed global and security mechanisms)

* A new render layer (and the the synchronized painting you mention)

* All the other browser bits that would need to be built up

---

DOM is a problem, but it's not the biggest problem, and performance-wise, there have been tremendous improvements in the last few years (Try running your benchmarks again).

However, imagine a world where all elements are defined with a set of public APIs like web components. No more crazy special cased properties, magic methods, etc. Imagine how much cruft the browser vendors could remove from the DOM. Imagine how much faster things would be.

Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.

>Yes, Polymer 1.0+ backs off from this a little bit)

I didn't know about this, any guidance on why?

Polymer 1.0 has support for shadow DOM, but also what they call "Shady DOM": https://www.polymer-project.org/1.0/articles/shadydom.html

TL;DR: Shady DOM provides an API that is similar to shadow DOM, but without all the crazy overhead when polyfilling it. The downside is that it's not quite transparent to someone outside of a Polymer element

A very interesting perspective -- that I happen to agree with. There's also nothing preventing you from using web components from React.

> Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.

It would be interesting to see if that's even remotely feasible with the current "limitations" of Shadow CSS and/or how Shadow CSS would have to be extended to support this.

Isn't that how normal frames used to work?

Before they were deprecated for iframes?

my thoughts exactly. what's old is new again

Frames like frameset? It sounds more like Netscape 4 layers.

I don't want to partition the page the way frames/frameset did, I want to sandbox code and content the way iframe does, just in a more lightweight fashion. If I could couple that sandboxing with a component factory library like React, that could really be something else.

I think you're talking about a "seamless" iframe.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

Note that this is not supported in any browser, and Chrome support was first implemented and then removed over two years ago, so it seems unlikely to ever be supported. Also a seamless iframe is not CSS-isolated, something that the GP said they wanted.

http://caniuse.com/#feat=iframe-seamless

I have sometimes thought about experimenting with rolling BLOB URL's for HTML, CSS, and JS and using that to initialize an iframe. I think that would work. One of the things I'd like to do is be able to build a frame sandbox using assets already loaded by the parent page.

I believe iframes can be very costly for the browser to manage, but I don't understand all the reasons why that would be - perhaps something to deal with the cross-domain security concerns.

It'd just be nice to have a stripped-down same-domain version of iframe that could layout nicely as a rectangle into the parent page, but not inherit styles nor Javascript namespace from the parent page.

The idea of having multiple threads contributing to the DOM that builds the page really intrigues me.

There's a proposed thing for HTML5+ called CanvasProxy, for example. The idea would be that you could detach a Canvas from the DOM thread and give it to a Web Worker. It could get a Canvas context in the worker from the proxy, and all draw commands would execute against the Canvas' pixel buffer in the worker. Meanwhile, back in the DOM thread, the actual canvas tag still lives on, just in detached mode, but you can still set CSS styles on that tag. You just can't get access to the Canvas context.

It sounds rad, and would make a big difference to canvases that represent heavy computations or frequent draws. No browser vendor has attempted to implement CanvasProxy however, it sounds like it is a challenge to keep it actually performant, and/or there are GPU threading issues?

You and me and lot of other people too. Get in line! ;)

It was so nice to finally get inline SVG, instead of confined inside Adobe's plug-in. Crazy days.

The problem is that the HTML standard is being written for regular computer users instead of for seasoned developers.