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