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

131–140 of 247 posts

Re: HTML Web Components

#131

Post by mortallywounded »

troupo wrote: post #110
mortallywounded wrote: post #83

Earlier quoted context omitted.

Yeah-- but a single component is a much smaller degree of JS than an entire React application.

Depends on how many "small components" you need. Reddit's new redesign downloads over 100 js files: https://x.com/dmitriid/status/1708772121260732494 to render a menu.

Of course there's a tradeoff--- if everything is a component then it may as well be an SPA (or at least bundle those files...).

I don't think the core idea was to ever use "hundreds" of components. HTML should be able to do a majority of the work, and you sprinkle a component here or there as needed.

Re: HTML Web Components

#132

Post by whatshisface »

joshstrange wrote: post #130
Xeamek wrote: post #115

Earlier quoted context omitted.

>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends True >which feels like a massive step backwards and completely the wrong choice for building a web app. Why? I mean, I'd agree if by 'web-app' you mean something like google-sheets. But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting framewor…

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

I think the future of webdev is a framework-like system that can be added gradually to basic HTML, rather than one which requires that you totally replace it with JSX, etc. from the start. Webcomponents are a huge step towards a time when we can add state managers and things like that without bringing in a monolith all at once.

Some projects require 1% of a framework, others require 98%, but the majority are in a range between 25% and 75% which currently need you to re-architect for a total perfusion of React or a competitor.

Re: HTML Web Components

#133

Post by joshstrange »

tored wrote: post #129
joshstrange wrote: post #116

Earlier quoted context omitted.

That still doesn't click for me. Why wouldn't you make the label/slider part of the component itself. It feels like you have the worst of both worlds. You more or less need/expect it to always wrap those elements but nothing enforces that so this seems very brittle to me, not to mention verbose. They mention not wanting to pass though all those props: We will ignore the last 2 since those are required anyway. How is…

The article argues between the difference of a JavaScript Web component and a HTML Web component, you describing the former, thus the need for JavaScript. Personally I think the main problem here is client side rendering to begin with, with a modern server side templating library you get a component based structure too and can abstract whatever HTML tags you want in your component before client side JavaScript. Probl…

> The article argues between the difference of a JavaScript Web component and a HTML Web component, you describing the former, thus the need for JavaScript.

The article goes on to add a good little bit of JS to make everything work they way they want. They still need JS to accomplish what they want. If you turn off JS things will break in that example.

> Personally I think the main problem here is client side rendering to begin with

I mean unless you want to roundtrip for new HTML segments (aka Liveview or whatever Laravel has) you either need to have client-side rendering or duplicate your rendering logic (in something like both PHP and JS for the fast update without refreshing on each click). I'll never duplicate rendering logic again if I can help it and that means client-side render (potentially with SSR for the first render). It avoids so many bugs/issues.

> but in my opinion the web should be HTML first

This just feels dated to me. I fundamentally do not understand this desire. What do you gain from the web being just HTML? What does that even mean? With a CSR framework you are still rendering out HTML, I don't understand why some people care that the HTML was generated server side or client side. The web has moved on from being just documents, it's interactive and that provides a much better UX.

Re: HTML Web Components

#134

Post by jiggawatts »

joshstrange wrote: post #130
Xeamek wrote: post #115

Earlier quoted context omitted.

>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends True >which feels like a massive step backwards and completely the wrong choice for building a web app. Why? I mean, I'd agree if by 'web-app' you mean something like google-sheets. But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting framewor…

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

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 maintenance.

Most of their sites could have been static HTML files on disk.

Re: HTML Web Components

#135

Post by joshstrange »

whatshisface wrote: post #132
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…

I think the future of webdev is a framework-like system that can be added gradually to basic HTML, rather than one which requires that you totally replace it with JSX, etc. from the start. Webcomponents are a huge step towards a time when we can add state managers and things like that without bringing in a monolith all at once. Some projects require 1% of a framework, others require 98%, but the majority are in a ran…

And I'll happily use such a system once it exists but Vue/React/Angular exist today and have allowed a level of productivity, DX, and UX unheard of with what browsers provide by default. If browsers want to compete then be by guest but FF seems to busy doing next to nothing, Chrome is eating everyone's lunch and giving the middle finger to standards, and Safari is derided for not being Chrome and slow to implement some things (while being fast on others).

I think it's more likely to see some kind of WASM-based replacement take off rather than browsers get their act together. That's not to say browsers aren't improving, they absolutely are, but when it comes to competing with the existing frameworks the only answer so far has been Web Components and it was very lackluster IMHO.

Re: HTML Web Components

#136

Post by yohannparis »

continuational wrote: post #55
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 "…

> I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.

This is a purpose of a blog.

This was not a tutorial or an article on how to use Web Components.

Re: HTML Web Components

#137

Post by robinson7d »

iteratethis wrote: post #126
codingdave wrote: post #66

I'm not sure I buy the "React is replacement, not augmentation" argument. At the end of the day/render, React still renders HTML elements... with javascript event handlers. Wrapping an ' ' in a React component doesn't mean I've taken away any functionality of 'img'. I just add to it -- augmentation. Maybe the author has worked in different React codebases than I have, but in my experience, we use built-in browser fun…

Surely every single web architecture ultimately renders HTML elements, that wasn't the point. The point is that the flavor "HTML Web Component" does not rely on JS to start rendering, unlike React.

You’re right for the large majority of cases, but there are exceptions. These days some use canvas or WebGL, in the past some have used Flash or Java Applets/Swing.

A popular app that some web developers here may use day-to-day recently is Figma, which uses WebGL for rendering.

Re: HTML Web Components

#138

Post by goeiedaggoeie »

kaba0 wrote: post #30
goeiedaggoeie wrote: post #26

Earlier quoted context omitted.

This is the main issue for me with webcomponents, they are not SSR friendly.

Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.

This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important.

Good load order and only loading in the content and JS above the fold initially helps a ton.

JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.

Re: HTML Web Components

#139

Post by toasted-subs »

jiggawatts wrote: post #134
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…

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).

Re: HTML Web Components

#140

Post by kaba0 »

goeiedaggoeie wrote: post #138
kaba0 wrote: post #30

Earlier quoted context omitted.

Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.

This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important. Good load order and only loading in the content and JS above the fold initially helps a ton. JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side i…

Oh, google closure was absolutely ahead of its time!
Post reply on HN