VanJS (Vanilla JavaScript): smallest reactive UI framework | Hacker News Reader

VanJS (Vanilla JavaScript): smallest reactive UI framework

github.com

252 pointsLwrless204 comments

I really don't want to be that guy, but... Vanilla JavaScript already exists as a popular term for JavaScript without any framework. No jQuery, no React - just JavaScript. Calling a library VanJS (as short for "Vanilla JavaScript") is just going to cause confusion.

The repo's own description uses the phrase vanilla JavaScript in this way, and even mixes both meanings within a single sentence.

If the author likes the theme, I'm sure they can still use it indirectly. eg. "icecream.js: add a scoop of vanilla to your project". Or "Go nuts and sprinkle in some Reactive syntax". It's still very punnable, I assure you.

Yea kinda felt the same, when reading the name and desc. Whats the value of names or terms if we keep reassigning a different meaning to it ? Especially in the tech industry.

Also it's almost immoral calling "a new" project "lightweight" and "small". Of course it is lightweight and small, it's a new project ! Wait for bug submissions, feature requests, feature parity, time, edge cases etc.

Anywhoo congrats on shipping something.

> Also it's almost immoral calling "a new" project "lightweight" and "small". Of course it is lightweight and small, it's a new project !

Unless it's Swing, where a "lightweight" component is one that uses enormous piles of slow Java code to duplicate native platform functionality.

Never understood why Java duplicated (poorly) native platform functionality rather than merely acting as a wrapper around the native platform.

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?

A framework build not to be a framework, it's almost philosophical :)

https://plato.stanford.edu/Archives/Fall2012/entries/liar-pa...

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.

Seems pretty vanilla compared to the full fat, popular alternatives? Absolutely!

Does it seem vanilla compared to vanilla? Haha..

You're mixing metaphors there! It might be lightweight but it's still a flavour.

It's still not part of the common browser API, so yes it's easy to add, but no, it's not vanilla.

> it's still a flavour.

> it's not vanilla.

Hate to interrupt, but vanilla is a flavor. And it's a pretty good one, dammit!

Insofar as the discussion on the name "vanilla javascript" goes, this mixes metaphors.

"Vanilla JavaScript" implies "without anything added".

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.

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

If I tell someone to "just use vanilla js" and they go googling and end up using VanJS instead.... that aint good.

> Seems pretty vanilla

No it doesn't, same as "automobile" doesn't seem pretty Saturn-5, despite the fact that both are moving under their own power.

Terms have meaning, including meaning derived from communities by and large accepting that a certain term has a certain semantic meaning. And the accepted semantic meaning of "Vanilla Javascript" is "runs without a framework besides the browsers own API".

If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period. And it matters exactly nothing whether the framework in question has 900,000 or 9 lines of code.

^^^100%

So loading an external library or framework isn't Vanilla JS, but if I copy/paste the VanJS source into a script tag, nothing gets loaded, there's no syntax magic, just some function calls, so that's Vanilla JS, right? If the latter isn't Vanilla JS by your definition, can I at least copy/paste something from stackoverflow?

Trying to make Vanilla JS a strict definition seems pointless to me in the first place.

> so that's Vanilla JS, right

I think we don't have to argue about the distinction between the library code and the application code. It doesn't matter how the library is loaded. You can get it from a CDN at runtime, load it from a scriptbundle, copypaste it into a <script> tag, it doesn't matter.

It's still library code that the rest of the application depends on. As soon as that is the case, it's no longer what the JS community by and large calls "Vanilla JS".

This is Vanilla JS:

    fetch('/readme.txt')
    .then(response => response.text())
    .then(data => console.log(data))
    .catch(error => console.log(error))

This isn't:

    awesomeLib().goesBrrrrr()

> Trying to make Vanilla JS a strict definition seems pointless to me in the first place.

Being able to name things, and having clarity in a community about what names denote, is anything but pointless.

When you do it this way isn't even a framework is just a helper library (at his best). There is another concept for this kind of micro-libraries but calling "framework" to something that will not establish a frame of work for you.

The important part is that if you don't copy VanJS into a script tag, or use it all, you're still doing Vanilla JS.

