Live data from Hacker News

HTML Web Components

blog.jim-nielsen.com

51–60 of 247 posts

Re: HTML Web Components

#51

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Unless you... server-side render them. Then your definition of "render" needs to change

Sorta-- that means you render it at least twice.

1. You convert the JavaScript/JSX into HTML on the server and send it down (along with multiple blobs of JSON/code to re-hydrate).

2. The browser parses all the HTML and added JSON/code.

3. The browser then re-hydrates the page via JavaScript loading all of the JSON/code and computing everything (rendering it again).

Re: HTML Web Components

#52
post #32

Earlier quoted context omitted.

Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer. The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ ) which in jquery was usually via https://select2.org/ For example…

The element with a text input field is an HTML native typeahead, which works great with SSR or you could wire up the datalist client side with an XHR creating the datalist. You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.

That's an interesting one I wasn't familiar with.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

It's a shame clicking on it doesn't show the options like a select box though.

Re: HTML Web Components

#53

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Unless you... server-side render them. Then your definition of "render" needs to change

Sorta-- that means you render it at least twice. 1. You convert the JavaScript/JSX into HTML on the server and send it down (along with multiple blobs of JSON/code to re-hydrate). 2. The browser parses all the HTML and added JSON/code. 3. The browser then re-hydrates the page via JavaScript loading all of the JSON/code and computing everything (rendering it again).

Not if you use react server components, then markup is streamed in chunks as it gets rendered on the server and patched into the dom on the client. The JS for those components is never sent to the client.

Re: HTML Web Components

#54

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Unless you... server-side render them. Then your definition of "render" needs to change

At least you can server render web comppnents.

You've been able to server render React for like a decade.

Re: HTML Web Components

#55

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.

Re: HTML Web Components

#56

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

Or You could instead use this magic thing that has been around for decades, has massive tooling and most importantly, doesn't lock you into one specific ecosystem of language that was never supposed to be run server side to begin with;

Html templating

Re: HTML Web Components

#58

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Unless you... server-side render them. Then your definition of "render" needs to change

Sorta-- that means you render it at least twice. 1. You convert the JavaScript/JSX into HTML on the server and send it down (along with multiple blobs of JSON/code to re-hydrate). 2. The browser parses all the HTML and added JSON/code. 3. The browser then re-hydrates the page via JavaScript loading all of the JSON/code and computing everything (rendering it again).

With progressive enhancement, the page is "rendered" for all intents and purposes before any js enters the scene

Re: HTML Web Components

#59
post #2

Also read these articles for more on the idea of "HTML Web Components": https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web." https://adact…

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…

Preact requires a build step otherwise you don't get JSX and you have to build applications a la mithril.js mode:

> const app = h('h1', null, 'Hello World!');

With Web Components no build step is required and you're still able to intermix HTML with JS just like JSX. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api

Re: HTML Web Components

#60
*Shameless self promotion warning*.

If you're looking for a middle-ground between React and Web Components, check out Joystick [1]. I designed it to take a React v1 approach to ergonomics but you write your components with vanilla HTML, CSS, and JavaScript (no attribute hacks or new syntax to learn—if it's on MDN, it will work in Joystick).

[1] https://github.com/cheatcode/joystick

Post reply on HN