📮 New post:
The Good, The Bad, The Web Components
https://www.zachleat.com/web/good-bad-web-components/
A full crash course on the state of web components, where they fit in JavaScript frameworks landscape, and how to make use of them moving forward!
Zach Leatherman 5050 replies 7575 likes3838 reposts Original on MastodonOriginal on BlueskyAlso posted to Bluesky.
50 replies
-
@khalidabuhakmeh we do what we must 😂
@zachleat Great post. I’d like to see the aspirational idea you have come to fruition.
The biggest issue with web component approaches, even the good ones like WebC, is that they still require a build step. This limits them to folks who are comfortable with JS build chains.
I want to spread the love to Django, ASP.NET, Laravel, Rails, and all future web frameworks.
@khalidabuhakmeh 100% agree—and I’m hopeful we’ll get there!
@khalidabuhakmeh @zachleat the aspirational ideal is literally how Enhance works. You define your template in a function and then it is expanded into light DOM custom elements by the SSR piece.
We’d love to bring Enhance SSR to other languages so if you are interested in submitting PR’s we’d be happy to work on that with you.
@macdonst @khalidabuhakmeh ah to be clear I mean that I want the aspirational idea to be a first-party platform feature.
@zachleat @khalidabuhakmeh Same! I think we need to rally around declarative custom elements since it is too late to change the web component apis.
@khalidabuhakmeh Is there no render step on the server you can tap into?
@macdonst @khalidabuhakmeh @zachleat kinda weirdly absent again. :/
@brianleroux @macdonst @khalidabuhakmeh this is the same talk I gave last year, Enhance is in the call-to-action section: https://www.zachleat.com/web/good-bad-web-components/#framework-tension
@khalidabuhakmeh @brianleroux @zachleat he missed the Enhance mentions on his read-through. I already mentioned it to him.
@macdonst @khalidabuhakmeh @zachleat yea sorry, missed the single bullet footnote mention there
@brianleroux @macdonst @khalidabuhakmeh everything okay?
I do try to mention Enhance whenever I talk about WebC e.g. https://github.com/11ty/webc#similar-works
I don’t see any mentions of WebC on enhance.dev though (which is fine!)—but I’m sensing a little passive aggressiveness here which in the larger picture seems a little unfair (same team!)
@zachleat @macdonst @khalidabuhakmeh not super great tbh. thx! sorry for making you feel that way. (we do mention 11ty a lot on our blog and even had support for it in Enhance pre-webc)
@brianleroux @macdonst @khalidabuhakmeh dang, man—really sorry to hear it.
If y’all want—we could rekindle our collab—I’d love to get Enhance SSR as a plugin for 11ty!
@zachleat @macdonst @khalidabuhakmeh we figured it was less confusing but if you don't think so I'm into it. we should have some ssg option to point folks at.
@macdonst @khalidabuhakmeh @zachleat Could you give me a hint how this could work, as the whole definition of the Web Component is still... JS? Wouldn't this expect something like a... JS to PHP transpiler or something? Or do I have a misconception here?
@mariohamann @khalidabuhakmeh @zachleat what we do with Enhance is expand the custom element on the server and send it down to the browser so it arrives as working HTML. Then the script tag is loaded with "enhances" the custom element to a full web component with the call to customElement.define(). We see two benefits to this approach:
1/2
@mariohamann @khalidabuhakmeh @zachleat
1. A lot of components don't need interactivity so client side rendering is overkill for them. These are the components that never upgrade to full web components.
2. Working HTML arrives on the client so if JS doesn't work for some reason your app still works.We'd love to port the SSR portion to other languages someday. So it would be deciding on a way to write custom element templates in PHP and writing the SSR package in PHP or some cross language.
@macdonst @khalidabuhakmeh @zachleat So something like an enhance/custom-element-php composer package, which allows to describe render etc. with PHP, having some kind of feature parity regarding slots, attributes etc. Of course this wouldn't allow to hydrate it on the client, but the templating part could somehow work. Do I get this right?
I love the possibility with enhance to decide to render on server or client... that would go away. 🫤
@mariohamann I don't think it would as you would just load the script tag to the web component in your PHP page to get client side rendering.
@macdonst Hm, but if the templating is using PHP on server side and JS on client side, these are actually two components. From their usage (tags with attributes and slots), of course they could behave the same, but the initial implementation effort is doubled.
My personal aim is more to write components once and then re-use them in every stack (PHP, JS, Plain HTML) or target (client, server).
@mariohamann in the case of other languages we'd have to separate the template from the JS side of things. That's something we do support already.
I think you have a very worthy goal there.
@khalidabuhakmeh Won't lie... it's what keeps me from investigating them any further than "the theory". I don't want node/npm on a live server. I have and trust PHP/Composer. Mostly because those are already my dependencies, and I don't want new ones with new exposure surfaces. @zachleat
@mattwilcox @khalidabuhakmeh sure, but the repetition issue can be “poorly” hacked together via other mechanisms in your server-rendered stack: https://www.zachleat.com/web/webc-in-eleventy/#a-history-of-component-like-things (PHP include comes to mind)
But, yeah. It’s interesting that non-JS server environments are almost their own slower pace layer in web development. (Ref to @adactio.com’s https://adactio.com/journal/19104)
@zachleat I actually find that slower pace a feature not a bug, is the thing. I *trust* PHP much more than I do Node. I *trust* Composer more than I do npm.
Is that rational? No and yes. I'm sure there are shoddy packages and all the same vectors for bad actors in Composer packages as for npm... but one has the reuptation of dodgy packages littered with dependencies, and actively abused ones, and the other doesn't.
@zachleat (Which is why I'm happy playing with 11ty locally, but do not use node on live servers) @khalidabuhakmeh @adactio.com
@mattwilcox @zachleat 😅 Yeah, I wouldn't dream of it. Any viable use of a Web Component framework or SSR with an SSR stack (Laravel and ASP.NET Core) would have to be a build step.
@mattwilcox @zachleat Welp… I got nerd-sniped. I hope you are happy now! #dotnet #aspnetcore
@khalidabuhakmeh @mattwilcox ahaha 🏆
@zachleat @mattwilcox There is a second level here that I’m not ready to go down, but I’ll write a blog post for the adventurous among us.
But I have to ask. Can the WebC toolchain process HTML fragments one at a time?
@khalidabuhakmeh @mattwilcox For sure, it can parse fragments, that’s the example on the README: https://github.com/11ty/webc?tab=readme-ov-file#javascript-api
Might be worth looking at the test suite for more examples too:
https://github.com/11ty/webc/blob/main/test/parserTest.js@zachleat @mattwilcox Well… I was hoping you would say no. 😅
I might have to implement this then.
@khalidabuhakmeh @mattwilcox @zachleat Khalid gave me a walk-through on this yesterday. His nerd-snipe then nerd-sniped me. Interesting where this pattern could go next.
@khalidabuhakmeh @mattwilcox @zachleat My current explorations into this have landed on creating isomorphic templates using a "universal template language" like Liquid
(Most languages seem to support Liquid in some form, but isn't quite as ubiquitous as Mustache.)
Dotnet has "fluid" I found: https://github.com/sebastienros/fluid
I come from Rails land so my ideal SSR would look like this:
<%= liquid_render "my-component", { attributes: {}} %>
The hardest part is having predefined "partials" for expansion
@khalidabuhakmeh @mattwilcox @zachleat The current prototype I have does have a build step by the "library" of components to produce a `.liquid` file on disk, but for first-party components you author, you can easily have them live in a "definitions" file, and directly read the template into your component and expand it.
It's a hard problem and why I feel like the browser having a first party template language could alleviate a lot of this. Though I'm sure it comes with other concerns.
@konnorrogers @khalidabuhakmeh @mattwilcox @zachleat So exciting to see so many people raving on this topic.
I enjoy Enhance Custom Element in combination with Enhance SSR: The first allows to use slots without (!) ShadowDOM, the second makes it feel like a universal templating engine which is super close to the platform.
I'm experimenting with doing SSR in combination with Laravel and Lambda/Node server - blog post will follow!
@nrk9819 thank you! 🙌
@zachleat Loved the talk when I first saw it and I’m really glad there’s a written version of it 🙌🏾
@hasanhaja it only took me 7 or 8 months to get it on the web site 😅 (thank you!)
I’m happy it’s there now!
If it’s any consolation, I’ve been working on part 2 of my web components fundamentals post for nearly 6 months now… actually the problem is that I haven’t been working on it 😅 Coincidentally, I picked it up again this morning and have made good progress on it. Just need to stop procrastinating and finally finish it
I'm not super keen on the DSD (Declarative Shadow DOM) API because of the fact you have to define the template for each component instance, but the DCE (Declarative Custom Elements) seems promising for scalably SSRing custom elements.
@zachleat Great post! I'm not super keen on the DSD (Declarative Shadow DOM) API because of the fact you have to define the template for each component instance, but the DCE (Declarative Custom Elements) API seems promising for scalably SSRing custom elements.
@stuffbreaker thanks! Yeah I’m hoping that can be a solved problem!
-