> If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period.

Minor nitpick, third party library and framework does not modify your browser. They all still run on unmodified browsers.

Suggestion: call it Bourbon JS. Wikipedia:

> The majority of the world's vanilla is the V. planifolia species, more commonly known as Bourbon vanilla.

Wait people write JavaScript without drinking bourbon?

I've been managing that since more than a decade. Having neither jQuery nor bourbon was a challenge at first but browser APIs evolved and I fell in love with green tea.

I prefer Scotch

My goto JS drink is Absinthe.

Please create a PR for my library goto-drink.js which uses labels for each libation so you can continue or break your drink.

You writing your front ends in Elm then?

No thanks, I get high with Javascript alone and a hangover so bad that lasts the entire weekend.

The relationship between Bourbon (spirit), primarily distilled and aged in Kentucky, and Bourbon (vanilla plant), primarily grown in Madagascar is one of fascinating cross-convergence of "things rich French speakers loved", plus the coincident accident of Bourbon, Kentucky being a shipping port (and Oak as an aging vessel high in imparting vanillins). Both are a reminder that vanilla as a flavor was long a spice for (and named after) kings and to be enjoyed mostly by the rich. It is still hilarious to see things like "vanilla JS" meant to imply "boring" or "cheap" when historically that's very inaccurate.

Also, yes, bourbon (spirit) is a good accompaniment to late nights in JavaScript.

The etymology is legit and comes from ice cream, for which vanilla is considered the default or “plain” flavoring.

https://en.wikipedia.org/wiki/Plain_vanilla

Vanilla historically being fancy but then becoming an attainable and cheap additive is probably somewhat responsible for it becoming the default ice cream flavor, and thus flipping the idiomatic meaning.

Though note it was primarily the invention of artificial vanilla substitutes that made vanilla seem cheap/attainable. (Real Bourbon vanilla from Madagascar, for instance, is still far more expensive than most people realize.) There may even be a larger useful metaphor there, too, that "plain" vanilla is most often "fake vanilla".

Lots of dessert / ice cream recipes use vanilla as an ingredient regardless of what the final flavor is meant to be. This also leads to the vanilla === plain misconception, imo.

Already taken. I know it's not JS but it's front end tooling.

https://www.bourbon.io/

Vanilla was already taken too:

https://github.com/idevz/vanilla

It's a zombie project as not many people use sass, let alone a heavy sass library.

bourbon.js it is?

Suggestion 2: call it IceCreamJS or just IceJS/CreamJS

jsAlaMode?

Vanilla.js is the most popular framework in the world!!!!

http://vanilla-js.com

Also has the smallest footprint:

0 bytes uncompressed, 25 bytes gzipped!

> 0 bytes uncompressed, 25 bytes gzipped!

Compression Considered Harmful

This is hilarious. I lost it at the empty line for loading it in production.

I clicked the download link to see what would happen, and it did indeed download a zero byte vanilla.js file. Zipping it using the OS X 'compress file' menu option gave me a 713 byte zip file however.

I understand the confusion, given the existing terms but it seems the intent behind the name 'VanJS' is to highlight the simplicity and 'bare-bones' nature of this new framework, aligning it with the 'vanilla' aspect.

While it might lead to some confusion initially, with clear and transparent communication about what 'VanJS' offers, it could still work as a brand that distinguishes itself by simplicity - or pivot to Van rentals

I'd like to suggest my new reactive JS framework called "react.js" not to be confused with reactjs.

>While it might lead

Might ?? Come now, be an adult and a thinking person ! Go down the hall find 10 js/frontend programmers. Ask them what do they think "Vanilla JS" might mean ?

I agree with you and I opened https://github.com/vanjs-org/van/issues/18

I will up you. Using the word "vanilla" to refer to anything neutral, default, or basic is wrong.

Vanilla is a sophisticated flavor, not to mention a precious and expensive ingredient. Most people have never consumed real vanilla in their lifetime.

Similarly, using the word "original" to describe plain potato chips is wrong. It's the most unoriginal flavor of the lot. Just call it "plain".

It's not similar. Unfortunately, "original" is one of the words with a couple of very close but different meaning. This one even goes first in the dictionary:

