What is the suggested approach for using uhtml on both the server and client?

[nickchomey]

I see that the uhtml-ssr and ucontent libraries are available for SSR templating, but they seem to have not received any updates in 2 and 4 years, respectively. That doesn't mean that they don't work, but I'm curious how they compare to uhtml which has been actively developed since then? Also should we be using uhtml-ssr or ucontent for SSR templating?

Moreover, are there any special considerations to take into account if we want to use one of those for SSR and use (ideally) the exact same code/templates with uhtml in the browser?

Thanks!

[WebReflection]

Currently uhtml/ssr is the new way to deliver server templates but it cannot compete in raw performance with uhtml-ssr because:

• uhtml/ssr uses uhtml/dom which is an even lighter version of linkedom but it still lacks hydration which will come at some point
• uhtml-ssr produces only strings, hence it has little-close-to-none overhead when vomiting out HTML
• ucontent needs some dependency update but I think it's still a valid/handy option that is more focused on SSR only, not necessarily to have feature parity with uhtml (because of minification and stuff that won't land directly in uhtml)

Arguably, ucontent for SSR only is probably the best way to go but if you are looking for 99% interop (events and hydration are still missing) uhtml/ssr would be my pick.

I promise I won't create any other library and all of these helped me to reach stability and maturity with uhtml itself but there's something missing for the BE story that one day I'll fix ... I don't have capacity these days though and free time to work on this is unfortunately too little.

[nickchomey]

Thanks very much for confirming that all of those are valid options (and also for making me aware of uhtml/ssr)! I'll give them a try to see which will suit my needs best.

[nickchomey]

Apologies if I should ask this elsewhere, but it seems relevant enough here:

What I'd now like to do is

1. fetch some html pages
2. parse them
3. Extract some particular nodes and replace parts of them with uhtml template literal placeholders
4. Save those as js scripta that can then be rendered later both SSR and in the browser

I'm curious which of your libraries you would suggest for this?

Is Linkedom the most appropriate for the dom parsing, extraction and manipulation? And then one of the above options for the actual SSR rendering of the templates? And then normal uhtml in the browser, with the same js script templates?

Thanks!

[drschwabe]

I made a helper lib to use uhtml-ssr on both client and server you might find useful:

const { html, render } = require('html-template-utils') 

With this module (npm install html-template-utils or https://github.com/drschwabe/html-template-utils/blob/master/html-template-utils.js#L19-L28 you can also just copy my code there) they will work the same both in NodeJS and the browser.

This lets you accomplish your goal of using the same exact templates client and server.

For browser I'm bundling with Rollup with CommonJS plugin this let's you use exact same templates and same require line too.

I tried mixing uhtml-ssr and uhtml v4 but found there are small discreptancies that will end up getting rendered differently in server and client. I also tried using the uhtml v4 dom export in an effort to bring uhtml4 rendering the other way; serverside - it does work however I became annoyed at having to pass along the dom context to all of the many modules I may have in a given app that use {html, render} functions (you can't just require them when using the uhtml dom object you now need to write an init function for every module)

The downside is that uhtml-ssr (and this implementation of render which just bakes it to a string and replaces innerHTML) is not as performant as uhtml4 in client and you will trash your form fields ie-if you are re-rendering a form this won't handle forms cleanly like uhtml4 you will need to work/hackaround that limitation.

As for your specific example use case it sounds a bit wonky, it sounds like maybe you should write a normal template from scratch and just render uhtml templates for the dynamic parts.