Inspriations and deriving state

[onsclom]

Hello! 👋

VanJS is awesome. You get the big benefits of modern frameworks with simple JS primitives: a succinct way to compose html, reactive state, and a way to compose both into reusable components. I had thought about combining hyperscript and some simple version of signals (like in SolidJS), but VanJS takes this to the next level. It looks you created a more modern version of hyperscript and a really natural signal API using the Proxy object. I'm curious, were hyperscript and SolidJS inspirations here, or did you end up arriving to similar ideas naturally?

In a lot of cases, VanJS really seems more ergonomic than modern frameworks. However, there was one thing that stuck out to me. The tutorial gives this example for derived state:

span({style: {deps: [size, color], f: (size, color) =>
      `font-size: ${size}px; color: ${color};`}}, " Hello 🍦VanJS")

But have you considered the following API?

span({style: () =>`font-size: ${size}px; color: ${color};`}, 
   " Hello 🍦VanJS")

It seem like an improvement because 1. It's more concise and 2. users don't need to manually track and declare dependencies. This is exactly how derived state works in SolidJS. If you haven't already seen this pattern, Ryan Carniato explains how to build this signal API in building a reactive library from scratch.

Similarly, van.bind could get the same benefits. This:

van.bind(deleted, d => d ? null : li(
    text, a({onclick: () => deleted.val = true}, "❌"),
))

Could be simplified to:

van.bind(() => d ? null : li(
    text, a({onclick: () => deleted.val = true}, "❌"),
))

It seems totally possible for VanJS to support this API, though I admit I may be missing something. If this seems interesting I'm happy to explore this more. If you aren't interested in this, that's OK too!

[artydev]

Nice improvement indeed
Let us see what Tao think about :-)

[Tao-VanJS]

Very interesting discussion! I will take a closer look and get back to you when I get a big chunk of time (maybe after the memorial long weekend).

[Tao-VanJS]

I'm curious, were hyperscript and SolidJS inspirations here, or did you end up arriving to similar ideas naturally?

The actually story is, I knew very little about modern front-end frameworks while developing VanJS. I heard of Vue.js, Angular by names (never knew what they really are), and I had seen some sample React programs, thus I knew a little bit about React at the concept level. jQuery is the only library that I had ever used while doing front-end programming. So my journey with VanJS started with my programming with Vanilla JavaScript while building personal tools. Thus initially, I was writing code like that:

const anchorDom = document.createElement("a")
anchorDom.href = "https://vanjs.org"
anchorDom.appendChild(new Text("🍦 VanJS"))

But soon I found this is quite verbose especially when the DOM structure becomes very complicated, thus I started to build some helper functions to help me write:

a({href: "https://vanjs.org"}, "🍦 VanJS")

instead. Thus this was the initial prototype of VanJS. I kept iterating the helper functions to make it more ergonomic, until it has been evolved to the current form. It worths to note that, the initial version of VanJS is a little bit hacky: providing tag functions by polluting the window object, as you can see from the code here, until the proxy-based solution was discovered.

The mechanism of adding the reactivity part was discovered by this March. Before that I was using the ad-hoc approaches to support application-specific reactivity for the personal apps I built. Initially my thought was that reactivity was so hard that only complex framework like React can do it correctly. But during one night, when I was trying to think through the problem, I discovered a seemingly correct solution with just web standard API like replaceWith and isConnected. It was that moment I am seriously considering publishing VanJS as an open source project.

Thus, if I was to summarize how VanJS was made, I would like to attribute its creation to "First Principles". Knowing so little about modern Front-End frameworks puts me into a quite unique position that is free from the influence of any modern frameworks. All what I was thinking was: given the problem, what is the shortest path to solve it with only web standard API available?

It is quite funny that only after the public release of VanJS I started to know the existence of so many frameworks like SolidJS, MithrilJS, ArrowJS and so on and so forth, because I can always see comments like "Oh, this is quite similar to ...", "How do you compare VanJS with ..."

So talking back to the SolidJS-style API. I never heard of SolidJS when VanJS was being developed. If I heard of it before, the design of VanJS might be influenced to another style. So looking at your examples:

span({style: () =>`font-size: ${size}px; color: ${color};`}, 
   " Hello 🍦VanJS")

my understanding is it wouldn't work as both ${size} and ${color} are just constants. I looked at the link you sent to me, the state value needs to be got with function calls, thus the working code will likely look like that:

span({style: () =>`font-size: ${size()}px; color: ${color()};`}, 
   " Hello 🍦VanJS")

So, my general feeling about SolidJS-style API: I agree the code for complex binding is relative less verbose than VanJS. But there are also downsides, like making a function call to get the state values feels quite unnatural. Also, to be honest, I feel that the React-style state-hook API like:

const [counter, setCounter] = useState(0)

is quite counterintuitive. Beginners need spend significant amount of time the grasp the concept. In this regard, I feel that VanJS's state API is much better.

While I agree that for complex bindings, VanJS code is slightly more verbose. This is a downside I have to admit. But the general philosophy of VanJS is to bind states directly to DOM node or DOM properties as much as possible, and only do complex binding when it's absolutely necessary. In all the sample apps I built with VanJS, the complex binding is only needed in sparse scenarios. In my personal opinion, VanJS's API choice is acceptable. But I definitely understand other people might hold different opinions. I totally admitted that for complex UI applications VanJS is not on par with React. I don't position VanJS as React's replacement or competitor. I am rational enough to recognize the fact. VanJS is just a project that I built with my personal time. There is no point it can compete with React which has hundred-billion-dollar companies like Meta's backing. The purpose of VanJS, is to solve the problem where other mainstream frameworks don't seem quite care to solve, which is:

I know very little about front end programming. I have no comprehensive tools, nor I am familiar with them. How can I build a useful UI app within just a couple hours?

