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

Microsoft Fast Design

fast.design

Post reply on HN
Print view View original

71–80 of 216 posts

Re: Microsoft Fast Design

#71

Post by parksy »

spankalee wrote: post #61
parksy wrote: post #60

Earlier quoted context omitted.

edit - to thank everyone who took time out to explain what's going on - I'm still cynical but it all makes more sense now. I also like to think the ignorant guy asking the ignorant questions (in this case me) can sometimes be valuable for others who aren't in the club. Previous rant intact below for fun and hijinks. --- As a jaded old web developer I've seen so many frameworks along the way all promising this and tha…

> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.

And I am trying to understand, I think I'm just in a bad mood about this (I think I have framework fatigue? if that's a thing?) so thanks for explaining.

Re: Microsoft Fast Design

#72

Post by pupdogg »

parksy wrote: post #67
spankalee wrote: post #61

Earlier quoted context omitted.

> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.

I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would y…

Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)

Re: Microsoft Fast Design

#73

Post by megaman821 »

dainiusse wrote: post #58

Don't want to be ride but that is yet more JavaScript fragmentation. That's it

Is it really? Web components seem good for reusable components and design systems.

If you are making a reusable component like a switch, you make a web component (maybe with a helper library like Stencil, LitElement, or FastElement). If you are feeling nice you can create thin wrappers for React and Vue. As a consumer you just use an import and an HTML tag.

If you take a bunch of reusable components and a theming system. Now you have a design system, but it is still just as easy to consume.

For most front-end developers the choices remain the same. Build your site with React, Vue, or whatever you normally use.

Re: Microsoft Fast Design

#74

Post by nojvek »

Have >3 years of experience working with web components full time.

1) Their templating library has a learning curve. It's not quite like svelte, nor like JSX. If you have templates as strings that aren't typechecked, it makes it really hard to work on large code bases where the components are built by someone else and you're the consumer. I remember breaking powerbi.com due to missing > in an angular template that ended up in prod that only triggered for non english customers. It was a hard lesson that day never to touch untyped string based templates ever again. It's so easy to miss something. You want strict compile time checks, not run time.

2) Being dependent on slots. It's not easy to watch for changes in attributes to a slotted child. Yes you can add mutation observers but they aren't cheap either. All sorts of bugs poped up because some code does querySelector(x).setAttribute on a slotted child but the parent doesn't rerender and the UI doesn't look right. We ended up going to json strings inside attributes so components take their inputs via attrs rather than reading slotted children. The other avenue is props (like ionic), but props don't show up in dom explorer, so you have to make the tradeoff.

3) the 3rd big gotcha of web components. Attributes are strings. You have to serialize and deserialize from strings. Sure you can listen to when they change via attributeChangedCallback and get immutability for free because of serialization, but that comes at a perf cost. for deeply nested objects, you have to serialize and deserialize from json.

All in all, I love that Microsoft is doing web components. Webcomponents are part of native dom api with simple lifecycle api. They're neat.

Re: Microsoft Fast Design

#75

Post by cfcosta »

parksy wrote: post #67
spankalee wrote: post #61

Earlier quoted context omitted.

> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.

I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would y…

I'd say the important word there is "team", you use those libraries and frameworks because they are curated ways of doing what you want, reducing friction. If you are coding by yourself, you know everything about the codebase, and you focus on different trade-offs.

In general those who use these frameworks are ok with adding build complexity if they allow to avoid, at least a little bit, problems that can come from lack of standardization and one-off solutions to deceptively simple problems, taking care of edge cases your team is likely to find but unlikely to think beforehand.

Re: Microsoft Fast Design

#77

Post by spankalee »

parksy wrote: post #67
spankalee wrote: post #61

Earlier quoted context omitted.

> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.

I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would y…

You can tell a framework by the "Hollywood Principle" (don't call me, I'll call you). A framework is the component host. It's responsible for defining the component model and calling the component lifecycle.

Since frameworks define their own component model, components are typically incompatible between frameworks. You can't use an Angular component in React because React defines a different model.

This leads to huge fragmentation across the ecosystem and internally within large companies, and a waste of effort to reimplement components in each framework.

Web components are a standard component model where the _browser_ is effectively the framework. It calls the component lifecycle, and to other userland JS code, or HTML markup processors, web components act like any other HTML element. It's like being able able to add your own elements to the HTML spec.

Web components only specify the interface between the components and the DOM, they don't specify how the components are implemented. So you see several libraries that help implement web components. These libraries usually do a subset of what a framework does: main templating and reacting to state changes. They don't do the component model part of a framework.

Fast is another library that helps you build web components. Polymer was probably the first, and currently there are Polymer's LitElement, Ionic's Stencil, Salesforce's Lightning, and many more. They're all compatible with each other and with frameworks because the libraries only manage the internals of the components, the externals are standard.

Re: Microsoft Fast Design

#78

Post by Udik »

ggregoire wrote: post #66

For all the comments asking what's the difference between this and Bootstrap, Ant, jQuery UI, React, Vue and friends: Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard _Web Components_. The important word here is Web Components, which are like React or Vue components but using only standard HTML and JavaScript (no frameworks). I guess y…

> but using only standard HTML and JavaScript (no frameworks).

Sounds like they ship a framework with the browser and call it "standard". Given that the size of a UI components framework is tiny anyway (3kb for preact) I'm not sure it's such a revolution.

I'm open to hearing alternative takes on this though.

Re: Microsoft Fast Design

#79

Post by Someone »

ggregoire wrote: post #66

For all the comments asking what's the difference between this and Bootstrap, Ant, jQuery UI, React, Vue and friends: Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard _Web Components_. The important word here is Web Components, which are like React or Vue components but using only standard HTML and JavaScript (no frameworks). I guess y…

So, like https://medium.com/ing-blog/ing-open-sources-lion-a-library-...?

Re: Microsoft Fast Design

#80

Post by yodon »

neogodless wrote: post #21
duopixel wrote: post #18

Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.

I would imagine the design convention is to show a + when you have more content hidden, and a - to indicate you can hide (minimize) it. Is that the popular consensus, or is that an odd way of looking at it?

The accordion tag doesn't make any assumptions about icons. You can use smiley faces & frowny faces for open and closed if you prefer, or you can use plus and minus signs in either order or anything else.

The bigger more systemic documentation issue is the examples pages lack a view example source mode so there isn't an easy way to discover that icons are a user choice thing rather than a prebuilt styling thing.

Post reply on HN