I appreciate how the author compares it to writing Stimulus components and it sounds like there's little real benefit for the day-to-day dev, unless you're doing something fancy and highly reusable in JS.
> This is used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names going forward).
So things that work today without a dash might break in the future if <badge>, for example, becomes a standard HTML element.
That's only a hard requirement if you're creating a web component. Unknown elements are treated as inline elements by default, so if you're just using it for styling and using global attributes (even JS ones like onclick), you can use whatever tags you want. You only run into trouble when you start doing more advanced stuff with your non-standard elements.
imho the vaunted readability of custom elements has long been available with haml, with added readability by virtue of the indentation rules replacing closing tags. Not sure why it didn't really gain much traction, maybe the pre-processing is problematic when there's no server-side framework like Rails?
Developers like to copy/paste UI component example HTML from Tailwind/Bootstrap documentation, they like predictability/portability. They don't want a project that's half HTML and half HAML...ie, Vue/React using HTML/JSX vs 50% of Rails views in HAML, 50% old ones in HTML.
Just like how using Vanilla JS is much smoother and reliable than using the latest wrapper framework.
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation.
I think it's worse than, e.g., typical yaml files because the nesting is deeper.
never knew you could do css selectors on custom elements! does seem like syntactical sugar over classes. I do like the current trend with tailwind: style with markup using smaller components. But maybe there is something here with so many components being just styles...
Great article, however using raw custom elements goes IMO against Rails' spirit, as it is way too low level, and requires lots of boilerplate to get working.
Stimulus is in the sweet spot for that. Both lean (as opposed to bloated), and not too low level, so that using it does not lead to verbose code. It is one of the very few JS frameworks that IMO do not contribute to JS proliferation, but actually work to reduce the amount of JS written.
This is actually a very nice primer on how to build custom elements even if you don't use Rails.
I appreciate how the author compares it to writing Stimulus components and it sounds like there's little real benefit for the day-to-day dev, unless you're doing something fancy and highly reusable in JS.
FWIW you don't even need to define custom elements to use them: https://html3000.dev/
This website violates the rule that all custom elements must have a dash in the tag name.
https://html.spec.whatwg.org/multipage/custom-elements.html#...
> This is used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names going forward).
So things that work today without a dash might break in the future if <badge>, for example, becomes a standard HTML element.
Indeed. And since a lot of web is fire and forget, one day you might get a surprise.
That's only a hard requirement if you're creating a web component. Unknown elements are treated as inline elements by default, so if you're just using it for styling and using global attributes (even JS ones like onclick), you can use whatever tags you want. You only run into trouble when you start doing more advanced stuff with your non-standard elements.
You can still run into problems if the standard one day decides to actually give your custom tag any semantics and default styles.
imho the vaunted readability of custom elements has long been available with haml, with added readability by virtue of the indentation rules replacing closing tags. Not sure why it didn't really gain much traction, maybe the pre-processing is problematic when there's no server-side framework like Rails?
Either everyone uses HAML or no one does IMO.
Developers like to copy/paste UI component example HTML from Tailwind/Bootstrap documentation, they like predictability/portability. They don't want a project that's half HTML and half HAML...ie, Vue/React using HTML/JSX vs 50% of Rails views in HAML, 50% old ones in HTML.
Just like how using Vanilla JS is much smoother and reliable than using the latest wrapper framework.
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation.
I think it's worse than, e.g., typical yaml files because the nesting is deeper.
never knew you could do css selectors on custom elements! does seem like syntactical sugar over classes. I do like the current trend with tailwind: style with markup using smaller components. But maybe there is something here with so many components being just styles...
I really like custom elements, I wish they were more popular.
Great article, however using raw custom elements goes IMO against Rails' spirit, as it is way too low level, and requires lots of boilerplate to get working.
Stimulus is in the sweet spot for that. Both lean (as opposed to bloated), and not too low level, so that using it does not lead to verbose code. It is one of the very few JS frameworks that IMO do not contribute to JS proliferation, but actually work to reduce the amount of JS written.
[dead]
[dead]