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

HTML Web Components

blog.jim-nielsen.com

Post reply on HN
Print view View original

201–210 of 247 posts

Re: HTML Web Components

#201

Post by yuretz »

socketcluster wrote: post #152

Web Components are highly versatile. I built a chat app with GitHub OAuth login, blockchain-based authentication and access control using only 120 lines of HTML in a single .html file with no custom code, no framework, no custom server-side code. It can run anywhere: https://github.com/Saasufy/chat-app/blob/main/index.html#L23... You can try the app here (if you have a GitHub account): https://saasufy.github.io/chat-…

> ... with no custom code ...

Except all the custom code in saasufy-components

Re: HTML Web Components

#202

Post by riquito »

What's the preferred way to version web components since their name is global and you can't risk breaking old usages when you introduce a breaking change? user-avatar-v2? What's todays suggested practice?

Re: HTML Web Components

#203

Post by lelanthran »

madeofpalk wrote: post #3

> React components cannot do this — full stop. Render your react components on the server and send them over the wire as plain html. no client side javascript required — full stop.

> Render your react components on the server and send them over the wire as plain html. no client side javascript required — full stop.

Doesn't this then require the server to be written in Javascript as well?

Re: HTML Web Components

#204

Post by troupo »

drawkbox wrote: post #173
troupo wrote: post #117

Earlier quoted context omitted.

> Staying closer to web standards is always best for maintainability and portability. That's what you get if you chose literally anything but web components. Because web components are really bad at using and playing nice with web standards: https://threadreaderapp.com/thread/1717580502280867847 They need dozens of new web standards to fix their self-inflicted wounds and to work with the browser in a way that everyon…

I mostly agree but Web Components is a web standards as is templates/custom elements now. The others like React/Vue/Svelte etc are all going more for platform/framework lock-in over making sure people are doing augmentation of standards. Those frameworks have incentive to lock you in while standards are lock-in at a lower level. Other standards I like playing with direct like html/css/canvas/WebGL/storage/svg/video/a…

> I mostly agree but Web Components is a web standards as is templates/custom elements now.

People keep repeating this mantra as if this alone makes web components good

> Those frameworks have incentive to lock you in while standards are lock-in at a lower level.

Or: these frameworks have the incentive to solve problems that web standards have been unwilling to solve for decades, and won't solve for another few decades.

> I like platforms that make web standards the core aim not the platform lock in.

Then you should use literally anything else but web components. Because web components don't make standards their core, are broken on multiple levels, and will require 20 more new standards to fix things that are not broken in literally anything else: https://threadreaderapp.com/thread/1717580502280867847

> Lit is just a lighter weight version of that and closer to web standards

The only thing that is standard in Lit is that it compiles to web components by default.

Re: HTML Web Components

#205

Post by yuretz »

joestrouth1 wrote: post #43
sesm wrote: post #37

> > https://example.com/path/to/img.jpg " alt="..." /> > I thought the standard way to do it is: https://example.com/path/to/img.jpg " alt="..." />

That is one way to do it, provided `user-avatar` extends HTMLImageElement and not the more generic HTMLElement. Extending built-ins and using the `is` attribute is not supported in Safari however and last I checked they were firmly opposed to it. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

There is a polyfill for customiziing built-ins on Safari.

https://github.com/ungap/custom-elements

Re: HTML Web Components

#206

Post by littlecranky67 »

Maybe it is just me but for me web-components were never able to deliver what they promised or a viable solution for a simple reason: i18n/translations. As a European freelance web dev, I've virtually never been in a project where we develop single-language UIs - its always at least the national language plus English. Those translations can't reside within a "component" itself for a simple reason: Translators push you to always share translations across components to achieve consistency throughout your UI. Now with react-intl or react-i18n-next those translation strings will live in a single or just a couple of files for the whole UI, and be provided through a react Context. It is also one of my pet peeves when people talk about "independent, self-sustained components". That is just not a thing in UI land, in most bigger projects each component has quite some external dependency from some form of enclosing context (translations beeing the most common one). In the article, user-avatar is probable one without any text at all, but thats the minority of components.

Re: HTML Web Components

#207

Post by ttfkam »

Apparently not widely know, but…

> Svelte components can also be compiled to custom elements (aka web components) using the customElement: true compiler option.

https://svelte.dev/docs/custom-elements-api

This would negate the "vendor lock-in" arguments and allow Svelte for component development but web component for consumption and use. Best of both worlds. All the DX advantages of Svelte over web components without sacrificing interoperability.

Re: HTML Web Components

#208

Post by nathias »

meowtimemania wrote: post #183
nathias wrote: post #76

web components are a failed standard, it was a good idea 10 years ago but now its a very bad idea

What makes them bad?

There are so many downsides of choosing web components you really need a very rare usecase to justify them. They are an artefact of a time we're all glad to be done with, they force you into OOP so you're doing inheritance acrobatics, add TS and now you're feeding two hierarchies of inheritance that don't quite match and bloat to a 80% of your codebase, making it unreadable, prone to hacks and bugs, impossible to maintain etc. The point of web components was to make components more shareable between frameworks, and code more reusable, but now code written in any of the major FE frameworks is more reusable (a component looks pretty much the same in React, Vue, Svelte, but not with web components).

Re: HTML Web Components

#209

Post by nathansherburn »

ttfkam wrote: post #207

Apparently not widely know, but… > Svelte components can also be compiled to custom elements (aka web components) using the customElement: true compiler option. https://svelte.dev/docs/custom-elements-api This would negate the "vendor lock-in" arguments and allow Svelte for component development but web component for consumption and use. Best of both worlds. All the DX advantages of Svelte over web components without…

Any examples of the web component code they spit out?

Re: HTML Web Components

#210

Post by shanghaikid »

Web components are encapsulated very well. It is different from template frameworks such as react. It is somewhat similar to frameworks such as angular. As we all know, angular fails because of its complexity. It uses javascript to look like java. Web components look like It is not that complicated, but it also introduces a lot of concepts. These concepts are rarely used by ordinary developers. It is generally difficult to change the developers' inherent concepts and development habits to adapt. If there is no react or vue, I feel that it may not be successful because there may be other simpler frameworks.
Post reply on HN