Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we decided against GraphQL for local state management

tech.okcupid.com

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Why we decided against GraphQL for local state management

#51

Post by sebmellen »

carabiner wrote: post #8
Matthias247 wrote: post #7

I wish they would just revert their site to where it was 2 years ago instead of doing anything new. The new version just looks like yet another Tinder clone, and doesn't resemble anymore what Okcupid was good at: Good profiles, which allowed to get an initial impression about people beyond "I like their looks".

I wish it was more like 6 years ago, or whenever the Match buyout was. It's become hot people clickbait like all the swipe apps now. The entire internet is being optimized to either outrage you or sexually arouse you as quickly as possible.

A friend of mine at Google is considering moving to another team or leaving because he's concerned about how addictive YouTube has become. Apparently it's a real discussion internally: is YouTube doing more harm than good?

To me, it seems that we're in a precarious position. I wonder what happens when we reach the limits of dopamine saturation, if there is such a thing. Otherwise, it seems Huxley was right -- "man’s almost infinite appetite for distractions" is a dangerous thing.

Re: Why we decided against GraphQL for local state management

#52

Post by weeksie »

acemarke wrote: post #46
weeksie wrote: post #45

Earlier quoted context omitted.

You've worked on two apps. Besides that you've been a part of the evangelist ecosystem for a tremendously simple framework. You are not what I could call an expert in using Redux. You are almost certainly an expert in Redux's internals but that's not what we're discussing. In fact the root of the problem is exactly that you've conflated one for the other.

I know I'm feeding a troll here, so last response. I've looked at hundreds of other codebases, ranging from beginner apps to complex enterprise-level apps. I've talked to thousands of people who are using Redux in many, _many_ different ways, and catalogued hundreds of libraries people have made to add on to Redux. I _know_ how people are using Redux in practice, and what kinds of problems they're running into. I'm q…

I'm not trolling you, I'm exhorting you to stop pushing extra frameworks for things that there should not be frameworks for.

The issue is not that one or another approach is always better, it's that the entire act of lobbing another framework onto the stack that a dev has to familiarize themselves with only adds to the confusion.

Rails worked because it contained everything in one package. The success of that model poisoned everybody's mind into believing there had to be "opinionated" frameworks to manage other (extremely simple) frameworks and has contributed greatly to the mire of misdirection that is modern front end development.

It's a case of not even wrong.

Re: Why we decided against GraphQL for local state management

#53

Post by weeksie »

jackewiehose wrote: post #48
weeksie wrote: post #33

Earlier quoted context omitted.

I see it as someone clout-chasing for their framework. A framework that promotes questionable practices. Framework developers and working engineers have diverging interests. The problem with his style is that he parades himself as an expert but he's emphatically not an expert. He's a guy with an agenda to push his open source framework. I understand where the bias toward politeness comes from, but that makes groups l…

> Framework developers and working engineers have diverging interests how is that?

Framework developers want you to use their framework. Engineers want to solve a problem in a manner that works best for their organization. The two incentives sometimes intersect but that is by no means a given.

Re: Why we decided against GraphQL for local state management

#54

Post by weeksie »

isakkeyten wrote: post #43
weeksie wrote: post #26

Earlier quoted context omitted.

What's with the copy paste spam on every one of your posts? None of what you're saying matters in the scheme of things. You can get everything you need from const { types, actions } = createActions([ 'ACTION_NAME', ...]); Where createActions is an exercise for the reader, but shouldn't take more than a few lines. Then go about your business from there. Adding another layer of framework over the top of this stuff only…

He's been doing it for a while now. I believe he has setup some google alerts on the words 'redux | thunks | sagas' and he just brings his redux toolkit gospel along. And not just on this site, like, everywhere. Dev.to, reddit, twitter... I've confronted him once but to no avail, I even got downvoted by the community. :) https://www.reddit.com/r/reactjs/comments/fvuwpl/handling_si... edit: i see that's happening to y…

Haha yeah. Evangelists, man. Ah well, what can you do.

Re: Why we decided against GraphQL for local state management

#55

Post by bauerd »

weeksie wrote: post #45
acemarke wrote: post #41

Earlier quoted context omitted.

Two, because I've spent the last 9+ years of my career working on the same couple apps :) But both were pretty complex - true SPAs, no routing, lots of complex client-side state manipulation going on. In fact, the first one is actually what inspired everything that I showed in my "Practical Redux" blog tutorial series, since I couldn't show off work stuff publicly. But hey, if that list of stuff I've done isn't good…

You've worked on two apps. Besides that you've been a part of the evangelist ecosystem for a tremendously simple framework. You are not what I could call an expert in using Redux. You are almost certainly an expert in Redux's internals but that's not what we're discussing. In fact the root of the problem is exactly that you've conflated one for the other.

