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://developer.mozilla.org/en-US/docs/Web/Web_Components

- https://developers.google.com/web/fundamentals/web-component...

- https://caniuse.com/#search=components

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

I wouldn't say that - Web Components (by themselves) do not allow you to write your view as a function of application state, which is the main draw of at least React.

But the initial use case of Web Components is to create a standard that allows developers to iterate on the web's built-in components (inputs, date pickers, etc.) without having to wait on the standards track, and FAST appears to intend to provide a number of such components.

(And there is more to such components than just styling (which is what Bootstrap provides) - it's behaviour, usability by people reliant on e.g. screen readers, an API to access its data, etc.

Handling data React passes all data to Custom Elements in the form of HTML attributes. For primitive data this is fine, but the system breaks down when passing rich data, like objects or arrays. In these instances you end up with stringified values like some-attr="[object Object]" which can't actually be used.

Handling events Because React implements its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of a workaround. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener. This makes working with Custom Elements cumbersome.

Stencil provides wrapping to circumvent these limitations. https://stenciljs.com/docs/react

1 - https://shoelace.style/getting-started/usage?id=react

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 components and attributes on HTML elements, with no syntax to set properties on elements. Then it special cases a list of attributes so that things like `class` map to `classList`.

So... remove special cases, add general abilities, and it all just works.

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.

You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing.

This is fundamentally React's problem. It's the only major framework to even have issues here.

React just had a more complicated way of setting properties. Entirely due to React's choices.

tl;dr you'll still be doing the wrapping in practice.

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.

Web components are the solution. No matter what library or framework or whatever that you're using, you can render a <div> so you can render a <my-component>. 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.

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.

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

For node: https://www.npmjs.com/package/lit-analyzer

For other Web Component libraries: 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.

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?)

In practice, most libraries built around web components only use attributes when serializing / deserializing HTML strings. When performing updates to existing DOM, it is very common for a library to use a corresponding property instead. This is very fast, supports all types of values, and many libraries enable users to think in terms of attributes while the library updates properties under the hood (conceptually similar to the React mental model).

By using attrs, they show up in dom explorer, so it’s neat, don’t need another devtool. attributeChangedCallback will only be called when the attribute changes.

For props, it’s a bit more work since HTMLElement itself has a ton of built in props, using a setter means anytime something sets, it will he called, even if the property value isn’t different. the worst thing is when you end up overriding an internal prop and weird things happen.

This gives you compile-time checks, and attributes can be objects.

Properties can be complex objects, do not trigger attributeChangedCallback, and don't need to be serialized.

What are you using to build your web components if you think they can only take strings?

Yes, it requires a plugin, but JSX required the parser, compiler, and type-checker to explicitly add support for it. They both require an extension to core TypeScript.

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.

---

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

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.

But I have used react, vue, jquery, and my favourite which is just plain old JS and to me this is just generating templates with a different DOM structure and class semantics. IDK it just seems like this is not something I'd want to retrofit but would have to adopt as a standard to see any value long-term over a bunch of projects.

Usually I am more measured in my responses but this time I tried to just say what I am thinking (screw my ignorance) so maybe I can learn a thing or two.

Thanks for responding.

On the one hand this is great because programming is in my bones and I know whatever comes along I'll figure out.

It's also terrible because sometimes something that looks like a rebranded version of what I already know is actually a fantastic new and easier way of doing things, and it's really easy to miss something great.

This just doesn't feel like something great, it just feels like another branded corporate way to structure code that there's dozens of examples of already, it's not an improvement just an alternative, if that makes sense.

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

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.

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?

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.

I did come out pretty strong in my apprehension but I am serious in wanting to know specifically what the benefit of this is, and I don't really care whether I am making a fool of myself for asking questions lol.

Reality:

- WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated.

- The standards provide a verbose, error-prone imperative API that leaks implementation details left and right

- The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API

- Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else

- You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components

- They break accessibility

- They don't work without JavaScript

- They cannot be rendered server-side

- They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent)

- And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks

1. Define elements in script by extending htmlelement

2. Follow the allowed structure in the DOM so that the custom elements don't break / conflict with anything

3. Use CSS to make the custom element look nice.

