Remix clone Hacker News

Custom Elements don't play well with HTML either. And "just dropping <my-dropdown>" is not much different from "just dropping <div id=app> and running some framework code on it"

All the reasons are here: https://dev.to/stuffbreaker/web-components-and-ssr-2024-edit...

▲

troupo 9 days ago | parent [-]

It's strange to see people downvoting this when custom elements still can't be properly rendered on the server. All the attempts are very framework specific, e.g. lit's list of caveats https://lit.dev/docs/ssr/overview/ (and shoelace referenced above depends on lit).

There's nothing very special in sending a html tag and then attaching functionality to it with javascript when it's loaded in the browser.

▲

spankalee 9 days ago | parent [-]

Framework server rendering is framework specific... Seems like a framework problem.

At least custom elements can just be including in framework-specific templates and be included in the rendered output, even if not deeply server-rendered.

It's actually very difficult to do this correctly and at scale with a framework like React, because in React you need an ID and JS call to initialize each embedded component, when custom elements initialize themselves.

Anyway, you have an axe to grind, so have fun with that. I'll see you next time I make a positive comment about web components I guess.

	▲	troupo 9 days ago \| parent [-]
		Note that we're talking about embedding them in a Rails app. - all SSRed custom components are framework/library specific and cannot be rendered outside of javascript runtimes - you need a JS call to initialize each custom component (though this is likely provided by the bundled JS) - since when providing an id in a server-rendered HTML become an insurmountable challenge? - and they have many additional issues. Example in the sibling comment: https://news.ycombinator.com/item?id=43641081 > Anyway, you have an axe to grind, I don't have an axe to grind. I correct the magical wishful thinking that exists around custom components