Live data from Hacker News

Microsoft Fast Design

fast.design

31–40 of 216 posts

Re: Microsoft Fast Design

#31

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.

default design is horrible

Good. That will encourage people to change it.

Re: Microsoft Fast Design

#33

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?

Yeah, this threw me as well, it is implemented incorrectly..

Re: Microsoft Fast Design

#34
post #24

I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines. Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a element. In this situation a shadowroot does nothing to help. All it me…

To clear my understanding of your first statement, you're saying that their "lightweight / low memory" claim is invalidated by components having one unnecessary level of nesting in DOM?

Re: Microsoft Fast Design

#36

Ok, so it looks like the main point of this is fast-components, which is a just a bunch of components styled as MS-style, but I'm more interested in the fast-foundation package. According to the instructions: > The exports of this package can generally be thought of as un-styled base components that implement semantic and accessible markup and behavior. > it exports parts and pieces intended to be composed into Web C…

The foundation package sounds a lot like the Lion components that ING Bank open sourced last year. It is indeed super handy to not have to worry about all the browser compatibility and accessibility issues!

Re: Microsoft Fast Design

#37
The "fast slider" is a perfect example of how animations make something perceptually slower, and might even be problematic as it implies the underlying value change is lagging behind the UI update.

Re: Microsoft Fast Design

#38
post #24

I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines. Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a element. In this situation a shadowroot does nothing to help. All it me…

> Shadowroots are great when you need encapsulation of styles or static non-content UI, but with this outer element neither of those are true. There isn't any additional UI, nor styles.

To my understanding of these components, because they are meant to be styled by the user or a downstream design system the component authors don't know ahead of time where style encapsulation needs to happen, so this approach makes sense for that.

Re: Microsoft Fast Design

#39

Allow me to ask the obvious question: How does Fast compare against React, Angular, VueJS, etc.?

It doesn't. It's more comparable to something like Google Polymer[0] They can be used in conjunction with eachother[1][2], so I'd imagine the same/similar would be possible with Fast. [0] https://en.wikipedia.org/wiki/Polymer_(library) [1] https://www.digitalocean.com/community/tutorials/vuejs-vue-i... [2] https://github.com/jscissr/react-polymer#readme

It reminds me more of https://material-ui.com/

Re: Microsoft Fast Design

#40

It looks like LitElement but more TypeScript first. The decorators do make it a bit more approachable for me.

LitElement is written in TypeScript so has great typings for all APIs, and TypeScript (and Babel 7) decorators. There's also a template type-checker CLI, compiler plugin, and VS Code extension: https://github.com/runem/lit-analyzer

The big difference from Fast is that LitElement's render() method is an instance method, so it can access any state with `this.` and any properties and methods it uses can be overridden. But it's all just as declarative:

    import { LitElement, customElement, property, html } from 'lit-element';

    @customElement('hello-world')
    export class HelloWorldElement extends LitElement {
      @property()
      name: string = 'World';

      render() {
        return html`
          Hello ${this.name}
        `;
      }
    }
We have decorators for reactive properties, registering elements, shadow root queries, and adding event listener options to methods: https://lit-element.polymer-project.org/guide/decorators
Post reply on HN