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

The State of JavaScript – Survey results

stateofjs.com

Post reply on HN
Print view View original

221–230 of 357 posts

Re: The State of JavaScript – Survey results

#221

Post by morgante »

tiglionabbit wrote: post #217
morgante wrote: post #63

Earlier quoted context omitted.

Not really. Relay is mostly designed around querying a backend data store, not updating/managing client-side state.

Relay already is a replacement for Redux. It wraps React components and it has a store. How could you even use Relay and Redux together?

> Relay already is a replacement for Redux. It wraps React components and it has a store

That's hardly the definition of a replacement for Redux.

Relay v1 has absolutely no client-side state management support. I'm sorry but it's incredibly disingenuous to say they're substitutes at this point. Apparently v2 will have some client-side support.

To be clear, I don't want to bash Relay. I really like GraphQL and have Relay to thank for helping me to get stated on it. I've just found it to have a lot of challenging complexity which is really hard to manage, especially compared to Apollo. Also, "replacing Redux" is really not a selling point. The Redux ecosystem is strong enough at this point that being able to work with it is a huge advantage.

> How could you even use Relay and Redux together?

Pretty easily. The nice thing about the React ecosystem is that things rarely conflict with each other. In my case, API data is updated/fetched via Relay while purely client-side info uses Redux.

Re: The State of JavaScript – Survey results

#222

Post by morgante »

bberrry wrote: post #135
morgante wrote: post #56

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all. The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo sp…

You wouldn't happen to have a seed project with that stack by any chance? I would be very interested in trying it out.

I haven't updated this to use GraphQL yet, but this is my standard project starter template: https://github.com/gigster-eng/python-starter

Re: The State of JavaScript – Survey results

#223

Post by tiglionabbit »

morgante wrote: post #221
tiglionabbit wrote: post #217

Earlier quoted context omitted.

Relay already is a replacement for Redux. It wraps React components and it has a store. How could you even use Relay and Redux together?

> Relay already is a replacement for Redux. It wraps React components and it has a store That's hardly the definition of a replacement for Redux. Relay v1 has absolutely no client-side state management support. I'm sorry but it's incredibly disingenuous to say they're substitutes at this point. Apparently v2 will have some client-side support. To be clear, I don't want to bash Relay. I really like GraphQL and have Re…

I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Personally, I'm happy to be rid of having to maintain this kind of state if I can.

Re: The State of JavaScript – Survey results

#224

Post by aidos »

spion wrote: post #210
darksaints wrote: post #72

Earlier quoted context omitted.

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers. So far, I've only found one common objection to i…

The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/ Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input eve…

Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state.

Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.

Re: The State of JavaScript – Survey results

#225

Post by k__ »

morgante wrote: post #221
tiglionabbit wrote: post #217

Earlier quoted context omitted.

Relay already is a replacement for Redux. It wraps React components and it has a store. How could you even use Relay and Redux together?

> Relay already is a replacement for Redux. It wraps React components and it has a store That's hardly the definition of a replacement for Redux. Relay v1 has absolutely no client-side state management support. I'm sorry but it's incredibly disingenuous to say they're substitutes at this point. Apparently v2 will have some client-side support. To be clear, I don't want to bash Relay. I really like GraphQL and have Re…

Interesting. Till now I only used redux to store server-side info. Client-side stuff always went into the component state.

Re: The State of JavaScript – Survey results

#226

Post by tiglionabbit »

This makes Firebase look wildly popular. But can you even use Firebase for an app where you don't trust every user to maintain your denormalized indexes properly?

I asked this question on Stack Overflow to not much response: http://stackoverflow.com/questions/39800531/collaborating-wi...

Re: The State of JavaScript – Survey results

#227

Post by morgante »

tiglionabbit wrote: post #223
morgante wrote: post #221

Earlier quoted context omitted.

> Relay already is a replacement for Redux. It wraps React components and it has a store That's hardly the definition of a replacement for Redux. Relay v1 has absolutely no client-side state management support. I'm sorry but it's incredibly disingenuous to say they're substitutes at this point. Apparently v2 will have some client-side support. To be clear, I don't want to bash Relay. I really like GraphQL and have Re…

I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Personally, I'm happy to be rid of having to maintain this kind of state if I can.

> I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server.

Exactly. For example, one application I'm working on has a complicated multi-page form/wizard. Redux is great for keeping this manageable and in fact takes care of all the management for this without me also having to write code for managing it on the backend at all.

Re: The State of JavaScript – Survey results

#228

Post by tiglionabbit »

morgante wrote: post #227
tiglionabbit wrote: post #223

Earlier quoted context omitted.

I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Personally, I'm happy to be rid of having to maintain this kind of state if I can.

> I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Exactly. For example, one application I'm working on has a complicated multi-page form/wizard. Redux is great for keeping this manageable and in fact takes care of all the management for this without me also having to write code for managing it on the backend at all.

You mean Redux, right?

Re: The State of JavaScript – Survey results

#229

Post by k__ »

djmashko2 wrote: post #126
morgante wrote: post #56

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all. The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo sp…

(Disclaimer: I work on Apollo) Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture. It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone…

Do you guys know something loke Apollo but on top of RxJS?

I'm not a big fan of Redux anymore since I discovered observable streams.

Re: The State of JavaScript – Survey results

#230

Post by sgdesign »

djmashko2 wrote: post #126
morgante wrote: post #56

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all. The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo sp…

(Disclaimer: I work on Apollo) Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture. It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone…

I agree that Apollo is a subset of GraphQL, but I wouldn't have been able to collect any data on it unless it was a separate answer.

It's your fault for building something innovative that doesn't neatly fit in a pre-existing box… (same thing with Meteor actually!)

Post reply on HN