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

141–150 of 247 posts

Re: HTML Web Components

#141

Post by joshstrange »

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…

That's understandable. Though I actually can see some logic in it. It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach (and do it in a maintainable/understandable way).

I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is worth it (I understand if you don't agree).

In the same vein, I know cross-platform frameworks like Ionic/Quasar are nowhere near as good as native apps. That said the skill set you need (and dedication to actually embracing the platform idiosyncrasies) to make _good_ native apps is not cheap or easy. Cross-platform apps might not fit in as well and might be heavier but they allow fewer people to do more with less. Heck, I have a side-business that relies _heavily_ on apps and it would not exist if I couldn't write them in HTML/JS/CSS as much as that makes some people's stomachs turn.

Re: HTML Web Components

#142

Post by toasted-subs »

sandreas wrote: post #124
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 "…

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?

Re: HTML Web Components

#143

Post by Xeamek »

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…

Would this example be considered "trivial"? https://www.youtube.com/watch?v=3GObi93tjZI

But also, you can mix things togheter. You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple.

"But why would i do that, if i'd already use react for some parts, why not every where".

Becuase then it leads to abominations like reddit or facebook, where websites that are basically glorified text forums will use gigabytes of memory, have terrible UX, be slow and will crash your browser if you leave them open for too long.

Re: HTML Web Components

#144

Post by continuational »

yohannparis wrote: post #136
continuational wrote: post #55

Earlier quoted context omitted.

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

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.

Re: HTML Web Components

#145

Post by tored »

joshstrange wrote: post #133
tored wrote: post #129

Earlier quoted context omitted.

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

Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component as opposed to JavaScript Web components, but it is the correct way of thinking about this.

There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm.

By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever, to the browser, over Ajax or in the email. No need for buggy asynchronous SQL JOINs over HTTP and infinite state handling.

If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers. And combine that with a library like htmx you can then enhance that experience for interactive parts and still keep everything in the same backend template. And if it still a need for more complex interactive parts a programmer can can add that with JavaScript afterwards. That is a much better division of labour.

And it is not outdated, browser actually excel in rendering HTML documents, that is what they are designed to do, thus it will always be faster to render the HTML document as it is rather than building it on the fly.

And also the core idea of reaching for JavaScript before HTML will result in suboptimal solutions, I have seen so much unnecessary JavaScript code that could have been easily solved with a few lines of HTML. This change of perspective changes how we think and reason about a problem and therefore our solutions as well. That is why the bootstrapping of a "modern" web app has become more and more asinine.

Another problem with frameworks like React, Vue, Angular and et al have is that they have their own lifecycle and that has made the web closed and not open how it once was, closed in the sense that you can't enhance the HTML document from the outside after it been rendered, thus this leads to the assumption that the person(s) who wrote the site is also the person(s) that manages or uses it, that is a bad assumption.

Re: HTML Web Components

#146

Post by winter_blue »

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.

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

Re: HTML Web Components

#147

Post by winter_blue »

sylware wrote: post #89
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 "…

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…

A lot of web apps fetch data from the server prior to rendering; and the data that's fetched is often necessary for rendering. I suppose for things like a "control panel" that doesn't have much data on it, HTML Web Components might work fine; but a lot of use cases need non-stale server-supplied user data. I guess one other use case is caching stale data in local storage, and rendering that -- but even that requires JS.

Re: HTML Web Components

#148

Post by andirk »

A web component should do ONE thing whereas a JS framework is a whole ecosystem.

I made a video player web component that could take in various inputs, with a torrent file being the most complex of them. I was then able to port it to Vue/React with StencilJS [0] (although it was good to go without). Just drop the `` along w/ its exported class from `awesomePlayer.js` and you have yourself a copy/paste HTML5 video player that plays torrents!

I also strongly suggest your web component attempt to mimic existing HTML elements, when possible, such as how I used `src` because `` does. That way the consumer doesn't have to RTFM to interact with it.

[0] https://stenciljs.com/

Re: HTML Web Components

#149

Post by fuzzy2 »

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.

Re: HTML Web Components

#150

Post by andai »

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

Post reply on HN