Microsoft Fast Design | Hacker News Reader

Microsoft Fast Design

fast.design

623 pointsno_wizard204 comments

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://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)

> but using only standard HTML and JavaScript (no frameworks).

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.

If all the open source components I used all used preact, I wouldn't be concerned about the 3kb. But if each component author uses a different framework or even a different version of a framework, it quickly becomes something like 3kb * number of components.

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

Yes, now you can use components without a framework (you could use them without a build step also before). But if you want to do anything more complex than a static page with jquery, you still need both.

To me it feels like the dream of 2005. It's cool, but we've been able to do the same for at least ten years at this point, and with the tools of our choice.

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

So, like https://medium.com/ing-blog/ing-open-sources-lion-a-library-...?

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

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

The difference is that FAST is NOT a component library. It is a tool for building component libraries. The fast-components package is a showcase of what this library is capable of. You could use FAST to create web component libraries that consume bootstrap styles if you want. Microsoft is using this same base to write web components for Fluent UI (previously Office Fabric): https://www.npmjs.com/package/@fluentui/web-components

> The important word here is Web Components, which is like React or Vue components but using only standard HTML and JavaScript (no frameworks).

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.

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.

Not quite, Ionic Stencil is library to helps build webcomponents. Since fast.design are webcomponents, they can be used in any with any framework, no wrapping required.

Ah, thanks for the clarification. I know the developer of Framework7.io has a tool to take his components (not webcomponents though) and make them into React/Svelte/Vue native ones. So I kinda mixed the two tools together in my head.

Web Components can't be directly used in React due to these limitations documented at https://custom-elements-everywhere.com/

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

This is a pain point of React + web components, but I’ve heard they’re trying to solve it in the next major version. In the meantime, I built a wrapper that lets you use custom elements as if they were React components. [1]

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

That is React's problem in fighting against Web Components.

> they can be used in any with any framework, no wrapping required.

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

They're not different from built-in elements and don't need special treatment.

The way that frameworks that work well with web components do it is be not giving special treatment to things. Vue, Angular, and lit-html all treat built-ins and custom elements then same, and they have different syntax for setting attributes and properties.

React treats elements different from components and sets properties on React 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.

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

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

That seems a rather silly distinction to me: "They're a special case because they're not on React's list of special cases".

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.

Again: I don't care who's to "blame". I care about whether I can just use Web Components in any web framework, which is not the case.

The do work in React. It's hard for them not to, since they're just elements.

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

Sure, but if your standard is "it can work in React, just with some more work and downsides", then technically you can use Angular components in React as well.

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

That's FAST.

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.

You can use JSX to implement as well as consume Web Components. See here: https://github.com/wisercoder/uibuilder

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

The template strings are sort of typed, using tagged template literals. These even come with editor support using extensions previously built for lit-html and the like.

You get compile-time checks for embedded JavaScript expressions. But you don't get checks for html tags and attributes. With JSX the TypeScript compiler checks JavaScript expressions as well as mismatched tags and attributes, all without any add-ons.

If the tagged literal approach takes off I'm sure tooling will keep up. JSX wasn't always as well supported as it is now.

With the lit-html TypeScript and VS Code plugins you _do_ get checks (and auto-completion) for HTML tags, attribute, and properties.

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.

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

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.

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

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

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

Yep that’s why said it’s a gotcha. As a team you have to decide the attribute/prop tradeoff and stick to it in a consistent way.

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.

Attributes are strings, but web components can have properties like any other object, and you can set properties on elements from JS and almost all template libraries.

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?

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.

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

Link to Lion's storybook demos for those interested: https://lion-web-components.netlify.app/?path=/story/intro-l...

Any idea how FAST compares to using storybook directly?

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

Fast is a set of components (and a base class). Storybook is a way to demo components.