Then, basically what we have is:

1. A class-based way to attach event listeners in a standard interface (which is nice)

2. what we always had to do anyway (unless framework forces using JS to inject HTML at runtime)

3. what we always had to do anyway

4. Can't use custom events anymore... Encapsulation fTW.

But now that brings us to a situation where, essentially, it comes down to which htmlelement classes take precedence in our dependency hierarchy. Some libraries are probably compatible but you can't guarantee it because there's no explicit package dependencies between different implementations, so if you choose two different component libraries you may end up with unexpected behaviours and bugs.

So if I were to build a component library that is "compatible" with all major component libraries, essentially what I'd have to build is a shit-ton of "mappings" and exceptions that define an order of precedence of which component variants my library should interact with or cede to? I don't really like the idea of "just magically working with incompatible libraries" right?

Does that seem about right?

I think I learned something new and fundamental today, and the overall approach makes sense if you pick a single library to build your application but I can't see it having any realistic value if you're to try and jimmy it into existing products, in fact I can see that being an extremely expensive exercise and potentially adding a load of overheads to maintain and configure.

Also I can see now why no one really answered the question about ARIA tab orders and accessibility, it's not the job of these libraries.

I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :)

This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world.

> I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :

No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.

I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply but it felt honest at the time, I am glad that we have had this conversation in general because it's given me a lot to think over.

My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results. I've been on projects that ended up taking far, far longer and costing way more to maintain simply because we had to nurse the framework rather than deliver the results.

Anyway thanks for taking the time out again, I need to percolate for a while and look into some of the ideas that have been expressed here.

Yup :) They decided to go for a flat namespace where all that distinguishes between components is their name. I'm guessing this already leads to collisions between different versions of the same element. And there has been an open issue for it for three years now: https://github.com/w3c/webcomponents/issues/716 And the "solution" seems to be "let's add more Javascript": https://github.com/justinfagnani/scoped-custom-elements

> I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply

It's perfectly fine :) I've been way more rude about web components before (and still am :) )

> My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results.

Indeed. That's my main gripe with web components, really: instead of providing tangible benefits to developers, they ended up being "an API primarily for library and framework developers"

> one of them is already deprecated, and v0 of another one is also already deprecated.

Sometimes you swing and you miss. Instead of moving forward with the initial design, they iterated and improved it. That’s how software works.

> The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API".

It’s not because the API is bad, it’s because the term “component” has become ubiquitous with framework components and that’s caused A lot of confusion. Web components are lower level than React/Vue components by design, but people hear “component” and have the same expectations. Having worked with web components almost exclusively for more than a year, I feel like the APIs are thought out fairly well. They’re not perfect, but they are good and there’s momentum to continue improving them (e.g. declarative shadow DOMs).

> You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events

It’s still pretty new, but it’s coming. These things take time to get right and become supported by all browsers. Search for form-associated custom elements, for example.

> They break accessibility

Only if misused, which is also possible to do in any framework or even plain HTML.

> They don't work without JavaScript

I’m so tired of hearing this. How well does your React/Vue/Angular/Alpine/jQuery-based app work without JavaScript?

Browsing the web in 2020 with JavaScript disabled is like driving your car down the road without any wheels. Things just aren’t going to work right. The experience will be inferior even the when effort is made, but IMO it’s not reasonable to expect developers to accommodate the < 1% of users who might actually do this.

> They cannot be rendered server-side

I’m no expert in SSR, but Stencil offers some examples of how to achieve this with their compiler, which is a joy to use. [1]

> They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events

It wouldn’t make sense to provide an “onclick” style prop for custom events, but you can attach listeners with `addEventListener` like any other event. The syntax is identical.

> And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public

I’m a proponent and I’m happy to discuss these things in public.

It seems, however, there are a lot of misconceptions about the underlying specs. Maybe that’s deserved — it took a long time for web components to get this far and it’s been a bumpy road. That doesn’t mean it hasn’t gotten much better.

I’d encourage anyone who hasn’t explored custom elements, shadow DOM, et al recently to take another look. We’re building some awesome things with them!

1. https://stenciljs.com/docs/static-site-generation

