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

191–200 of 247 posts

Re: HTML Web Components

#191

Post by keepamovin »

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 think the confusion caused by this article is because the author presents a false "pick your side" choice: "React-style" custom elements with props, or, custom elements with light DOM. Unfortunately, discussion of web frameworks often seems to occur with tribalistic attitudes, which can obscure a clear understanding of appropriate choices for a given application.

The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation.

Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example.

As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/-

Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.

Re: HTML Web Components

#192

Post by quickthrower2 »

andai wrote: post #182
andai wrote: post #150

Earlier quoted context omitted.

> 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

I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lin…

> 100% realistic and achievable in a dynamic language

Achievable by just removing automatic type coercion. Throw errors instead.

Would need to be feature flagged for backwards compatiability.

Re: HTML Web Components

#193

Post by phist_mcgee »

Xeamek wrote: post #143
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…

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

Cool what Contexte did with HTMX, but personally I really dislike the amount of data packed into those HTML templates, those hx-get attributes are frighteningly long.

Re: HTML Web Components

#194

Post by quickthrower2 »

sph wrote: post #175
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 "…

> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app. Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkl…

I wouldn't put Phoenix in the "would do" pile. That looks like a decent learning curve. PHP Laravel and Ruby on Rails are in the "would do" pile. This doesn't take away from your point though!

Re: HTML Web Components

#195

Post by quickthrower2 »

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.

No JS makes HATEOAS-like experience easy. Like for example right clicking an object you want to edit to open on a new page, edit it there, and click back and get it loaded as it was in less than a microsecond. Or opening 3 things to edit in different tabs, splitting them across the monitor and working with 4 copies of your app.

Re: HTML Web Components

#196

Post by keepamovin »

nightski wrote: post #17
simonw wrote: 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…

I think the criticisms of not solving state management and routing are well taken. I've tried to create a minimal sub-300 line, sub 3KB-compressed micro base class for using custom elements that reduces their cumbersomeness!

I wonder what minimal solutions to state management and routing might look like in Hyphen: https://github.com/00000o1/-

Re: HTML Web Components

#197

Post by nsonha »

I didn't have to read very far:

> ...they can render before JavaScript

what? Because web components are written in and run on magic?

> a design of composability... composing core content with HTML and then wrapping it in a custom element that enhances its contents with additional functionality

Put aside the self-reference, that's not what composability usually means, but I guess that sounds fancy to the uninitiated

Re: HTML Web Components

#198

Post by [deleted] »

micromacrofoot wrote: post #155
winter_blue wrote: post #146

Earlier quoted context omitted.

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.

[deleted]

Re: HTML Web Components

#199

Post by bluewalt »

jonahx wrote: post #189
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 "…

> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.

I think he knows that. The comparison with jQuery comes from the fact it is a DOM replacement logic too. Even if the syntax is way better, in the end, it’s still a way of working that scales badly, compared to components which embed their own logic.

htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.

Re: HTML Web Components

#200

Post by alethiophile »

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…

> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".

I would say it's precisely the opposite.

Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.

There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.

Post reply on HN