Back

@zachleat The “h-i” slide cracks me up.

@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!

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

@macdonst @zachleat I work with #dotnet and I don't expect MS to give folks a build-step that would allow you to process HTML before the final artifacts are built any time soon :(

There is a way to possibly do it, but I think it wouldn't be ideal.

@khalidabuhakmeh Is there no render step on the server you can tap into?

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

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

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

@khalidabuhakmeh @adactio.com

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