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

<record scratch>

Different, incompatible front-end frameworks?

So like, this shit is magic that will let me streamline components between my Oceania team's WordPress and my German team's Magento frontends?

And I don't have to learn any new paradigm to make this work?

I don't have to use their specific, custom HTML in order to leverage it? https://www.fast.design/docs/components/accordion

SWEET! (/s)

Come on. We'd have to re-write everything to use this library specifically, and train our teams.

Honestly this is to me just another bunch of shit that will get tacked into projects and have to be known and supported, because some sprightly young thing will convince management this is the panacea to seemingly redundant development work.

What's the actual selling point here.

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.

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

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.

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

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

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.

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.

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