Microsoft Fast Design

Ionic Stencil let’s you wrap webcomponents and turn them into React, Vue, or Angular components. MS should use that or do something of a similar nature. Otherwise there is a impedance mismatch between this and what most or used to.

I can't send DM's here and I don't know if you'll see an edit, so I wanted to add that I am sorry if I sounded condescending in my other reply, I initially just wanted to make sure you and other readers understand I am not new to the programming game to emphasise my frustration at not being able to understand something so simple as drawing html elements, and prevent assumptions about my ability to comprehend frameworks in general, but on re-reading it sounds like I'm trying to 1-up you, in reality I do find it hard to keep up and I am fearful that things are moving beyond my ability to comprehend. After some other discussions with other posters here this sounds like it might be a cool addition to the ug... component-o-sphere? It'll take me a while to get up to speed.

Thanks for taking the time, and I will try to be better next time.

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 drop it into a page and it won't mess up the rest of the page and the page can't mess it up.

This is particularly valuable for a design system, because a company will have a design and want their web properties to look consistent, but they'll have one app written with angular, and another couple with react, and a few ancient apps written with jquery. You could either convert _everything_ to the latest and greatest thing, or you could write your design system with web components, and it'll work everywhere.

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.

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.