Live data from Hacker News

VanJS – A no-JSX framework based on vanilla JavaScript

vanjs.org

41–50 of 178 posts

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

#41

People complaining about lack of JSX, HTML angle-brackets: I don't get it. XML gets all the hate for being overly verbose (and for good reason [1]) however with HTML syntax, which is almost the same, everybody seems to be just fine... [1] XML is sooo nineties, the "modern" developer uses markdown. inb4 S-Expressions (...yes I know)

For me it's about not to learn yet another new syntax, and HTML is here to stay.

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

#42

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)

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

#44

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)

More like:

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

#45
post #31
post #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

Modern reactive UI frameworks get away from maintaining virtual dom. If you want minimalist vdom preact is a great choice. If you'd like to part ways with vdom while keeping jsx, try svelte or solid-js

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

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

#46

People complaining about lack of JSX, HTML angle-brackets: I don't get it. XML gets all the hate for being overly verbose (and for good reason [1]) however with HTML syntax, which is almost the same, everybody seems to be just fine... [1] XML is sooo nineties, the "modern" developer uses markdown. inb4 S-Expressions (...yes I know)

For me it's about not to learn yet another new syntax, and HTML is here to stay.

If you know JS (or any other C family language), the syntax is not new.

It's about getting rid of a flawed syntax.

But it'll probably never happen because people are used to it and oblivious to change.

Unless of course if one of the FAANG publishes it as their New FrameWork [tm], then everybody will jump on it, and people that don't are seen as "not modern".

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

#47
post #31

Earlier quoted context omitted.

Modern reactive UI frameworks get away from maintaining virtual dom. If you want minimalist vdom preact is a great choice. If you'd like to part ways with vdom while keeping jsx, try svelte or solid-js

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 batching updates to reduce rerenders since it eagerly updates dom. It feels like one needs to be more meticulous

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

#48

Earlier quoted context omitted.

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

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

#49

Earlier quoted context omitted.

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

More like:

Please no

The {...} syntax is a non-standard extension to XML/HTML I think MS came first up with back in the day for XAML (WPF).

It's a hack to "fix" a shortcoming of the base language.

It does not compose, i.e. :

} />

does not work.

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

#50
This looks great! I love having the ability to bring existing React/JSX knowledge and be productive with VanJS, while also ditching the transpilation and build tool wildness that has afflicted the ecosystem.

React and JSX were needed in 2013, but with the power and convenience packed into new ES standards and supported by modern browsers, React and JSX should be viewed as bloated polyfills at this point.

It’s really heartening to see things trending back toward single script tags that help you avoid build tools, churn, and dependency hell. To that end, I’m leaning toward htmx for my own project, but what you’ve come up with looks really enticing as well.

Post reply on HN