Good question. Parts are elements that originate in the Web Component whereas slots are elements provided or "slotted in" by the developer (or by the app or however you want to think of it). In the case of the dialog, I want the developer to be able to provide the close button themself and wire up whatever logic or event handlers make sense for this particular dialog. They provided the button, I only defined a place for it to go, that's a slot. However, there's some nuance here in the case of dialog, isn't there? I technically probably shouldn't go for a slot in <dialog> because slots are for Web Components and <dialog> is a native element. I could just say "put a button in the dialog and wire it up", but that's just not enough for a good design system. I need to control a few details about that button, so I need some way of defining an API for it. Slots work well for this, so that's what I did. (there's some nuanced details that explain why, but too tired to type it all out right now) Although I'm using slots in a way that's not exactly technically correct. But then again the spec doesn't say not it and it works well for a number of reasons so I do it.

Thanks Kurt! Let me clarify the most important thing first: I am not sure what the right mix of custom tags, slots, attributes, classes, etc. is in some cases and I don't want to confuse people either by having some components be tags, others as attributes or classes In all cases TAC says components MUST be defined with tags. Remember, the T is for tags. Tag comes first. Button starts with <button> , table starts with <table> , dialog starts with <dialog> , icon starts with <x-icon> , badge starts with <x-badge> . So, as you've seen already a button would then of course start with <button> . Then your different kinds of buttons would be specified through an attribute. In all my years of doing this I've seen such an attribute named ord (ordinal, which has strong semantics if using "primary", "secondary", "tertiary" language) or kind or variant . In the case of the site header example, I would agree <x-siteheader role="header"> is probably like the ideal application of the TAC methodology, but WCAG strongly discourages the use of roles (or any ARIA feature) whenever you're able to use the equivalent HTML feature. So in the case of a site header component defining a custom tag like x-siteheader and then defining its relationship with a child <header> I think is technically a bit more correct according to WCAG. But again, I would agree <x-siteheader role="header"> is better :) Same goes for your x-card example: <x-card role="article"> seems great, but technically not the best way according to WCAG. Your second approach with a plain <article> and <x-card> inside I think is great too. Let article be an article, which is just a block-level element like div but with better semantics, then get the card styles and features from your actual card component. One more example that might help: dialog. In one of the design systems that I've built we started with the raw <dialog> element (of course!) and simply styled it according to the company design language. In addition to just the plain dialog tag , we defined a slot for the dialog's basic close button (the [ X ] button positioned to the top-right corner) and a kind attribute that is used to set the dialog as a "drawer" which makes the dialog slide in and out like other similar drawer components. We also defined a rule for an optional <header> child that gets some minor styling and improves structure and semantics and similarly a <footer> which we said was required for the dialog's action button(s), like cancel and/or save buttons. Hopefully that demonstrates how the component is always defined with a tag, then using the power of HTML primitives like attributes, slots, and parent and child and sibling relationships we can come up with some very capable components with really good API!

Awesome! Thanks for doing that Chanhee Kim

Thanks. Yes feel free to do that

Yes, the TAC methodology actually requires these theme elements (aka design tokens) to be implemented as CSS variables (aka CSS Custom Properties). There's a section on that here https://jordanbrennan.hashnode.dev/tac-a-new-css-methodology#heading-scaling-projects-with-tac In practice, these design tokens are shared by every bit of the UI, which ensures the overall theme you're referring to: Components like Badge and Alert use them Utility classes use them Your app would also use them for any additional custom styling Every design token is likely to have a utility class or more. Color design tokens for example would not only be used internally by the components, but also for utility classes like text color, background color, border color, etc. Same goes for typography tokens, spacing tokens, and others. Would definitely do less complex utility classes and use more of them to style something. The methodology states that utility classes should be single-purpose like .flex is just display: flex . Very much the same pattern as Tailwind.

Good read. You have legit writing talent! It's worth noting TS influencers (I hate that that's now a thing in the engineering world) who know nothing about Turbo were freaking out creating internet drama and trashing DHH all while not realizing removing TS changed nothing for the library's users - you don't interface with Turbo through JavaScript. Turbo API is HTML. Removing TS was strictly to make the maintainer's job easier. Your article... These arguments in support of TS are nothing new and I'm not suggesting they're wrong or bad, but there's strong counter-arguments to these that are universally ignored by folks who feel a strong affinity toward TS. They are: Yes, types already exist in JavaScript - let's use them! And create your own and use those too: if (color instanceof Color) setPaintBrush(color); There are dozens of features built into JavaScript that developers are unfamiliar with and don't use because they have been taught you need TS to do those kinds of things Tests are still 100% necessary. "But it compiled" is a bit of a joke even among strongly typed language communities like Java. It is a common misunderstanding of junior engineers that compiled = no bugs. TS hype reinforces this misunderstanding (not suggesting your article does that, but there's massive amounts of unbridled TS hype out there misleading developers) Intellisense and autocomplete is as good and often better with JSDoc I say better because all the TS projects I have worked on have no comments at all. Developers mistakenly assume typedefs and interfaces tell other developers everything they'll need to know. That's frequently not the case. In healthy codebases TS typedefs ironically have JSDoc comments to provide helpful and necessary information that TS can't, which is shown by intellisense Intellisense and autocomplete is powered by the same ts engine built into the IDE so the developer experience with JSDoc is the same as TS - the UI in my IDE is identical between the two You get type warnings with JSDoc too. Again, it's powered by the same ts engine built into the IDE TS adds bloat to your app bundle TS requires a build step and as such slows down your builds TS requires ongoing configuration and updates, JSDoc requires nothing whatsoever - it's just vanilla JavaScript comments made magical by the IDE TS makes zero guarantees about runtime safety, which is what really matters TS can do nothing about more common bugs like CSS and logical errors I tracked bugs for almost 3 years on a medium-sized app and out of 68 (I think that was the total) only 1 could have been prevented with TS We need to stop getting emotionally attached to technology. I'm guilty of this too🫣 It's weakening the software engineering culture and it moves important objective facts off the table

I've removed TS from projects before and never looked back. All the biggest benefits can be had with JSDoc (types documentation, intellisense and code-completion, IDE console warnings), but with zero costs (there's nothing to install and configure, never any obscure roadblocks, source code is valid JavaScript that doesn't need to be compiled first, app bundle is free of all the extraneous stuff from the compiler). It's critical to remember that TS guarantees nothing about runtime safety, you still have to write defensive code no matter how much TS syntax you smear all over your codebase.

You should find articles about the costs as well. TypeScript is a tradeoff and developers need to be mindful and purposeful about the tradeoffs they make.

For the beginner who might be confused, these actually have nothing to do with TypeScript. These are all native data structures built into JavaScript.

Dang I'm about to join you in the developers old folks home. I'm getting old!