> Existing at the beginning of a particular period, process or activity.

The original meaning of the root "origin" comes from Latin: to rise -> beginning, source birth.

> Most people have never consumed real vanilla in their lifetime

What exactly is the "vanilla extract, vanilla beans" in Ben & Jerry's ice cream then?

Supposedly Haagen-Dazs ice cream is made from "5 simple ingredients": cream, milk, eggs, sugar, and Madagascar (sic) vanilla (which is "real" vanilla I assume?)

And what about the vanilla extract which I have on my shelf, whose ingredients are "vanilla bean extractions in 35% alcohol?"

Have we all fallen victim to a diabolical vanilla conspiracy?

Even though the main character of the universe, you, has consumed real vanilla, the point stands. Almost everything labeled "vanilla" does not actually contain real vanilla.

That is why the name is only half vanilla: van ;-)

They could have taken another part of vanilla and called it nilJS, but unfortunately JS uses null and not nil, so it doesn't quite work...

Could have named it StraciatellaJS then. ;)

A following JS-Framework ;)

This. I originally thought this was a rebranding of http://vanilla-js.com/ and I'm disappointed.

what is interesting about that is when I saw solid.js performance chart, it is the closest to vanilla js in terms of performance.

SolidJS is probably the closest thing to a vanillaJS framework that you can get, in that 90% of the time it's doing the same DOM manipulations you would be doing, but with a nicer interface. So if an update causes a class to change, there's no tree to diff - that class attribute gets changed directly.

The non-Vanilla stuff is the signals implementation, which is kind of an RxJS-esque observable system, but more lightweight, and more push-based. It's very similar to Svelte, but with a React/hooks-like API (although far fewer rules to remember!) As I understand it, this system is pretty efficient, which means for simple use-cases, it's not adding much overhead over basic vanilla stuff.

The disadvantages (because there are always some) mainly come from the small ecosystem - there's not many off-the-shelf design toolkits, the documentation is a bit scratchy, etc. That community is still growing though, so that stuff will get there.

So now we have a framework that doesn't want to be a framework? They might call it "VoidJS" instead, as in void = vacuum = so lightweight it's almost as if there's nothing there?

Hey, that’s actually a pretty cool name.

Or Null.js. Or undefined.js.

And now I want to create a library/framework/whatever called NaN.js...

Would that be equal to zero.js?

Or even better: objectObject.js! Also, Infinity.js sounds like a really cool name, too...

Yeah, just call it VanJS everywhere and never call it "Vanilla JavaScript" and that would be good enough.

I also thought this was a "joke" on how you don't need a framework. But looks like it is indeed a framework so definitely confusing name.

I do like the idea of it. A lot of value of React for me is in the composition model and could see this being useful for small projects

How about an alternative name like Pure JS (already taken), JS Only, No-Framwork framework

I came to be that guy. Vanilla JavaScript is the term for plain JS without any framework, library or plugins.

   window.$ = (selector) => 
     applyExtendedTools(Array.from(document.querySelectorAll(selector)));

Oh noes, I'm now using a defacto Framework, even if I wrote the applyExtendedTools and the $ function to give me something like a lighter jQuery.

Kinda like calling a cloud server "serverless."

Or a software development platform a "no-code" solution.

Apparently all the cool marketing kids now want you to call your widget company "widgetless." Paraphrasing EJD's critique of Ada, "This stupid idea will take 5 years and a billion dollars to kill."

I agree.

I was confused reading the page and expected a description of a pattern I could use in actual vanilla JavaScript without any dependencies.

The term 'zero-dependency' played a role in my confusion. "VanJS" is a dependency.

Don’t you know, it’s 2023 and we’ve decided words don’t mean anything?

I love your suggestion and slogan.

100% I thought this was a meme repo like nocode

People are running their code on servers calling it "serverless."

We've somehow accepted that nomenclature.

It's very effective naming strategy. It's called VanJS not Vanilla JavaScript. But it's kinda hard to remember Van, or any letters really. By association of it's main quality which is small size/simplicity with common term such as vanilla JavaScript, suddenly VanJS becomes memorable.

