
Microsoft Fast Design - no_wizard
https://www.fast.design/docs/introduction
======
ggregoire
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 you could even add Bootstrap on top of Fast.

Some references:

\-
[https://en.wikipedia.org/wiki/Web_Components](https://en.wikipedia.org/wiki/Web_Components)

\- [https://developer.mozilla.org/en-
US/docs/Web/Web_Components](https://developer.mozilla.org/en-
US/docs/Web/Web_Components)

\- [https://developers.google.com/web/fundamentals/web-
component...](https://developers.google.com/web/fundamentals/web-components)

\-
[https://caniuse.com/#search=components](https://caniuse.com/#search=components)

Also worth reading: [https://dev.to/richharris/why-i-don-t-use-web-
components-2ci...](https://dev.to/richharris/why-i-don-t-use-web-
components-2cia) (discussion on HN:
[https://news.ycombinator.com/item?id=20232628](https://news.ycombinator.com/item?id=20232628))

~~~
Someone
So, like [https://medium.com/ing-blog/ing-open-sources-lion-a-
library-...](https://medium.com/ing-blog/ing-open-sources-lion-a-library-for-
performant-accessible-flexible-web-components-22ad165b1d3d)?

~~~
claviska
Lion is similar in that it’s intended to be customized from the start. For
something more “batteries included,” see
[https://shoelace.style](https://shoelace.style).

------
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.

~~~
e111077
Heyo, been working with WCs full time as well:

1\. Libraries like lit-html have syntax highlighting and tooling to do type
checking.

For the developer:
[https://marketplace.visualstudio.com/items?itemName=runem.li...](https://marketplace.visualstudio.com/items?itemName=runem.lit-
plugin)

For node: [https://www.npmjs.com/package/lit-
analyzer](https://www.npmjs.com/package/lit-analyzer)

For other Web Component libraries: [https://www.npmjs.com/package/web-
component-analyzer](https://www.npmjs.com/package/web-component-analyzer)

2\. Totally agree on slots. They suck and were hamstringed by Safari in spec
talks. Libraries like LitElement have the concept of reflecting a property to
an attribute and it's really easy to do so. Also, Chrome had a property
explorer in dev tools that just got deprecated which also sucks.

3\. Attributes are strings, yes, but you can also set properties on a
component. Easy to have a setter and getter for a property (can easily be
turned into a TS decorator) that just calls a render method on change, but
again, the cost for attributeChangedCallback to serialize a primitive is very
low. Passing objects should just be sent as a prop, but also, passing objects
to child web components we've found is a bad habit. Often the props of an
object should be spread (easy to make a directive of this in lit-html) over
the props of the child and arrays typically easier to turn their contents into
DOM nodes.

Also none of this takes into consideration of a web component using a state
library like redux.

~~~
lstamour
I’ve found that for an object-oriented web component API, you end up with less
flexible rendering — yes, redux can one-way bind attributes, etc., but you’re
missing half the reason why you’d want to write code that way, how React
schedules and renders to make immutable one-way data flows relatively
cheap/quick with little to no persistent state. (Note, less code is less work,
but caching and diffing DOM can also be less work...)

Things might have changed, but it’s easier to recreate web component features
in JS than it is to convince people to use a two-way object-oriented API
that’s mostly stringly-typed unless using JS. If the problem we’re solving is
we want a faster web, bake in and follow top JS libraries such that how they
render is part of the spec. I’d be very interested to see what a React
scheduler would look like if implemented in C++ on top of the browser’s
scheduler.

I really like parts of web components, but... I’d also like to see a Chrome
experiment where JSX and TS is baked into the browser to natively solve the
“stringly-typed” problem the Web Components spec has. Maybe that’s going too
far, or maybe we’ll end up shipping these features as “modules” that can be
toggled on if compatible.

I think it would help the web move to where developers are to include native
understanding and support for semi-“proprietary” solutions given widespread
adoption. For example, ES Modules are great, yes, until you have to start
building your own vendor modules because somebody shipped a Webpack module as
dist, for example.

Just as Babel lets us try new syntax earlier, so too could third-party
libraries popularize new browser-native APIs as loadable modules, maybe? (My
assumption being that integrating with existing C++ is cheaper than writing
scheduling and DOM update logic in JS, but the JS is cheaper to ship, so some
kind of browser-module-loading-with-JS-fallback is the only way we can have
performance wins for existing approaches while still shipping new versions of
features given how fast JS syntax and preferences change?)

------
pcr910303
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 Components,
> allowing you to implement your own design language by simply applying CSS
> styles and behaviors without having to write all the JavaScript that's
> involved in building production-quality component implementations.

Which means... if I want to make my own components, I can just take this
package and don't worry about making broken components. Since the core HTML/JS
is properly taken care (by MS, hopefully) I can less worry about re-
implementing keyboard access, or things like accessibility which is hard to do
properly. This is IMO huge, and should be more universal.

~~~
parksy
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 that.

Can someone who is familiar with this answer me this: Does this framework
automatically sort out ARIA standards for me? Like tab ordering and stuff is
dealt with automatically?

I know it seems I am being lazy but I am just fed up.

"FAST is a collection of JavaScript packages centered around web standards,
designed to help you efficiently tackle some of the most common challenges in
website and application design and development."

COOL! (/s)

"Have you ever needed a reusable set of UI components that you could drop into
your app and have an amazing experience? That's FAST."

UNIQUE! (/s)

"Have you ever needed to create your own components, and share them across
your company, including across groups that use different, incompatible front-
end frameworks? That's FAST."

<record scratch>

Different, incompatible front-end frameworks?

So like, this shit is magic that will let me streamline components between my
Oceania team's WordPress and my German team's Magento frontends?

And I don't have to learn any new paradigm to make this work?

I don't have to use their specific, custom HTML in order to leverage it?
[https://www.fast.design/docs/components/accordion](https://www.fast.design/docs/components/accordion)

SWEET! (/s)

Come on. We'd have to re-write everything to use this library specifically,
and train our teams.

Honestly this is to me just another bunch of shit that will get tacked into
projects and have to be known and supported, because some sprightly young
thing will convince management this is the panacea to seemingly redundant
development work.

What's the actual selling point here.

~~~
spankalee
> 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.

~~~
parksy
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 you say is the best resource for me to go
and upskill so I can see the actual value in this for me and / or my teams in
the future?

~~~
spankalee
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.

------
jjcm
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 <slot> element. In this situation a shadowroot does nothing to
help. All it means is instead of just creating children for the element, you
have to create them and add "slot='item'" to all of them. 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. This is something I see a lot in lazy libraries - they
automatically create a separate dom tree even if it isn't needed whatsoever.

This tells me either the library requires this every time (going against the
"lightweight / low memory" motto), or the developer for this one didn't have
enough understanding of when to use shadowroots.

That's not to say this is all bad though - their design system tokens are
really nice and provide a lot of flexibility. I'll probably emulate a lot of
them for the next webcomponent based design system I'm working on. Their
algorithmic color palettes are interesting, but so far I've never found a
solid algorithmic color generator - color is simply too tied to trends and too
subjective to be algorithmically made. Curious to see it work in practice, and
a shame they don't provide examples of it.

~~~
infogulch
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?

~~~
jsf01
No. They’re saying that it’s creating an entirely separate DOM tree
unnecessarily by using shadow DOM where it isn’t needed.

On a related note, I’m curious if anyone has a benchmark comparing performance
and memory consumption when attaching a shadow root vs not.

------
duopixel
Check out the FAST Component explorer to see it in action:
[https://explore.fast.design/](https://explore.fast.design/)

Looks very flexible but the presentation and default design is horrible.

~~~
neogodless
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?

~~~
yodon
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.

------
sholladay
Microsoft recently wrote a blog post saying they would be rallying around a
single component library. [1]

> What’s in a name? A lot it turns out. And we have a lot of them. Too many?
> We hear you and agree. That’s one of the key reasons we’re simplifying our
> story. To collectively rally around a single UI library for our web
> components—Fluent UI.

Yet, here we are, and they've released another component library. They really
seem to love these things. It's not entirely clear what the difference is
between them.

1: [https://developer.microsoft.com/en-us/office/blogs/ui-
fabric...](https://developer.microsoft.com/en-us/office/blogs/ui-fabric-is-
evolving-into-fluent-ui/)

~~~
fassssst
Fluent UI is the one the Office team is standardizing on.

FAST is from the Edge team and used for their settings pages.

That’s life at BigCo for ya.

------
red_admiral
Pet hate: SQUARE radio buttons ([https://explore.fast.design/components/fast-
radio-group](https://explore.fast.design/components/fast-radio-group))

In case it makes any difference: I'm on Win10, Edge 84.

~~~
erikig
Ditto on OSX+Chrome

------
d0m
There are many design issues with their website which IMHO don't provide great
confidence in using their components

------
qppo
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.

~~~
ourcat
While sliding it from 0% to 100%, the 'thumb cursor' reaches 100% before the
mouse pointer does, after some strange animation 'jumps' which have no bearing
on the step value setting.

Also, clicking anywhere on the bar doesn't set the slider to the centre of the
click. They don't appear to be making the correct calculations based on
Bounding Client Rects and Offset widths.

------
timvisee
Took a quick look: It has limited components. It isn't fast on my mobile
device. Some components appear to be broken. Why would I ever use this?

~~~
mey
Sliders and radio buttons do not seem to work on Firefox for Android nightly
build.

~~~
GrayShade
Neither do they seem to work in desktop Nightly.

------
mark_l_watson
I need to check this out. I have been using Bootstrap for years, and would
like to try something new. I am not a very good front end developer, even
though my [https://markwatson.com](https://markwatson.com) site is now about
27 years old.

I want something batteries included.

------
su8898
Not sure if it's just me but I kind of feel like these components are not very
polished - at least not to the point of Bootstrap/AntDesign. May be it's the
square unrounded borders or may be it's just the way the demo components are
presented.

------
MR4D
Possibly the best commercial for Microsoft is how ...fast... this site is.
(clearly the pun was unavoidable, which is evident in their name selection)

Honestly, one of the quickest loading & changing sites I've seen, and gives HN
a run for its money!

------
mrweasel
> fast-anchor is a web component implementation of an HTML anchor element.

Wait, what.... WHY? Can't you just use an a tag?

~~~
Vinnl
I was equally confused by fast-divider. I wonder what the rationale behind
these were?

~~~
CuddleBunny
The primary reasons seem to be encapsulating accessibility and styles. There
is nothing forcing you to use fast-anchor or divider. The theme is exposed in
CSS vars so you can use it from a stylesheet on native elements.

------
eimg
To my understanding, the point of this system is not actually how its default
component looks or how rich the default components set are. It's to provide a
framework to create Custom HTML Elements (which are browser native?) that we
can re-use across projects with different front-end frameworks.

e.g., Creating a React Button component using Fast Button like this:

`const ReactButton = () => <fast-button>Button</fast-button>`

~~~
mkl
Okay, but how its default components look and how rich the default component
set is is how you sell the benefits of such a component creation system. As it
is, it makes it look like you can only make limited, badly designed
components.

------
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.

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

------
wslh
I always wonder where is the VB6/Windows Forms for web apps. I don't want to
know the intricacies of Rect/Angular/Vue, I just want to do a declaration of
the UI, not programming. Zillions of apps doing the same thing and spending
weeks and months on the same problems. I start to think that this is not
interesting for, for example, Microsoft because the developer market will
shrink and their developers, developers, developers mantra. I remember when
Bootstrap come up and suddenly we don't need a lot of graphic design time to
build a web page.

Just an additional note about VB6/Windows Forms. They helped to build
commodity UIs but when you needed more advanced one you should rely on
specific components.

~~~
jokab
> I always wonder where is the VB6/Windows Forms for web apps.

they tried. it's called asp.net webforms.

it sucked hard. bécause they forced event driven paradigm in a stateless
environment (http) resulting to hacks (hello viewstate).

but hey it was my gateway drug into web development as a winforms guy. im the
sucker and i shouldnt be complaining. but 15 years later im back to aspnet
webforms because of legacy apps the client doesn't want to upgrade yet.

------
EisenbergEffect
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 umbrella term. You may remember when
the industry used to talk about "HTML5". This was also an umbrella term for a
collection of new HTML standards. Similarly, "Web Components" refers to a
collection of standards related to creating reusable custom HTML elements.
Some of the standards that are under the umbrella include the ability to
define new custom element tags, a standard component lifecycle, encapsulated
HTML rendering and encapsulated CSS (shadow dom), CSS properties, CSS Shadow
Parts, and more. These are all defined by W3C and have shipped in all major
browsers today. The work on Web Component standards, like the rest of the web,
is ongoing. New APIs continue to be designed and released. Some recent APIs
include form associated custom element APIs and CSS Shadow Parts. W3C is
currently working on standards for things like constructible style sheets,
declarative Shadow DOM, custom element registries, custom states/pseudo
selectors, and more. Microsoft, Google, Salesforce, and many others are
working together on this.

Because FAST is built on Web Components, it does not create its own component
model; it's using the standard component model. What has traditionally been
thought of as a "front-end framework" typically has its own component model,
not based on web components. Examples of this include Angular, React, Vue,
Svelte, etc. Any library that is based on web components isn't trying to
create its own model, but rather to leverage the standards. This allows a web
component to work like any normal HTML element. You do not need a framework to
use them. However, if you want, you can use them in combination with a
framework of your choice, or jQuery, or whatever.

To drive the point home that these are web standards, here are 4 lines of code
that you can execute in a modern browser console to define, create, and add a
web component. You can even execute it in this Hacker News page using
DevTools.

// define the custom element class

class HelloWorld extends HTMLElement { constructor() { super();
this.attachShadow({ mode: 'open' }).innerHTML = 'Hello World'; } }

// register the custom element by tag name

customElements.define('hello-world', HelloWorld);

// create an instance of your new element

const ele = document.createElement('hello-world');

// add your new element to the body

document.body.appendChild(ele);

If you do this in your console now, you'll be able to scroll down to the end
of the page and see your component rendering. Have a look in the element
inspector and you'll see the custom tag, along with its shadow dom, including
"Hello World".

When you start to build web components, you're likely to notice that there's a
pretty large amount of code you need to write to implement even a basic
component. That's because the standard defines low-level protocols, rather
than high-level abstractions. By doing this, the standard provides you with
interoperability and flexibility to innovate without boxing you in. At this
point, something like FAST comes along and provides a thin layer of opinions,
lifting the level of abstraction just enough to make it easier and FASTer to
build components. Things that FAST helps with include: providing
attribute/property syncing, rich Model-View-ViewModel (MVVM), template
rendering/update, style composition, etc. All of this is an internal
implementation detail of a FAST component, allowing FAST to integrate with Web
Components built in completely different ways or with different libraries. The
entire fast-element library, without tree-shaking, is around 10kb minified and
GZipped. It was designed for tree-shaking from the beginning, so any feature
you don't use when building a component will be removed during build, allowing
you to get it smaller based on your needs.

Architecturally, today FAST is composed of 3 layers. At the lowest level is
fast-element, which provides a basic mechanism for defining components. For
many people, this is all they need. However, others need an actual component
library to build their site/app with, and often times they need control over
the look/feel/branding. To address this, you can add the second layer, fast-
foundation, which provides a set of building blocks for creating component
libraries and design systems. It itself is not a component library. Rather, it
has the base behaviors for standard components like button, tree view, menu,
etc. It also has the basic functionality that design systems typically need,
such as color algos, design tokens (design variables), typography primitives,
etc. Foundation allows you to build your own button, tree-view, etc, without
having to design the semantic HTML, work out the correct Aria behaviors, mess
with proper keyboard nav, manage the JavaScript state and behavior, etc.
Instead, you can compose together a foundation button and foundation template
with your own styles, giving you complete control over the appearance of your
components. With these building blocks, it's possible to implement something
like Bootstrap, Material Design, Lightning, etc. However, if you don't need to
implement your own design system, you can use one that we build. This is the
third layer. We provide two design systems today. One is called FAST Frame
(featured on our web site). The other is Fluent UI Web Components.

FAST Frame is an early, experimental design system that our team is working
on. I saw some feedback below that it's "ugly" :‑D As mentioned, this design
system is a work in progress, being designed and developed in the open. So, we
welcome you to contribute to the project and help us define something that the
industry would feel proud to use in their apps. As for Fluent UI Web
Components, Fluent UI is Microsoft's design language. I saw some comments
below about how Microsoft was trying to consolidate and that FAST seems to add
yet another option. The consolidation work is around our design system first.
So, we're moving to a single design system "Fluent UI" across the company.
We're then consolidating implementations as appropriate. Previously, there
were several React implementations. There's work ongoing to consolidate that
into a single React implementation. But what about people who don't use React?
Well, that's what Web Components are for. FAST is providing the Fluent UI Web
Components implementation. So, regardless of what platform, framework, etc.
you use there will be a best fit implementation that provides you with a
consistent Fluent UI experience.

~~~
EisenbergEffect
Ok, let's get on to a few other items mentioned below...

* Being Dependent on Slots - Web components don't need to use slots and neither does FAST. When slots are needed, FAST provides facilities to respond to changes in slots and respond to changes in slotted child attributes. The render system is reactive in nature and specifically has features that enable rendering around these slot scenarios.

* Attributes are Strings - Yes, this is part of the DOM API. That's the way HTML works. However, HTML elements also have properties, and those do not have to be strings. They can be any type. As such, FAST enables properties of any type, and will provide type conversion between attributes and properties if desired. It is considered "bad practice" to serialize to json and pass through attributes. Rather, just use a standard JS property.

* Typing in Templates - If you use TypeScript with FAST, you can have full type checking and editor refactor support over the data in your template. Because FAST's templates leverage the JavaScript language's standard tagged template literal feature, popular editors (such as VS code) will provide syntax highlighting, documentation, and tag completion for both HTML and CSS written in this way. Additionally, lint tools understand tagged template literals and can lint the HTML and CSS that is written in them. So, there's strong support in tooling today and more coming in the future.

* Web Components Break Accessibility - Accessiblilty is difficult. When you build re-usable web components, you have to think carefully about the best way to accomplish this. That said, it's incorrect to say that WCs break accessibility. Our team has worked extensively on the accessibility of our components and the results have been good. If you find an accessibility bug, let us know. We prioritize those types of issues pretty high.

* They Don't Work Without JavaScript - This is true today not just of WCs but of every front-end framework (without leveraging SSR). However, it has never been the long-term plan. We are currently working with W3C on declarative shadow dom as well as declarative custom element definitions. Many WCs will always require JS but in the future a whole category of WCs will not.

* You Can't SSR a Web Component - Strictly speaking, this is not quite correct. Custom elements are just html tags and can be rendered by any server framework. If you want to SSR the shadow DOM itself, that's possible by inlining the template and using a small bit of JS to attach the shadow after streaming the template in. That said, as mentioned, we are working on declarative shadow dom, which will provide the W3C standard on which SSR and other WC capabilities will be built.

* The WC API is Very Bad - As mentioned earlier, the focus for v1 WCs is to provide a low-level API that enables interoperability and flexibility. Baking a high-level API in at this point would shut down innovation when aspects of component models are still being deeply explored, experimented with, and debated. As such, platform WC APIs are more like Win32 and less like Java or .NET. Over time, as the industry establishes more patterns, new higher level APIs will be added, but they will be built on the low-level APIs, always leaving open the opportunity for "user-land" innovation.

* You Can't Provide Callbacks for Custom Events - Maybe I misunderstand this but in my experience this is not true. You can use addEventListener on any web component to register for completely custom events. If you want an `onevent` property, you can set a function to as part of your API, you only need implement a property setter that internally calls addEventListener. Events from inside the shadow dom are re-targeted, but you have complete control over whether they bubble or compose. So, there's no issue there as long as you know how to use the composedPath() API.

* Why does Accordion/Anchor/Divider, etc. have a slot and nothing else? - It does have something else. Styles. Shadow dom can be used to enable composition and encapsulate styles. In this case, these elements are not doing anything interesting with composition, but are providing encapsulated styles. If you are wondering why you can't see them, it's because FAST leverages a new standard for constructible style sheets, which allows it to attach style sheets to the Shadow Root, via its adoptedStyleSheets property. If you find the shadow root in your inspector, and look at its adoptedStyleSheets property, you will see what you are looking for. For browsers that do not yet support this new WC feature, we fall back to standard style element injection. FAST does not force you to use shadow dom or slots. Any FAST element can render into the light DOM as well. If we're using shadow dom, there's a reason for it (or there's a bug if there isn't).

* It Has Limited Components - This is our first release, and includes a subset of the many components we have planned. Ultimately, we plan to at least implement everything in FluentUI.

* The Components Are Broken - As our first release, I'm sure it's not perfect. FAST is MIT licensed and open sourced on GitHub. Please feel free to report bugs and we'll work to get them fixed. If you feel comfortable contributing, we'd love to have you work with us on the fixes as well.

Ok, hopefully this helps a bit. At Microsoft, we're excited to begin our
journey into Web Components with FAST. These are our first steps, but we've
got a lot more planned for the future. We invite all of you to join us on this
journey. You are welcome to provide feedback, contributions, docs
improvements, thoughts on web standards improvements, etc. Looking forward to
seeing you around!

~~~
GordonS
> You Can't SSR a Web Component - Strictly speaking, this is not quite
> correct. Custom elements are just html tags and can be rendered by any
> server framework. If you want to SSR the shadow DOM itself, that's possible
> by inlining the template and using a small bit of JS to attach the shadow
> after streaming the template in. That said, as mentioned, we are working on
> declarative shadow dom, which will provide the W3C standard on which SSR and
> other WC capabilities will be built.

I mainly develop using ASP.NET Core, with some vanilla JS as needed.

I'm just starting to hear about Web Components, and have heard that you can't
use them with SSR because of the shadow DOM. I don't actually know what shadow
DOM is, but does this mean _no_ Web Components work with SSR, or that _some_
don't? What precisely is the issue?

~~~
lioeters
According to a fairly recent article (Feb 2020):

> It's a common myth that you can't server side render Web Components. Turns
> out you can if you look in the right place.

[https://dev.to/steveblue/server-side-rendering-web-
component...](https://dev.to/steveblue/server-side-rendering-web-
components-320g)

The article mentions a few libraries for this purpose.

\- Vaadin Router - [https://vaadin.com/router](https://vaadin.com/router)

\- SkateJS - [https://skatejs.netlify.app/](https://skatejs.netlify.app/)

\- SkateJS: Web component server-side rendering -
[https://github.com/skatejs/skatejs/tree/master/packages/ssr](https://github.com/skatejs/skatejs/tree/master/packages/ssr)

This latter looks good, I hadn't seen that before.

As a possible successor to React, Vue, et al, there's a wide range of
functionality expected of Web Components. Server-side rendering of shadow DOM
(I don't know what that really means, but) seems to be one of the tough
questions yet to find a definitive answer.

------
ramon
I was looking at the code it looks optimized, will do a couple of tests later
maybe combining this as the main webcomponent controller with something like
tailwind css makes sense, but just using this plain look and feel I don't
think it's viable at this moment but it's a good structural start I would say.
Was looking forward to do this with lit so maybe I might test this and see how
the code looks, from a code output perspective it looks promising let us see
this with something like snowpack. Till now Lit looks a lot easier to use and
all let us see how it goes.

~~~
CuddleBunny
I'm using FAST with the design system props mapped to Tailwind config for my
Blazor app team. This lets them consume the awesomeness without writing JS.

~~~
ramon
That is a great idea and usage. I was thinking about a Blazor setup.. but I
will think more about the approach first. I think in a very near future a
Fast-Tailwind repo will arrise.

------
rwieruch
For anyone who is interested in seeing a practical example of using web
components in a library like React [https://www.robinwieruch.de/react-web-
components](https://www.robinwieruch.de/react-web-components) Last year I
worked for a large company which had Angular and React teams, so the idea was
to use web components for their UI library and then just let the angular and
react teams write wrapper for these components. I had to prototype how to use
web components in react.

------
c-smile
How I would do that in Sciter:

fast.css :

    
    
        fast-something {         // custom element
          aspect: FastSomething; // its function-controller
          display:block;
        }
    

script:

    
    
        function FastSomething() {
          // note JSX is built-in in Sciter
          this.content( <b>Hello World</b> );
        }
    

and markup:

    
    
        <style src="fast.css" />
    
        <body>
           <fast-something /> 
        </body>
    

Easy, no?

~~~
DethNinja
I love Sciter and it is pretty amazing for what it does, but I still wouldn’t
use it to share internal web component libraries within my own company, never
mind some other 3rd party.

Sciter unfortunately uses it’s own dialect of JavaScript and CSS which might
not be compliant with browser JavaScript engines.

I really wish Sciter would move to some other commonly used JS engine and get
rid of TIScript, then I would be more confident with creating an internal
library, at least I would be able to use web components in a cross compliant
way between browsers and Sciter.

~~~
c-smile
That's just an illustration of how it can be done otherwise. The only non-
standard thing there is that CSS glue construct:

    
    
       selector { aspect: Func url(script.js); }
    

It tells that as soon as element matching that _selector_ will appear in the
DOM it will have Func() called (from script.js). No complex abstractions are
required.

"to share internal web component libraries within my own company, never mind
some other 3rd party"

My pardon, I didn't get the "to share" part, who share, what, and with whom?

~~~
DethNinja
I meant creating a web component based widget library and sharing that for use
on anything from desktop GUIs to web sites.

Sciter’s approach is pretty much the same approach used by web components
(combining css/html/js to a single reuseable element). Unfortunately it isn’t
100% compliant with browser based web components and hence Sciter based widget
libraries can not be used for web sites or vice versa.

~~~
c-smile
Again, that's not about Sciter but rather discussion of Web Components idea in
general.

Essentially WebComponent is the way of associating some JS class with custom
DOM elements.

At the nutshell, WebComponents is just this one JS function:

    
    
        customElements.define('hello-world', HelloWorld);
    

But it is quite limited as you see - a) only custom elements and b) you need
to load some JS file in order to initialize bindings.

That element->JS code binding could be done by CSS with much greater
flexibility:

    
    
        /* custom element */
        hello-world { aspect: HelloWorld url(hello-world.js); }
    
        /* existing element */
        span.hello-world { aspect: HelloWorld url(hello-world.js); }
    
        /* existing element, conditionally */
        a[href^="http"] { aspect: HelloWorld url(hello-world.js); }
    

Yet note that, in case of CSS bindings, hello-world.js will be loaded _only if
your document will have matching elements_ \- better componentization I would
say.

------
Omnipresent
Very interested in the background image on their home page that slowly
animates as well. That looks really great. Anyone know how are they doing
that? [https://fast.design/](https://fast.design/)

~~~
flowerlad
The background image is a <canvas> element on which they draw using
JavaScript.

------
mattlondon
A lot of the components don't appear to work? Checkboxes, radios, sliders.

There are also weird extra spaces and alignment issues on things like basic
links or the list numbers in the tab demo.

Bit of a shame

This is on Firefox on Android.

------
ruduhudi
Love it when I'm on a design system's website and it's broken on mobile.

[https://postimg.cc/N509Z8Kr](https://postimg.cc/N509Z8Kr)

------
unnouinceput
I like their transparent implementation. Went to text-area expecting
...something else, but I got Microsoft instead ¯\\_(ツ)_/¯

Is this a pre-pre alpha preview of the preview? Because it feels like

------
badrchoubai
I really love watching companies adopt the Web Components standard, Apple's
adoption of it for building Apple Music's web player got me interested in
learning them.

------
rakamotog
For a non developer like me,

Is it any different from Ant Design
([https://ant.design/](https://ant.design/))?

Also, almost every company I worked with (> 500 employees), eventually built
their own UI components. And in every company, developers seldom use these,
always customize or use something else.

Which brings the question - Why do we invest (internally) and open source
components? Whats the value?

~~~
scns
Ant shipped 1MB CSS minified, last time i used it at work.

------
manigandham
The project homepage is easier to understand than text:
[https://www.fast.design/](https://www.fast.design/)

And here's a ASP.NET Community Standup session that goes through the FAST
framework by one of the core developers:
[https://www.youtube.com/watch?v=sYTH_xYH3iA](https://www.youtube.com/watch?v=sYTH_xYH3iA)

------
dynamite-ready
At first glance, while the intro tries to differentiate the product from
Fluent UI, I doubt anyone, even the most enthusiastic devotees, would read
this...

"Have you ever needed a reusable set of UI components that you could drop into
your app and have an amazing experience? That's FAST."

...and think 'That's FAST'. They'd immediately think "That's Fabric (or
Fluent)".

------
r-w
For anyone who would like to take a look at the code for the respective
packages, here it is:
[https://github.com/microsoft/fast/tree/master/packages/web-c...](https://github.com/microsoft/fast/tree/master/packages/web-
components)

------
fareesh
The slider performs terribly on Android Chrome

------
darepublic
On mobile Firefox the side menu is quite janky

------
ramon
I just wrong a little tutorial on FAST with Snowpack if anyone interested:
[https://www.linkedin.com/pulse/microsoft-fast-snowpack-
ramon...](https://www.linkedin.com/pulse/microsoft-fast-snowpack-ramon-lima/)

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

~~~
spankalee
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](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`
              <h1>Hello ${this.name}</h1>
            `;
          }
        }
    

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](https://lit-element.polymer-
project.org/guide/decorators)

~~~
megaman821
Yeah, LitElement definitely has a cleaner render template. How would one do a
computed property in LitElement?

~~~
spankalee
You really don't need any special for a computed property. I'd start with a
simple getter:

    
    
        class MyElement extends LitElement {
          @property() value: number = 42;
          get valueSquared() {
            return this.value ** 2;
          }
        }
    

If the value is expensive to compute you can memoize it in the getter, or set
it in update.

------
the-dude
And I was thinking they bought this for $1.3bn in 2008 :
[https://searchengineland.com/microsoft-to-buy-fast-search-
fo...](https://searchengineland.com/microsoft-to-buy-fast-search-
for-123-billion-13082)

------
azinman2
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).

~~~
ggregoire
> I find it hilarious that they put a dark mode toggle in the corner (why
> would I want this on a per-website basis?)

They detect your OS preference and display their light/dark style
automatically based on that [1]. The toggle is just there if you wanna switch
it manually. My Mac is in dark mode but I usually prefer reading docs in light
mode, so that toggle is handy.

Agree that it should update the background of the examples tho. Probably just
a bug or something they didn't think about.

[1] [https://developer.mozilla.org/en-
US/docs/Web/CSS/@media/pref...](https://developer.mozilla.org/en-
US/docs/Web/CSS/@media/prefers-color-scheme)

~~~
azinman2
If that's the case then I think you should take your Mac out of dark mode. If
we have to put it in every app and webpage in a non-standard way, then that
suggests that dark mode itself is broken.

That it doesn't change the example on the web page seems like a giant
oversight, or a rendering error on Safari.

~~~
mkl
It's there so developers can look at the components in both colour schemes.

------
pjmlp
For those that miss it, the dark mode can be turned off on the top right
corner.

------
zelly
Even though they may be slow and have an unusable API, Web Components being
built into browsers means they will continue to work long after React, Vue,
etc. are all dead and unmaintained.

~~~
abraham
What makes you say web components are slow or have an unstable API?

~~~
zelly
It's slow and un _usable_ , not unstable. The one benefit of WC is that it's
going to be stable for the next hundred years, just like <marquee> still works
in 2020. It's unusable because of all the boilerplate it requires and doesn't
provide the most important thing of all which is data binding. So you have to
bring in some other support code to do data binding such as the Rx/Observables
or Redux patterns, but since this can't be shared with other shadow-rooted
WCs, the cost of that bloat is multiplied by the number of different WCs you
have on a page, which could be hundreds.

In benchmarks WC scales very poorly compared to React. It just wasn't designed
for performance. I could go on.

\- strings as the only native serialization format

\- templates are also strings

\- messages are passed to children as attributes which are strings

\- no way to take advantage of efficient tree algorithms (virtual DOM), just
manipulate a giant string every tick like a caveman

~~~
c-smile
You'd be surprised but in general this

    
    
        element.html = "...";
    

is faster then

    
    
        ReactDOM.render(vdom,dom);
    

at least for initial DOM tree population.

There are many reasons for that. `element.html =` is implemented as single
update transaction, JS function call is significantly more expensive then HTML
parsing of single element, etc.

~~~
zelly
This is thanks to how extremely optimized V8 and Chrome is for string
manipulation. It is faster in the small cases but doesn't scale to, say, 10000
rows in a table. Then it becomes several orders of magnitude slower than React
and virtual DOM. On low memory devices it could crash and never render. This
should just be kept in mind when choosing WCs. WCs are perfectly fine for the
Settings page in Edge, for example.

~~~
c-smile
"extremely optimized V8"

JS code is always slower than native html parsing code. No matter what.

"10000 rows in a table"

This:

    
    
        element.html = 10000 times "<tr>...</tr>";
    

is by order of magnitude faster than

    
    
        element.appendNode( document.createElement("tr") ... ); // ReactJS code
    
    

no matter how optimized JS runtime is.

array.forEach(func) is 30 times slower than plain for/at loop. Because of
function call.

------
sireat
Does FAST checkbox component have some sort of delay built in?

Compared to regular vanilla checkbox it seems to respond slower(100-200ms
delay perhaps).

This is on slowish 4G connection but that shouldn't matter.

------
trenchgun
That is some seriously cheesy but brilliant copywriting!

------
moneywoes
Slider doesn't work for me on Chrome Android.

------
mishkovski
It looks like alternative for [https://material.io/](https://material.io/)

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

~~~
lucideer
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)](https://en.wikipedia.org/wiki/Polymer_\(library\))

[1] [https://www.digitalocean.com/community/tutorials/vuejs-
vue-i...](https://www.digitalocean.com/community/tutorials/vuejs-vue-
integrate-web-components)

[2] [https://github.com/jscissr/react-
polymer#readme](https://github.com/jscissr/react-polymer#readme)

~~~
kutorio
It reminds me more of [https://material-ui.com/](https://material-ui.com/)

------
kingnight
I could have bet there was a low quality / compressed image on this when I saw
Microsoft. Low and behold the site logo is low res.

Why is that at MS... Switching to teams everyone’s face turned to mush which
while it might save on aggregate network traffic, it greatly reduces the
niceness of the conversation.

------
varbhat
It Looks and Feels very much like Google's Material Design.

------
StaticChamp
Microsoft and design in the same sentence! They have come far.

~~~
shp0ngle
What about "Windows 8 introduces new Metro Design language", huh

------
andybak
Is it just me or is the first thing you want to to see and try the damn things
out?

Ctrl+F "Demo" \- nope.

I think I found them eventually under "Component Explorer" \- but that's in
the secondary nav and not in the main menu.

------
winrid
Ha, can we add fast-comments as a component? :)

------
rondennis
On a side note, is Microsoft acquiring Tik Tok?

------
pearjuice
Kind of surprises me that Microsoft allowed this project to use Discord for
external communication.

~~~
CuddleBunny
Teams doesn't have a free public mode at this time so it sounds like the best
option to me. There are official Microsoft instances of Slack and Gitter as
well and teams seem to be given a fair degree of freedom.

------
cryptozeus
Not responsive, in 2020 ?

------
chrisweekly
Web Components, as a standard, remain problematic. Among other things, they
fail to address the critical need for server-side rendering.

~~~
zelly
I think a Web Component is meant to be like a <div/>. It's one of the pieces
that you render on the server. That way the client is dumb and just implements
a design language in Web Components/JS, and the server sends commands to lay
them out with data already bound.

------
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.

------
Datsundere
There are plenty of these libraries. Can someone tackle the hot mess css is?
Give me one way of doing things. Css breaks do much shit for me to the point
where I don’t want to code

~~~
crooked-v
If you use React, you might like Rebass ([https://rebassjs.org/getting-
started](https://rebassjs.org/getting-started)), which turns the most common
CSS attributes into component props with assorted built-in functionality for
common theming and media queries, or Emotion
([https://emotion.sh/docs/introduction](https://emotion.sh/docs/introduction)),
which lets you composably define CSS per component that automatically gets
scoped to that component only. Both are designed in a way that still render
efficiently, such as turning static CSS rules into statically-defined bundles
and only swapping out the dynamic bits on the fly.

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

~~~
megaman821
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.

------
russellbeattie
Oof. When will this "dark mode" fad end?!? Is this project made for edgy 14
year olds or actual professionals?

(Yes, yes. You can switch some of the site to light mode and, besides, you're
an elite uber-hacker and white text on black background is totally easier on
your eyes, and you always read everything like that since
blahblahblahblahblah. Uh-huh. There's reasons we've been printing with black
ink on white paper for 500 years.)

------
reaperducer
So, is this Microsoft's iteration of a more modern jQuery?

Forgive me if I don't get what's happening here. The coffee maker broke last
night.

------
bengale
I don't know if i'm missing something, but this seems crap. Its really ugly,
and there isnt a lot there. Why wouldn't I just use BlueprintJs?