So, what do ya say? Would you React the same way? ;)

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.

It's more about I guess what context is this framework more applicable in? What does this exactly "standardise" - given that "standardisation" frequently just means "now we have x number of frameworks to support instead of x - 1)"

I still have to train my team to structure their components differently than they currently do, to refactor existing systems away from their current frameworks to this one, a significant investment in time and energy... so... Why? Why is this one the ultimate framework for "web components" (which used to just be called "semantic html")?

It's like a while back I trained myself up on GWT because in my mind it was the future of reusability.

Sure it was Java based and everyone hates Java these days I guess, or at least hating Java is a meme. But the entire concept and value was that you write everything as reusable components.

Then all you really needed to do was choose your compile targets and the compiler would do the rest, generating cross-browser / device versions of your application code as needed.

I can see now what the OP means and honestly from my point of view the post-XHTML / DTD / XSD diaspora is circling back around to trying to find standard ways to separate data from presentation.

I think I get it now, thank you.

( https://storybook.js.org/ )

https://docs.microsoft.com/en-us/aspnet/web-forms/videos/how...

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.

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.

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.

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

The results are here: https://raw.githubusercontent.com/jjcm/shadowTests/master/re...

TL;DR - the withShadow element takes about twice as long to render as the withoutShadow element. Don't use them unnecessarily.

https://github.com/Polymer/tachometer

I.e. for testing shadowroot performance, I threw this together: https://github.com/jjcm/shadowTests

You can see the results here: https://raw.githubusercontent.com/jjcm/shadowTests/master/re...

TL;DR - a custom element with no shadowroot is about twice as fast.

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

Is that the popular consensus, or is that an odd way of looking at it?

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.

(I'm not a front end dev myself, but do enough full stack to think I know what is going on here.)

The API is easier, there’s less markup, and less room for error. A well-designed component also bakes in accessibility and provides encapsulation so your own styles and behaviors won’t leak in.

It’s a way better dev experience.

1. https://www.reddit.com/r/web_design/comments/hypdzz/comment/...

There might be some interesting base stuff underneath but the UI/design part is pretty barebones and meh. Maybe that's not the point?

Yes, many of the interactive elements look static. Anything built with this design would be very hard to use. And, as others have said, the accordion +/- buttons are reversed.

Good. That will encourage people to change it.

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

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

That’s life at BigCo for ya.

"This package has been moved to FluentUI and has been renamed to @fluentui/web-components"

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

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.

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

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

I want something batteries included.

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

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

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

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.

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.

Me too. Dreamweaver once did that. But the Javascript/CSS crowd complicated layout so much that writing WYSIWYG layout tools became extremely difficult.

Blue Griffon is perhaps the last remnant of that era.

https://cxjs.io

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.

* 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!

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?

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

The article mentions a few libraries for this purpose.

- Vaadin Router - https://vaadin.com/router

- SkateJS - https://skatejs.netlify.app/

- SkateJS: Web component server-side rendering - 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.

fast.css :

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

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

    <style src="fast.css" />

    <body>
       <fast-something /> 
    </body>

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.

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

"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?

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.

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);

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); }

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.

https://postimg.cc/N509Z8Kr

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

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

Is it any different from 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?

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

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>
        `;
      }
    }

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

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

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

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

    element.html = "...";

    ReactDOM.render(vdom,dom);

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.

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>";

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

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

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.

https://www.fast.design/docs/fast-element/observables-and-st...

> The arrow function bindings and directives used in templates allow the fast-element templating engine to intelligently react by only updating the parts of the DOM that actually change, with no need for a virtual DOM, VDOM diffing, or DOM reconciliation algorithms. This approach enables top-tier initial render time, industry-leading incremental DOM updates, and ultra-low memory allocation.

> When a binding is used within a template, the underlying engine uses a technique to capture which properties are accessed in that expression. With the list of properties captured, it then subscribes to changes in their values. Any time a value changes, a task is scheduled on the DOM update queue. When the queue is processed, all updates run as a batch, updating precisely the aspects of the DOM that have changed.

That's neat.

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

You'd probably still want to use React or similar ontop of it, but in the future we might get much lighter libraries covering that side of things.

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.

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