Similarly vanilla js was named like that, after common term describing plain flavor of icecream. Which was weird to me, and I learned that as a non-native speaker only after I heard about vanilla js.

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 initial page load will send the user a page of HTML that can be streamed (rendered as it downloads) so it'll display pretty much instantly (if you're concerned about styles you could inline for the important stuff and defer for rest). The React "Hello World" will be a lot bigger but it'll display a lot faster on a slow connection, and it'll work if the user has JS disabled.

Obviously it's early days for VanJS and the authors could add all sorts of fancy SSR and clever scheduling, but if they do they'll lose the tiny size and end up making something that starts looking very like React (or more likely, Preact).

It's all a trade off. Sacrificing speed and complexity for size and DX is fine. You just need to be aware that's what you're doing, and neither is 'better' for all aspects of web app dev.

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

Given that van replace the whole tree each time a value changed, SSR for van is simpler. You run chrome server side, capture the DOM once van has finished its first execution and modify the HTML of the page to includes the new nodes.

Don't run chrome on the server for SSR, I beg you. That's a massive performance hit and scales terribly with all the memory usage.

In this case, you can do it on your CI as part of the deployment, so it's not that bad.

Sure that's doable if the site is static only. I was going off the SSR terminology which usually means the html is rendered at the time of request instead of built one ahead of time (SSG)

Two way different scenarios where this would be used, so different I wouldn't even compare them.

I'd use this to prototype a basic web interface to interact with something like an IoT device. React would be overkill, and I doubt React would be faster to render than this for that scenario.

On a slow connection, the fully rendered interface could well be more bytes than this plus some data. I would say first to render depends entirely on what you're doing.

React is used in _way_ more places than a blog or ecommerce site.

They list SSR as a feature.

Also, using rollup would be trivial.

You are comparing apples to oranges. The author could probably couple their library with https://vite-plugin-ssr.com/ and have something comparable within a day.

The reality is most running React apps today are still traditional SPAs, and chances are likely the same apps can be rewritten with VanJS (or any other SPA framework) and the users would not notice a difference.

They would notice because vanjs trashes the entire DOM at the root of every state update so users will lose focus, animations will interrupt, and big perf hit layout reflows will occur.

The page will show nothing until the script runs

If you know what you are doing you can achieve full state restoration of a large SPA before CSS paints to the screen. In my personal app I am able to complete state restoration within the first 80ms of page load on old hardware. Vue and React are not capable of providing this.

Can you elaborate as if I didn't know what I was doing?

https://github.com/prettydiff/wisdom/blob/master/performance...

Just encapsulating css and js inside the html works perfectly fine. In a SPA you nowadays use history api for navigation and make dynamic dom changes on the fly. You only have to make sure than you serve the minimum amount of js and css on an initial page load. Then when the page is loaded you load the rest. Slight inefficient cache model when lots of initial page loads from different urls, but usually that's never happening (people are entering a site at one specific url) I have a SPA, full size is about 3mb of js files. Separate html files containing only that page are max 20kb. Super fast rendering. Nothing server side.

I often find splitting the difference is useful... embedding the CSS with the HTML, as different routes from the server, delivering the same html will still result in more cache being used, and lack of caching if a user shares/bookmarks something different from what a user may already have cached. async loading for routes and splitting on the bundler can help a lot as well. Similar to async load any graphing/charting libs only on components that need them too.

In the end, it depends on what you are doing... if you're wanting to do paged records against a database, then client rendering can help... The direction of React server components, next.js and the like bridge these gaps well. Combined with edge services like deno deploy, cloudflare pages/workers and others make this even more of a no brainer for many use cases.

There's also a place for pre-rendering most content... I don't know why any marketing or content sight like blogs wouldn't be static rendered at this point. JS enhancement for things like sharing or comments.

You have pretty much described the "php way" of developing things, is funny js-driking cool-aid guys talk about "SSR" being the thing to have, when we already had that, we already found that it can't scale without lots of money and started pushing computation to the client and now we are bring them back because it's not fast on the initial load...

damned we have come to full circle whats next, an assembly language so we can run binary code inside the browser kinda the way activex and applets just used do it... wait isn't that the whole point webassembly? sight you f** javascript developers have done it again sight

