Why we needed Redux in the past, and don’t any more

    Most things that people build
    don't need anything like this.

True. It would be great to show examples of websites that benefit from the complexity of an extra library to handle client side state. I would think less then 1% do.

For example, lets look at how HN handles state syncing. Function "toggle" in this file handles collapsing/expanding threads:

https://news.ycombinator.com/hn.js

    function toggle (ev, id) {
      var on = !afind($(id), collapsed());
      (on ? addClass : remClass)($(id), 'coll');
      recoll();
      if ($('logout')) {
        new Image().src = 'collapse?id=' + id + (on ? '' : '&un=true');
      }
      ev.stopPropagation();
      return false;
    }

How would the react+redux approach look like? Is it really worth it?

I head to re-read your comment 5 times before I understood that by "MVC framework" you mean "thing that renders HTML on the server".

Admittedly it's a bit of a beef of mine, but most React apps are very MVC. I even blogged about it a while ago: https://blog.talkjs.com/how-react-brought-model-view-control...

Me neither, Java and .NET MVC frameworks forever! :)

From what I've seen it's just that clients like Apollo cache already requested properties so there's less unnecessary fetching. Not that compelling IMO.

The way we are doing this is, we have a proxy layer that exposes REST APIs, the proxy translates the REST requests to GraphQL requests; For the ones which are challenging, like authentication for instance, we are just forwarding the request to the main server.

I see GraphQL queries at work and some of them are almost 100 lines long because we're asking for/receiving almost all of the available data fields.

So what would be a 1 line request in REST format is now 100x longer and complex and why? It's an internal service so we weren't worried about reducing bandwidth costs (the problem FB was presumably trying to solve). I assume it was adopted because it's sexy and/or the developer wanted an excuse to use it.

I also wonder about the performance benefits if your data is in a SQL db...if you're running a no-SQL db then you can specify only the fields you want but I'm guessing a SQL db is likely to lock and read the entire row/record, even if it's only returning a subset of values.

If you're building a big, public-facing API or if people will only want a small subset of available data fields exposed by the API, GraphQL makes sense, but I feel like devs are swapping out easier-to-implement and use REST APIs just because GraphQL sounds cool.

Same here. Very complex to implement, or you decide to use libraries that provide tremendous abstraction. And you still have to worry about query optimisation and n+1 problem. Not to mention if certain users can see certain fields!

Yup. Complexity. You may spend more time writing REST endpoints, but they're very simple to profile and target for optimisation. In situations where you're consuming the API you're writing, just iterating on a REST API is so much faster.

After using Redux for about a year on a few different projects I still generally hate it. I fantasize about an alternative timeline where the stars didn't align to couple Redux with React in so many peoples minds. I'd love to see/hear more about MobX when React comes up.

All articles on hackernoon I've seen are clickbait with very little in-depth content. I stopped opening their articles a while ago.

Turns out apollo (graphql client for react) is doing more or less redux's work.

I planned on using both at first when I started migrating to graphql, but quickly saw that indeed redux was becoming redundant when we use apollo. Especially since they added local state management [1].

[1]: https://www.apollographql.com/docs/react/essentials/local-st...

There is probably half a dozen way of maintaining state to handle multi-form pages without Redux and GraphQL (both on client-side or server-side, or a combination of both).

I guess one of the point the author was trying to make is that using GraphQL makes it easier to handle the state on the server, and it has multiple advantages (what if you fill a form half-way through on your desktop and want to resume on another device).

GraphQL also makes Http requests "cheaper", you only ask for what you need and reduce payloads in general.

Yep, I started out doing java swing and awt UIs in the nineties. That stuff was a walk in the park compared to the craptastic react garbage that passes for software engineering these days. Looking at the JS landscape right now, it feels like we are running backwards in a hurry. Back in the day you could drag and drop simple uis together in minutes in range of IDEs for several languages. Any idiot could do it. In fact there were lots of idiots being productive in stuff like VB. The pros would do it programmatically in basically not a lot more time and end up with something that was easy to maintain and evolve.

You'd struggle to replicate most of that stuff in javascript even if you had days/weeks to do it. You'd be reinventing off the shelf components along the way that were completely bog standard 25 years ago; hand crafting event handling mechanisms; dealing with hard layout and positioning issues; etc.

That style of development seems to have died out for no good reason that I can think of other than that Javascript has been the only thing that actually works in a browser for the last 20 years. There's no other good reason for people to tolerate that.

Looking forward to WASM fixing that problem over the next few years. I might even get back to doing some frontend stuff.

UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the design/review stage, but also at runtime.

So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change.

Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results.

Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem.

What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API').

GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure.

But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.

Right? I fail to see how I can keep components all in sync across different parts of my app with GraphQL.

I'm already using Firebase, most of my operations are already unique API calls. I typically dispatch an update to my store and to firebase simultaneously in one thunk action. I typically dispatch the thunk directly from a connected component or from it's connected parent container. Seems like GraphQL solves literally no problems for me

He's missing the point entirely. User interface programming is hard. And time-consuming. The discussion about client Vs server side is simply talking about where to shift this burden.