[90s_dev]

According to a resonating reddit comment, Svelte isn't more popular because it's simply too late; React and Vue got there early and got good enough, so Svelte can't really get as big as them.

I think this might be true short term, but long term it means Svelte has more room to evolve with the web and with JavaScript itself, since fewer users means more room to move fast and break things, like Zig can and does. And Zig isn't dead.

This gives me a little encouragement for my personal web reactivity project. I'm confident I came up with a reactivity model that's technically innovative, which does and is what I always wanted React to do and be. But being so late to the game, my hypothetical framework has no chance to gain traction. I say hypothetical because I haven't even started making it yet. It would be built on the Ref class[1] that came out of my experimental work on os.90s.dev, but only last night did I finally get around to experimenting with using it with HTML[2].

The concept is to have JSX transform to allowing attributes to be given MaybeRefs and if its a ref then watch it and set the attr to the value, and just return the HTMLElement itself. This should be a good enough foundation to build an entire reactive framework around.

Having almost no users is a blessing, because it gives me the complete freedom to experiment with this relatively slowly. The time between creating refs and stabilizing them was a few months. The time between stabilizing them and using them in that experiment was another month. It'll probably be another month before I get a functioning non-trivial app working with it. And another few months before it's cleaned up enough to be both generic and convenient.

Maybe this should have been a blog post. I never know.

[1]: https://90s.dev/guides/refs.html

[2]: https://github.com/sdegutis/bubbles/commit/cde2bea973b22538f...

[benmccann]

It's neither true that Svelte has few users or that we can easily break things. Tons of sites are built with Svelte like Yahoo Finance and Apple Music. Svelte 5 was the only big change in syntax in the past five years and we made sure that there's a good migration tool, etc. to minimize the amount of hardship and upgrade might cause. As a result the majority of users have already upgraded to Svelte 5.

That being said, Svelte absolutely does continue to innovate. We'll be introducing a new async primitive, RPC mechanism, etc. in the near future: https://m.youtube.com/watch?v=1dATE70wlHc

[jmogly]

I think svelte, especially now svelte 5, will “win” because it doesn’t fight with vanilla web dev it just beautifully supplements the short comings of rolling plain html, css, js.

This is coming from someone who is no way a front end dev, but svelte 5 in particular is just so easy to get started with and has the most sane approach to reactivity and syntax compared to the other frameworks I have tried, and it seems like it is in the best position to grow with the web as well.

[90s_dev]

I am surrounded by geniuses.

So I will stop trying to be like them. I can't.

I'll just keep my head down and write my little apps for fun.

[edflsafoiewq]

IIUC this is how VanJS works.

  // Create new Ref
  const r = van.state(0)
  // derive functions as adapt/watch/multiplex.
  // Implicitly depends on any Ref it uses and re-runs when they change.
  const r2 = van.derive(() => 2 * r.val)
  van.derive(() => console.log('r2 is ' + r2.val))
  
  // Changing the value doesn't update r2 or print immediately, it schedules
  // a batch update when all derives will get recomputed.
  r.val = 3
  // ...So 'r2 is 6' won't be printed here.
  r.val++
  
  // Refs can be used in a hyperscript-style DOM builder.
  // This creates a regular HTMLElement, with a regular Text node where r2 goes,
  // but it holds onto that Text node behind the scenes and automatically
  // updates it when r2 changes.
  const {p} = van.tags
  document.appendChild(p("The value is ", r2))

[90s_dev]

Man I don't even know why I write any code anymore. Everyone's already done everything.

[haburka]

I would recommend to not make a web framework with the idea of it being popular, like competitive with react. It’s much better to make a library that works with react / vue / svelte and see if that can become popular.

There are enough web frameworks. If you make a blog post where you state what limits you have with the current state of web technology, and you describe it really well, I’m sure someone will be able to point out how there is a web framework that deals with that. Or a way to implement that in current web frameworks.

[ricardobeat]

> The concept is to have JSX transform to allowing attributes to be given MaybeRefs, and if its a ref then watch it and set the attr to the value

That is essentially what Signals are, including directly setting .textContent when possible.

This model actually predates all of this and was used way back, in Backbone.js and other pre-react frameworks, except we didn’t have JSX or virtual DOM at the time.

[90s_dev]

I remember Backbone using two-way bindings, which I think is more complicted than what my experiment does:

    const el = document.createElement(tag)

    for (const [k, v] of Object.entries(attrs)) {
      if (v instanceof Ref) {
        el [k] = v.val
        v.watch(val => el[k] = val)
      }
      else {
        el[k] = v
      }
    }

[ricardobeat]

You might be thinking of Knockout.js. Backbone used a manual event-driven approach where you'd wire up each component to a model/observer that you called .set(value) on. Except it was a lot more verbose, and because you'd be using chunks of string templates for rendering, it wasn't very fine grained — basically how far up the tree you added the subscriptions defined the update granularity. Most importantly, no incremental rendering or virtual DOM meant manual management for any input states, and the lack of a defined render lifecycle meant it was hard to keep track of updates and very easy to get into infinite recursion loops.

As someone else mentioned in this thread, the main innovation in the React era was actually it's sister library Flux which brought the idea of a unidirectional data flow into the picture, later inspiring Redux et al. We are now getting past the immutability detour and keeping the best of both worlds, maybe.