Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declarative Custom Elements/HTML Modules/HTML-in-JS - February 2024 #79

Closed
Westbrook opened this issue Feb 9, 2024 · 4 comments
Closed

Comments

@Westbrook
Copy link
Collaborator

At the WCCG's February Meeting (#77), we resolved to hold a breakout session specifically focusing on gathering use cases and proposals to present to implementors in the April Quarterly Face-to-face. Here we're looking to get this session scheduled and gather an agenda for the conversation.

If you'd like to participate, please use this link to share your availability between February 21st and February 28th for this session. It would be great to have a consensus meeting time by February 16th at the latest.

I know that @EisenbergEffect, @trusktr, @sashafirsov and more have some prototypes that could lead to solid proposals in this area...hope to see you there.

@Westbrook
Copy link
Collaborator Author

WCCG Breakout: Declarative Custom Elements/HTML Modules/HTML-in-JS
Wednesday, February 21 · 1:00 – 2:00pm
Time zone: America/New_York
Google Meet joining info
Video call link: https://meet.google.com/wpv-capn-xob

@Westbrook
Copy link
Collaborator Author

Agenda:

  1. Use Cases. Bring your use cases, make sure we fully understand them, make sure we can fully explain them to browser implementors.
  2. Checkout the proposals/prototypes. There are a lot.
  3. Confirm next steps in preparation for presenting these to implementors in April.

Questions:

  • why are we doing this?
  • who's done similar things?
  • what is the far future in this area?
  • what are the small steps we can take to get browsers there?

@Westbrook
Copy link
Collaborator Author

Thanks everyone for joining in the conversation today! Really great input all around.

We started to gather some bolded use cases in our meeting notes, available here.

Our current next steps are as follows:

  • create an issue to track proposals that would like to present to the group, likely 15 minutes at maximum, but it would be best to keep things highest of levels to start, coming soon!
  • share when2meet links for one or more sessions in March to review those, coming soon!
  • follow up that process with clarification on how we can prepare a focused stance on the subject(s) to implementors, in April (or the beginning of May)
  • keep having rabid conversations in Discord, happening now and always! 😉
Meeting chat hidden within...

You
1:01 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit#heading=h.z1iz3zw5c5hx
You
1:05 PM
Notes doc: https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit#heading=h.z1iz3zw5c5hx Would be great to get all of you lovely attendees included! 🙏🏼
You
1:10 PM
Related docs: https://docs.google.com/document/d/1gVwERmYfjOHAgp0TIjrJydP5pSGr4Ko2Ti6VnSxh4EE/edit#heading=h.22xe8q7xd8fj
https://gist.github.com/EisenbergEffect/8ec5eaf93283fb5651196e0fdf304555
Michael Warren
1:16 PM
is there an inherent distinction between DCE and HTML Modules?

Imo HTML modules is "make .html files be able to hold stuff in a modular way"

and DCE is "the stuff inside HTML modules"?
Sasha Firsov
1:17 PM
we need to create one
Michael Warren
1:18 PM
HTML modules could exist and just import raw DOM with no custom elements in them at all, right?

So HTML modules could be useful as just HTML includes right?
Keith
1:19 PM
Can we open the notes document to those who have a link?
Or failing that, can I get access ;)
You
1:19 PM
Done.
Joe Pea (Joseph Orbegoso Pea)
1:19 PM
My take is HTML modules are like the old HTML imports: a bag of stuff, not just CEs.