This is fairly reductive. SSR is less about rendering HTML on the server, and more about having both the initial render and the client-side updates use the same process. Contrast this with other ways of rendering the front-end where either the client needs to build the entire view itself, or you need to write a separate application to do any client-side manipulation that might be necessary.

As with everything in software, it's all about tradeoffs. Using PHP to render your templates works great if there's limited client-side interaction (say, blogs, forums, documents, marketing pages etc), while frontend rendering allows you to build much more complicated applications that can react much quicker to user interaction, but will be slower to load the more complicated they become. And SSR tools try and have the best of both worlds, but make other aspects more complex in exchange.

The cliëent lib could be 2kb and the speed difference between first render vs server side render is less than 10ms. In fact the client side render version could be faster if the compiled output is larger than 2kb. Which then normally must be pushed from the server

There's a "mini-van" renderer and examples on usage for node/deno on the library's website. I actually found that probably more compelling than the JS client library usage.

For me what's missing is wiring with a larger state machine (jotai or similar) and async importing of components at runtime.

In the end, I'm not completely convinced this is better than React/Preact/Inferno, and even then, adding a UI library like mui will get even bigger. It's the patterns and the size/scale of what you're building and how many other devs you would have to develop with that should determine things like this. Are your using on generations old phones where access is akin to slow 3g, or is everyone on a modern 1440p+ desktop with over 30mbps of bandwidth?

> The "Hello World" example is a really good example of why React <...>. The page will show nothing until the script runs.

Until the script runs! Nothing! Blank page of death! As numerous research articles have proven times and again, if visitors see a blank page of death for longer than 0.00068 picoseconds, 96% of them will leave the site, with that number reaching 97% if that time goes over 0.0124 picoseconds.

When users visit your site, your page will show nothing, unless you use React. React is awesome. React shows you the page before the script runs. Even if the script runs on the server, React will show you the page. Because React is full of optimizations. The rumors are, the cases were reported when React showed the page even before the browser completed the DNS query.

This is really just a DSL to make dom:

https://github.com/vanjs-org/van/blob/3f98060971a8ff141179ef...

And a very simple system that replaces the dom from scratch each time any data changes:

https://github.com/vanjs-org/van/blob/3f98060971a8ff141179ef...

That's bad for performance (recomputing the style/layout and repainting even for minor changes), bad for accessibility, breaks focus, etc.

It's unlikely the smaller bundle size compared to preact and friends wins anything once you've abandoned all reuse of the rendering engine computations.

While that's true, I wonder how many websites really benefit from smart diffing algorithms instead of just directly updating the dom.

In my world, I just directly update the DOM which I described recently in https://news.ycombinator.com/item?id=36067280

The diffing algorithm for preact is super simple, I think it's along the lines of a dozen lines of code. I'd wager the code to directly updating the DOM will be larger than preact + usage code

Using tagged template literals with Lit or Preact + htm is more readable than Van.js, is much faster on update, and is also completely vanilla JS (no JSX and so no build step needed)

> VanJS has the vision to be the scripting language for UI, just like bash is the scripting language for terminal.

I find this quite strange. Wouldn’t javascript be to the browser what Bash is for the terminal? This is after all just another library.

Bash?

So VanJS will make the simple things easy and anything else nigh-on impossible?

Some day browsers will implement native data binding with reactivity and the current dark ages of front end development will end.

This is my dream! I started RxHTML with the premise that something was missing from HTML, so I just added it: https://news.ycombinator.com/item?id=36067280

It's working surprisingly well for a client that I'm working for.

That's cool but my favorite vanilla js framework by far is vapor.js. https://github.com/madrobby/vapor.js

I really love the documentation for this project! Super-intuitive!

I appreciate that they offer a vapor.packed.js version, for those of us who care about keeping bundle size down.

Looks nice, but does it support Internet Explorer?

Fantastic! It even has 200 forks!

The website for this is top-notch. It always turns me off when frameworks have bad websites, thankfully this amazing project doesn't.

http://vaporjs.com/

https://web.archive.org/web/20120322223910/http://vaporjs.co...

