Deno: Support for HTMLElement

[brianleroux]

Similar to other browser globals but recognize this is an ambitious request. If web compatibility is a goal then from my perspective this should be too.

Currently there are only a few options for constructing a DOM on the backend. Some folks are using Chromium/Puppeteer but this is really memory intensive and crummy for places where coldstart performance is important (like AWS Lambda). JSDom has some support for doing this but resolving esmodules mixed with Node require is clunky at best. A first class runtime solution on the backend for Web Components would be extremely useful for those of us that want to render as much of the DOM as possible before sending it to the client.

I think that's a very large audience and a worthwhile goal. Thanks for considering!

[nayeemrmn]

Effective duplicate of #3447.

[ry]

I'm open to it. It needs to be done in a way that doesn't effect our size or benchmarks, but I think that's possible.

I'll close #3447 in favor of this one because it's more specific.

[jsejcksn]

Can the scope of the request be clarified?

I don't want to assume anything, but it sounds like DOMParser and XMLSerializer are being abandoned by closing #3447 in preference to this one.

[nayeemrmn]

... are being abandoned by closing #3447 in preference to this one.

@jsejcksn This issue requests a specific and foundational part of the DOM with a use case. It's better to let any more advanced API be gradually requested _after_ the prerequisites are implemented, with specificity and a use case. See #4756. As another reason, #3447 is requesting a jsdom port in std which would be redundant if we're considering built-ins.

@brianleroux For server rendering, I guess for now you're looking for the ability to document.createElement()s, append them to each other, change attributes etc. and just stringify it for the client?

[0kku]

DOM APIs in general are something we've found to be necessary for our needs, and have started work on an implementation using Rust, Html5ever from Servo and TS because we didn't find JSDOM's performance satisfactory. Our goal has been to be able to run DOM code in Deno without modifications, which would involve implementing, among others, the aforementioned DOMParser, XMLSerializer, and document.createElement(). Ofc the work is in its infancy at this time. Would be really cool to see this supported natively in Deno.

For server rendering, I guess for now you're looking for the ability to document.createElement()s, append them to each other, change attributes etc. and just stringify it for the client?

I don't know if that they were looking for, but that's pretty much exactly what I/we've been looking to do with Deno.

[jsejcksn]

As another reason, #3447 is requesting a jsdom port in std which would be redundant if we're considering built-ins.

I'm on the same page with everyone else here. I guess I didn't say it, but I always thought the JSDOM port wouldn't necessarily be a literal port, but rather it would bring the browser built-ins that JSDOM provides.

document.createElement() obviously depends on document, and document is yielded by DOMParser:

const doc = new DOMParser().parseFromString('', 'text/html');

Similarly, serialization methods on element (for example, element.innerHTML/outerHTML) utilize the exact same fragment serialization algorithm which is used by XMLSerializer.

That's the reason I brought up DOMParser and XMLSerializer specifically. I realize the DOM spec is (overwhelmingly) massive, and agree on case-driven feature development. Is there a browser-compatible API that could be employed to address the mentioned cases that wouldn't rely on those two?

[Alhadis]

Would this extend from Element, Node and EventTarget? Or will it only implement a subset of properties that are useful, rolling them all into the HTMLElement class...?

This could be a slippery slope. Be careful.