Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML with Superpowers: An Introduction to Web Components

htmlwithsuperpowers.netlify.app

Post reply on HN
Print view View original

81–90 of 130 posts

Re: HTML with Superpowers: An Introduction to Web Components

#81

Post by lordgroff »

dmitriid wrote: post #63
lordgroff wrote: post #3

It obviously hasn't happened, but I hope that web components eventually make serious inroads. A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them). Since I really like mithril and there's one UI library, I've been playing with Shoelace and Crayons and they're pretty nice to work with, but I remain a bit puzzled why there's…

> A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them). You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and inc…

Can you explain how open-ui solves the problem? I went on the website, and to be fair I didn't really get it, but say for component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

Re: HTML with Superpowers: An Introduction to Web Components

#82

Post by extra88 »

fergie wrote: post #74
VoodooJuJu wrote: post #68

Earlier quoted context omitted.

Although not vanilla HTML, server side includes are the closest to this that we've got. I use them quite extensively. This is basically what my boilerplate looks like: I'll put all my favicon, CSS, and other common head data in the /ssi/head.html file. Nice and simple and good enough for me. Can make it even more minimal by moving the and tags into their respective SSI files.

Unfortunately SSIs dont work on s3 and some other plaforms, thereby negating their utility for running static sites on CDNs or keystores. But YES- why isn't there an SSI equivalent in the HTML spec?

> why isn't there an SSI equivalent in the HTML spec?

Because HTML Imports died in the spec drafting process. Unless you want a client-side SSI equivalent that doesn't require any JavaScript, HTML Imports wasn't that. I'm not aware of an alternative proposal that doesn't.

https://www.w3.org/TR/html-imports/

https://webmasters.stackexchange.com/questions/127482/on-wha...

Re: HTML with Superpowers: An Introduction to Web Components

#83

Post by Existenceblinks »

qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

In almost a decade I never understand why anyone would use Shadow DOM. What's the point of scoped style solution here. Why can't I just™ styff? .. admittedly I never scope style because I never have to add 3rd party components with style in it.

Re: HTML with Superpowers: An Introduction to Web Components

#84

Post by Existenceblinks »

dmitriid wrote: post #45
qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

> faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM Because very few of the people developing web standards are web developers. And of those who are very few have done anything of note in the past 20 years or more. They do love working on standards though.

I got tricked into following a standard (something something about data) and had read their github issues for 2 years! Omg such a waste of time they barely ship anything. Yes, they also write mediocre (or terrible) codes. I have to stop whining I'm getting mad .. was losing my years.

Re: HTML with Superpowers: An Introduction to Web Components

#85

Post by Existenceblinks »

colecut wrote: post #15

Why is there no standard/widely used vanilla-js based webcomponent for creating a table with filtering+sorting+pagination? It's such a common and useful thing.

Notion table seems to be close to generic. Basically let users provide a `f` in `filter(f, collection)`.

Re: HTML with Superpowers: An Introduction to Web Components

#86

Post by Existenceblinks »

The_Colonel wrote: post #61
colecut wrote: post #15

Why is there no standard/widely used vanilla-js based webcomponent for creating a table with filtering+sorting+pagination? It's such a common and useful thing.

I assume that it's because there's basically no upper scope limit, and it's not obvious where the cut should be done. Just take filtering - there are so many possibilities of how filters can look like, how can they be combined (AND, OR, nested) etc.

That. Basically a `f` in `filter(f, collection)` is code which can be arbitrary business logic.

Re: HTML with Superpowers: An Introduction to Web Components

#87

Post by pjmlp »

asurty wrote: post #8
_boffin_ wrote: post #4

I’ve been playing with webcomponents for a month or two and really love them. I do wish that IntelliJ would play nice with the formatting of them though. Question: when and or if they gain in adoption, could you see them replacing react? If not, what’s the use-cases that you believe they wouldn’t work for?

IMO they are complimentary to react. Frameworks like react/angular/backbone/vue solve the problem of creating a single page application with a nice architecture and sharing code between components within the SPA. Web components solve the problem of sharing code between any application. There are opportunities to share code (eg/ data binding) and I believe that is the case (they use the same underlying browser APIs wh…

With exception of React, all those frameworks have options to generate WebComponents for their component model.

Re: HTML with Superpowers: An Introduction to Web Components

#89

Post by fergie »

prox wrote: post #80
fergie wrote: post #77

Earlier quoted context omitted.

Pretty sure that you can't define an HTML snippet in one file and then include it in two or more other files using flexbox or grid? Or maybe I am wrong?

I do this using PHP. It gets the template file, the data and off you go.

Right- but you cant do it in plain HTML

Re: HTML with Superpowers: An Introduction to Web Components

#90

Post by dmitriid »

lordgroff wrote: post #81
dmitriid wrote: post #63

Earlier quoted context omitted.

> A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them). You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and inc…

Can you explain how open-ui solves the problem? I went on the website, and to be fair I didn't really get it, but say for component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

> Can you explain how open-ui solves the problem?

It doesn't solve the problem, but would solve the problem if it was started 10 or 20 years ago.

This is what needed in the browser: an actual properly specified comprehensive set of controls. Web Components are not it, as they continue re-inventing the wheel with the same components that libraries where defining since the dawn of the web: buttons, avatars, tabs etc. All of them different, all of them incomplete, all of them inaccessible etc.

> but say for component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

Because if you go to any UI library for the web, it's one of the components almost everyone defines. As you can see in the research for each component. What does having it as a web component give you? Nothing. It gives you fifteen hundred different incompatible re-implementations [1]

Having a higher level abstraction you don't need to re-implement it, you don't have to to manually provide additional things (like accessibility hints etc.)

In general, if everyone attempts to implement the same elements in the browser, it makes sense to have them as a part of the platform, doesn't it?

[1] https://shoelace.style/components/breadcrumb, https://web-components.carbondesignsystem.com/?path=/story/c..., https://vivid.vonage.com/?path=/story/alpha-components-bread..., https://sap.github.io/ui5-webcomponents/playground/component..., https://ionicframework.com/docs/api/breadcrumbs ...

Post reply on HN