New blog entry: "Rethinking reactivity"

[tipiirai]

My attempt to explain how Nue JS internals work and how Nue is different from the other frameworks:

https://nuejs.org/blog/rethinking-reactivity/

Or course the site has a brand new blogging area.

Curious to hear your thoughts!

[nobkd]

Found a typo:

Nue uses classes to bring the DHTML wibes back to modern component-based web development.

[tipiirai]

Fixed. Thanks!

https://github.com/nuejs/www/commit/653df4433ad0cf271e7f1248e4694023d070fdd7

[siduck]

Hi @tipiirai , it'd stay like this forever right? Svelte recently added Runes, addressing some problems with their previous way of adding reactivity ( Nue's using this same way too )

https://svelte.dev/blog/runes

[tipiirai]

I don't expect this syntax to change ever. At least not in a fundamental way like Vue or React did. Fully aware of the upcoming Svelte 5, I even have a Runes example in the article. Nue's syntax a bit more like Svelte 4: let count = 0; vs. count = 0. Syntax-wise Runes went more into direction of Vue and Svelte I think. Evan You said the same thing in the opening comment here: https://news.ycombinator.com/item?id=37584224

[tipiirai]

Some discussion about this on Hacker News: https://news.ycombinator.com/item?id=37734251

[siduck]

would it be possible to export the state? so it'll behave like a global state. Would be fun to use! unlike react for which we need external libraries

[tipiirai]

This is an important topic and relates to the general question of "How to make scaleable single-page applications". Nue's answer is the classic MVC (model/view/controller) pattern. I'll tackle this topic along with a more complex demo application when I push out Nue MVC. Check https://nuejs.org/tools/#nue-mvc

[JensRoland]

Great article! Two points:

1. I love the examples, all except when it comes to fetch -- while the syntax is fine for what it is, these examples are just begging to be abstracted away with something like HTMX / Unpoly / LiveWire. Frankly the more I see of Nue JS: the HTML-first philosophy, the minimalist & DX focused syntax by design -- the more it's feeling like the ideal companion to an HTMX-based stack -- what Alpine.JS or Hyperscript should have been but so severely aren't.

2. Wrt. the Svelte 4 count = 0 syntax and the regression to Runes with Svelte 5: Nue JS may someday run into some of the same issues that Svelte did, but since Nue JS reactivity is runtime and Sveltes is compile-time, some of the issues just aren't. As for "not knowing what variables are reactive" I think that's a fair point as codebases get complex, yet noooooothing stops developers from adopting a simple naming convention a la rxCounter = 0 is reactive but let counter = 0 is not, or whatever they want. An explicit observer syntax is clearly not the only way to solve that.

[tipiirai]

Thank you Jens!

1. I see your point. I'll check HTML more deeply. Maybe there are some compelling use cases for collaboration with them. I guess you meant that the fetch() example should be replaced with something more minimalistic? Like setTimeout or something.

2. I'm sure there will be issues and bugs in the code when people start using Nue more heavily. I still think they are very different from what Svelte had. The internals are so different in Nue. Ie. there is no separation between reactive vs. non-reactive variables in Nue.

[JensRoland]

Wrt. (1) I wasn't so much talking about fetch vs. setTimeout -- I was talking about the way HTMX (and a few other similar tools) abstract away the boilerplate fetch-and-update-DOM code that makes up 80% of real world web interactions. To illustrate, the first fetchexample from the blog post:

<form @submit.prevent="submit">
  <input type="email" name="email" placeholder="[email protected]" required>
  <button>Submit</button>

  <script>
    // input validation is natively taken care of by the browser
    async submit({ target }) {
      await fetch(`/api/leads?email=${target.email.value}`)
      location.href = '/thank-you'
    }
  </script>
</form>

With HTMX this would be (in its entirety):

<form hx-get="/api/leads">
  <input type="email" name="email" placeholder="[email protected]" required>
  <button>Submit</button>
</form>

And in the api/leads endpoint, you would simply respond including a hx-redirect header to redirect the user to the /thank-you page.

People will tell you htmx is about replacing React or call it a framework or this or that, but at its core, HTMX (and Unpoly, LiveWire, and my very own T2) is about taking the most common 'AJAX' patterns and just turning them into declarative, intuitive HTML attributes.

Makinde Adeagbo's JsConf presentation from 10 years ago perfectly explains why and how they did this at Facebook with the 'Primer' system: https://youtu.be/wHlyLEPtL9o?si=fnQ6hQBtQ0BBL3zh&t=413 (I cannot recommend this presentation enough)

Basically they realized that almost all the interactions on Facebook fit a particular pattern:

1. User clicks
2. Send an AsyncRequest
3. Insert/Replace some content

and writing a custom, nearly identical bit of JS code for every single tiny interaction is verbose, redundant, and a recipe for terrible Time To Interactive as the JS bundle sizes grow larger. So at Facebook they came up with Primer to solve this, around the same time as intercooler.js appeared (2012-ish) - which was later renamed to HTMX.

