Live data from Hacker News

VanJS – A no-JSX framework based on vanilla JavaScript

vanjs.org

161–170 of 178 posts

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#161
post #106

Earlier quoted context omitted.

Not needing to use a transpiler is genuinely the thing that excites me most about VanJS. If you're not a daily JavaScript developer, any form of transpiler / build mechanism seems almost guaranteed to break in the gaps between when you are working on a specific project. The projects I have that are transpiler/build free are SO MUCH more pleasant for me to intermittently hack on!

I use TypeScript exclusively over Javascript so being pure JS is a con not a pro to me.

The library does have Typescript definitions available to use.

https://github.com/vanjs-org/van#typescript-support

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#162
post #115

The author seems to be chasing the small size trophy at any cost...to the point where he's using "var" instead of "const" because it saves a few bytes. Not indicative of someone serious...

The author works as a back end engineer @ Google. I appreciate his "outsider" approach as it is quite a bit simpler than other UI libraries & even reactive state management libraries such as Nanostores. I'm sure if he were in a different development role, his technique would be refined to account for full stack development use cases. I don't mean to throw any shade on Tao. He is very talented & his approach is benefi…

Where is your repo link?

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#163

This is cool, though I think a table-stakes example that is missing is how to do a network request. I see the stargazers example but that entire component is awaited, which doesn't mirror the common case of async fetch in response to user input, in which the response is fed to sub-components. The stargazer example leaves me with questions like- are components both async and non-async? What if the component re-renders…

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

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#165
post #163

This is cool, though I think a table-stakes example that is missing is how to do a network request. I see the stargazers example but that entire component is awaited, which doesn't mirror the common case of async fetch in response to user input, in which the response is fed to sub-components. The stargazer example leaves me with questions like- are components both async and non-async? What if the component re-renders…

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 }) => (
      
        
        {login}
      
    );

    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 (
        
           setRepo(e.target.value)} />
          
            {stargazerResp.map((s) => (
              
                
              
            ))}
            
        
      );
    }

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#166
post #163

Earlier quoted context omitted.

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 }) => ( {login} ); export function App() { const [stargazerResp, setStargazerResp] = useState([]); const [repo, setRepo] = useState("vanjs-org/van"); useEf…

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.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#167
post #166

Earlier quoted context omitted.

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 }) => ( {login} ); export function App() { const [stargazerResp, setStargazerResp] = useState([]); const [repo, setRepo] = useState("vanjs-org/van"); useEf…

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))
      );
    };

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#168
post #107
post #58

Either you should statically/server generate your site, or you have rich content that needs a client side app and you should pick a framework with rich features.

If you're worried about an extra network round-trip, section of your document.

Frameworks need product code.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#169
post #166

Earlier quoted context omitted.

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.

Re: VanJS – A no-JSX framework based on vanilla JavaScript

#170
post #86

Earlier quoted context omitted.

Sure thing. But it's also one of those things that comes back to bite you when you least expect it: https://vanjs.org/advanced#why-not-dom-valued-states

I don't get you. Could you elaborate?

In the example I linked, the VanJS state cannot contain an element reference.

This would lead to unexpected results. So you have to be careful with state management, regardless of whether it's automated or not. There are similar pitfalls, including performance issues, with any state management system, hence dedicated state management solutions like Redux exist to address this.

The core of the argument is that complexity sometimes cannot be avoided. You can quickly wind up with moving this complexity elsewhere, e.g. by pulling in an additional library dependency. This results in having to learn, master and manage additional dependencies. Whether that's fundamentally better than the explicit and straight forward way depends on the scope of the project and its specific requirements. There's no silver bullet in any case and pros and cons with every approach.

Post reply on HN