5 ms·

> I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all What is the difference between SPAs and other monolith

> I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all What is the difference between SPAs and other monolithic architectures, e.g. on desktop, that makes it so? Why can’t you go with OSGI-style plugins, for example? Loose coupling, separate SDLC and deployments etc?

realusername 2y ago
The reason it works fine in a native app and not on a browser is that the browser streams documents over the network. It's pretty much the worst place to download large payloads on demand. Native apps do not suffer from this problem, your binary can add an extra 20mb without much downsides
- theultdev 2y ago
  It's fine to stream 20mb in a browser as long as it's not part of the core JS. Browsers can handle many GBs of storage. You can even store them via OPFS directly on the native filesystem if supported. There's also Chrome File Storage API and if all else fails IndexedDB (which is more limited, but works decent for synced databases).
  - realusername 2y ago
    This isn't the use case of an SPA though since those extra megabytes would end up in the bundle, this is more like a game. Ironically I would agree that games are better suited to the browser than SPAs because you can afford to wait, you use wasm and you don't have to reinvent the wheel of the basic browser features.
    - theultdev 2y ago
      The bundle can be split up into chunks. Chunks can be loaded on demand. SPA assets (just like game assets) can be downloaded and cached on demand. They don't have to be bundled at all.
      - realusername 2y ago
        I'm aware of that, that's why I pointed out the insane complexity of the bundler tooling. Splitting in chunks isn't a solution, it's adding fuel to the problem.
        theultdev 2y ago
        Not really, it's just a solution to the need of complex apps and the need to support the ability to load pieces of the app without having to download and install it like a native app. Native apps can do similar things with dynamically linked libraries, and there's a lot of complexity when it comes to compiling native code. The web bundler tooling really isn't that complex nowadays, especially with Vite. It's one file usually 10 lines long. It can use SWC and LightningCSS, written in Rust. They're safe, fast, and require minimal config.
        realusername 2y ago
        I'm also aware of those, that's exactly what we're using in my company. It's a power hog, so much so that I had to change my laptop to run the SPA properly. The local experience is absolutely terrible since it has to disable the bundling to use hot reload (at least that's what I guess is happening) and each browser reload takes >1min to load. Then there's the complexity of the caching in continuous deployment, we literally have a custom metabase dashboard to make sure the caching isn't too bad and lasts a few days. Then the default config doesn't scale either as you can guess and we have our own. There's a reason I have this opinion, I know what I'm taking about, I've been using all those tools and they add a lot of complexity to your app. The reason it works on an native app is because loading a dynamic library is essentially free, it's just stored alongside the binary.
        theultdev 2y ago
        Seems like you guys set up a complicated stack. My large app takes <5s to build. Hot reloading takes 0.2ms. We can agree to disagree though.
- ivan_gammel 2y ago
  Native apps do network downloads of comparable or even bigger size too. I do not see how this can be an argument in SPA vs MPA decision making. „Rich client“-server architectures existed long before SPA became a thing and on much slower networks, so pretty much every problem modern SPAs face, from UX to performance to change management, was already solved by someone. Isn’t it actually ignorance of JS frontend community which has reinvented many wheels in rather ugly way, that causes the trouble?

realusername 2y ago

The reason it works fine in a native app and not on a browser is that the browser streams documents over the network. It's pretty much the worst place to download large payloads on demand. Native apps do not suffer from this problem, your binary can add an extra 20mb without much downsides

theultdev 2y ago
It's fine to stream 20mb in a browser as long as it's not part of the core JS. Browsers can handle many GBs of storage. You can even store them via OPFS directly on the native filesystem if supported. There's also Chrome File Storage API and if all else fails IndexedDB (which is more limited, but works decent for synced databases).
- realusername 2y ago
  This isn't the use case of an SPA though since those extra megabytes would end up in the bundle, this is more like a game. Ironically I would agree that games are better suited to the browser than SPAs because you can afford to wait, you use wasm and you don't have to reinvent the wheel of the basic browser features.
  - theultdev 2y ago
    The bundle can be split up into chunks. Chunks can be loaded on demand. SPA assets (just like game assets) can be downloaded and cached on demand. They don't have to be bundled at all.
    - realusername 2y ago
      I'm aware of that, that's why I pointed out the insane complexity of the bundler tooling. Splitting in chunks isn't a solution, it's adding fuel to the problem.
      - theultdev 2y ago
        Not really, it's just a solution to the need of complex apps and the need to support the ability to load pieces of the app without having to download and install it like a native app. Native apps can do similar things with dynamically linked libraries, and there's a lot of complexity when it comes to compiling native code. The web bundler tooling really isn't that complex nowadays, especially with Vite. It's one file usually 10 lines long. It can use SWC and LightningCSS, written in Rust. They're safe, fast, and require minimal config.
        realusername 2y ago
        I'm also aware of those, that's exactly what we're using in my company. It's a power hog, so much so that I had to change my laptop to run the SPA properly. The local experience is absolutely terrible since it has to disable the bundling to use hot reload (at least that's what I guess is happening) and each browser reload takes >1min to load. Then there's the complexity of the caching in continuous deployment, we literally have a custom metabase dashboard to make sure the caching isn't too bad and lasts a few days. Then the default config doesn't scale either as you can guess and we have our own. There's a reason I have this opinion, I know what I'm taking about, I've been using all those tools and they add a lot of complexity to your app. The reason it works on an native app is because loading a dynamic library is essentially free, it's just stored alongside the binary.
        theultdev 2y ago
        Seems like you guys set up a complicated stack. My large app takes <5s to build. Hot reloading takes 0.2ms. We can agree to disagree though.
ivan_gammel 2y ago
Native apps do network downloads of comparable or even bigger size too. I do not see how this can be an argument in SPA vs MPA decision making. „Rich client“-server architectures existed long before SPA became a thing and on much slower networks, so pretty much every problem modern SPAs face, from UX to performance to change management, was already solved by someone. Isn’t it actually ignorance of JS frontend community which has reinvented many wheels in rather ugly way, that causes the trouble?