I got an error trying to go to their website.

It's been vapoorized. https://www.youtube.com/watch?v=cpads8s5mik

Very on brand. (˃̣̣̥‿˂̣̣̥)

You are not really getting anything in the size difference between this and something like preact, you are going to end up bottlenecked on something else like waiting for CSS to load. This is fine if you just want to write the code in a minimalist style, but I really doubt cutting things back to this extreme has tangible performance benefits for like 99% of applications.

Hard to see a real-world use for this but reading the code and docs is pretty interesting. The code taught me some cool tricks. Good job!

Some of the binding API is a bit weird, like that object with `deps` (State-derived properties). Maybe providing a function for this would be more ergonomic.

Might be of interest as well https://github.com/zserge/o

Would seem that it's not difficult to come by a framework tiny and functional. The question is, how long are they valuable to maintain and how tiny they keep if you cater for all the corner cases and fix bugs

We probably saw since React came up at least 20-30 of these "smallest reactive UI frameworks" with similar API but none of them named itself "Vanilla" for a reason.

I share the opinions of others in this thread that the current name is an unlucky one.

This narrative (https://vanjs.org/about#story) about modern JS tooling being opaque, exclusive, and hard to learn is frustrating.

If all you need is HTML rendering and basic state, any modern web framework will do that extremely simply. The barrier to entry is really not that high!*

*Except maybe at Google. I hear their internal tooling is a huge pain to work with.

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.

> Building an app that renders a complex page in under 16ms isn't that easy if there's a lot going on

We struggle to render a few boxes and some text under 16ms while games with vastly more complex sound, network, physics, UI and whatever else systems render frames in < 8ms at 4k.

We struggle to render a few boxes and some text under 16ms

Only if a dev has screwed up. Most simple sites are fine. You have to push the DOM quite hard for the browser to be the bottleneck. I've worked on apps that have DOM trees with 60,000+ nodes that remain under 16ms (because very few were actually changing at any given time..)

games with vastly more complex sound, network, physics, UI and whatever else systems render frames in < 8ms at 4k

The Servo project is bringing a lot of what makes game UIs fast to browsers. It's a massive shame that it's not a Mozilla/Firefox backed idea any more but it's still going. Hopefully it'll get a bit more mainstream one day.

> Only if a dev has screwed up. Most simple sites are fine. You have to push the DOM quite hard for the browser to be the bottleneck. I've worked on apps that have DOM trees with 60,000+ nodes that remain under 16ms (because very few were actually changing at any given time..)

You mentioned that frameworks like React make it simpler to get better performance but based on my observations it's quite the opposite and React is often a double barreled gun where one of the barrels is constantly pointing at your feet. With vanilla JS (not the one from this post) you have to put effort to get everything to update properly. With React you put effort to get the least amount of things to update. It's not even about DOM size but about managing state and how much code gets run on state change.

To give you an example - Reddit is a simple website. You have a list of posts which are either text, image, or a video and each of them has comments. Absolutely nothing complicated about that, yet the performance on their React frontend, even with all analytics JS and ads blocked, is horrendous. You would assume that at Reddit's scale they'd be able to hire competent React developers.

FWIW the app that pushed 60,000 DOM nodes around at 60fps was entirely in React.

I keep seeing an advert for a Principle Frontend Dev at Reddit on LinkedIn. Maybe I should apply...

Already happening, see the current popularity of htmx [1]

[1] https://htmx.org/examples/infinite-scroll/

The day they make native web components as useful as using Vue or React without needing a single third party library, that is when this might happen. Until then, I dont think its happening any time soon.

But that's only because the frameworks guided the direction of the specifications. You couldn't use vanilla in this way 10 years ago.

Since the other comments are complaining about something or other, I just want to say that this looks great! I can imagine using this for something that needs more than jQuery and less than react.

I use the same Html-in-JS syntax for my own project and it works really well. The good folks at solenya have written a converter: https://www.solenya.org/convert

HTML-builder APIs like this are a pretty bad idea, IMO.

They assume that HTML is a closed system with no new tags, and don't account for custom elements or new tags. It doesn't even have support for existing tags like <track>, , or ( is used by some systems now for icons). It doesn't appear to have a way to emit comments.

We have the ability to embed real HTML strings, with expressions, directly into JS, which means that the rendering library doesn't have to have any knowledge or opinion of what the tags are.

This is what Lit does with lit-html templates. The example in the Van readme would be:

    const Hello = () => html`
      <div>
        <p>Hello</p>
        <ul>
          <li>World</li>
          <li><a href="https://vanjs.org/">VanJS</a></li>
        </ul>
      </div>
    `;

Such template strings can contain any HTML - any tag, comment, attribute, entities, SVG, etc.

You can just add a generic version tag function that takes a tag name as its first param to solve that issue. Lets you create your own generator functions with ease for tags that aren’t included by default. Don’t see any reason you can’t add a comment() function either.

If you use a template string like that then you lose a lot in terms of type checking/IDE tooling/etc unless you add a ton of complexity, which is antithetical to this library’s goals. I definitely think they went with the right option.

Interestingly the `tags` object seems to support any tag name: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...

And it still allows to provide specific types for the known HTML elements: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...

Cool stuff

> is used by some systems now for icons

This is somewhat alarming. is still a valid tag and used, e.g., for marking up titles of artistic works, etc. (which is not a use case for , nor for <cite>.) Similar goes for , which is (semantically) different from .

For most icon libraries that use for their icons, it's usually just a suggestion and using instead works fine. They mainly use because it's "pretty".

Actually, it should be a label (or a button, depending on the use case).

I like this, but https://github.com/vanjs-org/van#ultra-lightweight should really list svelte, which is only 1.6-1.8kB compiled last I checked (though it's possible it makes some of the compiled markup that gets shipped larger than the source due to component style scoping)

For comparison, similar tiny JS view libraries

- https://redom.js.org 2kB

- https://nanojsx.io 1kB

nanojsx looks great! I don't really get why mini-van don't use JSX.. Maybe some people just don't want any html tags in their project ? Or maybe their template engine allows a lighter approach.

I suppose the idea is to not have to do transpilation.

You can avoid a build step by not using JSX.

My library https://github.com/jhp/imperative is also under 2kB

Another one, https://github.com/jsniffen/tinyjs

Makes me think that jquery may have missed a boat to integrate reactive elements (as there was clearly a need for them for a long time before angular, react etc took of) and retain relevance.

Maybe for projects that don't aim to replicate desktop app functionality there is a "small-is-beautiful" yet all-inclusive js library that is missing.

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

So how do you clean up global event listeners, clear intervals and timeouts, etc when a component unmounts?

s/shadow/virtual/

Very cool! See also El, which is similarly sized, with an arguably more natural reactive interface: https://github.com/frameable/el

To my eye, this makes vanilla JS more like React rather than making vanilla JS reactive. I'm basically looking for an even lighter Svelte if I can get it. Maybe this just isn't for me!

If you just want to make vanilla js reactive, you can use solid js but without jsx (or something similar). This library could likely do the same.

    import { createRoot, createSignal, createRenderEffect } from "solid-js";  

    function SomeComponent() {  
      const [count, setCount] = createSignal(0);  

      const result = document.createElement("button");  
      createRenderEffect(() => result.textContent = "++ (" + count() + ")");  
      result.onclick = () => setCount(count() + 1);  
      return result;  
    }  


    createRoot(cleanup => {  
      const appv = document.getElementById("app");  
      appv.appendChild(SomeComponent());  
    });

nice project, very cool, but I don't see the meaning to do this.

nowadays, most small project can use vanilla javascript, if they don't need a framework, they really don't need it.

if we are building a large project, why not use react/vue/svelte ? better docs, better features, better community.

> if they don't need a framework, they really don't need it.

I don't think it's an "all or nothing" situation. I do UIs without big frameworks, but that doesn't mean I don't use any library for some needs. I personally appreciate anything that needs no transpiling.

The syntax is more like mithril.js, think would just stick with that or go with solidjs.

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")),
      ),
    )

