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.
VanJS – A no-JSX framework based on vanilla JavaScript
161–170 of 178 posts
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#162The 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…
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#163This 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…
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#164What about https://www.arrow-js.com/
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#165This 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
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
#166Earlier 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…
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#167Earlier 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.
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
#168Re: VanJS – A no-JSX framework based on vanilla JavaScript
#169Earlier 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)) ); };
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#170Earlier 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?
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.