Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progressive Web Components

arielsalminen.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Progressive Web Components

#51

Post by DangitBobby »

claytongulick wrote: post #15
microflash wrote: post #7

Earlier quoted context omitted.

In reality, building anything complex is a huge pain using web components, particularly because it is hard to author them with appropriate level of styling API and accessibility support. In my experience, web components are fantastic for consumers but terrible for the authors. Still, the advantages are clear: they don’t need any special runtime and can be used with other JS frameworks. Another thing in favor of web c…

Try keeping them in the light dom. Everything works like normal html + css, but you get all the benefits of reusability and encapsulated script logic. Lit-html (the library, not the framework) gives this approach super rendering speed too.

At what point does a library start being a framework and when does the distinction matter to the end user?

Re: Progressive Web Components

#52

Post by mock-possum »

wildpeaks wrote: post #45

My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered. It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.

Why is the uniqueness constraint of tag names a problem?

Re: Progressive Web Components

#54

Post by lelanthran »

troupo wrote: post #38
lelanthran wrote: post #37

Earlier quoted context omitted.

Ah, I see what you mean. You were talking about using imports recursively. I use fetch instead of imports for web components because I have a web component that does client-side includes, and it's literally easier to do client-side includes in a performance manner than anything else, including the recursive case.

So we're back to my original comment: https://news.ycombinator.com/item?id=49131513 Yes you can invent all kinds of workarounds for their core design . Re-implementing imports like you do. Or bundling, like everyone does and something that even lit recommends: https://lit.dev/docs/tools/production/

> So we're back to my original comment: https://news.ycombinator.com/item?id=49131513

And we're back to my original comment - imports get served from the local cache, so a bit of a nothing-burger in the great scheme of things.

Re: Progressive Web Components

#55

Post by shimman »

DangitBobby wrote: post #49
shimman wrote: post #46

Earlier quoted context omitted.

I'm sorry but purposely ignoring standards that were decided upon by multiple parties is always a shithead move. It shows that you don't actually care about community standards and just want to thrust what you believe down everyone's throats.

Lol. Or is introducing a "standard" that no one asked for and squealing that no one wants to spend their lives integrating your leaky "solution" a shithead move? Who is shoving things down people's throats really? You are very confused about the timeline for how these events played out.

Sorry but software development is more important that what some tech bro at a malware company thinks. I'm not confused at all. This is the culture of SV and it is the culture that VC wants: when they don't get their way they complain and force it upon others. The desire to exploit is their only ethos.

Re: Progressive Web Components

#56

Post by troupo »

lelanthran wrote: post #54
troupo wrote: post #38

Earlier quoted context omitted.

So we're back to my original comment: https://news.ycombinator.com/item?id=49131513 Yes you can invent all kinds of workarounds for their core design . Re-implementing imports like you do. Or bundling, like everyone does and something that even lit recommends: https://lit.dev/docs/tools/production/

> So we're back to my original comment: https://news.ycombinator.com/item?id=49131513 And we're back to my original comment - imports get served from the local cache, so a bit of a nothing-burger in the great scheme of things.

Except cache is not infinite, it is routinely expunged and re-fetched.

The "nothing burger" is so significant that even projects whose stance is "web components are the end all be all of web development" like lit recommend bundling.

Re: Progressive Web Components

#57

Post by DangitBobby »

shimman wrote: post #55
DangitBobby wrote: post #49

Earlier quoted context omitted.

Lol. Or is introducing a "standard" that no one asked for and squealing that no one wants to spend their lives integrating your leaky "solution" a shithead move? Who is shoving things down people's throats really? You are very confused about the timeline for how these events played out.

Sorry but software development is more important that what some tech bro at a malware company thinks. I'm not confused at all. This is the culture of SV and it is the culture that VC wants: when they don't get their way they complain and force it upon others. The desire to exploit is their only ethos.

That's nice. You keep being confused about who is imposing their choices on whom. The rest of us can keep using productive frameworks while you opine about how people aren't being ideologically pure enough in their software use. Best of luck out there.

Re: Progressive Web Components

#58

Post by cube00 »

wildpeaks wrote: post #45

My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered. It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.

Scoped custom element registries should help with this letting you register to a shadow root instead of globally. [1] Unfortunately Firefox hasn't come to the party yet. [2]

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1874414

Re: Progressive Web Components

#59

Post by cube00 »

mock-possum wrote: post #52
wildpeaks wrote: post #45

My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered. It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.

Why is the uniqueness constraint of tag names a problem?

The scoped custom element registries proposal covers some of the use cases where global elements are problematic https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Re: Progressive Web Components

#60

Post by cube00 »

Seems unusual that a commit with the message "Fix broken URLs" stripped out multiple sections on performance from the FAQ [1]

- How does Elena compare against other tools? (Elena vs Lit, Elena vs Stencil, Elena vs Enhance)

- What is the performance like?

The removed sections were once so prominent they were linked from the home page, however that link was not removed along side the parts of the FAQ that were stripped so it's now broken [2].

[1]: https://github.com/arielsalminen/elena/commit/2982c0f79ea113...

[2]: https://elenajs.com/#:~:text=Read%20how%20Elena%20compares%2...

Post reply on HN