Live data from Hacker News

VanJS – A no-JSX framework based on vanilla JavaScript

vanjs.org

21–30 of 178 posts

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

#21

The whole “small footprint” thing is always weird to me. I understand that lots of people really want to squeeze efficiency out of every single kb but Im struggling to see where this is helpful. A single image, a single pixel from the marketing team, the actual application code, the page, etc are all going to dwarf the framework.

Coming from living in third world countries where I had to ration data transfer, at speeds ranging equally from 50kbps to 1mbps, I appreciate these efforts greatly

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

#22
Feels weird to seem to seriously represent your framework as being about size without including a comparison to preact - the obvious choice for a react developer looking to reduce their footprint.

Preact claims 3kb on their site, and for a 3-4x savings you're going to need to be fairly compelling. I don't mind paying a modest cost for 10x or 100x improvements, but (call it Stockholm syndrome) I like react syntax

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

#23
post #5

This doesn't look too bad for pushing down minimal dom manipulation, since it includes reactivity Looking at my own use of solid, things this is missing are: - jsx - stores (having some way to hook into van's reactivity would address this, maybe digging into van.state internals there's a way) - onMount/onCleanup - For/Index/Show which helps handle efficient reuse, this could probably be built as a layer on top of van…

> jsx

I don't agree, this syntax for html is much nicer than JSX when you get used to it. Converter from HTML at https://www.solenya.org/convert

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

#25
post #12

The whole “small footprint” thing is always weird to me. I understand that lots of people really want to squeeze efficiency out of every single kb but Im struggling to see where this is helpful. A single image, a single pixel from the marketing team, the actual application code, the page, etc are all going to dwarf the framework.

Not necessarily. Lots of jpegs go below the 1 mb mark (and tons of framework are bloated like crazy)

I think you misread the title. The framework is 0.9kb, not 0.9mb.

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

#27

Why do people even reinvent this wheel every few months? Does the Anyone can build a "reactive" type framework by following tutorials online now, they're super in vogue. Is my cynicism here warranted, or am I just jaded from 20 years of watching pendulums swing left and right and watching the wheel be reinvented over and over?

[dead]

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

#28
post #7
post #3

Oh, this is literally Xeact. https://xeiaso.net/blog/xeact-0.0.69-2021-11-18/

Not literally

While literally literally does not mean figuratively, people often use literally to say figuratively with extra emphasis, to the point where some dictionaries literally⁰ list figuratively as a secondary meaning for literally.

Yet another example of language evolving through variations in common use that take hold.

--

[0] literally literally, not figuratively literally

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

#29

The whole “small footprint” thing is always weird to me. I understand that lots of people really want to squeeze efficiency out of every single kb but Im struggling to see where this is helpful. A single image, a single pixel from the marketing team, the actual application code, the page, etc are all going to dwarf the framework.

It’s about execution cost, not size over the network.

I think this is why, for me, the future of JS are resumable frameworks like Qwik and Marko 6 – you get all the benefits of NextJS + React (composable UIs, state management, server-side code, etc) with no hydration, which is a big cause of sluggishness with web apps.

Your code only executes when needed, and only that specific chunk of functionality.

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

#30

Why do people even reinvent this wheel every few months? Does the Anyone can build a "reactive" type framework by following tutorials online now, they're super in vogue. Is my cynicism here warranted, or am I just jaded from 20 years of watching pendulums swing left and right and watching the wheel be reinvented over and over?

The amount of code matters when the lowest-performing Androids on the market have an order of magnitude less single core performance than a modern iOS device. V8 parse times have got much better over the last few years (they used to be a big bottleneck) but you’ve still got major execution cost leading to bad user experience.

The code size is a poor proxy for performance though. React likely has some areas which are much more performant just because of development efforts, even if it's larger. If we want performance, that's the metric that should be public and clear.
Post reply on HN