101–110 of 214 posts
For comparison, similar tiny JS view libraries - https://redom.js.org 2kB - https://nanojsx.io 1kB
nanojsx looks great! I don't really get why mini-van don't use JSX.. Maybe some people just don't want any html tags in their project ? Or maybe their template engine allows a lighter approach.
Earlier quoted context omitted.
Chaining is very... 2010? Mainly because it's used().to().make().awful().APIs().like().this(). It got popular then seems to have died out. href() isn't a function name. One doesn't 'href()' anything.
You know what promises are right?
Do you use JS or TS currently? We've had async/await since ES2017, it's supported everywhere you want, and there's no reason to see .then() chains anymore outside jokes regarding early 2000's film classic "Dude, Where's My Car?".
Pasting some code and cutting out the boring bits:
const transaction = await makeTransaction(...);
const signature = await sendAndConfirmTransaction(...);
const tokenAccountsByOwner = await getTokenAccountsByOwner(...);
Earlier quoted context omitted.
> Seems pretty vanilla No it doesn't, same as "automobile" doesn't seem pretty Saturn-5, despite the fact that both are moving under their own power. Terms have meaning, including meaning derived from communities by and large accepting that a certain term has a certain semantic meaning. And the accepted semantic meaning of "Vanilla Javascript" is "runs without a framework besides the browsers own API". If my code wor…
So loading an external library or framework isn't Vanilla JS, but if I copy/paste the VanJS source into a script tag, nothing gets loaded, there's no syntax magic, just some function calls, so that's Vanilla JS, right? If the latter isn't Vanilla JS by your definition, can I at least copy/paste something from stackoverflow? Trying to make Vanilla JS a strict definition seems pointless to me in the first place.
I think we don't have to argue about the distinction between the library code and the application code. It doesn't matter how the library is loaded. You can get it from a CDN at runtime, load it from a scriptbundle, copypaste it into a tag, it doesn't matter.
It's still library code that the rest of the application depends on. As soon as that is the case, it's no longer what the JS community by and large calls "Vanilla JS".
This is Vanilla JS:
fetch('/readme.txt')
.then(response => response.text())
.then(data => console.log(data))
.catch(error => console.log(error))
awesomeLib().goesBrrrrr()
Being able to name things, and having clarity in a community about what names denote, is anything but pointless.
Earlier quoted context omitted.
There's a bit of work to do to make a JS framework work server side. You need a mechanism to render in Node, which assumes you don't use any browser APIs that aren't available in whatever DOM library you use. Then you need a way to stream the HTML to the client, but that's easy with Express. Then when the page has loaded on the client you need a way to know what the server rendered and attach listeners to the reactiv…
Given that van replace the whole tree each time a value changed, SSR for van is simpler. You run chrome server side, capture the DOM once van has finished its first execution and modify the HTML of the page to includes the new nodes.
Earlier quoted context omitted.
> Building an app that renders a complex page in under 16ms isn't that easy if there's a lot going on We struggle to render a few boxes and some text under 16ms while games with vastly more complex sound, network, physics, UI and whatever else systems render frames in < 8ms at 4k.
We struggle to render a few boxes and some text under 16ms Only if a dev has screwed up. Most simple sites are fine. You have to push the DOM quite hard for the browser to be the bottleneck. I've worked on apps that have DOM trees with 60,000+ nodes that remain under 16ms (because very few were actually changing at any given time..) games with vastly more complex sound, network, physics, UI and whatever else systems…
You mentioned that frameworks like React make it simpler to get better performance but based on my observations it's quite the opposite and React is often a double barreled gun where one of the barrels is constantly pointing at your feet. With vanilla JS (not the one from this post) you have to put effort to get everything to update properly. With React you put effort to get the least amount of things to update. It's not even about DOM size but about managing state and how much code gets run on state change.
To give you an example - Reddit is a simple website. You have a list of posts which are either text, image, or a video and each of them has comments. Absolutely nothing complicated about that, yet the performance on their React frontend, even with all analytics JS and ads blocked, is horrendous. You would assume that at Reddit's scale they'd be able to hire competent React developers.
Earlier quoted context omitted.
Given that van replace the whole tree each time a value changed, SSR for van is simpler. You run chrome server side, capture the DOM once van has finished its first execution and modify the HTML of the page to includes the new nodes.
Don't run chrome on the server for SSR, I beg you. That's a massive performance hit and scales terribly with all the memory usage.
I 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 was confused reading the page and expected a description of a pattern I could use in actual vanilla JavaScript without any dependencies.
The term 'zero-dependency' played a role in my confusion. "VanJS" is a dependency.