But the concept of an "element module" or "custom element module" is specifically focused on defining and exporting (to both other JS and element modules) custom elements in a HTML-first format (JS being optional).
Joe Pea (Joseph Orbegoso Pea)
1:20 PM
Maybe we don't need "element modules", and can stick DCE inside HTML modules, but personally, the only thing I think that I want, as a developer, is element modules.
(like Vue or Svelte SFCs)
(and I could achieve that by using a subset of HTML modules)
James G
1:22 PM
i would've thought html modules are a dependency of DCE. you could declare a CE in a html module or the main doc, its just a means to get the source there
Justin Fagnani
1:22 PM
Vue is arguably that adoption
Steve Orvell
1:22 PM
Can we respect the queue please?
Michael Warren
1:25 PM
for me personally, the biggest use cases are

  1. minimizing FOUC
  2. Server side rendering
    Justin Fagnani
    1:25 PM
    declarative elements aren't necessarily less bytes anyway
    Rob Eisenberg
    1:26 PM
    The browser vendors themselves have indicated an interest, if only for the possibility of binary caching of element definitions. Firefox in particular has indicated this multiple times.
    James G
    1:30 PM
    thats actually our use case (C# backend)
    Nathan Knowler
    1:30 PM
    I’ve noticed that Enhance is exploring using WASM for SSRing their components in other languages.
    Joe Pea (Joseph Orbegoso Pea)
    1:31 PM
    ambitious
    Justin Fagnani
    1:31 PM
    why do we think that bytes over the wire is better with declarative custom elements vs plain custom elements? I don't see that this is obviously true
    You
    1:32 PM
    Justin did we catch all four of your use cases in the notes doc?
    Justin Fagnani
    1:32 PM
    let me check
    Michael Warren
    1:33 PM
    imo bytes over the wire will completely depend on the kind of component it is.

for something super simple where the only dynamic thing is attrs/props re-rendering it might be less bytes. for more complex logic DCE might end up being more bytes
Rob Eisenberg
1:33 PM
There's a value to html modules on their own. I think people would use template imports today even if the module format supported nothring else.
Steve Orvell
1:34 PM
Depending on the capabilities they have, HTML Modules seem like they could replace a lot of the features of a library like HTMX possibly.
Michael Warren
1:34 PM
i agree with Rob, if DCE implementation was a phased approach, imo HTML Modules should be phase 1
Owen Buckley
1:35 PM
+1 on HTML Modules
Justin Fagnani
1:35 PM

There's a value to html modules on their own.

+1
James G
1:35 PM
everyone seems to agree they are separate so its probably worth just tackling them as such. html modules are useful in general, not only for dce
Owen Buckley
1:36 PM
yeah, I think the point of "equalizing" all web languages through the module system is a great milestone
Justin Fagnani
1:36 PM
HTML modules would allow for userland declarative element libraries w/o build steps
James G
1:36 PM
yup, splitting them up will help this stuff move forward i imagine too
Steve Orvell
1:37 PM
^^ yes, but even that's not required... and it does feel to me like more user land DCE might be needed before standardization can/should move forward
Joe Pea (Joseph Orbegoso Pea)
1:37 PM
also assuming that we get template interpolation and repeats, etc
Justin Fagnani
1:37 PM
I think that HTML modules and Template Instantiation would be a good foundation to build slimmer userland declarative custom element solutions
Joe Pea (Joseph Orbegoso Pea)
1:37 PM
+1
Owen Buckley
1:37 PM
^^ +1
Michael Warren
1:38 PM
+1 for HTML Modules as phase 1 of DCE
Joe Pea (Joseph Orbegoso Pea)
1:38 PM
its already not too much code to make our PoCs, but with some limitations: f.e. regexing import.meta.url fails if import.meta is first saved to a var.
James Stuckey Weber
1:38 PM
+1
Steve Orvell
1:38 PM
As Rob has brought up, I think a richer API for attributes and properties makes sense to pursue in isolation.
Justin Fagnani
1:39 PM
sorry I wasn't at that meeting... which implementors said that?
I thought HTML modules were almost ready to go
Joe Pea (Joseph Orbegoso Pea)
1:40 PM
Idea (namely for Sasha's sake):

use import attributes to specify that JS should be disabled for the imported module?
Justin Fagnani
1:40 PM
Dan Clark was about to start implementing before he got pulled off to other things
Jared White
1:40 PM
HTML has no reuse mechanism right now, none at all. Seems bonkers to say that's not an interesting use case just on its own
Joe Pea (Joseph Orbegoso Pea)
1:40 PM
+1
moon man
1:40 PM
+2
Michael Warren
1:41 PM
+1
Rob Eisenberg
1:42 PM
I haven't seen Dan in a while. I suspect it's more of a matter of internal priority changes and less of lack of interest as a standard. Just geussing.
Brian Kardell
1:43 PM
Some of the people who championed html modules aren't at MS anymore, right? Like Travis? Maybe MS has just had a lot of changes/priority rejiggering for those who are still there
Michael Warren
1:44 PM
+1 for that proposal. imo we should frame it as HTML Modules are phase 1 of DCE
You
1:44 PM
w3ctag/design-reviews#334
Current Tag issue.
Joe Pea (Joseph Orbegoso Pea)
1:45 PM
Can we schedule a call for specifically presenting PoCs and their pros/cons?

+1 to understanding what's the use case for HTML modules without DCE.
Michael Warren
1:45 PM
HTML Modules is basically Vue's component model. a .vue file is basically an HTML module imo
Jared White
1:45 PM
document fragment, plus any JS exports
Joe Pea (Joseph Orbegoso Pea)
1:46 PM
Not exactly, because they export a component. Whereas these HTML modules exports other things besides DCE
Owen Buckley
1:46 PM
My naive implementation was assuming a template, but not set in stone
Doug Wade
1:46 PM
My naive implementation also assumes a template, rather than a document fragment
Rob Eisenberg
1:46 PM
To get an idea of adoption, I think Vue single file components, simple Ember components. Aurelia HTML-only components, etc. are the best examples. And they seem to be well liked.
Owen Buckley
1:46 PM
i guess whatever would pair will with DOM parts would make me happy

  • well with
    Brian Kardell
    1:47 PM
    I think sasha has the last comment on that issue, no?
    Justin Fagnani
    1:47 PM
    I don't understand Sasha's question
    moon man
    1:47 PM
    I like the idea of writing layout styles with semantic HTML, and reusing them a la Svelte's +layout.svelte files. IDK if that counts as a use case.
    Sasha Firsov
    1:48 PM
    will comment on discussion in github
    Rob Eisenberg
    1:48 PM
    I have explicitly not made my compiler public because I think it would be an immediate compete with something like Vue or Svelte...and I'm personally not prepared to do that. So, it's a bit of a pickle when trying to gauge more "pure" interest in declarative custom elements.
    Justin Fagnani
    1:48 PM
    I think the current proposal makes a lot of sense. What are the complaints?
    Owen Buckley
    1:48 PM
    but mostly that HTML comes from the server tough? not the module system
    re: htmx
    Justin Fagnani
    1:49 PM
    I think declarative custom elements need a new HTMLElement subclass, which can handle what to do when properties/attributes change, etc
    Rob Eisenberg
    1:52 PM
    ^ I think I agree with that based on my experience building stuff. Properties set prior to upgrade are a specific case where that's probably needed.
    Justin Fagnani
    1:53 PM
    named exports is a big one
    and scripts is a huge one, but has open questions
    Steve Orvell
    1:53 PM
    Participation in the module graph.
    Justin Fagnani
    1:53 PM
    yes ^ deduplication
    I think that people generally don't use runtime solutions for this, they use build systems... like Vue
    the average developer uses tools
    James G
    1:54 PM
    real world examples of fetched doc fragments etc - agree it would be interesting to see some
    Justin Fagnani
    1:54 PM
    I really don't think you'll see any real world usage now. People don't do this stuff imperatively. They want something in the module graph
    Owen Buckley
    1:56 PM
    Angular might like HTML Modules. They are pretty big on separation of concerns / technologies
    (e.g. a file for each web format). but I guess they might just compile that away anyway I suppose
    James G
    1:57 PM
    i think vue is closer than react
    Justin Fagnani
    1:57 PM
    Angular is... p[robably going to move to JSX
    Michael Warren
    1:57 PM
    +1 vue is closer
    Owen Buckley
    1:57 PM
    :o
    Joe Pea (Joseph Orbegoso Pea)
    1:57 PM
    +1 vue/svelte/and aimilar
    Michael Warren
    1:57 PM
    react components are just components at build time...after build time they are just DOM
    Justin Fagnani
    1:57 PM
    You didn't hear that from me
    James G
    1:57 PM
    aha
    Owen Buckley
    1:58 PM
    :D
    Justin Fagnani
    1:58 PM
    React components aren't event DOM. They are JS that can produce DOM
    Michael Warren
    1:58 PM
    gotta jump
    later everyone!
    Justin Fagnani
    1:58 PM
    I want to demo Stampino Element
    Jared White
    1:58 PM
    I can demo Heartml
    Justin Fagnani
    1:59 PM
    I think we'll need 2 hours
    Rob Eisenberg
    1:59 PM
    I'm happy to do a screen share and show stuff, but I don't want to make my compiler public at this time. I do have the proposal doc that talks a lot about what it does though.
    Steve Orvell
    1:59 PM
    ^^ going through that doc and showing a demo would likely be really valuable.
    James G
    2:00 PM
    i think so too

@trusktr
Copy link

trusktr commented Feb 22, 2024

Opened issue to track proposals for demo day:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants