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

231–240 of 247 posts

Re: HTML Web Components

#231

Post by davedx »

Xeamek wrote: post #220
davedx wrote: post #218

Earlier quoted context omitted.

I don’t like Facebook but claiming it’s a “glorified text forum” is utterly absurd. Please argue in good faith here

But it is though? I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum. And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under th…

Inherently different things:

- the social graph underlying every post and content producer (one of the reasons FB introduced graphql)

- the recommendation and advertising algos that are interdependent on the content feed

- the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources

Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex than a forum.

FWIW I’ve developed social networks and forums professionally; social networks are inherently more interactive. My first real exposure to front end dev was when I worked on a social network. If I had to build the same webapp today there is zero consideration of writing it as a backend rendered application or restricting to only progressive enhancement. It would only put off the inevitable migration to real FE tech.

Re: HTML Web Components

#232

Post by Xeamek »

davedx wrote: post #231
Xeamek wrote: post #220

Earlier quoted context omitted.

But it is though? I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum. And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under th…

Inherently different things: - the social graph underlying every post and content producer (one of the reasons FB introduced graphql) - the recommendation and advertising algos that are interdependent on the content feed - the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex tha…

The things you mentioned are backend dependant, though, not intrinsic to how you render and present them.

What specific aspects of facebook's comment section under post make it that json response is so much better then a html one?

Re: HTML Web Components

#233

Post by hasanhaja »

wayfinder wrote: post #177
joshstrange wrote: post #130

Earlier quoted context omitted.

> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top" We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places wh…

React is not a framework. It is a fancy HTML templating library first and foremost and you should use it when you need HTML templates, which means you that can use as little or as much of it as you want. I’ve built mostly static pages with React loaded and embedded into parts of the page. The webpages would function without JavaScript enabled.

How does the React part of your page work without JavaScript enabled? Are you using a static site generator (or another server side rendering tool) like Next.js?

Re: HTML Web Components

#234

Post by hasanhaja »

continuational wrote: post #144
yohannparis wrote: post #136

Earlier quoted context omitted.

This is a purpose of a blog. This was not a tutorial or an article on how to use Web Components.

I mean, anybody is free to write how they like on their blog. I just don't find arguments like these convincing without realistic non-trivial examples.

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.

Re: HTML Web Components

#235

Post by hasanhaja »

davedx wrote: post #217
joshstrange wrote: post #130

Earlier quoted context omitted.

> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top" We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places wh…

Fully agree, thanks for elucidating. IME there’s a crazy amount of strawmanning that goes on with these “anti-react” technologies/cults. Yes of course your html and css static site doesn’t need react. But most of us who are actual software devs/engineers aren’t working on static websites like that!

I think this is a little gatekeep-y. Building static sites is real engineering. When you're building a site that scales in content (for e.g. one that contains thousands of pages that are updated regularly) you need to really know what you're doing. A CMS can help you manage your content, but you need to decide how to build your pages from it. There are things in the React space that can handle a lot of the complexity (for e.g. Next.js on Vercel with ISR), but you need an engineer to make the right trade offs.

Re: HTML Web Components

#236

Post by hasanhaja »

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

This is a better and more concrete example of the point made in the article: - https://www.zachleat.com/web/details-utils

The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this.

That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

Re: HTML Web Components

#237

Post by floriankiem »

littlecranky67 wrote: post #206

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

I'm from inlang and we're building an ecosystem around globalization. Recently, we have released paraglideJS – a typesafe, super lightweight library that works with every framework. We've received a lot of good feedback in the last couple of days, feel free to try if it satisfies your purpose: https://inlang.com/m/gerre34r/library-inlang-paraglideJs

Re: HTML Web Components

#238

Post by continuational »

hasanhaja wrote: post #234
continuational wrote: post #144

Earlier quoted context omitted.

I mean, anybody is free to write how they like on their blog. I just don't find arguments like these convincing without realistic non-trivial examples.

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.

Re: HTML Web Components

#239

Post by sirwhinesalot »

webstrand wrote: post #95
boredtofears wrote: post #84

Earlier quoted context omitted.

I think the Eric Meyer post demonstrates the intention of that much better: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... The benefit boils down to progressive enhancement: because an img tag has built in behavior you simply rely on default rendering behavior and provide "augmentation" as needed via your web component.

What's the advantage of this over just using divs for everything, though? If this used shadow dom, I could understand. But custom elements don't even behave like blocks by default. Namespace collisions with custom components are just as bad as class collisions, if not worse since you can't `.myns.button`. Is it just the `connectedCallback` versus some manual method of wiring up elements to their javascript behaviors?

Yup, connectedCallback is a lot nicer than a for loop applying the right code to the right divs.

Re: HTML Web Components

#240

Post by ivanjermakov »

willio58 wrote: post #92
ivanjermakov wrote: post #88

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Umm, that's why SSR was created?

Web components are standardized by the web consortium. They are the way web browsers have agreed components should work. They have value inherently and don’t necessarily mean you can’t use react, in fact they can be used together very well especially for things like framework agnostic design systems. Basically, web components have more holding power inherently because they are browser native. React and SSR is just a…

SSR is the traditional way to write frontends. PHP, Rails, JSP, most technologies that revolutionized the web were rendering HTML on the server. SSR, in one form or another, will exist for as long as HTML will.

Additionally, SSR doesn't replace web components, it's a different technology with an intersecting feature. There is no problem to use them together.

Post reply on HN