Hacker News Reader

Comment by Sharlin | Hacker News Reader

The real problem is all the pages that could be static HTML with some JS on top, but are instead SPAs with a dozen layers of abstraction taking half a gig of RAM and five seconds to render.

View on HN

I've thought about this a lot and my position is that it all boils down to how bad is the result when you apply any of these approaches wrongly.

Turns out static pages with JS on top can be even worse than badly done SPAs - especially when the server infrastructure is lacking and a single request takes a significant amount of time.

Surely all of the money invested into that SPA could be redirected into a simpler full-stack app, with sprinkles of progressive JS?

On the one hand you have a shared-nothing architecture that serves HTML and can enjoy varying forms of caching.

On the other you have an application that still depends on a server, but replaces all of that simplicity with a stateful client-server architecture that requires _more_ infra to manage, at a greater expense.

There's one important factor you're missing: for lack of a better word - "staffability".

Just about every programming language has also a web framework implemented in it, so if you want to create a full-stack web app, the range of options is just dazzling, which results in a highly fragmented ecosystem.

Meanwhile on the front-end there's essentially one language(with different flavours) and 3-4 leading frameworks, so once a developer has these covered, they can be hired to do anything in this part of the stack.

The overall result is that it's easier to scale work if you offload it to the front-end, because by the time you found your <insert highly specific language/framework combination>, your front-end developers would have done most of the work twice over.

There are many more reasons why you would want a SPA instead of a full-stack app, but this is one of the strongest.

I mean, that's just bad development though. You can write React with literally 0 external libraries and have a fully-fledged state management solution built-in.

The same folks who fail to understand that and just recklessly add dependencies aren't going to craft a nice static HTML site with smart, minimal, performant JS; they just don't have the chops for clean solutions. The medium barely matters.

I disagree. Making a good site with React takes more effort than not making bad site otherwise. Also because it’s fashionable React (and similar frameworks like Angular or Vue or Ember) are used in places where they don’t belong and it stinks.

I just am saying, someone with clean HTML/CSS/JS knowledge who abuses React to the degree you're implying just sounds like a strawman to me.

Frameworks shield from footguns like unpredictable DOM modifications all over the place put one over the other.

I was there when AngularJS was still this revolutionary new framework and back then any sufficiently sophisticated form would eventually become unmaintainable.

Wait.. no. There is enough information out there that suggests that React's Context should not be considered a replacement for Redux. Just think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled with stateful logic or other undesired patterns.

> think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled

Can you expand on this?

I have created entire applications which are operating off of a single React context, and then also created some generic components which themselves expose a provider to their managed subtree. I have not faced any issues or "coupling" between these layers; I just pass props from the top-level context to the top of another subtree / component, and it works as I would expect.

I don't rely super heavily on derived state, but I find useEffect and useMemo to both be quite simple and effective when I need side effects or to memoize a piece of derived state to prevent throttling.

What situations am I missing that introduce these issues you talk about? How does Redux solve them more cleanly?

I'm just speaking from my own experience where we had an redux app with 30-40 reducers operating on quite a lot (100-200) of dynamic attributes in those objects and approximately the same amount of attributes that are initialized just once and don't change over the lifespan. I can't imagine using a single context for it all. We used thunks heavily, of course. I would prefer to look at the code to better understand how we approached problem solving in each case. Also, have you ever had to invest a good chunk of time to solve performance issues in any of those projects? We did.

Reply on news.ycombinator.com