5 ms·

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconce

The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.

colordrops 3y ago
Or just don't even bundle if you can serve your users with ES6 modules.
- TheAceOfHearts 3y ago
  Performance with native ESM isn't great since you get cascading requests, unless you have very shallow dependency trees.
  - colordrops 3y ago
    They work fine for everything that doesn't require immediate response on first load, and even the there are ways to address that - for instance special pages for entry points and/or loading indicators. For general performance you can cache the modules using a service worker. In any case they are fine for most use cases.
realusername 3y ago
That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.
- gausswho 3y ago
  Perhaps I can help? Which bundler? What issues are you encountering?
  - realusername 3y ago
    We're using Vite.js/esbuild, the bundler takes 2.5GB of RAM locally.
    - gausswho 3y ago
      I can offer suggestions on code-splitting, but bundler memory consumption gets into the weeds quickly.
      - realusername 3y ago
        Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
        gausswho 3y ago
        I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
        realusername 3y ago
        We're a web application and even with those, I'm not sure the bundling is worth it. Customers in some regions complain about the high payload, we made sure the chunks are split properly but with continuous deployment, there's a lot of cache invalidation anyways.
- randomwebdev 3y ago
  Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`
  - realusername 3y ago
    You still are going to build the whole thing locally anyways, even with vite.js, it takes 2.5GB of RAM on my machine.
    - randomwebdev 3y ago
      I don't understand your concern with it and why this is a problem. I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.
      - realusername 3y ago
        It's a problem because it slows down my machine and each js file which is added makes the ram and cpu problem worse, it just doesn't scale. We're using typescript so building only once a day isn't an option.
        Tade0 3y ago
        > It's a problem because it slows down my machine I don't know what machine you're using, but filling 2.5GB of RAM was already taking less than 200ms back in 2018. I don't suspect memory usage is an issue here.
        realusername 3y ago
        It wouldn't be an issue if other work tools were taking absolutely nothing yes but as it is now, 16GB of RAM with a JS oriented stack isn't enough anymore. And getting more RAM is just delaying the problem anyways since it takes more RAM every week as the product evolves.
deleted 3y ago
[deleted]
pjc50 3y ago
In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR. Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!
- gausswho 3y ago
  I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications. As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.
the8472 3y ago
"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.
- gausswho 3y ago
  That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.

colordrops 3y ago

Or just don't even bundle if you can serve your users with ES6 modules.

TheAceOfHearts 3y ago
Performance with native ESM isn't great since you get cascading requests, unless you have very shallow dependency trees.
- colordrops 3y ago
  They work fine for everything that doesn't require immediate response on first load, and even the there are ways to address that - for instance special pages for entry points and/or loading indicators. For general performance you can cache the modules using a service worker. In any case they are fine for most use cases.

realusername 3y ago

That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.

gausswho 3y ago
Perhaps I can help? Which bundler? What issues are you encountering?
- realusername 3y ago
  We're using Vite.js/esbuild, the bundler takes 2.5GB of RAM locally.
  - gausswho 3y ago
    I can offer suggestions on code-splitting, but bundler memory consumption gets into the weeds quickly.
    - realusername 3y ago
      Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
      - gausswho 3y ago
        I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
        realusername 3y ago
        We're a web application and even with those, I'm not sure the bundling is worth it. Customers in some regions complain about the high payload, we made sure the chunks are split properly but with continuous deployment, there's a lot of cache invalidation anyways.
randomwebdev 3y ago
Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`
- realusername 3y ago
  You still are going to build the whole thing locally anyways, even with vite.js, it takes 2.5GB of RAM on my machine.
  - randomwebdev 3y ago
    I don't understand your concern with it and why this is a problem. I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.
    - realusername 3y ago
      It's a problem because it slows down my machine and each js file which is added makes the ram and cpu problem worse, it just doesn't scale. We're using typescript so building only once a day isn't an option.
      - Tade0 3y ago
        > It's a problem because it slows down my machine I don't know what machine you're using, but filling 2.5GB of RAM was already taking less than 200ms back in 2018. I don't suspect memory usage is an issue here.
        realusername 3y ago
        It wouldn't be an issue if other work tools were taking absolutely nothing yes but as it is now, 16GB of RAM with a JS oriented stack isn't enough anymore. And getting more RAM is just delaying the problem anyways since it takes more RAM every week as the product evolves.

deleted 3y ago

[deleted]

pjc50 3y ago

In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR. Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!

gausswho 3y ago
I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications. As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.

the8472 3y ago

"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.

gausswho 3y ago
That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.