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.
VanJS – A no-JSX framework based on vanilla JavaScript
21–30 of 178 posts
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#22Preact 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
#23This 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…
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
#24Re: VanJS – A no-JSX framework based on vanilla JavaScript
#25The 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)
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#26Re: VanJS – A no-JSX framework based on vanilla JavaScript
#27Why 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?
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#28Oh, this is literally Xeact. https://xeiaso.net/blog/xeact-0.0.69-2021-11-18/
Not 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
#29The 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.
Your code only executes when needed, and only that specific chunk of functionality.
Re: VanJS – A no-JSX framework based on vanilla JavaScript
#30Why 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.