Neither does react?

Throwback to ten years ago and libraries like Mercury: https://www.npmjs.com/package/mercury

This is what we were doing before React and Babel came along. No dependencies, no transpiling, light weight, no IDE setup, were all a given and not special features.

I was expecting this to be a prank project saying that you should use vanilla JS, my disappointment is immeasurable.

I thought this was gonna be terrible but it actually looks pretty nice. It reminds me of Nim's Karax.

It can do "Hello world". How cool is that?!

I think the API is quite nice. I've always been a fan of the Elm-like `div`, `p`, `span`, etc. individual html element functions for templating.

The approach to local state is also similar to Preact Signals, which is cool.

Glad to see jsx-less approaches to declaring dom!

Very similar to: https://github.com/jehna/longwood

I like it! Its minimal, super straight forward and easy to understand, dont need a transpiler. I'll use it with my next upcoming project and see how it fares.

Please check out https://github.com/jorgebucaran/hyperapp

Now that everyone is advertising their own similar frameworks, I guess I'll have to do that too: https://github.com/RauliL/pakertaja

Until i run into a big bottleneck in react and cannot find a way to overcome it, i am not gonna switch from react to yet another new framework. Time is better allocated for more important things.

That's not the point. Imagine wanting to do a quick prototype, for example. A miniframework like this could be a great fit. Or when you code something (probably not too big) from scratch.