The point is, HTMX is not a replacement for rich client side JS. It is a really nice HTML-first syntax for declaratively expressing the most common low-fidelity server-roundtrip interactions that don't really need anything fancy or custom. In other words, HTMX won't get you all the way to a complex modern web app -- it needs a lightweight JS framework to bridge the gap; one that doesn't insist on taking over page routing, application state, the whole DOM, and on front-loading 400KB of JavaScript before presenting a single interactive pixel. The standard choice for HTMX' JS framework is Alpine.js, but frankly it's an abomination. But Nue JS is ridiculously well suited for it, philosophically and even syntactically.

There is actually no need to collaborate formally with the team building htmx, it's not even difficult to integrate as-is. I just wanted you to be aware that a lot of people are looking at HTMX right now and finding that they need to pair it with a JS framework, and I really hope they find Nue JS. Maybe a quick blog post on "htmx + Nue JS" just to demonstrate the power and elegance of Nue JS to the devs looking to compose the next big frontend stack?

[tipiirai]

Now, this was a great introduction to HTMX! Thank you. Also a great idea for a blog post.

It would also be quite easy to implement HTMX- like tags with Nue. I mean something like this:

<nuex-form action="/api/leads">
  <input type="email" name="email" placeholder="[email protected]" required>
  <button>Submit</button>
</nuex-form>

Just thinking aloud.

[seneca]

Thank you for writing this blog post.
Just. couple of things.

1. Is it a typo or there is a reason for Impl: to start with a capital I. All other properties like name:, tmpl:, etc, start on lowercase.
2. Could you explain a little bit more why we can omit "let, const, etc" before count = 0 in the script element.

[JensRoland]

I think Impl is capitalized because it's a class, and class names are generally capitalized. The other properties are strings, so they are not.

[tipiirai]

1. @JensRoland got this one right: class names are generally capitalized
2. That's how ES6 class syntax works. Here's an example from MDN

[JensRoland]

One comment about the article is --- it buries the lede a little bit.

I am guessing a lot of people who click on a title like 'Rethinking reactivity' are developers with a fairly advanced understanding of reactivity in JS frameworks. Those people don't need all the context of the full article but are kind of looking for the condensed, single-paragraph technical answer: Does it use Signals? Does it use VDOM? How fine-grained is it? Do we wrap calculations in effects callbacks or update functions or something else -- and what about memo/derive values? Reactivity in JS is always a compromise, so what was the choice made here?

If I could make one change, I would add a paragraph at the top to briefly explain the reactivity model to the nerds, and let everyone else skip past that to the long version.

[tipiirai]

Great idea! Can you maybe draft the content for this section? I could then simply copy/paste it there, with possible fine tunings.

[ledihildawan]

When I first learned web development I liked HTML, CSS and JS. Which is really pure writing, but to stay relevant to my work I learned React (JSX) and started to hate writing purely. Angular, Vue and Svelte are almost the same as pure writing, but with Nue I feel like my experience of learning web development comes back to me. Hopefully in the future the timeline for this project will be on time. Obviously this cuts down on material while studying and makes it easier for people to work. Thanks @tipiirai.

[tipiirai]

I'm so happy to hear this! Always great to see people who value minimalism and web standards. Thanks for keeping my motivation and spirit high!

[hichem-dahi]

I don't think getters are reactive.

ex: after adding a contact in the contacts object. The maleContacts property doesn't get updated

    contacts = [{
      firstname: 'hichem',
      lastname: 'dahi',
      gender: 'male'
    },
    {
      firstname: 'hichem2',
      lastname: 'dahi2',
      gender: 'male'
    }];


    get maleContacts() {
      return this.contacts.filter(item => item.gender === 'male')
    }

[tipiirai]

This should work. At least it works on the Todo MVC: https://nuejs.org/todomvc/

Can I see the full code?

Thanks!

[hichem-dahi]

@tipiirai here the full code's link

Thanks in advance!

[yerlaser]

There's now a JS proposal for native signals: https://github.com/tc39/proposal-signals
Looks like it's gaining momentum and some frameworks are already adjusting for it (e.g. Lit, Angular).
Do you plan to incorporate it as well?

Here's some write up from one of the authors of the proposal: https://eisenbergeffect.medium.com/a-tc39-proposal-for-signals-f0bedd37a335

[tipiirai]

Hey @yerlaser. This is bit of a rant, but here we go.

The signals proposal perfectly illustrates how framework thinking has warped our perspective on web development. We're trying to standardize complex reactive patterns when the real solution is questioning why we need such complexity in the first place.

Consider what signals aim to solve: managing UI updates when data changes. But this "problem" largely exists because we've normalized JavaScript monoliths where everything - markup, styling, business logic - lives in framework components. The complexity of signals (or hooks, or observables) becomes necessary only when we abandon proper separation of concerns.

The web platform already provides elegant solutions through standards:

• Form elements naturally manage their own state
• CSS handles visual updates through transitions and animations
• Custom events allow targeted updates when truly needed
• LocalStorage and SessionStorage handle persistence
• The History API manages URL state

When you work with these standards rather than against them, the need for complex reactivity patterns disappears. Your HTML stays semantic, your CSS handles presentation, and JavaScript remains focused on true interactivity needs.

The push for signals is a symptom of framework thinking - trying to solve framework-created problems with more framework abstractions. The real solution isn't standardizing complexity, it's returning to the natural strengths of web standards through proper separation of concerns.

This doesn't mean signals are inherently bad - they may be useful for truly complex application state. But for most websites and many web applications, they represent unnecessary complexity that could be avoided through better architecture.