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

React and Redux are a joke right?

games.greggman.com

Post reply on HN
Print view View original

31–40 of 119 posts

Re: React and Redux are a joke right?

#31

Post by joncampbelldev »

mariusandra wrote: post #21
joncampbelldev wrote: post #19

Earlier quoted context omitted.

60k is hardly an issue, most hi-res images would be larger than that. Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers. Add to that tree-shaking (removing unused code) and the long term size of your app is looking good. I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoo…

60k is a big issue if your users are on older smartphones. I'm tired of people equating the time it takes to download an image in the background with the render blocking cpu-crunching parsing that javascript requires.

Like the 966k of JS on your homepage? ;)

There are several things to consider with download time:

- is this a website? why on earth do you need react or anything for a website?

- is this a single page web application? then to develop with a medium sized team and an increasing feature set its nice to pick a language and library/framework that enable that.

- do you really care about mobile users performance and bandwidth? then you need a native app

This is all unrelated to the article, which is merely an uninformed rant about someone who doesn't understand the point of immutability and its use within functional programming as opposed to shoe-horning it into imperative code.

Re: React and Redux are a joke right?

#32

Post by boubiyeah »

mariusandra wrote: post #21
joncampbelldev wrote: post #19

Earlier quoted context omitted.

60k is hardly an issue, most hi-res images would be larger than that. Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers. Add to that tree-shaking (removing unused code) and the long term size of your app is looking good. I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoo…

60k is a big issue if your users are on older smartphones. I'm tired of people equating the time it takes to download an image in the background with the render blocking cpu-crunching parsing that javascript requires.

Word. Such a stupid comparison.

You can add JIT too :) More JS, more time needed to reach decent runtime speed post JIT. React's first render is very slow.

Re: React and Redux are a joke right?

#33

Post by tck30 »

tl;dr of this blog post: "Oh no, I don't understand how immutable data structures work and need to rant about why it doesn't make sense!"

I don't want to be mean about it, but there's a lot of literature on functional programming and how mutable data complicates things as your states increase. The problem isn't how React forces you to write long code to get around immutability, the problem is the fact that you're trying to force your approach.

And no, this isn't because React is heavily opinionated -- it's because React's underlying philosophy is functional programming.

Re: React and Redux are a joke right?

#34

Post by davidmurdoch »

mariusandra wrote: post #28

Try using ES destructoring and spread operators plus a library like Kea ( https://kea.js.org ) to provide a framework over Redux and most of these arguments become irrelevant.

Not the author, but my opinion on the matter is that react already has too many abstractions and helpers, which just adds to the problem. React is difficult to grok on its own. Adding another framework to the tech stack just makes it worse if you don't already have a fluent understanding of the layers beneath. This is my experience with it, at least.

Re: React and Redux are a joke right?

#37

Post by joncampbelldev »

boubiyeah wrote: post #32
mariusandra wrote: post #21

Earlier quoted context omitted.

60k is a big issue if your users are on older smartphones. I'm tired of people equating the time it takes to download an image in the background with the render blocking cpu-crunching parsing that javascript requires.

Word. Such a stupid comparison. You can add JIT too :) More JS, more time needed to reach decent runtime speed post JIT. React's first render is very slow.

A one-off event for a single-page-app which is likely to be used for more than a few minutes, and if performance of old mobile users matters then a native app is necessary, period.

If you're talking about a webpage then yes that would be awful.

Re: React and Redux are a joke right?

#38

Post by andrewingram »

boubiyeah wrote: post #24
allover wrote: post #3

Stopped reading half-way through, as lots of incorrect stuff off the bat. > In the react world though you can’t mutate your data Sure you can. > If you get 3 people react will end up re-rendering 3 times because of the code above. Each call to `setState` triggers a re-render. Nope, calls to setState are batched.

They're not always batched. They're only batched within the context of an Event listener. A fairly odd distinction made necessary because React rendering was made synchronous initially but I guess it works for most apps.

The fact that it's currently within the context of an event listener is probably the wrong way to think about it. The only sane and safe way to work with setState is to think of it as scheduling a change to be made at some point in the future, and that batching will occur if possible.

It's clear from the post that the author didn't learn how setState works, he's not aware of either batching or the callback form, which neatly address most issues related to setState.

I didn't pay much attention to the second half of the article, because I avoid heavy use of Redux anyway. Ultimately the author shouldn't have even been looking into Redux before understanding how React works, so presumably he's been misinformed somewhere along the way.

Re: React and Redux are a joke right?

#39

Post by BigJono »

gorm wrote: post #5
joncampbelldev wrote: post #2

If the author wishes to continue with js/react/redux then he needs to pick up a library like immutable.js to cut down that immutabiilty helper crap. However, there is a better way ... lein new figwheel my-app, clojurescript+reframe gives you all the benefits of redux with an order of magnitude less boilerplate (also hot reloading and immutability by default without no extra setup or ceremony)

Immutable.js is just another complication with another 60k size penalty with a few new negative drawbacks that he would need more complexity to solve. Author is already arguing against this approach.

Yep.

I've been working with React for years now, over several large projects. I still feel like I'm not used to it, and I still hate it. That's not normal.

We need to either figure out how to do this shit with mutable data structures, or we need a new language that's immutable by default.

ImmutableJS blows chunks. Yeah it "saves" code until you start doing the data transformation dance trying to figure out when and where to convert between plain JS objects and Immutable ones. Then you end up with some real ugly shit that'll trip up every new hire you walk through it (we use a higher order component that converts a component's Immutable props to regular objects, which incidentally is another import that like 800 unrelated files depend on...)

God help you if you don't use well commented code or Hungarian notation to differentiate between Immutable objects and regular ones. We all know how long good commenting practices last without thorough code reviews, and we all know how long those last in fast-moving environments, which is where React is most useful.

I guess a typed language would solve that. No, Flow and Typescript don't count.

Post reply on HN