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