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

181–190 of 216 posts

Re: Microsoft Fast Design

#181

Post by jjcm »

WorldMaker wrote: post #38
jjcm wrote: 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 se…

For sure, and that's a pretty cool feature of this library. Nonetheless they should be checking whether or not there are included templates/designs before generating the shadowroot. I put together a small demo of this in action: https://github.com/jjcm/shadowTests/blob/master/withOptional...

The results speak for themselves: https://raw.githubusercontent.com/jjcm/shadowTests/master/re...

Creating a shadowroot conditionally has nearly equivalent performance to no shadowroot at all, but always creating a shadowroot is about twice as slow.

Re: Microsoft Fast Design

#182

Post by siquick »

One of the worst things about Windows and other Microsoft products is the design of their interfaces and typography - not sure why anyone would ever want to use their design principles for anything.

Re: Microsoft Fast Design

#183

Post by simooooo »

azinman2 wrote: post #103

I find it hilarious that they put a dark mode toggle in the corner (why would I want this on a per-website basis?) that doesn't even change the rendering of their sample components (the only reason I can think why that would be useful).

That sounds positively hilarious... rather you would just poop on other people’s work

Re: Microsoft Fast Design

#184

Post by CraigJPerry »

Did the concept of atomic design never take off? A few years ago i remember various css and js bundles spawned around Brad Frost’s atomic design movement but i don’t recall any of them lately being on HN.

It’s a shame if they’re not making the grade, i thought the idea of composable UI elements sounded spot on.

Re: Microsoft Fast Design

#185

Post by HugoDaniel »

CraigJPerry wrote: post #184

Did the concept of atomic design never take off? A few years ago i remember various css and js bundles spawned around Brad Frost’s atomic design movement but i don’t recall any of them lately being on HN. It’s a shame if they’re not making the grade, i thought the idea of composable UI elements sounded spot on.

Tailwindcss is getting quite big.i would dare to say mainstream even.

Re: Microsoft Fast Design

#186

Post by dheerajvs »

Someone wrote: post #79
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-... ?

Or like Adobe's react-spectrum: https://react-spectrum.adobe.com/architecture.html

Re: Microsoft Fast Design

#187

Post by mrmonkeyman »

rictic wrote: post #126
Udik wrote: post #123

Earlier quoted context omitted.

True, but what I meant to say is that there is nothing revolutionary. It's not providing capabilities that we didn't have before. It's simply establishing a standard for a tiny subset of what a modern web framework does- roughly equivalent to those 3kb of code- by doing the equivalent of incorporating it natively inside the browser. Yes, now you can use components without a framework (you could use them without a bui…

The big thing web components solve is interoperability. How do you use a preact component inside an angular app? How do you use an angular component inside a vue app? Web components are the solution. No matter what library or framework or whatever that you're using, you can render a so you can render a . That combined with shadow dom means that the element's internals and its styles are encapsulated, so that you can…

One angular component? Yeah sure. Add 500kb for one calender widget.. nice solution guys.

Literally never had this problem. Lots of other problems though, but no, let's focus on interoperability because we like to mix react, angular and vue.

Re: Microsoft Fast Design

#188

Post by 29athrowaway »

EisenbergEffect wrote: post #128

Howdy! I'm the architecture lead on FAST at Microsoft. There's a great conversation here with lots of questions, so I thought I would chime in and try to clarify a few things. The first point of note is that FAST is built on Web Component standards. I see a number of comments that indicate some folks aren't familiar with Web Components. So, let me give a brief explanation. First, the term "Web Components" is an umbre…

For code examples on HN, indent code 4 spaces.

Re: Microsoft Fast Design

#190

Post by Vinnl »

spankalee wrote: post #153
Vinnl wrote: post #147

Earlier quoted context omitted.

> they can be used in any with any framework, no wrapping required. That's the selling point, but is not quite true. At least a while ago there was still some ceremony needed at least in React. You could say that that's React's fault, but it doesn't really matter whose fault it is - Web Components are different from standard DOM elements, and thus need special treatment from frameworks that interact with standard DOM…

They're not different from built-in elements and don't need special treatment. The way that frameworks that work well with web components do it is be not giving special treatment to things. Vue, Angular, and lit-html all treat built-ins and custom elements then same, and they have different syntax for setting attributes and properties. React treats elements different from components and sets properties on React compo…

They're different from built-in elements at least in the fact that they're not built-in - that is the problem with React, which works with a list of built-in components that are treated differently from React components. Which means React needs special treatment for Web Components.

Whether React should or should not be doing that is irrelevant; what's relevant is that as a developer, you need to be aware that you can't "just" use Web Components in any framework.

Post reply on HN