Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VanJS – A no-JSX framework based on vanilla JavaScript

vanjs.org

Post reply on HN
Print view View original

61–70 of 178 posts

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

#61

Post by [deleted] »

__s wrote: post #47
threatofrain wrote: post #45

Earlier quoted context omitted.

What are the long term theoretical benefits of vdom? Concurrent rendering?

At least with solid, you can't do `const a = ` without caveats. Instead you have to store it as `const a = () => ` (which isn't quite the same, having problems managing state/renders). In React I was optimizing things by storing vdom in state/memo & then interpolating that exact vdom. Or sharing vdom in multiple places. Without vdom you can't throw jsx results around so haphazardly In solid there's also managing batc…

[deleted]

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

#63

Post by iamsaitam »

3dGrabber wrote: post #42
iamsaitam wrote: post #37

Why do people dislike JSX? For me the lack of JSX is a negative point. Why would I want to write nested functions everywhere? JSX is HTML on steroids, but it can be just HTML if you wish it.

Why would you insist to write the function name both before AND after the call? args vs DoStuff(args)

Is this the main argument? I think the simplest answer is boundaries. Taking into account how much nesting is involved in writing HTML, it's a clear benefit having a named boundary vs a closing parenthesis.

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

#64

Post by jrajav »

__s wrote: post #47
threatofrain wrote: post #45

Earlier quoted context omitted.

What are the long term theoretical benefits of vdom? Concurrent rendering?

At least with solid, you can't do `const a = ` without caveats. Instead you have to store it as `const a = () => ` (which isn't quite the same, having problems managing state/renders). In React I was optimizing things by storing vdom in state/memo & then interpolating that exact vdom. Or sharing vdom in multiple places. Without vdom you can't throw jsx results around so haphazardly In solid there's also managing batc…

The flipside of this is that in React you are paying the cost of active vdom all the time, even when it doesn't pay off by optimizing large batched updates. In Solid, you sometimes have to optimize for some eager updates, true. That will have to be done at some point, though, when the situation calls for it - in either a specific or a general way. It feels natural to shift that optimization to the state layer, and completely eliminate the need for vdom, at the expense of some more thought and active, upfront work. It's a similar tradeoff to spending more time crafting static typing that works well, versus forgoing static types. The tradeoff seems to have good effect too - Solid seems much faster than React both on paper and in practice (my personal experience).

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

#65

Post by jrajav »

xiphias2 wrote: post #20

This is where most libraries are going. Svelte 5 builds upon these signals / derivations as well, and I guess a bunch of other libraries. It would be time for them to get together and standardize on a signals library at this point that could be adopted to be a web standard and help interoperability between web components built with different frameworks.

I fully agree with the sentiment, but Svelte does not seem like a natural leader on that front since their version is a JS superset. Already a bit off the map for interoperability.

Solid's attempt feels more promising since it's building on existing native functionality (proxies / getters), and has intuitive, low-footprint usage (just function calls and reference comparisons).

Edit: It seems I'm not up to speed in fact, I hadn't seen Svelte 5 and runes yet, which are not compile-time. I will need to give it another try. I agree in general that signals and signal-based APIs are the future and definitely better than hooks at least, and a single agnostic standard would be good for everyone.

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

#66

Post by downvotetruth »

n2d4 wrote: post #15
codebeaker wrote: post #4

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?

For privacy reasons, resources are no longer cached across origins, so the size does matter (though arguably 1KB more or less makes absolutely no difference on any webpage that has a medium-sized image, especially if you have SSR for the first paint). But the better reason why these projects exist is for experimentation and iteration. It's not like everyone who uses React will switch to this over the holidays, but ma…

It is strange when this was rolled out as to why decentralizeyes like functionality was not targeted to be built into browsers enabled by default.

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

#67

Post by 3dGrabber »

iamsaitam wrote: post #63
3dGrabber wrote: post #42

Earlier quoted context omitted.

Why would you insist to write the function name both before AND after the call? args vs DoStuff(args)

Is this the main argument? I think the simplest answer is boundaries. Taking into account how much nesting is involved in writing HTML, it's a clear benefit having a named boundary vs a closing parenthesis.

> Taking into account how much nesting is involved in writing HTML

which is another one of its flaws.

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

#68

Post by mdavid626 »

helsinkiandrew wrote: post #33
theandrewbailey wrote: post #24

This is unacceptably huge compared to the similarly named Vanilla JS. http://vanilla-js.com/

> This is unacceptably huge compared to the similarly named Vanilla JS. It took me a minute to get it. 0 bytes uncompressed, 25 bytes gzipped

Can you enlighten us?

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

#69

Post by dmit »

buster wrote: post #60
bovermyer wrote: post #10

Earlier quoted context omitted.

Size does still matter. Just because we _can_ serve huge amounts of data over the pipe quickly doesn't mean we _should_.

Except... the huge amount is photos and fonts and whatnot. As you can see on the vanjs size, the biggest framework Angular weights 85 kB and it will be cached. Compared to what Angular also brings in functionality, i don't see size of the framework as an argument anymore. Consider Hackernews: hn.js comes with 21,4 kB. The Y logo on the upper left is a 46,32 kB SVG! What should i care about 1kB minimal framework or 85…

> Consider Hackernews: hn.js comes with 21,4 kB. The Y logo on the upper left is a 46,32 kB SVG!

hn.js is just north of 5.2kB (2.3kB compressed), and the logo is 315 bytes.

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

#70

Post by n2d4 »

downvotetruth wrote: post #66
n2d4 wrote: post #15

Earlier quoted context omitted.

For privacy reasons, resources are no longer cached across origins, so the size does matter (though arguably 1KB more or less makes absolutely no difference on any webpage that has a medium-sized image, especially if you have SSR for the first paint). But the better reason why these projects exist is for experimentation and iteration. It's not like everyone who uses React will switch to this over the holidays, but ma…

It is strange when this was rolled out as to why decentralizeyes like functionality was not targeted to be built into browsers enabled by default.

Because it's a different threat model: Separating caches per-origin prevents a site A from seeing what resources you requested on site B.

But something like Decentraleyes prevents site A from seeing what resources you requested on site A.

(Or rather, whichever CDN provider site A is using.)

You could have both at the same time, but they are orthogonal. As for why it's not in browsers, assuming good intent, I'd think it's because it requires you to bundle a whole lot of libraries with the browser for it to be useful as a local CDN. If browser vendors decided which JS frameworks are bundled with the download and which ones are not, I'm not sure if that would help decentralisation!

Post reply on HN