I was expecting this to be a prank project saying that you should use vanilla JS, my disappointment is immeasurable.
VanJS (Vanilla JavaScript): smallest reactive UI framework
171–180 of 214 posts
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#172Earlier quoted context omitted.
It's been explained well. If you want to point out a fact that paints someone in a bad light, but you are concerned about the fact rather than making people feel bad, you say "I don't want to judge, but [what I say here implies a judgement.]" For example: "I don't want to judge, but I bought a gallon of milk three days ago and didn't get to use a drop of it." My concern isn't that you feel bad about drinking the milk…
>If you want to point out a fact that paints someone in a bad light, but you are concerned about the fact rather than making people feel bad What you do is that you just don't say it... that's what you do if you're actually concerned about painting someone in a bad light / don't know if the fact applies at all.
No. Reality is that people will disagree with other people. And pretending that an opinion has no value because it might upset someone or apply to a generalization or group that isn't intended to mean "all of Group X" so much as "many/most of Group X, from my experience" as a disclosure doesn't mean that the rest of the statement, that could be impersonal or even offensive to some has no value.
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#173I really don't want to be that guy, but... Vanilla JavaScript already exists as a popular term for JavaScript without any framework. No jQuery, no React - just JavaScript. Calling a library VanJS (as short for "Vanilla JavaScript") is just going to cause confusion. The repo's own description uses the phrase vanilla JavaScript in this way, and even mixes both meanings within a single sentence. If the author likes the…
I came to be that guy. Vanilla JavaScript is the term for plain JS without any framework, library or plugins.
window.$ = (selector) =>
applyExtendedTools(Array.from(document.querySelectorAll(selector)));
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#174The "Hello World" example is a really good example of why React, Vue, etc are better than something more minimal like this library if you're optimizing for speed. The page will show nothing until the script runs, which requires downloading the VanJS lib and the script itself. You could inline them into the page, but that gets seriously messy at scale. A modern React app that's using some serverside rendering for the…
There's a "mini-van" renderer and examples on usage for node/deno on the library's website. I actually found that probably more compelling than the JS client library usage.
For me what's missing is wiring with a larger state machine (jotai or similar) and async importing of components at runtime.
In the end, I'm not completely convinced this is better than React/Preact/Inferno, and even then, adding a UI library like mui will get even bigger. It's the patterns and the size/scale of what you're building and how many other devs you would have to develop with that should determine things like this. Are your using on generations old phones where access is akin to slow 3g, or is everyone on a modern 1440p+ desktop with over 30mbps of bandwidth?
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#175Earlier quoted context omitted.
The page will show nothing until the script runs If you know what you are doing you can achieve full state restoration of a large SPA before CSS paints to the screen. In my personal app I am able to complete state restoration within the first 80ms of page load on old hardware. Vue and React are not capable of providing this.
Just encapsulating css and js inside the html works perfectly fine. In a SPA you nowadays use history api for navigation and make dynamic dom changes on the fly. You only have to make sure than you serve the minimum amount of js and css on an initial page load. Then when the page is loaded you load the rest. Slight inefficient cache model when lots of initial page loads from different urls, but usually that's never h…
I often find splitting the difference is useful... embedding the CSS with the HTML, as different routes from the server, delivering the same html will still result in more cache being used, and lack of caching if a user shares/bookmarks something different from what a user may already have cached. async loading for routes and splitting on the bundler can help a lot as well. Similar to async load any graphing/charting libs only on components that need them too.
In the end, it depends on what you are doing... if you're wanting to do paged records against a database, then client rendering can help... The direction of React server components, next.js and the like bridge these gaps well. Combined with edge services like deno deploy, cloudflare pages/workers and others make this even more of a no brainer for many use cases.
There's also a place for pre-rendering most content... I don't know why any marketing or content sight like blogs wouldn't be static rendered at this point. JS enhancement for things like sharing or comments.
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#176Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#177do not call this vanilla js, that's what using no js is called
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#178Earlier quoted context omitted.
>If you want to point out a fact that paints someone in a bad light, but you are concerned about the fact rather than making people feel bad What you do is that you just don't say it... that's what you do if you're actually concerned about painting someone in a bad light / don't know if the fact applies at all.
No. Reality is that people will disagree with other people. And pretending that an opinion has no value because it might upset someone or apply to a generalization or group that isn't intended to mean "all of Group X" so much as "many/most of Group X, from my experience" as a disclosure doesn't mean that the rest of the statement, that could be impersonal or even offensive to some has no value.
If the only person being discussed is the author of the library, and you don’t know them…. what relevance is someone’s experience with other people who share a trait?
The idea of “pretending” here is interesting, I find the whole “ I don't want to judge him” to be its own form of dishonesty….
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#179HTML-builder APIs like this are a pretty bad idea, IMO. They assume that HTML is a closed system with no new tags, and don't account for custom elements or new tags. It doesn't even have support for existing tags like , , or ( is used by some systems now for icons). It doesn't appear to have a way to emit comments. We have the ability to embed real HTML strings, with expressions, directly into JS, which means that th…
Interestingly the `tags` object seems to support any tag name: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...
And it still allows to provide specific types for the known HTML elements: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...
Cool stuff
Re: VanJS (Vanilla JavaScript): smallest reactive UI framework
#180To my eye, this makes vanilla JS more like React rather than making vanilla JS reactive. I'm basically looking for an even lighter Svelte if I can get it. Maybe this just isn't for me!
If you just want to make vanilla js reactive, you can use solid js but without jsx (or something similar). This library could likely do the same.
import { createRoot, createSignal, createRenderEffect } from "solid-js";
function SomeComponent() {
const [count, setCount] = createSignal(0);
const result = document.createElement("button");
createRenderEffect(() => result.textContent = "++ (" + count() + ")");
result.onclick = () => setCount(count() + 1);
return result;
}
createRoot(cleanup => {
const appv = document.getElementById("app");
appv.appendChild(SomeComponent());
});