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

181–190 of 247 posts

Re: HTML Web Components

#181

Post by Nathanba »

tolmasky wrote: post #119

I can't tell if people who champion web components don't understand why the React model took off, or purposefully pretend to not know why since web components don't really solve most of the things people using React care about, and thus look bad in comparison. This article is a good example of this. For starters, the "one shell component" thing is kind of a red herring. There's plenty of React components that interac…

Most people just don't know what they are talking about. I think the only way that web components would be winning is if they were designed around a single render function to replace react but of course then the entire react/svelte/etc community would be crying out because they can't compete with a natively implemented virtualdom so everyone would have to switch to web components. But isn't that the point though?! Making life exponentially easier for developing a web application?! We shouldn't have to need all these extra frameworks like react, the browser could simply give us a blazing fast virtualdom and then everyone uses that and gets on with their lives.

You only get two things with web components: 1. style isolation (imo everyone will switch to @scope because shadow dom is unwiedly to use, even me probably) 2. the tiny nice advantage of being able to querySelector("my-element") and being able to actually call instance methods on the thing that it gives back, directly. Dont really need that very often though, it just feels super nice.

The argument for web components is really meager and the tooling is far worse, like you said: SSR is missing, autocomplete IDE support for elements and their attributes is missing, bundling and minification is missing for the html templates and you have to do it all yourself. People are now showing off unminified js and ordering their imports manually like it's 2011 again and act like that's good. No of course that's not better than what we have. lit.dev is okay partially because I think the fact that they use web components is almost besides the point, it's just a single render function like you have with react again.

Re: HTML Web Components

#182

Post by andai »

andai wrote: post #150
joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

> lackluster with no "Batteries included" I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote: "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

I am of course, slightly exaggerating, but... by way of analogy:

I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why!

Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).

Re: HTML Web Components

#184

Post by presentation »

toasted-subs wrote: post #139
jiggawatts wrote: post #134

Earlier quoted context omitted.

As a counterpoint: I consult for government agencies that have all separately decided to standardise on Angular. They mostly publish static content: alerts, updates, reports, etc… At most they might have a single page somewhere for submitting a payment or a simple form. But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency…

Kind of obvious why, any of the react based frameworks all fail an audit. Doesn't even make sense to me why anybody uses them. You cant audit static sites (ones thing I don't like about having traditional linked libraries).

Probably since 99% of websites don’t need to pass an “audit”, whatever that means

Re: HTML Web Components

#185

Post by marcus_holmes »

I recently used Web components to make a fairly complex form. It works well, but I am absolutely building the entire DOM tree inside the component in JS. The component relies on a bunch of tags being in the right place in the tree, with the right id. If the tags were specified by the HTML then there's too much opportunity to get it wrong. Templates might be do-able but there's no convenient way to add a template to a script file, or specify a template in JS (I guess this is why JSX came to be).

I definitely feel like I'm doing it wrong, but all the guidance I see doesn't help - they're all very "hello world" examples that don't get into the difficult stuff.

Re: HTML Web Components

#186

Post by mardifoufs »

troupo wrote: post #166
Fahata wrote: post #127

Earlier quoted context omitted.

I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with then-ancient abstractions. The JavaScript of a well-written web component should be as valid now as it will be in 10 years, as you're just using the platform.

This year I pulled class-based React component into a greenfield React project. Worked without a hitch, even though its a 10-year difference between approaches. Meanwhile, "use the platform": - all form components written before form participation landed in browsers are broken - all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM - ... you may continue this…

Yeah I don't get the comments either. React has been there for a decade now, is pretty stable and very backwards compatible. You can't really go wrong with it and it's a super lightweight "framework" (I know, it's not a framework, maybe a library would be a better term) all things considered.

The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.

Re: HTML Web Components

#187

Post by mewpmewp2 »

andai wrote: post #182
andai wrote: post #150

Earlier quoted context omitted.

> lackluster with no "Batteries included" I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote: "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lin…

At least PDF libray you can update to include new functionality under a new version, but you can't just out of blue change the JS behaviour of undefined being rendered. It would definitely break something without warning.

Re: HTML Web Components

#188

Post by mickael-kerjean »

superkuh wrote: post #8

It's a nice idea and I'm glad we can expand the language to differentiate between html web components and javascript web components. That's important because the vast majority of use of web components are in the form of javascript web components. The only time I've ever seen HTML web components are on blog posts talking about how you can use web components. Never on an actual website about something besides web compo…

I do use them on my OSS work (https://github.com/mickael-kerjean/filestash/tree/master/pub...) since I've started migrating away from React to VanillaJS. The app itself is a file manager for every possible file transfer protocol there is (FTP, SFTP, S3, NFS, SAMBA, ....) and is used by many thousands of people

Re: HTML Web Components

#189

Post by jonahx »

joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery

Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.

Re: HTML Web Components

#190

Post by keepamovin »

fuzzy2 wrote: post #149
joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

My take is: As explained in the article, user-avatar does absolutely nothing. If anything, it could only enhance the existing markup (with behavior), but never replace it. It’s… semantic markup, if you will. Baloney if you ask me.

Yeah I was thinking about what it could do, but I don't get it. The point of custom elements is to define a class in JavaScript that does something. Custom elements are just a part of web components tho, and you can use shadow DOM, more JS, and templating with slots.

I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.

Post reply on HN