61 Followers
97 Following
72 Posts
Web Developer

@zzt @fasterandworse
I've been kind of fascinated by similar ideas recently after reaching peak JS weariness. Would love to see what you're working on too.

IMO the approach to rendering used in enhance-ssr strikes a really nice balance (nicely written up by @ryanbethel here https://begin.com/blog/posts/2024-05-03-portable-ssr-components).

It's relatively straightforward to port to other languages as long as you can lay your hands on a HTML parser. See e.g. https://github.com/DavidGregory084/ssr-java which uses https://jsoup.org/ to do all of the work.

Portable Server Rendered Web Components with Enhance SSR — Begin Blog

Developers want to build sites with custom components, companies want to reuse those components on all their sites, users want those sites to be fast, and everyone wants them to be stable.

Begin

For context I have written a lot about how I think SSR for WC's can work. It is all about the constraints you chose for the components. If you pick the right ones it makes SSR easier and you can share components between many frameworks and backend languages.

https://begin.com/blog/posts/2024-05-03-portable-ssr-components

Portable Server Rendered Web Components with Enhance SSR — Begin Blog

Developers want to build sites with custom components, companies want to reuse those components on all their sites, users want those sites to be fast, and everyone wants them to be stable.

Begin

There is no way to reliably SSR *generic* web components. WC specs are browser specs. They define behavior that happens in a browser. You *could* perfectly SSR them by rendering in a headless browser on the server. That is slow. But worse you end up with a DOM, not a document. You have to peal an HTML document out of that DOM and send it to the client. And then send instructions to rewire any event listeners and data that lived in JS.

To reliably SSR WC's they need to be reliably constrained.

Another useful constraint is that HTML attributes are strings only. I know objects for React props are nice, but that decision massively complicates SSR. Better to stick to strings as attributes and keep the objects in JS. You can still do all the things you want or need to do by passing complex data in other ways if needed. But following the grain of the platform by keeping attributes strings makes life easier in the end.
You can read more about the Enhance approach to SSR and how it enables portable components (https://begin.com/blog/posts/2024-05-03-portable-ssr-components). Or if thats too long just read the "how it works" section (https://begin.com/blog/posts/2024-05-03-portable-ssr-components#how-does-it-work%3F). I really hope others will copy this code or just copy the algorithm with similar constraints. I think this is a win for the web. Try it out.
Portable Server Rendered Web Components with Enhance SSR — Begin Blog

Developers want to build sites with custom components, companies want to reuse those components on all their sites, users want those sites to be fast, and everyone wants them to be stable.

Begin
The key is respecting the server/client boundary with a few constraints. The most important of these constraints is that components on the server are defined as a pure function of state that returns plain HTML. We can include event listeners and all kinds of client behavior, but that happens on the client side of the boundary. With this and a few other constraints the problem of SSR WC becomes much easier.
Enhance SSR is only about 200 lines of code. It server renders WC's. It is not magic. The simple algorithm is easily reproducible. I wish more people would copy it (https://begin.com/blog/posts/2024-05-03-portable-ssr-components#how-does-it-work%3F). @kristoferjoseph wrote the original (https://github.com/enhance-dev/enhance-ssr) and I ported it to PHP (https://github.com/enhance-dev/enhance-ssr-php). We even have a WASM version that has examples in a dozen languages (https://begin.com/blog/posts/2024-04-08-introducing-enhance-wasm). And a Wordpress plugin (https://github.com/enhance-dev/enhance-wordpress-plugin)
Portable Server Rendered Web Components with Enhance SSR — Begin Blog

Developers want to build sites with custom components, companies want to reuse those components on all their sites, users want those sites to be fast, and everyone wants them to be stable.

Begin
Server rendering Web Components is not hard. The problem is WC specs define client side (browser only) behavior like `connectedCallback`. SSR happens on the server so it can only do server things. On the server a web page is just a string. It does not include a DOM with `connectedCallback`. If a WC renders its content in `connectedCallback`(or by other clientside methods) it is difficult to SSR. This is why Lit SSR has been in experimental limbo for so long. The assumptions are baked in already.

I still have all of these issues with WordPress and portable patterns: https://cloudfour.com/thinks/wordpress-blocks-portable-patterns-and-pain-points/

But, it’s really heartening to see what the @enhance_dev project is doing to break down those barriers, as detailed here by @ryanbethel: https://begin.com/blog/posts/2024-05-03-portable-ssr-components

(I’ve updated my article to include a link.)

#WordPress #PHP #WebComponents #WebDev

WordPress Blocks, Portable Patterns and Pain Points

The block editor is super powerful, but how do we bring in dozens or hundreds of external HTML and CSS patterns?

Cloud Four

I thought I would take up the challenge of getting @enhance_dev #WASM working with #aspnetcore with the ability to SSR web components directly into the request pipeline.

Yep... it works. TagHelpers make this nice and natural part of the #dotnet web stack. #webcomponents #web #javascript

Update: You can try it out for yourself at this #GitHub repo. https://github.com/khalidabuhakmeh/EnhanceWebComponents

GitHub - khalidabuhakmeh/EnhanceWebComponents: Use Enhance WASM to render server-side web components in Razor

Use Enhance WASM to render server-side web components in Razor - khalidabuhakmeh/EnhanceWebComponents

GitHub