I keep hitting this: How to add reactive templating to part of the page in a way that doesn't drive a steamroller through the DOM? @vuejs.org is my current go-to, but it recreates elements, which doesn't play nice with libraries not made for it and makes it fail badly when there's an error. [1/3]
I'd give github.com/jorgebucaran... a shot. It has reactive templating, it's client side (no build step needed!), its DOM diffing is very efficient, and your data (= state) stays in JS. I've been using it for quite a few years, and it plays very nicely with its neighbors.
would Astro work for this? you can set up islands with any framework. it still “steamrolls” but only the island you let it, while leaving the rest of the page untouched
I remember checking out ArrowJS , which checks some of your requirements, but not sure if all. Doesn’t look like it is actively maintained either. github.com/justin-schro...
this is so slick. i love it! thanks for sharing!
Else qwik is actually pretty amazing, it renders entirely to html and reactivity does granular dom updates of attributes, it leaves html comments for this. If you don’t get too funky in for loops and do everything with html attributes there’s no jsx loaded on the page.
Lol overlooked the part you said no alpine. But but but alpine lets you script in js , Alpine.data({…})
Alpine? As far as I know it’s the follow up for petite vue
I've had something like this development for a long time, but never bothered to push forward github.com/Munawwar/Pep... Check hydrate: true mode. Plus if you add is="component" attribute to an element then the diff logic skips the inner part of the element, meaning it plays nice with 3p libraries
These requirements remind me of the Interactivity API that's built into WordPress on top of Preact. I love the concept. But I'm afraid there's no “standalone” version of this available. Happy to learn, though, that I'm wrong on this.
It looks like that technology can be used outside of WordPress. github.com/WordPress/gu...
Here's a demo: stackblitz.com/edit/iapi-no... Haven't seen any other approach yet that combines server-rendered HTML + virtual DOM so nicely without any JS-based view definition.
Combining lighterhtml with something like signals is super light and easy. It's what I did for Minne: github.com/JimSchofield... You don't have to go the web component route
I like how we solved all this with enhance but I ack it's gotta be bought into enhance.dev/docs/convent...
Doesn't require to be initially rendered by a server. But it will work there too. And because of how we built it the server render part can happen in any runtime not just node.
Possibly HTMX to avoid the rendering entire components?
Ugh rerendering not the rendering...
[2/3] Petite Vue was close, but - is unmaintained - assumes this means I *also* want my data in the markup, which makes no sense - assumes this means I need tiny filesize, which is nice but orthogonal and makes it very underpowered Is there anything else in this area that is actively maintained?
[3/3] Reqs: - Reactive templating, not managing render() calls, so no React - Client-side, so no Svelte - Not recreate DOM when not needed (ok for loops), so it plays nicely with other stuff, so no lit-html - Data in JS, so no Alpine.js Is there anything? Am I alone in needing this?
You may be interested in a library I write that is made to be very DOM friendly. You may not, it is very poorly documented. I'm working on that. github.com/stephband/li... The entry point is inside which all tags that access a ${ data } object ...
... cause the renderer to react to mutations of the data object. I use it in production on swisstypefaces.com and many other sites. If you're interested I will make a concerted effort to document it this week, at stephen.band/literal/
(half the examples on that documentation page are just placeholders at the moment, not very useful)
I’m curious about “Data in JS, so no Alpine.js” With Alpine, data does not need to be included in markup; you can inject data into Alpine’s scope from external JS. This makes your template reactive without mutating data in the global scope. Does your use case require the global scope to be reactive?
Doesn't Alpine allow you to define your data in JS? Unless I misunderstood what you meant. alpinejs.dev/globals/alpi...
Oh that's interesting, thanks! I'll take another look at Alpine.
Is svelte not client side? I'm genuinely out of the loop, last I used it you needed sapper for SSR, I'm vaguely aware of sveltekit, but not familiar
svelte is the templating library that works exclusively client side, svelte kit is the additional routing framework
Yeah that's my impression, I was wondering if newer versions of svelte only supported sveltekit, but I just went to check the docs and seems like it's just as before, and instead of sapper we use sveltekit
yeah youre correct here
bsky.app/profile/lea....
Last I checked @svelte.dev did not have a client-side version, I believe it goes against the philosophy of the tool completely.
Going through the new tutorials I believe the section on basic svelte is client side only, it'll compile into js which you can serve statically. you can also create a basic svelte project with vite, not sveltekit (apologies in advance if I'm over explaining, wanna make sure we're on the same page)
bsky.app/profile/lea.... (also, ❤️ at the "apologies if I'm over explaining")
What do you mean it doesn't have a client side version? Svelte is primarily a client side UI framework, SSR is baked in as a first class citizen and you can get it easily with sveltekit but it absolutely has client side reactivity
bsky.app/profile/lea....
I would be interested to know how you ended up with this impression so that we can fix it!
Reading the other responses, I see where the confusion may be: By client-side only I was referring to not requiring a build step, nothing to do with routing. AFAIK SSR is part of the core philosophy of the project, which is counter to anything without a build step. Is that not the case?
i would say the core philosphy of svelte (sans kit) is precompilation into vanilla js as opposed to say a superset like jsx
You're conflating separate things — whether something requires a build step is nothing to do with whether it works client-side. Routing is a separate consideration altogether. We encourage SSR (via SvelteKit) because that's the right way to build resilient, performant apps. Not required though!
It's not totally clear what you're asking for — should the initial DOM also serve as the reactive template? Because that feels impossible. Is the template separate? Which is the source of truth? You're asking for _hydration_, but I'm not aware of any systems that can hydrate HTML they didn't create
Precisely that! Hydrate HTML that was already there (through Vue-like annotations about where data goes). JS would be the source of truth for the *data*. Important: I'm not suggesting this as the right approach for everything or even most things. Just that these cases exist and are not niche.
E.g. mostly static content where a static site generator works fine, with a few dynamic islands that you want to be able to manage with good DX without affecting the architecture / build process of the whole site.
Not 100% what you're looking for, but there's some interesting nuggets here github.com/ChrisShank/p.... My favorite takeaway here is annotating the markup with "event intentions", and then orchestrating the events in single place via event bubbling.
I would guess Preact is closest to what you want — you can SSR then hydrate, and if you don't mind using htm you can do it all without a build step preactjs.com/guide/v10/no... But it sounds like you'd be better off just leaving a gap in the HTML and filling it with JS. Worse user experience though
yes with some effort you can kinda get svelte to run clientside without a build but its not really made for that i would just use lit in this case, or preact: preactjs.com/guide/v10/no...
Yes, these may not need a build step, but they don't fit the other requirements.
Interesting 🤔 which requirements don't they fit?
Reactive templating and preserving DOM nodes (outside loops). I literally mentioned lit-html and React (Preact has the same issue AFAIK) in the 3rd post.
Maybe alien signals github.com/stackblitz/a... or datastar data-star.dev
A while back I needed super basic state management so I created CheapState, which implements a publication - subscriber pattern on localStorage This enabled me to do reactive templating (but I had to roll my own for templating) cheapstate - npm share.google/m1l19PkLyqLB...
Wouldn’t Proxy, or something derived from it, plus plain web components be an option?
If I have to build it myself, I have a pretty good idea of how I'd do it, but I'm *really* hoping to avoid that.
I’d love to use what you find too, I ended up using something self baked because I didn’t find anything. Solidjs is something I tried with its store, no-build option, worked ok, but feel a bit too much for me.
I forgot a made a presentation about it! codepen.io/JackHP95/pen... It had many working titles, but I settled on ringtail.
Bi-directional data-binding for HTML/JS - No build step - Hydration from DOM - `Proxy` trigger DOM updates - `MutationObservers` trigger data updates - [o-*] denotes data binding. (hence the name o (ring) - (tail)) - the suffix has how it binds. - attr.value holds the data path. ie `users[0].name`
Although it's simple, it required me to build several "libraries" to make it work. - idempotent html getter/setter library. (required for hydration) - unified JS event/microtask/frame library. - simpler DOM change event system. - JS graph library for performance. (IMO, over optimized, already fast.)
I built several demos. Simplest concept: codepen.io/JackHP95/pen... - Parsing `Jack` would essentially run this JS: `o_.user.name = "Jack"`. - Running `o_.user.name = "Lea"` would update the HTML to `Lea`. That's the whole idea.
Loose theory/example on how custom plugins would work: codepen.io/JackHP95/pen... I never really finished it because I got burnt out on for-loops and got stuck thinking about writing all the docs. Might pick it up again if there's enough interest.
Working titles were `adios` and `buck.js`. github.com/jackhp95/buc... - Adios was an anagram of `as, is, do`. `[o-as="is"]` and `[onevent="do"]`. I realized the state update `do` wasn't relevant. It was all about lossless templates. - Buck `$` was initial namespace for the global state object.
Yes, I know you lose an `s` in the anagram. It was a working title. It was also a way of saying goodbye to the typical FE framework conventions.
You're not alone. I built something exactly like this. I was baffled it didn't exist. Knockout was close. Alpine was close. Petite Vue was close. Htmx was sort of close. The initial intent of "hypertext" was close! Bidirectional. Let me look for the demos... I'll report back once I find them.
Would changing the state in react help/fix this? I am very noob but I'm looking into using valtio from pmnders in react to see if I can get it to behave better than standard react. Also testing solid and preact eventually
What about @hawkticehurst.com’s Stellar framework? github.com/hawkticehurs...
Alas probably wouldn’t work for @lea.verou.me’s needs. Stellar embeds all data in HTML and then let’s you manipulate it with JS
Hm. I’m not sure how you would avoid putting the initial values in the HTML if you wanted there to be HTML and not just client-render the entire thing.
Yeah I’m not sure that can be fully avoided either (maybe JSON payload?). But I think the “data in JS” req might be more about JS being the source of truth for the data in your app In Stellar HTML is the source of truth for the data — stored in element text content / custom attributes
Oh interesting, seeing this exchange elsewhere in the thread I suppose it’s worth mentioning Stellar *does* let you optionally define your data in JS. It’s just not the “idiomatic” way of writing Stellar code github.com/hawkticehurs...
I think this is what I was thinking of. Maybe I’ve been using Stellar wrong 😅
The native HTML tag is a big waste of potential that could do so much more. So for years, I have been attaching micro templating syntax to it. I can bend it to do what I want, and it keeps me out of the framework nonsense. johnresig.com/blog/javascr...
And, I'm joking here, but I wonder if an ancient technology called "jQuery" can fill all the requirements you're looking for.
It looks like I was late on the joke, I found this github.com/meteor/blaze
The first requirement was reactive templating :) If I have to manage UI imperatively, I can just use the DOM with a couple of my own abstractions just fine, I don't need jQuery. But managing UI updates imperatively is hell for anything nontrivial.
I’ve wanted this for so long as well. I don’t know if anything
Could you share an example of a use case / the problem(s) you’re trying to solve? Super curious and might help with providing a good recommendation
Knockout.js maybe?
What do you mean by: > Not recreate DOM when not needed (ok for loops), so it plays nicely with other stuff, so no lit-html Lit reuses nodes.
Reuses nodes it created. Not nodes that were in the page already. No?
Ah. Yeah, and even the diffing ones often only diff one layer or implicitly key nodes. I wonder if morphdom would work, but I don't think it has a template syntax, it's just a library.
I wonder if something from @webreflection.bsky.social ... 🤔
I think Lea is after "hydration" that works out of the living DOM and not out of logic render() or JSX created. uhtml5 should satisfy all requirements but v5 has current glitches with convoluted signals and hydration is not fully there yet. Hydration needs to be SSR instrumented though or it's bad.
It seems a lot of the libraries that did that are old (e.g. Knockout). I wonder why. Impossible to get good performance without DOM ownership or lack of interest?
In Lit's case it's perf and simplicity. Doing one reference check to see if you need to render the template anew, or update the DOM parts is just much faster than checking each node.
Yes, for Lit it would defy its very premise (which is very elegant!)
Would a combo of morphdom/idiomorph and an HTML templating lib (mustache, handelbars, pug, etc) work? Not quite clear on what the workflow would be for integrating a reactive library with markup it didn't make 🤔
I've often considered making a morphdom integration for lit-html...
I’m not super familiar with lit-html source code, but doesn’t it have its own diffing logic? I just worked on a mustache + morphdom combo integration with ReactiveElement at work. Seems to be working well, but not battle-tested yet
lit-html doesn't diff. It just checks whether the new template to render is the same as the previous template. If they're the same, just update the bindings. If they're different, replace the DOM. Much faster than a diff.
Can you use Preact Signals on their own for what you need? I know you can use Signals on its own without using any other part of Preact or JSX, but I don't know whether the markup management that comes with that would fit.
Also, FWIW, it is possible to just use Svelte itself on the client side, and not SvelteKit or any of its server/routing stuff.
Forgive me if I misunderstood your requirements as you listed them but isn't what you're describing satisfied by Vue Vapor? It's being rolled out in the 3.6 alpha release (currently at `alpha.2`). github.com/vuejs/core/r...
How? Vue Vapor seems to require a build step at all times.
Lit + signals maybe? Svelte is a good choice but leans towards build time stuff. Preact possibly too
I'm in the middle of refactoring it so there are some definite rough edges, but I've been working on this petite-vue-esque framework for web components While I plan to support directives, they're totally optional and it reexports effect and reactive from \@vue/reactivity github.com/gingerchew/k...
```js createApp({ i: 0, MyButton() { effect(() => this.textContent = ++i); return { connected() { console.log('connectedCallback()') } } }).mount() ``` ```html 0 ```
Even though I'm aiming to keep it as small as possible, since the "app" is making web components, they can do anything a web component can do (with hopefully nicer DX experience)
What if you split up the requirements? Reactivity can be done through something like preact signals. And for not steamrolling the DOM… D3 perhaps?
Not sure if it fits here, but I once built a mechanism for dynamically loading Vue components anywhere that a data-vue="MyComponent" attr was set, allowing small "islands" of interactivity (in a WP site!) without committing to something like Astro. Happy to try to recollect more details if it helps.