EisenbergEffect

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

GitHub has corrected the issue, restoring our organization access and web site. They have reported that the org was flagged as part of an automated process. The flagging occurred because we have two external contributors from Iran (non GH org members). They told me that there should have been a warning and they are investigating why that didn't happen. The CEO of GitHub also reached out personally to try to speedily rectify the situation.

I'm the project lead for Aurelia, so I'd like to take a minute to address a few of the points from the linked post. Jeff makes some valid points, for sure. However, there is also some inaccurate information and a healthy dose of subjectivity.

* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now. * TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript. * Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did. * Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like. * Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented. * Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"? * Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly. * Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.

Now, we realize that Aurelia is far from perfect and that we always have plenty of work to do and things to improve on. I and my team of about 30 engineers have poured countless hours, worth millions of engineering dollars into Aurelia. We don't have the brand power of Google or Facebook. Who does? So, if you write this type of comparison post, please be careful to validate the information and maybe even reach out to the project contributors for feedback. Posts like this can cast all our work in an overly-negative light, particularly for those who haven't encountered Aurelia before and don't know better. We're all working for the same thing here and want to help each other and our businesses succeed. I always take feedback like this to heart and I and my team will continue to work hard to make Aurelia better every day. We invite everyone to join our community and contribute together to making Aurelia the best platform for modern web apps.

I should also state that we do use HTML Imports, for view loading, which is part of Web Components and we also use HTML Template Element, which is part of Web Components...and you can optionally use Shadow DOM...which is part of Web Components. What we don't do is use document.registerElement as part of our own custom element implementation because we would give up too much control over critical aspects of binding and resource loading.

So, we use 3/4 of the spec. One of the APIs we don't use...but we will allow you to export your Aurelia elements to a document.register form for v1.

Yes. We support web components. That doesn't mean we are built with Web Components at the core. The WC specs have a number of design flaws, in my opinion, and they don't work as efficiently as possible with databinding solutions, etc. I can expound more on this in a blog post. But our binding system works fine with Web Components. So, you can import a Web Component and use it inside a view with databinding and even attach additional behaviors to it without any problems.

Web Components are not yet a standard. They are primarily being pushed by Google without taking much feedback from other vendors. I spent almost a year working with building frameworks around them...and decided there was no real advantage to using document.registerElement for an Application Framework.

Again, if you want to build Web Components or use Polymer...that is fine. You can use that with Aurelia. But Aurelia's custom elements aren't built that way.

As a side note, Aurelia will be able to "export" its custom elements to Web Components. So, before we hit v1 you will be able to do that and then take an Aurelia Web Component into a non-Aurelia app and use it, the same way you would use a Polymer element. We haven't done that yet because we are focused on the application experience first and foremost.