You're jaded. Look at this as someone completing the exercise to understand reactive frameworks by implementing a toy implementation. Like when someone implements yet another lisp. Maybe you disagree with it getting to front page, but then don't upvote & move on. There'll always be some amount of front page content someone considers crap & it's best if we don't collectively fill every comment thread disparaging about it

> Look at this as someone completing the exercise to understand reactive frameworks by implementing a toy implementation

I don’t think that’s the intention of the author or the person who posted this or the people who voted it to the top of HN

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 maybe in five years some of the ideas in here will become more mainstream, and a future version of React (or a different framework) may adopt them.

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!

I think your cynicism is warranted for you. Like if you're not looking for a new framework and you are interested in the new, shiny JS refactor, don't bother. I live a happy life, using the same framework and never looking at all the other stuff.

But at one point our big contenders were also shiny and new, and I am glad someone less cynical than me was willing to put them to the test.

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.

FWIW, VanJS's performance is very impressive. At least much better than React: https://vanjs.org/#performance

>Does the amount of written lines of code matter when there's modern linters and tooling?

So long as JavaScript is interpreted it matters a whole lot on mobile devices.

The amount of code delivered and executed on the device has a huge bearing on performance on lower end devices. Unless you're on some $1000+ phone and arguing from a place of privilege.

Let them reinvent it. You are not required to learn it right now. If it really manages to become widely used you can learn it then. If not well the guy is spending his own time on doing something he likes.

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 85kB all-included framework? Skillset, maintenance burden, compatibility matter.

> 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.

Sure? I was looking in the network tab of Firefox.. Mhh, strange.

You should also be mad at all the people making game engines, compilers, llm's, and container hosts.

People feel unsolved problem for them and want a better solution for them individually. As you said “anyone can” so “anyone will”. Just ignore posts like this ;). After 20 years of experience just pay attention to v1 of anything :)

The problem is not size. The problem is installation, configuration, dependencies, transpilation, IDE setup, etc. And here you have the plain old notepad with browser - nothing else...