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

241–247 of 247 posts

Re: HTML Web Components

#241

Post by [deleted] »

naasking wrote: post #118
nightski wrote: post #17

Earlier quoted context omitted.

I just don't get the point. They are cumbersome to use, so now you need a lightweight framework on top of the built in framework such as Lit (which btw is larger than Preact). Then they solve none of the real problems like state management, routing, etc... so you'll likely need to pull in more. Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underne…

State management is only a problem if you have client-side state that isn't HTML state. Lots of web apps don't fit that mould.

[deleted]

Re: HTML Web Components

#242

Post by hasanhaja »

continuational wrote: post #238
hasanhaja wrote: post #234

Earlier quoted context omitted.

What would a non-trivial example look like to you? I'm working on building exactly this resource alongside a series of posts on web components.

One example would be a search field that shows suggestions from the server while typing.

Here's a pre-built one that I found that even lets you customize the debounce amount: https://ionicframework.com/docs/api/searchbar#debounce

The Stackblitz example is quite good too.

I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.

Re: HTML Web Components

#243

Post by fkyoureadthedoc »

revskill wrote: post #180
fkyoureadthedoc wrote: post #72

Earlier quoted context omitted.

So when react components were classes they were comparable, but now that react components are functions they are not?

A class is a closure ?

    function Dog() {}
    var dog = new Dog();
Hey look classes are actually functions, now you can compare them, have at it.

Re: HTML Web Components

#244

Post by socketcluster »

yuretz wrote: post #201
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

It's generic code, not specific to the application as it can be reused for any application. There is code behind native HTML tags too but we don't say that writing HTML is writing code, the browser handles that.

Re: HTML Web Components

#246

Post by drawkbox »

troupo wrote: post #204
drawkbox wrote: post #173

Earlier quoted context omitted.

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 decad…

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

You did ask. heh.

As I mentioned, I prefer direct standards or at least frameworks that make standards a main part of the design, even if only on output.

Standards are slower to finalize, frameworks front ran them via abstractions that may have been needed for a while --like Flash with interactivity before HTML5/canvas/svg/WebGL/etc and I was huge into Flash and plugins, those days are over though. Standards will be around longer and more maintainable on standard schedules not just feature/dependency pump frameworks of today that have verbloat.

Plugins and now frameworks innovate and front run, and influence standards, then standards win the long game every single time. Like why use virtual DOM when shadowdom is now available, unnecessary abstraction now that will always lose to native dom abstractions like shadowdom.

Right now with web standards where they are at, Javascript how far it has come, and the coming WebAssembly + WebGPU platforms now being ready or close to ready, the current frameworks are about to be lapped. It is just the way things go and the typical waves in innovation to standards and repeat.

About Lit, I mentioned it as I said in another comment "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"

We can agree to disagree on the rest.

Re: HTML Web Components

#247

Post by mock-possum »

troupo wrote: post #111
mock-possum wrote: post #44

Earlier quoted context omitted.

I’ve made a couple of big SPAs that use Lit to manage views. I can’t link you to them here without blowing my cover, but honestly I love working with web components, and being able to do it natively rather than propped up by a mound of JavaScript feels good.

You're not doing it natively. You're using a framework replete with its own custom DSL, multiple workarounds for issues like SVGs, its own data binding system etc. It's just as native as any other framework under the sun.

Sorry, I’ve been working with web components since before they had wide browser support - so now, it’s ‘native’ in the sense that web component is a feature native to the browser, instead of being shimmed / polyfilled in. You can just write web components in an .html file, drag it into the browser, and it works, no build step or servers or external libraries required.
Post reply on HN