121–130 of 178 posts
The 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...
Is there a reason they compare bundle sizes with for example jquery when every framework ends up importing jquery anyways, since animations are a headache and are often readily available already with jquery?
Evidence?
The 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...
I don't mean to throw any shade on Tao. He is very talented & his approach is beneficially novel. I just don't think he as much experience what life is like as a full stack (or front end) developer as many here.
I forked his work to create relementjs & rmemo. Tao didn't want to support server side reactivity & I heavily use it. Also, Andrey (maintainer of Nanostores) didn't want to add my PR for autosubscriptions due to the complexity cost that would be added to Nanostores...So I wrote my own set of libraries. I hope library simplicity trends more because it is very nice to work with simple libraries.
Tao's approach is sound. He just relies on the DOM to manage the reactive state, so SSR reactivity would require a different approach. I ended up using WeakRef, which is significantly smaller than the approach used by traditional reactive state management libraries.
Earlier quoted context omitted.
It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.
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!
Earlier quoted context omitted.
What would the alternative be? How can you design a UI without nesting things?
Too much nesting usually signals that you should decompose it to smaller components. Same as with regular code and functions — overly deep nesting screams bad code. Honestly, JSX is just a verbose way of calling functions / constructing objects, which is probably OK if it was a language of its own (XML/HTML) — and even then, JSON/YAML won over XML — but makes little sense being embedded in a language which had functi…
> (A rule that can be told by words, is not the rule that should universally apply)
I'm curious where the dev got that translation or if they made it themselves. I have translated it before like "No method that can be explained is universally applicable" but I haven't seen many other translations like that.
Earlier quoted context omitted.
It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.
JSX does seem to fit that niche better than any other alternative I've tried. It pulls off a rather remarkable trick of avoiding the "uncanny valley" that you usually get from starting with a language and contorting it to do something different. JSX manages to feel just about right: it's plain-old-HTML when you want it to be, and plain-old-Javascript when you need an out. Still... I wouldn't mind writing in a truly s…
https://github.com/relementjs/relementjs
https://github.com/rmemo/rmemo, which exports https://github.com/ctx-core/ctx-core/tree/main/rmemo. Note that rmemo also supports server side reactivity.
After reading the tutorial at https://vanjs.org/tutorial I was about to open an issue suggesting that they include constants with the SVG and MathML namespace, so that this: const {circle, path, svg} = van.tagsNS("http://www.w3.org/2000/svg") const {math, mi, mn, mo, mrow, msup} = van.tagsNS("http://www.w3.org/1998/Math/MathML") Could be expressed like this instead: const {circle, path, svg} = van.tagsNS(van.SVG) con…
Oh wow, didn't know ChatGPT could de-obfuscate code!!
I don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
JSX is redundant, at best. VanJS demonstrated ordinary JavaScript syntax is as good as JSX, if not better. How can something feel sugar-ish if it's actually more verbose than ordinary JS code? Plus, you can't really execute JSX code in browser's developer console.
I personally find XML much easier to parse than a lot of nested callbacks and I especially like that content is always inside tags, rather than another argument as part of the library's functions. p("Hello, world") is readable enough, but as soon as you start adding html attributes, it becomes less legible to me:
li(a({href: "https://vanjs.org/"}, "VanJS"))
vs.
VanJS" rel="nofollow noreferrer">https://vanjs.org/">VanJS
I'm certain some people probably prefer the former over the latter, but I much prefer how JSX/XML reads. I can immediately tell where the content starts and in formatted code, I think it's a lot easier to see visually where things start and end, because of closing tags, instead of just a parentheses.