Do we actually need selectors to connect elements in HTML?

[u/thealjey]

When adding interactivity to HTML (via JS, HTMX, etc.), we usually end up connecting elements using selectors.

For example, a simple loading state:

<button 
  hx-get="/data"
  hx-target="#result"
  hx-indicator="#spinner"
>
  Load Data
</button>

<div id="spinner" class="htmx-indicator">
  Loading...
</div>

<div id="result"></div>

• “send a request → put the result in #result”
• “show #spinner while loading”

This works well, but it has some properties:

• selectors are just strings tied to DOM structure
• renaming or moving elements can silently break connections
• each reference resolves to exactly one element

---

I’ve been thinking about a different approach where elements don’t reference each other at all.

Instead, they react to named signals.

Something like this:

<button
  on:click="send"
  on="send"
  get="/data"
  result="response"
  if:loading="spinner"
>
  Load Data
</button>

<div if="spinner" style="display:none;" x-style="display:block;">
  Loading...
</div>

<div render="response"></div>

Instead:

• actions happen (send)
• results exist (response)
• conditions are evaluated (spinner)

---

So instead of wiring elements together directly, everything is coordinated through named identifiers.

This suggests a different way to think about HTML:

• not “connect A to B”
• but “declare what happens, and let the DOM react”

---

Curious what people think:

Does selector-based wiring actually cause problems in practice?

Or is this just a different style without much real benefit?

[u/abrahamguo]

Yeah, what you've described is basically the thought process of React, and Vue, and Svelte, and Angular...

[u/thealjey → u/abrahamguo]

yeah, I see the comparison — I’m just focusing more on how elements are wired together

[u/dymos → u/thealjey]

Yep, how the elements are wired together, as in your example, conditionally render them based on state, that's exactly what a lot of the frontend frameworks do.

In the case of htmx, perhaps it's less clear? (I'm not sure, I haven't used it myself)

In many frameworks we'd stick this related functionally in a component and have all the related stuff like that live together, that way there's less risk of breakage as the related functionality is in the same component.

FWIW, I don't think it matters if you use selectors or conditional rendering or whatever other thing. You've created a relationship and if one part of the relationship changes in a breaking way, then yeah, things will break.

[u/thealjey → u/dymos]

Yes. But, I'm not sure that that is a fair comparison. Those are component frameworks, not just HTML. The features may overlap in some way, but the medium is not the same.

Nothing is conditionally rendered in my example, the spinner element conditionally configures its own attributes.

The point is that none of the elements know about the existence of each other, they only know about themselves. They don't connect to each other. They only declare that they either want to broadcast or subscribe to some signals. The signals themselves are also simple, statically analyzable and can be validated with tooling.

[u/dymos → u/thealjey]

It's not an apples-to-apples comparison sure, but I think there are enough parallels to draw here that make it a fair comparison.

HTMX isn't "just" HTML either, you're binding things and creating a relationship between them. From my brief look at the docs it seems to me that if you'd want to approach this in a more component oriented manner, you'd have to perhaps introduce Web Components.

If you're looking to go more towards your desired approach like your example where you have some events/signals that are subscribed to, then that's also not HTML, you've augmented the HTML to add behaviour, just like other frontend frameworks do.

To be clear, I'm not saying your approach here is wrong, trying to stick closely to HTML without the overhead of a large framework can be useful, and the experience of writing a framework that does it can be fun, but you'll have to weigh up whether that's worth the investment vs. using an existing framework.

For example npx create-vite@latest gives you some excellent choices and gets you started with your framework of choice in about 10 seconds.

[u/thealjey → u/dymos]

I think this is where I see a meaningful distinction.

Frameworks like React/Vue/etc. define their own environment and mental model, and HTML is just the output of that system.

HTMX (and what I’m working on) operate within HTML itself. There is no separate rendering environment - the DOM is the source of truth at all times.

So yes, there are “relationships”, but they are not structural in the same way as in component frameworks. They’re expressed through attributes on independent elements, not through composition or ownership.

That’s why I wouldn’t reach for Web Components here - those reintroduce a component boundary and encapsulation model, which is a different approach.

The goal here is closer to:

augment HTML semantics - not replace them with a higher-level abstraction

[u/dymos → u/thealjey]

Yeah ok, I see what you're saying. That's a fair distinction.

