Likely unpopular opinion: NodeJS should prioritize first class DOM support over esmodules. Only one of those things is ready for production use and would provide a real win for the web devs.

Only one of those things could be easily supported by user-land solutions, though. I think I'd like ESM first.

I would too but they're not ready. We got the impl feedback. They're slow. The bundling semantics now need to be figured out. Loaders also. This guarantees divergence. Thus: not ready. That's ok! We need prerender now though and the DOM is very stable.

I imagine the TSC would love this feedback. I know @MylesBorins is especially keen on Node.js and the web platform having eventual parity - he may be able to help navigate this as a suggestion.

We need to work on ESM now because we need to collaborate with the web platform on the implementation before it is even further set in stone There is no reason why this needs to be a zero sum game though. First step would be what low level apis are making DOM slow

oh ya for sure, imagine it'll be in a flag for a few years yet, think the comms and community could use a wake-up call though. they're transpiling themselves into a Flash-like situation.

I could see it being behind a flag for maybe another year and a half tops tbqh Most of what we need is there. Once we reach consensus on interop there won't be much of a reason for a flag

the year and a half number is estimated based on the time it will take for dynamic import + import.meta to land in V8 I'm not sure we would be in a place to remove the flag by 10, so it may end up being 11

Heh, an estimate on time from a developer? I'll take that bet. I remember thinking the same thing in 2014.

We already have code shipped though :P BTW, regarding the DOM stuff.. I think that there are some interesting bits here regarding a number of browser APIs and figuring out how to standardize + test implementation across platforms Node needs to be considered part of web platform

yar! have the intention and todo list item to try to champion Node as a proper user agent with @treshugart and @MylesBorins / its an awesome goal for Node

I started writing a snarky retort implying that "ready for production use" hasn't really been a popular node concern. But it hit too close to home so I didn't.

heh, idk, I've been a happy prod user for a long time. (def happier than…things I've used in the past.) maybe my use cases aren't very interesting though.

This assumes a priority list. It's an OSS project, people work on what they are passionate about 🤷

OH WOW can you PLEASE tell me more about how open source works?

touché

[sorry that was p knee jerk shitty of me] I get what you were trying to convey.

Would you mind elaborating on the specific use cases you have in mind?

To expand: use-cases that are not satisfied by the available user-land implementations. (Or ones that are but would benefit from this being in Node.js core.)

Web Components prerender is my primary desire. Somewhat possible in userland but bigger idea here is Node as a first class user agent makes it have proper “skin in the game” that is the web platform.

I think suffient skin could be TSC Working Group which focuses on web compat. Empower and encourage experimentation in userland.

on #webcomponents ... do you know a way/polyfill/alternative to make customized built-ins useful, cross-browser?

Idk but from what I understand @WebReflection’s custom elements impl the best if you’re shipping to production

thanks! that looks like it supports CBE, I will try ... github.com/WebReflection/… i was looking at github.com/webcomponents/… all the time and that seems up in the air

heads up: custom elements builtin are a ghost in the specification ... fully unsupported and nowhere in the process of being concretely standardized. Current API regarding CE and builtin extends is dead already.

Ok, Thanks for sharing that. I saw the discussion going nowhere. Too bad though.

What is the current best practice for extending a native element? Feels like the the right thing for what I currently need to solve.

I think @polymer has a very good summary of the situation and a way how to move forward with it. polymer-project.org/2.0/docs/about… #webcomponents #cbe

Yeaaah I’m not sure what happened. I liked `is` but 🤷‍♂️ Cc @slightlylate

has been writing up what happened on the way to the Forum; TL;DR: if the point is to reduce magic and improve reuse, we can only really get there through further decomposition.

I.e., behaviours from built-in that you want to re-use should be factored out into mixins that the built-in elements also happen to use.

Makes sense. Inherited behaviour would turn into an accessibility nightmare whereas it just gets retained by composition (I am assuming).

From what I recall Safari came up with this 💡, if I remember the discussion correctly.

sounds like the thing that elix.org is doing ... cc @JanMiksovsky

That means `is=` is history, and agreed to not become reality? /me trying to figure out which future proof way to go ;)

personally feel @WebReflection has the best plan for this medium.com/@WebReflection… (tho I'm sure some won't agree / but it is really smart from a migration perspective)

I'd rather neither, not ES Modules for the same reasons as you, and not DOM-in-node, because I don't see it as needed bloat. I'd love to see it as an official extension/module though.

Idk that it’d be bloated. Guess some browsers get pretty big. A lot of our problems in interop would go away though. Not sure that Node has any official extensions (outside npm).

how about: lambda should offer headless browser runtimes.

How do you stop people running untrusted web pages on this browser runtime? No sandbox and custom DOM bindings => pwned in 60 seconds. Bear in mind most pages contain untrusted ads even if it's your own page.

sandbox perhaps; docs that state “don’t aim this potential foot gun at your face” 😏

for sure, and pwnage on a serverless platform seems like it’d be much less catastrophic.

Unless I'm completely mistaken, the use case would be to prerender local application frontend code, not loading remote code. Anyway, that would eliminate most of the pain we have with things like Angular Universal.

If only we had DOM tree serialization to array buffers...if only there were proposals for this.... IF ONLY 🙃

What are the current proposal(s)? I’m always a bit more interested in experimenting and prototyping but pictures and stories are helpful too.

github.com/whatwg/dom/iss… I (not speaking for chrome) like this proposal at a high level

Yeah that’s neat! I’m thinking a bit more about construction of a DOM String for prerender (which I guess this hypothetically would do also but in a clientside hydrate step)

Frankly I think we owe it to ourselves to spend a couple years playing around with jsdom-alikes in WebAssembly. We can learn a lot DIY-ing out of core, now, performantly.

Ya it’s reasonable to keep things separate. Skin in the web platform game would also be a reasonable forcing function to avoid repeating past mistakes. I can think of a few.

Node getting back with the tribe is definitely a good good thing.

I'm into it

What would be different from jsdom?

Governance forcing function. Makes the Node project a browser user agent w real skin in the web platform game.

Otherwise nothin.