If you gave actual technical arguments instead of just attacking the credentials of a person you'd actually contribute to the discussion at hand. As is, you seem to have a pretty bad day …

Re: Why we decided against GraphQL for local state management

#56

Post by deckard1 »

crooked-v wrote: post #20
city41 wrote: post #17

Earlier quoted context omitted.

You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machi…

Having used Redux for some elaborate stuff (in particular, a web app that used a couple of KB of info in Redux to generate an extremely dynamic UI, with diff-style data changes via Websockets inserted in realtime), honestly, the biggest problem I've seen with Redux use is just... people using it for things when they shouldn't. This is most glaring for the whole "do a GET and store it in Redux" thing, where if there's…

> people using it for things when they shouldn't

I know people that advocate putting everything in redux. They are quite serious about this. Then you end up with reselect everywhere and the whole goddamn universe is memoized. No one seems to know how React renders (or re-renders), so memoize everything! Yes! That's the ticket.

The overuse of Redux and the React hook brain damage stems from the tide finally turning against OOP. Haskell did a number on the OOP paradigm. So everyone is afraid of encapsulated state and localized logic. Then you end up with React hooks. Instead of making React's object API better, they choose to make functions worse. So everyone is pretending they are doing functional programming when in reality they are just using functions that are bastardized with this weird flavor of dynamic scoping and all the subtleties of that. But I digress.

Today, there are a thousand different ways to do web development wrong and practically no way to do it right. Starting with misconfiguring webpack and working up the stack. It's a true complexity quagmire. But surely there is a SaaS or open source toolkit (with adjacent commercial services!) coming soon to help guide us out of the fog.

Just kidding. This hell of ours is by design.

Re: Why we decided against GraphQL for local state management

#57

Post by wolco »

acemarke wrote: post #50
isakkeyten wrote: post #43

Earlier quoted context omitted.

He's been doing it for a while now. I believe he has setup some google alerts on the words 'redux | thunks | sagas' and he just brings his redux toolkit gospel along. And not just on this site, like, everywhere. Dev.to, reddit, twitter... I've confronted him once but to no avail, I even got downvoted by the community. :) https://www.reddit.com/r/reactjs/comments/fvuwpl/handling_si... edit: i see that's happening to y…

Honestly, the only alert I have is a Tweetdeck search for hashtag `#redux`. Other than that, I just spend too much time on social media :)

I would shorten the copy to be more effective.

Re: Why we decided against GraphQL for local state management

#58

Post by pastrami_panda »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

This might be obnoxious, but could you share some insights on what svelte is doing correct in your opinion? I've never worked with it but am curious to what is the secret sauce that made you feel like it was the correct abstraction.

Re: Why we decided against GraphQL for local state management

#59

Post by crooked-v »

deckard1 wrote: post #56
crooked-v wrote: post #20

Earlier quoted context omitted.

Having used Redux for some elaborate stuff (in particular, a web app that used a couple of KB of info in Redux to generate an extremely dynamic UI, with diff-style data changes via Websockets inserted in realtime), honestly, the biggest problem I've seen with Redux use is just... people using it for things when they shouldn't. This is most glaring for the whole "do a GET and store it in Redux" thing, where if there's…

> people using it for things when they shouldn't I know people that advocate putting everything in redux. They are quite serious about this. Then you end up with reselect everywhere and the whole goddamn universe is memoized. No one seems to know how React renders (or re-renders), so memoize everything! Yes! That's the ticket. The overuse of Redux and the React hook brain damage stems from the tide finally turning ag…

> Instead of making React's object API better, they choose to make functions worse.

I'd be really curious to see how you'd make the object API reusably composable, given that that's one of the basic reasons for hooks existing as they do.

Re: Why we decided against GraphQL for local state management

#60

Post by mschuster91 »

vosper wrote: post #27
claydavisss wrote: post #13

I would definitely encourage all of my competitors to use GraphQL. Nothing like getting a free six-month lead. That's two months they spend learning GraphQL, two months introducing a mystery-meat binding layer and learning that, and two months debugging it all and pulling their hair out. And no, using a giant third-party lock-in toolkit like Hasura or Apollo is not a response.

Genuine question: What technologies / techniques are you using while your competitors flounder around with GraphQL?

Tried and true server side rendering. Sure it will not look as snappy as a PWA... but I guarantee you that a seasoned team of Drupal developers can get up and running faster than a team of juniors fresh out of coding bootcamp, or even a team of senior-ish Javascript frontend devs who haven't heard about GraphQL yet, and much less have years of experience.
Post reply on HN