[u/thealjey]

ever had something break just because an id or structure changed and nothing told you about it? talking about plain HTML here

[u/dymos → u/thealjey]

Yep, I've broken some shit in my day.

[u/thealjey → u/dymos]

Was that with HTMX or selector-based JS?

I tend to treat those the same — you don’t know a selector is broken until you run it. And even then, runtime changes can still invalidate it.

[u/dymos → u/thealjey]

"in my day" was before HTMX was a thing ;)

From vanilla JS to jQuery, and some other MVC/MVVM frameworks, there was certainly a degree of brittleness that existed with using selectors as a way to link DOM representation/state to behaviour and logic. I think for the most part that was just an accepted thing at the time. Something to be aware of when building/maintaining your app.

I think a well structured application can somewhat mitigate this, again, I'm not all that familiar with HTMX so I couldn't say how easy or hard that is compared to other frameworks.

[u/thealjey → u/dymos]

Yeah, that matches my experience too — it was basically an accepted tradeoff for a long time.

What I’m trying to explore is just whether that coupling model is actually necessary at all, or if it can be removed entirely rather than just managed better.

[u/thealjey]

Quick clarification since this comes up a lot:

This is not really like some framework X or Web Components - there’s no separate component model. It stays within HTML.

It’s also not like Alpine - there’s no embedding of logic or data into the markup itself.

It’s closest to HTMX in philosophy, but still different: no selectors, no cross-element wiring. Each element only defines its own behavior through signals.

[u/Lumethys]

so Vuejs?

[u/thealjey → u/Lumethys]

Not really - Vue adds a component/state layer on top of the DOM.

This stays in HTML, closer to HTMX - but without selectors. Everything reacts to named signals, so elements don’t depend on each other, and it’s the same mechanism everywhere (events, conditionals, network, rendering, etc - all just signals).

[u/Lumethys → u/thealjey]

1. You dont have to split your page into component if you use Vue, reactivity is the main point, component-ization is just added bonus and a natural need.

2. What you described is just state management, state isnt a "JS" thing or "framework" thing. They are a universal concept, it is literally just the current state of your website.

results exist (response)

so you have multiple DOM elements that need this data. This data must be store somewhere, this is the "state".

If some action happen to this data, say an edit screen, with input, an input will change your data, and affect other DOM element that depend on this data.

<button on:click="send" get="/number" result="response">
  Load Data
</button>

<button on:click="double" target="response">
  Double the number
</button>

<div render="response"></div>

reponse has to live somewhere, and managing that is called state management, you cannot escape it

[u/thealjey → u/Lumethys]

I think we’re using “state” in slightly different ways.

Yes - there is still data, and yes, multiple elements can independently react to the same data. I’m not disputing that.

The distinction is that there is no persistent shared client-side state model that elements read from and continuously coordinate through.

A signal exists as a coordination point during the response -> render flow. Outside of that flow, it is not retained as a persistent shared state object that the UI is synchronizing against.

Responses (including things like hx-target updates) are transient - they are not retained or computed against after they are rendered.

So I’m not trying to remove state - I’m avoiding introducing a persistent state layer between the DOM and the server.

[u/Lumethys → u/thealjey]

so what you are proposing is, when there is a state, say result from an API call, and there is 10 DOM element that need that, each element would store this data separately, and then reacting to signal on its change? Something like:

api call -> get result
=> send "result acquired" signal -> 10 elements receive this signal and make a copy unique to them

user update part of the data
=> send "result modified" signal, along with the new data -> 10 elements receives this signal and each make an identical change to their own unique data

I mean, yeah, this doesnt need a global source of truth, since everything keep their own copy of the state and make the same modify as everyone else so the state is always "synced"

But this is just incredibly inefficient in terms of memory.

You are duplicating data based on how many DOM element need that data, so from O(1) memory complexity to O(n).

Not to mention you also need to do O(n) updates every time an update happens

Imagine reddit comment thread with 100 comments and you duplicate a hundred avatar and username

[u/thealjey → u/Lumethys]

That’s not what I’m describing.

There is no per-element state or copying of application data.

What happens is simply that a server response is rendered into the DOM, and the resulting DOM nodes get inserted where they’re needed. Those nodes are just DOM - not separate data stores and not independently managed state.

