Microsoft Fast Design

Re:Microsoft Fast Design by dmitriid on Friday August 07, 2020 @03:14PM (#24085475)

In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)).

This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world.

> I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :

No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.

[ Parent | on HN ]

Re:Microsoft Fast Design by parksy on Friday August 07, 2020 @03:57PM (#24085872)

Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? This feels like another example of the XHTML apocalypse coming full circle and we're trying to find objective approaches to loosely defined data.

I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply but it felt honest at the time, I am glad that we have had this conversation in general because it's given me a lot to think over.

My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results. I've been on projects that ended up taking far, far longer and costing way more to maintain simply because we had to nurse the framework rather than deliver the results.

Anyway thanks for taking the time out again, I need to percolate for a while and look into some of the ideas that have been expressed here.

[ Parent | on HN ]

Re:Microsoft Fast Design by dmitriid on Friday August 07, 2020 @04:27PM (#24086098)

> Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard?

Yup :) They decided to go for a flat namespace where all that distinguishes between components is their name. I'm guessing this already leads to collisions between different versions of the same element. And there has been an open issue for it for three years now: https://github.com/w3c/webcomponents/issues/716 And the "solution" seems to be "let's add more Javascript": https://github.com/justinfagnani/scoped-custom-elements

> I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply

It's perfectly fine :) I've been way more rude about web components before (and still am :) )

> My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results.

Indeed. That's my main gripe with web components, really: instead of providing tangible benefits to developers, they ended up being "an API primarily for library and framework developers"

[ Parent | on HN ]