5 ms·

Well, still a subjective take. Heavy use of interactivity is hard. React makes it maintainable. It was hell before. I've been working with React (and RN) sinc

Well, still a subjective take. Heavy use of interactivity is hard. React makes it maintainable. It was hell before. I've been working with React (and RN) since it came out and I've had nothing but good experiences, especially compared to the previous decade before React. My motto is local-first, the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Move everything to the client, especially the database. Let the database do the syncing. Plus you get offline and undo/redo basically for free. Pagination? Fuggetaboutit.

MBCook 2y ago
(Not a GP). Yeah. I use and like React. I don’t have an issue with it. It’s not tiny but it does a lot of work and makes my life easy. My general complaint is the JS ecosystem in general and its tooling.
apsurd 2y ago
> Heavy use of interactivity is hard. React makes it maintainable. It was hell before. Agree, React is great for UI interactivity. > ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects. Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.
realusername 2y ago
The more stuff the client does, the higher the payload is going to be and the more complex the bundling and tooling will be. I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all unless you throw a insane amount of devs hours in the tooling, even then it barely does. That's not mentioning the insane npm churn that you have to maintain, the testing story which is pretty abysmal outside of a few top libraries, the typescript tooling which is eating so much ram that I'm changing my laptop. And I'm not sure why you mention the pagination as a plus where it's one of the big downsides of the front-end stack, there's a lot of hacks to make it behave okay in most situations.
- ivan_gammel 2y ago
  > 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.

MBCook 2y ago

(Not a GP). Yeah. I use and like React. I don’t have an issue with it. It’s not tiny but it does a lot of work and makes my life easy. My general complaint is the JS ecosystem in general and its tooling.

apsurd 2y ago

> Heavy use of interactivity is hard. React makes it maintainable. It was hell before. Agree, React is great for UI interactivity. > ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects. Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.

realusername 2y ago

The more stuff the client does, the higher the payload is going to be and the more complex the bundling and tooling will be. I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all unless you throw a insane amount of devs hours in the tooling, even then it barely does. That's not mentioning the insane npm churn that you have to maintain, the testing story which is pretty abysmal outside of a few top libraries, the typescript tooling which is eating so much ram that I'm changing my laptop. And I'm not sure why you mention the pagination as a plus where it's one of the big downsides of the front-end stack, there's a lot of hacks to make it behave okay in most situations.

ivan_gammel 2y ago
> 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.