Is this is what you are looking for? https://vanjs.org/vanui#await

Hmm, maybe! Is that the idiomatic way to do async? I was thinking something along the lines of this, which react devs will have written a variation of plenty of times :)

    import { useEffect, useState } from "react";

    const GithubUser = ({ login, avatar_url, html_url }) => (
      <div>
        <img src={avatar_url} style={{width:40, height:40}}/>
        <a href={html_url}>{login}</a>
      </div>
    );

    export function App() {
      const [stargazerResp, setStargazerResp] = useState([]);
      const [repo, setRepo] = useState("vanjs-org/van");

      useEffect(() => {
        fetch(`https://api.github.com/repos/${repo}/stargazers?per_page=5`)
          .then((r) => r.json())
          .then((r) => Array.isArray(r) ? setStargazerResp(r) : setStargazerResp([]));
      }, [repo]);

      return (
        <div className="App">
          <input value={repo} onChange={(e) => setRepo(e.target.value)} />
          <ul>
            {stargazerResp.map((s) => (
              <li key={s.login}>
                <GithubUser
                  login={s.login}
                  avatar_url={s.avatar_url}
                  html_url={s.html_url}
                />
              </li>
            ))}
            </ul>
        </div>
      );
    }

You can do with VanJS in this way as well. `set...` functions in React map to `....val = ...` in VanJS (which I think is more intuitive). But the `Await` component is a good abstraction so that you can specify what to show when the resources are being fetched and what to show when there are errors while fetching the resources.

Would we expect the list to re-render once the fetch finishes? This may just be years of react poisoning my brain

    const Stargazers = () => {
      const stargazers = van.state([]);
      fetch(`https://api.github.com/repos/vanjs-org/van/stargazers?per_page=5`)
        .then((r) => r.json())
        .then((r) => stargazers.val = r);
      
      return ul(
        stargazers.val.map((s) => li(s.login))
      );
    };

Yes. This is how VanJS works. Code with VanJS is often more concise compared to equivalent code with React.

Ah ok! Very cool. Maybe I'm still missing a tiny piece of syntax? I don't see any output when I run that code in the fiddle

https://jsfiddle.net/397fb684/

Ah.. you need a binding function to wrap the state-derived content into a reactive UI element, see: https://vanjs.org/tutorial#state-derived-child. I made the change in your code to make it work: https://jsfiddle.net/rkfmpx06/1/

Oh! I understand, thanks for walking through that. Yes very terse compared to the equivalent react :)

Here is the break down of my understanding about the philosophy described in 道德经:

1. There might be some universal rules about the world. 2. There are limitations in human's understanding and human language. 3. For all the rules that can be described in human language (which is subject to the limitations in 2), they can't hold universally.

Putting into the context where the words are cited. Any claim (in human language) about programming like "you should program in this way" is most likely not universally sound.

Of course a philosophy book 2000+ years ago can be interpreted in a different way. Happy to see the elaboration of your understanding "No method that can be explained is universally applicable".

The word dao literally means “road” but by the time of the DDJ, it had come to mean “way of doing something” and “speech that explains how to do something”. Interestingly, in Greek “method” is meta + hodos and hodos means “road” so it’s an etymologically appropriate translation.

道 (dao) means "the way of doing thing" in modern-day Chinese as well. For instance, 王道 means the "the way of governing". 路 is more common for the literal meaning of "road", though 道 has a meaning of both "road" and "waterway" as well.

States are mutable whose value can be get/set via the ".val" property. However, the value of the states should be (ideally) an immutable object (or primitives).

Yeah I understood that better, thanks.

My current best score is 125. Feel free to share your score here :-)

If you care enough to do your own research and math, you will definitely know that <# forks> / <# stars> for VanJS is in a normal range.

Did you realize this is true for many GitHub projects? Also "used by" for VanJS is undercounted as it only counts the projects with NPM integration, which was only added recently in the 1.0 release.

A web-based Unix terminal with notable improvements, built with VanJS - https://vanjs.org/. Under 300 lines in total.

We've seen numerous efforts to bring in more modernized terminals and shells. VanJS goes with the other direction. Why not making building UI apps as simple as CLI programs so most of us aren't confined to the limitations of terminals? Indeed, even for the quest of modernizing terminals, VanJS is pretty good at it.

So, what's the problem here?