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

151–160 of 247 posts

Re: HTML Web Components

#151

Post by lpedrosa »

toasted-subs wrote: post #142
sandreas wrote: post #124

Earlier quoted context omitted.

Basically, HTML Web Components are classes extending HTMLElement registered manually via JavaScript / DOM API. class superSlider extends HTMLElement { connectedCallback() { let targetEl = document.querySelector(this.getAttribute('target')); let unit = this.getAttribute('unit'); let slider = this.querySelector('input[type="range"]'); } } customElements.define("super-slider",superSlider); For a more sophisticated examp…

I don't understand why people use the shadow Dom. Why not edit the Dom directly?

You are correct. You don't have to use the shadow DOM, when you create a new Custom Element.

The shadow DOM provides two things:

- style encapsulation (as well as `id` attributes)

- ability to use `` for templating

You should use it if you require one of the above or both.

Re: HTML Web Components

#152

Post by socketcluster »

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-app/

The backend is serverless built using Saasufy.com - The platform/startup I'm working on currently: https://saasufy.com/

An effective approach I've found is to create components which consume slotted elements to produce HTML that can be fully customized and injected with data they loaded from a back end. This allows you to create components which are declaratively bound to specific back end resources.

Re: HTML Web Components

#153

Post by iteratethis »

winter_blue wrote: post #146
iteratethis wrote: post #126

Earlier quoted context omitted.

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.

Where does the data come from, if not JS? How then do HTML Web Components start rendering, without data?

The data would come as part of the server response in most cases.

A variation could be the rendering of a partial UI whilst you then fetch data client-side. Even in this case the web component has the advantage as no JS is needed to render the initial UI.

Re: HTML Web Components

#154

Post by zztop44 »

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…

Svelte is pretty close to this (at the expense of a build step). It gives you (in my opinion) better ergonomics that React, has no runtime and outputs sites that don’t require JS unless they do.

Sveltekit (its official fullstack framework) even encourages building apps that fall back gracefully for users with JS disabled.

Of course, none of that is to say that you can’t build bloated, badly performing apps in Svelte. Just that you *can* have the best of both worlds, even for simple/static sites.

Re: HTML Web Components

#155

Post by micromacrofoot »

winter_blue wrote: post #146
iteratethis wrote: post #126

Earlier quoted context omitted.

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.

Where does the data come from, if not JS? How then do HTML Web Components start rendering, without data?

As long as you're not shoving everything into the shadow dom, then you've got a fallback HTML element that can render before JS is read (and even if the JS is completely broken)...

This image will render before the JS is executed, so you've got no blockers and a perfectly fine fallback, then with the web component you enhance your image with whatever JS you want.

Re: HTML Web Components

#156

Post by coffeecantcode »

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…

> try using the default date/time picker and get back to me.

Building my first web application in react currently and this resonated with me on such a deep level.

Re: HTML Web Components

#157

Post by toasted-subs »

goeiedaggoeie wrote: post #26
cantSpellSober wrote: post #5

> they can render before JavaScript. React components cannot do this — full stop Not a full stop; SSR means they could render before client-side JS. The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.

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

You can pre-generate them on the client though.

Re: HTML Web Components

#158

Post by locallost »

I don't really agree that frontend framework components are meant to be replaced completely and are not composable. Maybe from the outside, but I use slots quite a lot in my components because they are very easy to do and they trivially work. Web Components on the other hand are usually demonstrated as insert which basically inserts a ton of code to create some kind of an editor. Using slots in Web Components is a pain, a lot of appending nodes manually, templates as strings, for some more complicated things when I tried them I had to listen to the slotchange event etc. It's essentially the DOM api, which if it wasn't terrible, we wouldn't have switched to frontend frameworks like react etc.

Also disagree with the side note that XHTML failed because it didn't augment HTML. IMHO it failed because if forced the applications to be completely valid and it put the validation on the client/browser. If you'd really used real XHTML a small error in the markup would've crashed your page. So we all validated our XHTML to be future ready, but it was always utopia that a business would risk crashing their, well, business because a p tag was not properly closed.

Re: HTML Web Components

#159

Post by sylware »

joshstrange wrote: post #105
sylware wrote: post #89

Earlier quoted context omitted.

The core of the web only need basic HTML with closing tags (and properly shaped singleton element/tags) with the basic grammar (from the specs), utf8 encoded, no script. It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders. Of course, you can have a full blown Big Tech web app, but don't forget to have a…

If you don't care about UI/UX then I agree. I do and even if I didn't the companies I work for absolutely do and the customers expect a certain level of UI/UX that is absolutely not possible with no script. I also work primarily on web apps which cannot be done without JS.

Well, it all depends on what the "client" "wants".

The problem often lies with the client tantrums.

I was more talking about critical online services which have a duty of interop with Small Tech and must not force users into Big Tech engines only, that to keep the door open to alternatives of reasonable "size", and at the same time to lower significantly exit costs.

But that's smashing open doors, most are aware of those issues here on HN. The real issue is implementation: it has to happen in a regulatory framework, laws dealing with discrimination, and my lawer has been looking into other legal leverages (yeah, I have an open conflict with my administration). The regulatory framework is here, but lobby-ied heavily by Big Tech, making it ineffective and pointless.

A bit like what they have in the US with the "utilities" which then have much more regulatory duties than "non utilities". You also have anti-trust stuff: dominant corpos are much more tied to regulatory constraints, that to let alternatives to be viable (well, that does not seems to work very well in the US). In my country, anti-trust ultra-aggressive regulations did wonders in the telecom industry.

You can still have a web app with a rich GUI, an anonymous simple and stable in time public HTTP-based middleware protocol (which allows to develop Big Tech independent rich GUIs), etc, until the core functions are provided to noscript/basic (x)html browsers (if one thing must work, it is this one).

Re: HTML Web Components

#160

Post by lpedrosa »

> This feature of web components encourages a design of composability.

I am not a React, Vue (and friends dev) at all. Heck, I haven't done front-end or full stack for a long time now.

However, taking React as an example, where does it not encourage composability?

I like Web Components. I even spent the last couple of weeks playing only with the vanilla APIs (no Lit, etc.) just to see what is like:

https://lpedrosa.github.io/blog/web-components-part-3/

https://github.com/lpedrosa/webcomponents-blog-examples

Like many other people have pointed out in this post, it is great that you can leverage the platform. All the things you will learn e.g. DOM APIs, native elements and events, etc., are things you can carry over to React and Vue.

However, I believe articles like this fail to acknowledge the contribution React and friends brought to developer experience.

Building complex desktop like UIs was no longer impossible to maintain. You can easily make components and compose them, customise them, etc.

The general complaint is more around "you don't need Next.js" to build a news/marketing/blog website. The pendulum is swinging, especially with things like HTMX gaining traction.

IMO, people do it because:

- It's easier to hire developers that know the framework du jour

- Custom Elements are very flexible, so it's hard to enforce a particular style

- There aren't enough examples of people using vanilla Web Components (and I mean vanilla, not Lit and friends), so why use a web component framework when I can use a react based one?

Write more about how we can combine things like Custom Elements and "traditional" server side templating.

Write more about how a native element reacts to changes to its attributes or how it communicates user interaction and how that helps building a good custom element.

Or how building a good custom element is similar to building a good React component, and where it differs.

Antagonising existing knowledge or even the status quo is not constructive, and leads to poor discussions e.g. "Web Components is a failed technology" or articles like OP

Post reply on HN