[onsclom]

This is a great response, thanks! It's really interesting to hear more about the origins of VanJS.

my understanding is it wouldn't work as both ${size} and ${color} are just constants. I looked at the link you sent to me, the state value needs to be got with function calls, thus the working code will likely look like that:

Whoops! You are right that ${size} and ${color} is incorrect, sorry about that. However, they don't need to be used as State(). What could work is:

span({style: () =>`font-size: ${size.val}px; color: ${color.val};`}, 
   " Hello 🍦VanJS")

VanJS doesn't need to adopt the React-style state-hook API to take advantage of automatic dependencies. Since van.state has a special prototype defining a getter and setter, something cool can happen. Users can just use state.val naturally, and dependencies get setup automatically. Here's a simplified proof of concept:

let currentEffect = null

const stateProto = {
  get val() {
    if (currentEffect) this.listeners.add(currentEffect)
    return this._val
  },
  set val(val) {
    this._val = val
    this.listeners.forEach((fn) => fn())
  },
}

const state = (initVal) => ({
  __proto__: stateProto,
  _val: initVal,
  listeners: new Set(),
})

function effect(fn) {
  currentEffect = fn
  fn()
  currentEffect = null
}

// example #1

const counter = state(0)

effect(() => console.log(`count: ${counter.val}`)) // count: 0
counter.val++ // count: 1
counter.val++ // count: 2

// example #2

const sideA = state(3)
const sideB = state(4)

effect(() =>
  console.log(`sideC: ${Math.sqrt(sideA.val ** 2 + sideB.val ** 2)}`)
) // sideC: 5

sideA.val++ // sideC: 5.656854249492381

This simplified example already feels really powerful. You just use State.val like you would normally and effects re-trigger exactly when they should. This would simplify all usage of van.bind, state-derived properties, State.onnew (when you don't need the old value), and it would make it easy to introduce a van.effect that works like the example above.

I'll leave things with a classic example:

const Counter = () => {
  const count = van.state(0)
  return button(
    { onclick: () => count.val++ },
    () => `pressed ${count.val} ${count === 1 ? "time" : "times"}`
  )
}

Whether you decide to explore this idea or not, VanJS is already awesome! Making such an elegant yet expressive API, some of my favorite documentation and examples, TypeScript support, server rendering, etc. is all so impressive.

[Tao-VanJS]

Thank you so much for your detailed response! I have to admit that my previous understanding of SolidJS-style was only at the surface level. I did learn a lot from your post! I think this is the beauty of open sourcing. There are indeed lots of things I learned from this great community.

After thoroughly thinking through this proposal, a reasonable pathway seems to surface. We can utilize these SolidJS-style effect functions as syntax sugar of the binding mechanism in VanJS. This way existing implementation can be reused and we don't need to make breaking changes to existing users.

I am thinking of something like:

span(() => `pressed ${count.val} ${count === 1 ? "time" : "times"}`)

will de-sugar to:

span(funcToBind(() => `pressed ${count.val} ${count === 1 ? "time" : "times"}`))

and will finally de-sugar to:

span(van.bind(count, () => `pressed ${count.val} ${count === 1 ? "time" : "times"}`))

similarly for state-derived properties:

span({style: () =>`font-size: ${size.val}px; color: ${color.val};`}, 
   " Hello 🍦VanJS")

will de-sugar to:

span({style: funcToDerivedProp(() =>`font-size: ${size.val}px; color: ${color.val};`)}, 
   " Hello 🍦VanJS")

and will finally de-sugar to:

span({style: {deps: [size, color], f: () =>`font-size: ${size.val}px; color: ${color.val};`},
   " Hello 🍦VanJS")

We can also provide van.effect function as a syntax-sugar to onnew as well.

van.effect(() => console.log({a: a.val, b: b.val}))

will de-sugar to:

a.onnew(() => console.log({a: a.val, b: b.val}))
b.onnew(() => console.log({a: a.val, b: b.val}))

For advanced feature like stateful binding, we can always fall back to the more verbose van.bind API.

Let me know your thoughts about this proposal. If everything looks good. I can consider add this feature as part of the 1.0 release.

[onsclom]

Yay, I'm glad this idea wasn't totally off base. Adding this without making breaking changes makes sense.

Those examples seem great. The de-sugar versions seem to have the same behavior as the sugar ones. However, there are some cases where there isn't a clear de-sugar path. Here is an example.

Using the follow state:

const shouldAdd = state(false)
const a = state(1)
const b = state(2)

A reactive effect could be setup like:

effect(() => {
  if (shouldAdd.val)
    console.log(a.val + b.val)
  else
    console.log(a.val)
})

or

function myEffect() {
  if (shouldAdd.val)
    console.log(a.val + b.val)
  else
    console.log(a.val)
}

shouldAdd.onnew(myEffect)
a.onnew(myEffect)
b.onnew(myEffect)

These actually result in different behavior that can be seen with:

b.val++ // triggers effect only in the verbose example!
shouldAdd.val = true // triggers in both
b.val++ // triggers in both

I'm not sure if this is a big deal or if it will make reusing existing code harder yet. If this ends up being something you'd want contributions for, I'd be happy to give it a try!

[Tao-VanJS]

Hmm..., my current thinking is:

van.bind(dep1, dep2, ..., depN, () => a.val + b.val)

will bind dep1, dep2, ..., depN together with a and b (because a.val and b.val is being called inside the generation function).

whenever a generation function is called, we will bind all states whose val property is accessed.

In this way, most of the van.bind calls can indeed be done in the simplest form:

van.bind(() => a.val + b.val)

and can be sugared to just () => a.val + b.val when being used as a child DOM node.

My feeling is this mechanism is correct. But I need to think through it for a few days to make sure.