Lit has been doing this for a while it's from that Polymer project. https://lit-element.polymer-project.org/ Web Components is a huge deal, you can do just web components on plain notepad and not need any build system for something very simple just using module based packages on the browser this is really cool. Snowpack for me was something huge, getting away from webpack was like getting back hours of work. But I don't know, till now for me I still see the Lit-Element and stuff as being more flexible than this one, the beauty is for example you can have a component in react and another on in Vue, it doesn't really matter and another one in JQuery. You can have whatever works best for you for each case.

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

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.

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

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?

Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)

I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and dismay. That's not going to happen either.

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.

Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours.

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

Okay I think I get it:

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

In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)).

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.

Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? This feels like another example of the XHTML apocalypse coming full circle and we're trying to find objective approaches to loosely defined data.

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.

> Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard?

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"

Creator of a popular web component library here. Some observations:

> 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

What I meant was that are a lot of like minded developers here who cringe every time they have to hear how JS is going to teleport us from Earth to Mars. And since there are no bonus cookies that can won by proving that you can create a functional website simply by using some good old HTML with CSS and vanilla JS, a lot of us resort to being silent and enjoy the show!

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

It's funny because in writing my previous reply to you I felt a momentary sense of inclusion into a special club, I did think something along the lines of "should I just enjoy the show" and then on reflection I realised that taking such a stance would be equivalent to having no voice at all, and it would also essentially evaporate my chances to learn anything new from the good folk here as it would set up a "me vs them" context, which I don't believe would lead to me learning anything new.

Don't get me wrong, I can see where you're coming from and feel the same way many times myself, but I am no stranger to conflict, and I spent a great deal of my life fawning to people or deferring my opinion for some "greater ideal" that other people tried to set for me, like you are doing now. You have set up so many logical fallacies, talking about "so many developers", "bonus cookies", and some weird need to "prove" ourselves, that I don't even know where to begin unwrapping whatever complex you have.

Get help. You will be happier.

I decided in this instance to say whatever is on the top of my mind no matter how stupid it makes me look, I don't seek camaraderie with anybody at face value just because you purportedly represent a group that I can join. "Like minded developers"? You would have to try harder to entice me to be a part of your group, if you even have a group. I really don't care to feel superior to anyone, results speak for themselves, so good luck I guess establishing a weird inner circle of ideals but I really want no part of it, nor do I need any endorsement from such a group.

Wow, that felt so fucking weird to type.

Take it easy Freud, there’s no need to break your intellect down into so many pieces and get personal. Cheer up!

I'd say the important word there is "team", you use those libraries and frameworks because they are curated ways of doing what you want, reducing friction. If you are coding by yourself, you know everything about the codebase, and you focus on different trade-offs.

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.

I understand the framework concept very well and have (oh god I hate this term) "spearheaded" multiple componentisation schemes over the years, to make code more reusable across teams, to reduce coding effort, to reduce expense for the business while improving the QA outcomes for the client etc. We standardised on frontend frameworks, set up and configured automated build systems way back when most web dev shops were still FTPing their shit up to servers, automated the task of installing dependencies and so forth. So I honestly get the value of frameworks and systems in a general context, I know what frameworks are...

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

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.

Frameworks mean React, Vue, Angular, etc. Usually, if you make a TextInput component in React, you can't use it in Vue and vice-versa. If you create a <text-input> web component, then you can use it in any of these frameworks (or with no framework at all), like a native html tag.

Thanks that actually sounds like it could have value, but again it's a new paradigm to learn.

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.

And I am trying to understand, I think I'm just in a bad mood about this (I think I have framework fatigue? if that's a thing?) so thanks for explaining.

"just HTML elements"

-- which depend on Javascript and have no good answer to "what about SSR"?

Focus on Web Components and forget Fast you'll see the benefits then and then start looking around at other projects focusing on Web Components. The benefit is that you can have whatever frontend tech stack at your project, someone doing Vue another one in React.. another one in JQuery there's no limits.

Thanks I have asked another poster to fill me in because maybe I'm too old school and yelling at kids to get off my lawn. I might have to shut up now for a while until I run away and get back up to speed in this arena.

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.

