
Why we needed Redux in the past, and don’t any more - kiyanwang
https://hackernoon.com/goodbye-redux-26e6a27b3a0b
======
peteforde
Honestly, when I read this kind of thing, I have absolutely no idea what would
compel someone to throw away the MVC framework of their choice to
logarithmically ramp up the complexity of their apps. Most things that people
build don't need anything like this. It is of great concern that code
bootcamps are now teaching JS frameworks as the default expectation.

I guess it'll be more project work for those who get brought in to bail these
projects out.

~~~
TekMol

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

~~~
k_
React+redux (or just react) doesn't add much to websites. Maybe Vue.js would
be a better fit when some complexity is needed in a website.

I see React as a tool for building web applications, not websites. Using it
for something like hacker news is not needed nor worth it, except for learning
purposes or for the sake of using your favorite tech (which has its pros and
cons).

Edit: I use React a lot, and really like it. It's just not the perfect tool
for everything, and by no means a necessary one (at least when you don't have
much complexity); even if it is a good one in many cases.

In the case of HN, seeing the current js [1] I find it pretty obvious that no
"big tool" like React is necessary. It doesn't mean using React for a HN clone
is a bad thing, one just don't have to.

[1]:
[https://news.ycombinator.com/item?id=17915560&goto=news](https://news.ycombinator.com/item?id=17915560&goto=news)

~~~
TekMol
In my book, "website" and "web application" are equivalent.

How do you define those terms?

~~~
k_
I don't define them precisely either. I'll borrow an answer from stack
overflow [1]:

This is totally personal and subjective, but I'd say that a website is defined
by its content, while a web application is defined by its interaction with the
user. That is, a website can plausibly consist of a static content repository
that's dealt out to all visitors, while a web application depends on
interaction and requires programmatic user input and data processing.

For example, a news site would be a "website", but a spreadsheet or a
collaborative calendar would be web "applications". The news site shows
essentially the same information to all visitors, while the calendar processes
individual data.

Practically, most websites with quickly changing content will also rely on a
sophisticated programmatic (and/or database) backend, but at least in
principle they're only defined by their output. The web application on the
other hand is essentially a program that runs remotely, and it depends
fundamentally on a processing and a data storage backend.

[1]:
[https://stackoverflow.com/a/8694944/7510753](https://stackoverflow.com/a/8694944/7510753)

~~~
mattmanser
Most web applications don't need a JS framework either, so the distinction's
actually worthless.

------
Areading314
Why would a client/server query protocol replace the need to manage client-
side state? No matter how you build your client/server syncing there is
inevitably going to be client-side state that needs to be managed. You can't
just assume that any action will be atomically and instantly synced to the
server when you are operating over an (unreliable) network.

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

------
ishitatsuyuki
GraphQL is actually pushing all the complexity to the server; to make a joke
using the words in the article, it reduces the frontend coding time to 4 hours
while making backend to take 32 hours.

Actually, I also tried to move to GraphQL and still haven't a good fit yet.
GraphQL queries are hard to translate to efficient SQL, and there are
additional problems to tackle like authorization which is much complicated
than the REST model.

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

~~~
arisb
If you are only reading from a table I don't think any relational database
implementing MVCC would lock anything.

------
Epskampie
For everybody who is tired of the 10-step redux program I cannot recommend
Mobx enough. With mobx, the 10 steps simply become:

1: update a field in your model.

1b: the views that depend on exactly that data are automatically rerendered.

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

------
maaaats
I'm not a big fan of Redux, it's often fairly complex for simple things, but I
don't think the author has any compelling arguments in his article.

And I have to say, I'm not so fan of this peppy-feel-good-emoji way of writing
I see more and more often. Especially if it's just hiding lack of substance.

------
bellwether
Clickbait much? This doesn't even go into the real developments within React
to allow direct use of connective functions vs. using Redux. And there's been
articles by the React team saying even that is not meant to be a replacement
for Redux, just another tool in your arsenal.

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

------
cryptozeus
What ? How can redux be replaced by graphql ? How would you handle multi form
pages where you have to maintain state ?

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

~~~
cryptozeus
Right, but you don't always want to or need to go to server to maintain state.

------
zaro
The author apparently has no clue what he is talking about as he is stating
that a client/server protocol is obsoleting client state management library.

------
preordained
Sometimes I wonder if these framework astronauts have ever done a little Java
Swing or VB GUI or the like. A user interface is not the greatest problem of
our time...it's not supposed to be this hard...

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

~~~
kthejoker2
So on one hand, this this this. I left web dev 10 years ago for data precisely
because I saw that I was being asked to learn complexity for complexity's sake
and no notable benefit to my users.

On the other hand, the rise of cross-browser and cross-OS compatibility is
really the root cause that drove a lot of this complexity from jQuery to React
to even WASM, so you can't throw the baby out with the bathwater.

------
agentPrefect
_The way Redux works is that it essentially stores all the dynamic information
of an app in a single JavaScript object._

This is the temptation when starting with Redux/Mobx/GraphQL/etc. You can't
simply relegate reasoning through your application architecture to a single
library or because some big company solved a problem with it.

Redux is a fantastic way to organise some of your app state & GraphQL is also
great at a lot of stuff! Absolute no need to play the all-your-eggs-in-one-
basket game.

------
dansingerman
TLDR: You don't need to manage state in the client now; manage state in the
server by making more API requests. And GraphQL makes that a bit easier. Oh
and you still need to manage state in the client.

~~~
brendanmc6
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

------
kozak
Today for my React state management I use just a plain vanilla JS class
(ES2015, to be precice). I have immutable state and PureComponent classes,
like all the cool guys. I could, in principle, maintain the immutable state
myself using a lot of Object.assign() calls, but there is a nice little
library called "icepick" that does it for you. The library is just a set of
pure functions that return standard JavaScript frozen objects.

This way I have all the advantages of Redux, but with very terse BS-free code.

------
bryanrasmussen
So he says most of the functionality is maintained in the frontend now thanks
to these frameworks and then complains he spent 32 hours in frontend coding as
opposed to 4 hours backend - what split was he considering should have been
adequate?

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

~~~
bryanrasmussen
right that's my point, he's moved the burden around and then is surprised that
the burden on one side is really big now.

