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

VanJS (Vanilla JavaScript): smallest reactive UI framework

github.com

Post reply on HN
Print view View original

51–60 of 214 posts

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#51

Post by ohgodplsno »

jitl wrote: post #23
aspyct wrote: post #8

Earlier quoted context omitted.

Yes, please be that guy. Or I'll do it. Vanilla Javascript refers indeed to "javascript without a framework". So creating a framework and calling it "vanilla javascript" is... wrong?

It’s 93 lines, less than most CSS resets. Small enough to copy paste to the top of your index.html in a script tag. You can use it without NPM, webpack, a special compiler pass, or a template language. Seems pretty vanilla compared to the full fat, popular alternatives.

Minified React is 1 line, line length isn't exactly a great judge of how much it does.

It's 3KB of barely documented code.

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#52

Post by onion2k »

threatofrain wrote: post #22
onion2k wrote: post #14

The "Hello World" example is a really good example of why React, Vue, etc are better than something more minimal like this library if you're optimizing for speed. The page will show nothing until the script runs, which requires downloading the VanJS lib and the script itself. You could inline them into the page, but that gets seriously messy at scale. A modern React app that's using some serverside rendering for the…

I'd argue that SSR is somewhat orthogonal to React or VanJS. I don't see preliminary reasons to suspect that VanJS will be unable to plug into meta frameworks and eventually get SSR.

There's a bit of work to do to make a JS framework work server side. You need a mechanism to render in Node, which assumes you don't use any browser APIs that aren't available in whatever DOM library you use. Then you need a way to stream the HTML to the client, but that's easy with Express. Then when the page has loaded on the client you need a way to know what the server rendered and attach listeners to the reactive bits (and optionally to rerender in the background on the client to check things are working properly). That's assuming you don't bother with things like lazy loading and dynamic imports, which will make devs a bit cross because those are really nice things to have.

It's not a huge amount of effort and it's definitely achievable by a single dev leaning on some existing libraries, but it would mean giving up on some of the lightweight aspects of Van, and, like I said, you'll end up half way to building your own React library...

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#54

Post by chrsjxn »

mattigames wrote: post #47

If I was making this kind of mini framework instead of this a({href: "https://vanjs.org/"}, "VanJS") I would have gone with this shorter way a("VanJS").href("https://vanjs.org/") And make it chainable and allow class names as second argument as in a("About us", ".big.red").href("/about.html").target("_blank")

Tag functions being implemented with a Proxy (https://vanjs.org/tutorial#api-tags) could make that a little cumbersome, and would break the abstraction that `div(...)` just returns an HTMLDivElement you can do whatever you want with.

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#55

Post by nailer »

jitl wrote: post #23
aspyct wrote: post #8

Earlier quoted context omitted.

Yes, please be that guy. Or I'll do it. Vanilla Javascript refers indeed to "javascript without a framework". So creating a framework and calling it "vanilla javascript" is... wrong?

It’s 93 lines, less than most CSS resets. Small enough to copy paste to the top of your index.html in a script tag. You can use it without NPM, webpack, a special compiler pass, or a template language. Seems pretty vanilla compared to the full fat, popular alternatives.

That's nice but still: don't do that. VanillaJS is already a thing. Make your thing have a different name.

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#56

Post by mattigames »

chrsjxn wrote: post #54
mattigames wrote: post #47

If I was making this kind of mini framework instead of this a({href: "https://vanjs.org/"}, "VanJS") I would have gone with this shorter way a("VanJS").href("https://vanjs.org/") And make it chainable and allow class names as second argument as in a("About us", ".big.red").href("/about.html").target("_blank")

Tag functions being implemented with a Proxy ( https://vanjs.org/tutorial#api-tags ) could make that a little cumbersome, and would break the abstraction that `div(...)` just returns an HTMLDivElement you can do whatever you want with.

Yeah, plus I realized after posting that for nesting children it would mean having the properties at the end, not very dev-friendly, maybe the way this lib does it is the best way (without JSX or anything like that)

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#57

Post by nailer »

mattigames wrote: post #47

If I was making this kind of mini framework instead of this a({href: "https://vanjs.org/"}, "VanJS") I would have gone with this shorter way a("VanJS").href("https://vanjs.org/") And make it chainable and allow class names as second argument as in a("About us", ".big.red").href("/about.html").target("_blank")

Chaining is very... 2010? Mainly because it's used().to().make().awful().APIs().like().this(). It got popular then seems to have died out.

href() isn't a function name. One doesn't 'href()' anything.

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#58

Post by hu3 »

progx wrote: post #45
pyrolistical wrote: post #28

What does “unopinionated Reactive UI framework” even mean?

Use it as you want, it will not force you to build your UI in a specific way.

But it does force:

    const Hello = () => div(
      p("Hello"),
      ul(
        li("World"),
        li(a({href: "https://vanjs.org/"}, "VanJS")),
      ),
    )

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#59

Post by _old_dude_ »

robertoandred wrote: post #11

Not sure how this is any more natural than JSX/HTML. It looks much messier and harder to follow. Also I’d like to see how they handle mount/unmount logic like event listeners.

No shadow dom, so no mount/unmount logic ! A whole new DOM sub-tree is re-created each time a value change.

There is an example in the tutorial about how state are handled [1]. [1] https://vanjs.org/tutorial#state-binding

Re: VanJS (Vanilla JavaScript): smallest reactive UI framework

#60

Post by onion2k »

10xDev wrote: post #33

Web development is going to come full circle once everyone comes to terms with the fact that web development has been overcomplicated and you don't need 1000 packages and abstractions on top of abstractions just to interact with some DOM elements.

you don't need 1000 packages and abstractions on top of abstractions just to interact with some DOM elements

I don't think many developers believe that you do. Most of the complexity around 'modern web dev' isn't about achieving the basics of moving DOM nodes around. If that's what you're doing then it's hard to argue that a framework adds much benefit.

Frameworks bring two benefits:

Firstly, they push you down a specific path around the shape of the code. When you're on a team of 20 working on part of an app that shares data across n other components then you need something to keep the code from turning into a swamp. Frameworks bring that experience. You don't need it on a small app or if you're a lone dev, but even then it kind of helps if you're not especially disciplined. If you want an example, have a look at some of the demos from the react-three-fiber team. It's so much nicer to work with a declarative API than imperative vanilla Three.js code.

Secondly, frameworks used well enable you to eek out additional perf. Building an app that renders a complex page in under 16ms isn't that easy if there's a lot going on, and leaning on a scheduler like the one in React makes it simpler. It's still far too easy to get it wrong and kill all your perf even in a framework though.

Post reply on HN