I'm in the same boat, I still like the plain old vanilla JS I do see the benefits of Typescript and all but I don't know I have been doing JS since I was 10 years old so I guess it's something that comes from my childhood haha. I just love JS in any fashion, it's a love relationship since the beginning and way back then I always saw that there was huge value around JS but never imagined back then that we would get to were we are today, back then Flash was the big deal and it was doing the more advanced functionality in the front-end could never imagined that Shockwave, Flash would all get basically banned due to security. Interesting turn around for JS and the open source nature it has always had since its infancy with the Mozilla Browser.

I started coding BASIC in the late 80s and built websites before CSS and JS was a thing in addition to just coding stuff in whatever language took my fancy to solve whatever whimsical project I had that day, I had a particular affinity for optimising getpixel and putpixel routines in ASM when you could still directly address video memory.

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.

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.

MS had this back in 2006 with CSS Friendly Control Adapters for asp.net.

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

fast-foundation and fast-element are the main point of this. The components are mostly just a showcase. Though the MS-style set of components (https://www.npmjs.com/package/@fluentui/web-components) leveraging FAST will probably end up one of the most consumed products.

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.

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?

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.

It's more than one unnecessary level of nesting in the DOM, it's that they're creating an entirely separate DOM tree they aren't using. I threw together a test using tachometer to demonstrate the differences: https://github.com/jjcm/shadowTests

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.

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

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

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

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

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

Another funny thing with the accordion component: the icons for expand and collapse seem to my mind to be reversed (- for expand and + for collapse)?

Just curious - where did you learn this level of detail w.r.t DOM, and what would you recommend I take a look at to learn it the right way?

Honestly just by making components and benchmarking them. Webcomponents are too new to really have a solid best practices guide at the moment and there's a lot of varried opinions out there. My main recommendations are to benchmark early and often. Tachometer is a library from the polymer team that I find does this very well:

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.

Check out the FAST Component explorer to see it in action: https://explore.fast.design/

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

I would imagine the design convention is to show a + when you have more content hidden, and a - to indicate you can hide (minimize) it.

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

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

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.

The default design looks awful, especially on phone. I’m not a frontend dev, but I don’t see any reason why would I use this instead of, for example, Bootstrap for sideprojects. Can some FE comment on the project usefulness? Why go with Fast?

The impression I get is FAST is trying to simplify the markup you see in for instance Bootstrap's documentation by trying to build standard components that Bootstrap themselves could use (or Material or their own Fluent stuff). The emphasis is on a lot of the little things in Bootstrap's documentation that doesn't either get copy/pasted or it gets copy and pasted and ignored/forgotten/left-to-bit-rot. Stuff like aria- tags for accessibility. Seems the idea here is that by baking them into web components that do most of the work for you they are less likely to be forgotten or left to bit-rot.

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

I maintain an alternative web component library, and this is the Bootstrap comparison I like to use. [1]

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

Strange how the switch uses the default arrow cursor and the checkbox uses the pointer, while neither have a hover effects, but the other form elements and interactive components all have hover/active effects.

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

On desktop all of it looks like they either didn't do any styling, so I can hardly tell I'm not looking at unstyled HTML (lots of the static elements) or what they did is pretty bad-looking (everything else). Is this representative of the work, or is this presentation just weirdly bad for some reason? What's good about it? What am I missing?

default design is horrible

Good. That will encourage people to change it.

How is that good? If they make it have good design then people don't have to try to make it good (and often fail).

> the presentation and default design is horrible

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.

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

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.

The components part of Fast has moved to Fluent. See https://github.com/microsoft/fast/#fast-components-msft

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

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

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

Ditto on OSX+Chrome

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

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.

The slider thing is horrible, it animates while dragging so it looks like it's lagging behind the cursor.

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.

That Slider's unusable on mobile. Seems to just be click for a value, hope you don't need to make a small tweak.

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?

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

Neither do they seem to work in desktop Nightly.

Agree, UI and UX is really bad for the components demo, but I think their goal is not to be an UI framework, but a step before that? I am very confused about what they are trying to achieve and how. I personally that think this project has no future.

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

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.

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 site is now about 27 years old.

I want something batteries included.

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.

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!

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

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

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

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.

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

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

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

I'm using FAST as a foundation for my atomic design revolution at my job. I'm gaining much traction!

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.

I always wonder where is the VB6/Windows Forms for web apps?

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.

CxJS tries to solve common UI problems related to CRUD apps and dashboards.

https://cxjs.io

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

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.

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!

Thanks for the detailed responses, and thanks for the release. I am looking forward to digging...

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

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

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.

This kind of information, and bits of your reply comment, should be part of the website. I found all the "That's FAST" paragraphs uninformative, and this much clearer (but I am not really a web developer).

thanks Rob! i agree with the other that parts of your reply should be included in the FAST homepage

For code examples on HN, indent code 4 spaces.

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.

maybe hook us up with a writeup later? im interested in whatever you find out.

Sure I do write ups on linkedin follow me there: https://www.linkedin.com/in/ramonck

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.

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.

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

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?

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.

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?

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.

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.

Your comment makes absolutely no sense. Sciter is not a browser engine nor it tries to sell itself as a browser engine light. Sciter just happens to use dialects that are similar to CSS and JS sort of what XAML is to WPF or what QML is to QT.

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/

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

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.

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

https://postimg.cc/N509Z8Kr

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

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.

The project homepage is easier to understand than text: 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

For a non developer like me,

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?

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

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

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

The slider performs terribly on Android Chrome

On mobile Firefox the side menu is quite janky

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

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

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

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

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

      render() {
        return html`
          <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

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

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.

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

And I was thinking they bought this for $1.3bn in 2008 : https://searchengineland.com/microsoft-to-buy-fast-search-fo...

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

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

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.

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

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

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.

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

It's slow and unusable, 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

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.

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.

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

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.

That is some seriously cheesy but brilliant copywriting!

Slider doesn't work for me on Chrome Android.

It looks like alternative for https://material.io/

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

Apples and oranges. A design system is a collection of components that fit a certain look-and-feel; it is not tied to the implementation so it can be implemented by React, Angular, or VueJS: https://www.fast.design/docs/integrations/introduction

My understanding is this is closer to something like Bootstrap but using Web Components (or material-ui if you want a react component set) than it is to React itself.

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.

Appears to be a custom HTML elements (and some helper libraries) that you can plugin to vanilla, Vue, React, etc?

Well, the focus on Web Components is good for cross-compatibility, but means not being able to do the full static analysis of components that you can do with JSX or equivalents.

It doesn't.

It's more comparable to something like Google Polymer[0]

They can be used in conjunction with eachother[1][2], so I'd imagine the same/similar would be possible with Fast.

[0] https://en.wikipedia.org/wiki/Polymer_(library)

[1] https://www.digitalocean.com/community/tutorials/vuejs-vue-i...

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

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

From this page:

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.

At first glance it seems the fast-components are akin to material components and fast-foundation kinda reminds of angular cdk

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.

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

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

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

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.

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

On a side note, is Microsoft acquiring Tik Tok?

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

Why not? It's incredibly popular.

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.

Not responsive, in 2020 ?

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

I don't think that was the objetive of Web Components at all but to really create open standards around what React started a long time ago. Server-side rendering is not going away ever, there will always be a way to optimize things and to do tree-shaking and all so don't think that a new technology replaces everything else the rest of the eco-system will still remain with a clear purpose. You can do a small little project without builds and all but every "real" project will still need a build process in the end this concept was inherited from Continuous Integration and it's not going away.

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.

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.

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

If you use React, you might like Rebass (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), 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.

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

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.

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

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.

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?

Reply on news.ycombinator.com