seems like a cool, intuitive library. surprised how much discussion time on here was spent on "the name" relative to the framework itself

You can try this plugin to quickly land UI animations。https://pag.art/

> Programming with VanJS feels a lot like React.

closes tab

Why is everybody so obsessed with size? 100kB means nothing these days.

i'm also a bit confused why e.g. they have an explicit rule that they only use `let` instead of `const` when declaring variables, "for reducing the bundle size", which seems like a bad trade-off in order to save maybe a couple dozen bytes at most?

I’m a bit confused why they made it in the first place given the dozens of similar ultra minimal spartan frameworks to choose from that nobody uses (every other comment here is plugging one).

This library actually has some pretty unique ideas, like the use of Proxy objects which is not commonplace in javascript frameworks. Even if it didn't, sometimes it's just nice to build your own take on something.

Proxy objects are absolutely common in js state management frameworks.

And yes it’s nice to build something on your own, but this project is clearly aiming to convince other people to use it in their projects.

Don't minifiers convert these anyway?

    const a = 1;
    let b = 2;
    console.log(a, b);

bun build --minify a.js // bundles this to:

    var o=1,l=2;console.log(o,l);

It's not even using const or let, it's flattened these multiple statements into one 'var' statement

Only if you're targeting super old browsers.

Wrong. You know it never ends up being 100kb, and when it reaches 1MB (it always does) then you get the real issues.

It’s because of your thinking that we got bloated webpages.

Because of people like you we will have the collapse of civilization, global warming and apps like Slack.

Not caring about memory usage, data usage, speed is the reason why software is so brittle and broken these days.

They pretend it matters as they download thirty 10MB Tictok videos.

do not call this vanilla js, that's what using no js is called

Jsx is one of the best things about react

ha, the good old html construction functions, i don't know but it relaxes me to see that after a year of jsx

Cute.

could this replace jQuery?

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)

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.

You know what promises are right?

Yes I do.

Do you use JS or TS currently? We've had async/await since ES2017, it's supported everywhere you want, and there's no reason to see .then() chains anymore outside jokes regarding early 2000's film classic "Dude, Where's My Car?".

Pasting some code and cutting out the boring bits:

  const transaction = await makeTransaction(...);
  const signature = await sendAndConfirmTransaction(...);
  const tokenAccountsByOwner = await getTokenAccountsByOwner(...);

Even back when .then() chaining was used: chaining only existed because that was the only way we had to handle promises, rather than because it was a desirable syntax.

Why would you be so snarky in your answer? Always better to be humble and assume you might be wrong. In this case you are: Nobody chains promises anymore.

I think the way it's done is correct, an object passed as a parameter with key value pairs for attributes seems a lot more logical.

Maybe, but I bet this way would be slightly faster, because the library wouldn't have to loop through keys if they write functions for all the most common attributes (href, rel, className, type, etc)

Here's one for React:

https://github.com/jehna/nosx

Reply on news.ycombinator.com