4 ms·

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 a

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.

onion2k 3y ago
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...
- _old_dude_ 3y ago
  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.
  - flagrant_taco 3y ago
    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.
    - _old_dude_ 3y ago
      In this case, you can do it on your CI as part of the deployment, so it's not that bad.
      - flagrant_taco 3y ago
        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)

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.

onion2k 3y ago

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

_old_dude_ 3y ago
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.
- flagrant_taco 3y ago
  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.
  - _old_dude_ 3y ago
    In this case, you can do it on your CI as part of the deployment, so it's not that bad.
    - flagrant_taco 3y ago
      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)