Hacker News Reader

Comment by theultdev | Hacker News Reader

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.

View on HN

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.

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

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

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?

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

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.

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.

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.

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.

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.

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.

That's exactly what I meant by "not scaling". Sure if you have much less developers than us and you don't make 100 deployments per day, maybe an SPA can work. I can assure you that when you need to support a complex product, it absolutely doesn't scale at all, even with some developers full time to try to fix the stack.

Our full bundle itself is close to 70mb and still growing every week, that's absolutely insane.

70mb is insane and not at all the standard.

There's a reason why Vite has a default bundle chunk warning of 500kb.

There's really no reason it should be that large. If you just lazy load each route your chunks should distribute into manageable size pretty much automatically.

It sounds like you may also have a bunch of dependencies. Which can happen in a native app, but in a web app as you know you'll have limited resources so size is important.

You're all over this thread saying "We couldn't scale it, so you little plebs certainly can't." I'm sorry it didn't scale for you, but it's telling that you think your experience is THE experience. Facebook uses it, I think your company of 100 devs could scale it fine, as many do.

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

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

Reply on news.ycombinator.com