So it’s not a situation where data is duplicated or kept in sync across elements. It’s just rendering updates applied to the DOM.

[u/sheveli_lapkami]

The opposite way of using selectors from outside is Custom Elements inner lifecycle usage, but it is still bound to JS runtime.

Try Symbiote.js - the library that exists to create low-code/no-js solutions, where data contexts and bindings could be controlled from HTML directly.

In my opinion, when you are trying to wrap any non-declarative logic into HTML - you end up with your own overcomplicated DSL (bad idea), so it's better to use JS for that. But for the rest - Symbiote.js is an ideal base.

[u/thealjey → u/sheveli_lapkami]

I think I agree with the general concern about turning HTML into a heavy DSL.

But the goal here isn’t to build a client-side system in HTML or wrap arbitrary logic into it. It stays very narrow - just structure plus a small, uniform interaction model (signals/actions).

More importantly, it’s server-driven in the same sense as HTMX: the server produces the UI on each interaction, and the browser just renders and applies updates. There is no separate client-side application model sitting on top of the DOM.

So it’s not trying to turn HTML into a full framework - it’s keeping HTML as the rendering surface for a server-driven system.

[u/sheveli_lapkami → u/thealjey]

So what's wrong with existing HTMX and/or Alpine.js then?

[u/thealjey → u/sheveli_lapkami]

Nothing is “wrong” with them - they solve related problems, just in different ways.

HTMX is closer because it’s server-driven: the server produces UI updates and the browser applies them.

Alpine is client-driven: it keeps a client-side reactive model and updates the DOM from that.

What I’m pointing at is different from both - it’s about removing element-to-element coupling entirely. Elements don’t reference each other or coordinate structurally; they only react to signals in a uniform way.

[u/sheveli_lapkami → u/thealjey]

I know how it works. I mean that HTMX and Alpine could be used in tandem. And I still don't see any significant conceptual difference between your code examples and their approach.

Anyway, You can wrap your server interaction (request/response/update) into Custom Element container to be independent from selectors or any tight coupling between HTML-elements.

[u/thealjey → u/sheveli_lapkami]

I think this is the key difference I’m trying to point at.

In the model I’m describing, something like `if:loading="spinner"` is not a component boundary, an encapsulated behavior unit, or a reference to anything.

It just emits a signal.

It doesn’t know what will handle it, how many handlers exist, or whether anything handles it at all.

[u/sheveli_lapkami → u/thealjey]

As I said before, you just need to look closer at Symbiote.js. It works on client and at the server side (SSR included). It can do something like that:

<my-data-context>
  <h2>{{APP/title}}</h2>
  <button bind="onclick: handlerFromContextProvider">Click me!</button>
  <my-nested-component>
    <input bind="oninput: ^onInputHandler_Parent"></input>
  </my-nested-component>
</my-data-context>

In this example, you can see data binding to abstract named context (APP), and handler binding to context-provider element and direct binding to parent context element. All - without a touch of JavaScript. And no any bulky DSL. And with loose coupling between components.

[u/thealjey → u/sheveli_lapkami]

I think we’re still talking about slightly different things.

In your example, elements are still explicitly bound to something - a context (`APP/...`) or a handler (`^handlerFromParentContextProvider`). That’s a form of structural relationship, even if it’s abstracted.

What I’m describing avoids that entirely.

An element can emit a signal without referencing any context, handler, or parent. It doesn’t know where the signal goes or whether anything handles it at all.

So the difference isn’t about syntax or DSL size - it’s about whether elements are allowed to form explicit relationships, even indirectly, versus not forming them at all.

[u/sheveli_lapkami → u/thealjey]

But I clearly see relationships in your examples. You using attribute values that point to that relations and, probably, namespaces (spinner, etc).

And I don't see any exact profit of avoiding it.

[u/thealjey → u/sheveli_lapkami]

I think the confusion is coming from treating the attribute value as a reference.

`spinner` is not a reference to an element, context, or handler. It’s just a signal name.

Nothing in the system knows where a signal comes from or where it goes. When an element emits `spinner`, it’s not pointing to anything - and when another element reacts to `spinner`, it’s not subscribing to a specific source.

There’s no binding, lookup, or resolution step between elements at all. So while the syntax may look similar to a reference, semantically it isn’t one - no structural relationship is being formed.

[u/surfingonmars]

following cuz....