13 ms·

React and Redux are a joke right?

120 points by oal 9y ago

littlecranky67 9y ago
Author complains about "lots of code" needed for changing his data, but at the same time refuses to use modern ES6 features.Most of his code would come down to 2-3 lines when using destructuring and object/array rest operator.
- bokglobule 9y ago
  Agree. Some of the complaints get back to not really understanding the ES6-7 feature set that was created to allow JS to become more compact yet expressive in doing common tasks (like creating an object from an existing object, yet changing a few parts). For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data. So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component). I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation. So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help. I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.
joncampbelldev 9y ago
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)
- gorm 9y ago
  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.
  - joncampbelldev 9y ago
    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 hoops to get a project setup, or pick the latest and greatest build tool (grunt->gulp->webpack->jspm)
    - mariusandra 9y ago
      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.
      - joncampbelldev 9y ago
        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.
allover 9y ago
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.
- ryanbrunner 9y ago
  I think sometimes you need an outsider view to call out that the emperor isn't wearing any clothes, and that's going to result in botched details. I don't think it impacts the overall point the author is trying to make. I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less productive or effective by the end of the course - they're doing well if they have the barest skeleton of a CRUD app up, whereas the Rails apps were all fleshed out and far more engaging. There's something rotten with the state of development these days - we're dealing with far more complexity and being less productive for what's usually the same result.
  - vim_wannabe 9y ago
    One problem is people reach out to client-side code earlier than they should. 90% of websites have no need for Javascript. Of those that do 90% won't be needing any "take over the world" frameworks, just little sprinkles of Javascript or jQuery. Not to mention most required uses of Javascript are interaction related. At least let me read the landing page without having me enable javascript instead of greeting me with a blank page.
    - ryanbrunner 9y ago
      I agree. I think 90% of the "problem" with React or Redux is that people espouse using "the right tool for the job", but almost never practice it when the right tool is unsexy.
  - littlecranky67 9y ago
sambeau 9y ago
TL;DR: Author confuses Redux for React and then rants about it.
LoSboccacc 9y ago
Without a big push in uniforming and standardizing ways to listen to property changes on both objects and components there won't ever be a sane UI framework in javascript, it's simple as that. They'll either be too limited so that you cannot express the full featureset of html within their bindings without hacks or too convoluted to use and impossible to debug.
mamon 9y ago
Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?
- VeejayRampay 9y ago
  Because if everything is immutable, it gets very easy to compare two given states and know when and what to update, by using referential equality (if you create a new object every time, then a different "ID" means the data has changed, to grossly simplify the idea behind it).
- romanovcode 9y ago
  The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.
  - joncampbelldev 9y ago
    Immutability in js is awful hence the complexity, a library like immutable.js can make it better, but the language is just not built for it. Because imperative code and persistent, immutable data do not play nicely together.
    - romanovcode 9y ago
      Agree, but the problem is that you need unreal discipline because what I see in projects that are 1+ years old half of the code is using Immutable.JS and half is not - and that is even worse!
  - davidmurdoch 9y ago
    Haha. You just made me choke on my coffee with that last line!
romanovcode 9y ago
Some people like immutability, some don't. It's the way of life.
davidmurdoch 9y ago
I started working on a react native+redux project myself recently (after working with react on its own for about 1 year) and have been feeling the same way. And we've just been working on auth, data persistence, and screen navigation. My problem with it is that there is so much abstraction that almost no prior knowledge from using other frameworks or libraries is useful. It seems like everything is magic. Here is a chain of react tech things: React->Flux->Redux->Redux-Persist->PersistGate The latter is talked about in documentation, i.e., "do it like PersistGate does", but I can't find PersistGate anywhere. With so many react extensions and libraries all having their own helper functions to do everything it seems like we are no longer programming, but instead, we are tasked with stringing together configuration functions after searching for hours for the currently relevant documentation. I think react does some pretty amazing things, but the learning curve is too steep because of fragmented documentation (mostly the community created how-tos are the problem here), confusing abstractions, and poor method naming (thinking about redux's `reducer` here). Anyway, I, and several programmers at my company, share your sentiments; you are not alone. This will probably be my last greenfield react project.
- hungerstrike 9y ago
  This is exactly my experience. Eventually, I skipped redux/mobx/etc altogether by creating a singleton EventEmitter which can hold application state objects, emit events when the state changes and persist it to SQLite. For data that does not need to be in memory, I just access SQLite directly (and I can still use my appState singleton to let the rest of the app know when SQLite data has changed.) Yesterday I spent probably 5-6 hours just trying to figure out how to navigate easily with react-navigation. There are probably over 100 questions on their issue list asking the same thing: How do you easily navigate between nested navigators? They all have the same setup: A StackNavigator that contains a TabNavigator that contains one or more StackNavigators. Nobody knows how to do it without redux and users that do use redux have other complaints. The react-navigation examples all show a `path:` property, but they don't just have a global service that you can use to navigate to all those paths. Instead (I think) you have to wrap all of your navigators and pass around the `navigation` property. When I tried following their example of passing down the navigation property, I just get errors. I blame the people who tried to force their stupid functional programming ideology onto the whole framework.
bauerd 9y ago
>In the react world though you can’t mutate your data. Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library? >If you get 3 people react will end up re-rendering 3 times because of the code above. Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault? >So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays. I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a tree and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for. >Why is the UI library dictating how we store and manipulate our data!!! It does not do this, it's a virtual DOM/diffing library (!!!). >Maybe someone needs to start the browser over. This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least. Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?
- BigJono 9y ago
  > I've found that deeply nested structures make it more cumbersome to write reducers for. Well, that's kind of his point isn't it? It's no more difficult to update a deeply nested regular Javascript object. But it is more difficult to update a deeply nested Redux data store. > Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is? I'd argue that Redux is not just "not a silver bullet", it's an arrow head shoved into the barrel of a gun. You might kill something with it, doesn't make it any good. I agree completely with the rest of your points though.
- stickfigure 9y ago
  I'm about 6 months into a React project (coming from Angular1) and honestly I find the OP's rant pretty coherent. React requires a preposterous amount of code to maintain state, and Redux doubles down on boilerplate. In Angular-land you can just mutate some JS objects and the UI magically updates. I really miss that. I picked React over Angular2 because the setup was simpler and I wanted to try out this new thing that everyone has been raving about. I have a lot of misgivings about the choice. There are some things I like about React, but I probably will not choose it for my next SPA. There's just too much typing.
Tade0 9y ago
I think the author may like to consider Vue.js + Vuex. In Vuex in particular the first argument of each mutation is the store state, which you can mutate how you wish and the framework takes care of the rest.
- overallduka 9y ago
  Yeah. VueJS is powerful, easy, and made based on Javascript principles itself. I recommend for sure for who thinks React overcomplicates stuff, like me.
mariusandra 9y ago
Try using ES destructoring and spread operators plus a library like Kea (https://kea.js.org https://kea.js.org) to provide a framework over Redux and most of these arguments become irrelevant.
- davidmurdoch 9y ago
  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.
  - mariusandra 9y ago
    But that's kind of the point with react: it's just a view library so you're forced to add things to the tech stack until they click together. Of course it helps a lot of you know how all the layers work on their own.
tck30 9y ago
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.
- mediumdeviation 9y ago
  React feels like a library written for a language that's not JavaScript. JavaScript defaults to mutability by default - there are no immutable primitives that you can easily use, and even in ES6 just maintaining immutability without deep cloning everything takes a lot of effort. In that respect React is heavily opinionated.
  - tck30 9y ago
    Yeah, I guess that was a false statement. You're right.
  - striking 9y ago
    "there are no immutable primitives" Many array prototype functions work in an immutable way like map and reduce
    - mediumdeviation 9y ago
      Updating an array element arr[3] = 'New content'; Updating an array element immutably arr = arr.map((element, index) => { if (index === 3) return 'New content'; return element; }); It's possible, sure, but it feels terrible. JavaScript objects want to be mutated - it's the most idiomatic way of interacting with them. Whether functional programming paradigm is good (I certainly feel it is) is beside the point - JS wasn't designed for it. When I think of immutable primitives, I think of Python's tuples, which will raise a big fat error when you try to mutate them, or even better, Swift's structs, which gives you a new copy with every mutation.
franzwong 9y ago
Choose the tool which is suitable for you. When your web app grows to a certain scale, you will need "lots of code" to maintain state and prevent rendering.
skilesare 9y ago
I've tried to 'get' redux a couple of times and have reverted back to reflux each time because sanity is nice.
sotojuan 9y ago
Not the biggest JS fan but this is ill-informed and poorly written. Sounds about right for tech blog posts at least.
halayli 9y ago
It doesn't feel op have done their homework well. You should check immutable-js.
amelius 9y ago
Could somebody outline how I can write an efficient rich text editor using the state management techniques of React and Redux? (Not that I want to try this, but I'm interested in how that would work).
- chii 9y ago
  Tyr https://draftjs.org/ https://draftjs.org/
captainmuon 9y ago
The article has a point. We tend to fix issues with state by avoiding mutability. That is like going to a doctor because it hurts when you laugh, and they just say "don't laugh". I wish there was a language that embraced mutability instead [1]. Mutability is how the computer works at the lowest levels, and how we tend to think about the world. You would use plain old data objects to store everything. Then you would have first class observers, meaning you could have callbacks react to any changes to any object. But you wouldn't use that low-level functionality often. Instead you would e.g. create a listview, and just set it to observe the array. This is like "list adapters" that are in many frameworks, but built into the language. One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion (and occasionally sends mutating messages to the backend thread). You could implement that with read-write locks, but as far as I know no framework supports it directly. Maybe this language would have a special block that takes imperative, mutating code, and lifts it to implement the command pattern [2]. You then could "undo" these blocks, coalesce them, and so on. (That doesn't work with arbitrary code, but with most code that operates on business data.) (Here are some questions I asked on StackExchange, trying to find out if something like that already exists:) [1]: https://softwareengineering.stackexchange.com/questions/229876/language-that-embraces-mutable-state https://softwareengineering.stackexchange.com/questions/2298... [2]: https://softwareengineering.stackexchange.com/questions/351593/automatically-convert-mutations-in-imperative-code-into-functional-actions https://softwareengineering.stackexchange.com/questions/3515...
- arcbyte 9y ago
  Mutability is actually a kluge.
- trgn 9y ago
  `One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion` Dojo-stores, observable-collections essentially, were like that. A Dojo-view was a monitor for this. A very simple, elegant model-view design. I agree that we should embrace mutability. The JS-code most people write now has horrible performance characteristics since we do not take advantage of the benefits of mutating objects to manage state. Instead, in JS-world, we recreate and duplicate state all the time, spamming the heap. One library doing this is not too bad, but all libraries doing this is the main cause of slow web apps.
neya 9y ago
I'm one of the laggards - Over the years, based on staying around tech communities (esp. HN) I've learned not to invest time / effort into the hype that surrounds a newly launched tech. I did burn my finger a couple of times, especially with MongoDB back then, so these days I'm pretty cautious. I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework war, purely based on opinions. My opinion is pretty simple and resonates with a lot of people, apparently[1]: ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: [1] This alone makes React a joke for me, let alone the author's post. If it resonates with you, then good for you. I may not be from Facebook or Google to have the authority, but I do know what's good in the long run and what isn't. I couldn't be happier with Vue. [1] https://twitter.com/thomasfuchs/status/810885087214637057?lang=en https://twitter.com/thomasfuchs/status/810885087214637057?la...
- TheCoreh 9y ago
  I don't see how vue's take on this same issue is significantly or even marginally better: https://vuejs.org/v2/guide/conditional.html https://vuejs.org/v2/guide/conditional.html Instead of getting HTML fragments on your JS, you get JS fragments on your HTML? Whenever you need to programatically generate markup with conditionals and iteration over existing data structures, you end up having to mix a programming language with your markup. (The other option is of course to create an entire programming syntax on top of your markup language.) BTW, I haven't actually used vue, so this post is by no means me saying that it doesn't have its merits or it's not a good framework.
  - rhinoceraptor 9y ago
    Having used Angular 1 quite a bit, I think the whole DSL for HTML business is not the way to go. But at least Vue had the good sense to compile them rather than evaluate them at runtime like Angular.
- coldtea 9y ago
  >~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar. Such separation of HTML/JS/CSS was misconceived. It makes sense for web documents and simple forms, but not for web apps with rich widgets etc (which is what we're trying to do). Tons of problems stemmed from cargo cult adherence to that. Everybody else, including those that add JS instructions (or ad-hoc "templating language" instructions inside HTML tags) are getting it wrong.
thenewvu 9y ago
React does its job fine. I think the good part of the post is pointing out the verbosity of Redux and you don't accept it. According to me, it totally depends on your implementation, Redux is just a concept of data flow, you made your choice when using react-redux. By time and eventually, you will figure out how to minimize the boilerplate, because you didn't accept it.
coldtea 9y ago
Judging from the title I expected one of the usual BS posts like "OMG, React mixes code and html!!!" etc and was ready to post a "No, you just don't get it" comment. But this actually makes several good points on accidental complexity imposed by React/Redux. I know why they impose it, but there must (should) be a better way.
bichiliad 9y ago
There's a lot of comments in here addressing some of the conceptual misunderstandings of "how to use react" (i.e. "use immutable.js", etc). I started writing React within the last year and, while I still find parts of it strange, I've found its real strength comes from the fact that it's easy to reason about, particularly at scale. In a large project, I don't find myself digging around the codebase looking for the place where event listeners are being bound, or where a piece of the DOM is getting mutated. The unidirectional flow of data makes it very easy to jump into a piece of an app. It's not without its complexities, however. Mainly: 1. using JSX, instead of a more transparent templating language, means people with less technical knowledge (i.e. product designers) have a higher barrier to entry when trying to make simple UI changes (I'm looking at you, `className`). 2. it is unclear at times whether a component should have its properties passed in directly from state through `mapStateToProps`, or from a parent component through `props`. 3. there does seem to be an tiring amount of boilerplate when adding a new piece of interaction to a component (an action, an action type, a reducer case, and usually a piece of state all need to be added). 4. to a newcomer, the benefits of immutable.js are apparent, but the benefits of a memoizing layer like reselect.js were less obvious. When you're still trying to wrap your head around How To Write React Things™, it's not apparent that you'd even need memoization ("isn't React supposed to be good at diffing stuff?" you ask yourself after watching large pieces of your app redraw itself over and over). I'm curious to hear how people deal with these particular issues. React was one of the more useful tools I learned about this year, and I'd love to see the process for newcomers to React become less frustrating. Edit: formatting
tboyd47 9y ago
This guy expresses a lot of opinions about React/Redux that I share, but he doesn't understand something fundamental about web development. The look and feel of the page comes first, and the structure and coherence of the code comes second. And you don't really need complicated, fast UI for most web projects.
- coding123 9y ago
  Yes, but I sense that he's in a similar boat as me right now. I just joined this team that's already using React/Redux, and the code quality is... very sad.
  - tboyd47 9y ago
    Code quality was the main issue driving a lot of folks to React. Like lambs to the slaughter...
anilgulecha 9y ago
I get his point -- javascript object observation has been a pain, and causes the stated workaround.s With new API like Proxy [1], we should not be able to just modify data as needed, and any observers can be notified by handlers in the object get/set. This will lead to data being fully mutable. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- styfle 9y ago
  The Proxy API is how dot-dom[0] implements a React-like component API [0]: https://github.com/wavesoft/dot-dom https://github.com/wavesoft/dot-dom
obfk 9y ago
WHY would you even considering composing your own diffing structure for updating a components state when that's entirely against the paradigm React proposes. Pass props from the parents and let the tool do the heavy lifting. State is an abused and misunderstood interface in React.
websitescenes 9y ago
Honestly, I don't recommend using React unless you're building realtime web applications. Otherwise, you're correct, React is too heavy. If you're not doing realtime, the idea of state is completely unnecessary. But if you are doing realtime web apps the idea of state and hoops that React make you jump through make sense. Is it hard? Yep. Is it worth it. Yep. Will there eventually be a better way? Yep. With that said I think some of the pain points you identified could be simplified. State is needed but immutability could be made easier.
keymone 9y ago
yep, let's all just get back to mutating everything everywhere and generating dom elements in arbitrary places. because it has worked so well for us in past 12 years. i get a feeling author had no prior experience with js ui whatsoever.
agentultra 9y ago
> This is probably an ill thought through rant but... Everything after the "but" and all. The whole point of Redux is to separate actions and state manipulation. An argument that, "well I want to manipulate variables feely," is not an argument. Just don't use Redux. End of story. The pattern doesn't come from React. There are many patterns in React that are just Monads by a different name. Redux isn't much different.
Nekorosu 9y ago
Somehow author jumps from the problem of convenient data structures updating and immutability to Redux which solves a different problem. There are several things about React, Redux and React based tech stacks: 1. React requires knowledge of basics of functional programming React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. Without this knowledge, a lot of things will be a struggle and won't make any sense. You'll mess up pretty bad. React requires the understanding of its principles which require the understanding of FP essentials. 2. React is not a framework and does only one thing well It does only one thing well, turning your UI into a function of data. Yes, there is a virtual DOM but it's an implementation detail and not the purpose of React. If you think about it everything which is there is needed to make that UI=F(data) possible. However, it's enough for simple apps. Immutability isn't always needed so it's optional. It's not built into JS, you'll have to use an additional library. 3. Building non-trivial apps requires a lot of knowledge and experience Building non-trivial apps with React only is a pain. That's expected because the only thing it does is making a UI a function of data. It's not a framework with a complete set of tools and practices for building a whole SPA. That means you have to assemble your own tech stack for your particular task. This requires a lot of experience but lets you have the tools which are a better fit for your app. Redux is just one of the available choices for solving the problem of complex app's architecture. It isolates state from React components. UI interaction with the outer world is behind actions. Data access is behind selectors. State mutations are centralized in reducers. This is very convenient, you always know where to look for something. Business logic part is very clear because of actions and reducers. Not messing everything up requires knowledge and discipline though. The funny thing is React+Redux isn't a complete framework. For case, there are several solutions for writing asynchronous actions. The main idea is React is ok to use by itself for simple things. You don't need to know much except FP essentials. Using more advanced React based tech stacks requires much more knowledge and experience. If you don't know which of your problems React solves you don't need it. If you don't know which of your problems immutability solves you don't need it. If you don't know which of your problems Redux solves you don't need it.
- coding123 9y ago
  I completely agree here. and I think if most people followed these last 3 lines, there might be what, 6 projects using React? I find the highlighted article on Facebook's "reason" for inventing Flux/Redux very laughable. - This message unread indicator kept saying (1). And how it went away with bug fixes and came back... Did they ever stop to realize they just had some really bad devs working on the chat app? Any re-write, whether they had to invent flux or not would have fixed that indicator. It's a false story.
williamle8300 9y ago
Seems like the source of his gripes are with functional programming, not ReactJS itself.
Harkins 9y ago
This example doesn’t fit with the React style I’ve seen before, where state is rarely used. This data isn’t flowing (https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_end#c_1z3hjq https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_en...) like I’ve come to expect, but one of my biggest gripes with React is that the docs are no longer very good because they haven’t been comprehensively rewritten for the current design and because the only sentence in the docs to address the crucial distinction between props and state is the distinctly unhelpful: > If you imagine a component tree as a waterfall of props, each component’s state is like an additional water source that joins it at an arbitrary point but also flows down. In this post’s example, I would expect to see a component for an individual Person with the props name and location, then a People component storing the ordered list in props. If the app does a lot of this general “maintain a sorted list with random insertions from over the net”, People would be wrapped by a higher-order component (https://facebook.github.io/react/docs/higher-order-components.html https://facebook.github.io/react/docs/higher-order-component...) managing that. Otherwise there’d probably be a page-level custom component or just random stateful javascript pulling in the data and passing it down to People for rerendering. (I don’t know Redux to address the second half of his example.) It’s ironic that the author advocates for immediate mode GUIs, because normal React looks and works like an immediate mode GUI with memoization. A component is a function responsible for part of the page. Its props are the input to the function and it returns a render of part of the page (possibly by rendering more memoized components). The cache is busted when props changes. There’s also a hack to be used sparingly called state so that small bits of UI state can be managed at a low-level instead of in their parent component.
shafyy 9y ago
I agree that there is some amount of boiler plate code to Redux that doesn't seem to make sense and takes a long time to do when you're new. But I think it really helps with maintenance and scalability of projects down the road and saves you time later on. Of course, as others have said, React and Redux is not a panacea - depending on what you want to achieve and on your personal preferences there might be better tools.
- hex13 9y ago
  > I think it really helps with maintenance and scalability of > projects down the road and saves you time later on. It's popular argument but I don't think it's completely correct. On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability. Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none). I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.
  - shafyy 9y ago
    I see your points and don't disagree. However, Redux is a fairly young concept and I think it has some potential to grow (as is React).
luord 9y ago
After reading so much about it and trying it several times, I think my problem with react (alongside the licensing issue anyway) is that it feels like the perfect example of the fundamental theorem of SE: Everything is full of indirections and, when that isn't enough, then more abstractions in the form of tangentially related libraries (such as immutablejs in this thread) are recommended. I'm sticking with Vue, it's not perfect but it was at least designed to play with js's strengths instead of abstracting them to shoehorn functional principles.

120 points by oal 9y ago

Author complains about "lots of code" needed for changing his data, but at the same time refuses to use modern ES6 features.Most of his code would come down to 2-3 lines when using destructuring and object/array rest operator.

bokglobule 9y ago
Agree. Some of the complaints get back to not really understanding the ES6-7 feature set that was created to allow JS to become more compact yet expressive in doing common tasks (like creating an object from an existing object, yet changing a few parts). For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data. So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component). I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation. So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help. I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.

joncampbelldev 9y ago

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)

gorm 9y ago
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.
- joncampbelldev 9y ago
  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 hoops to get a project setup, or pick the latest and greatest build tool (grunt->gulp->webpack->jspm)
  - mariusandra 9y ago
    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.
    - joncampbelldev 9y ago
      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.

allover 9y ago

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.

ryanbrunner 9y ago
I think sometimes you need an outsider view to call out that the emperor isn't wearing any clothes, and that's going to result in botched details. I don't think it impacts the overall point the author is trying to make. I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less productive or effective by the end of the course - they're doing well if they have the barest skeleton of a CRUD app up, whereas the Rails apps were all fleshed out and far more engaging. There's something rotten with the state of development these days - we're dealing with far more complexity and being less productive for what's usually the same result.
- vim_wannabe 9y ago
  One problem is people reach out to client-side code earlier than they should. 90% of websites have no need for Javascript. Of those that do 90% won't be needing any "take over the world" frameworks, just little sprinkles of Javascript or jQuery. Not to mention most required uses of Javascript are interaction related. At least let me read the landing page without having me enable javascript instead of greeting me with a blank page.
  - ryanbrunner 9y ago
    I agree. I think 90% of the "problem" with React or Redux is that people espouse using "the right tool for the job", but almost never practice it when the right tool is unsexy.
- littlecranky67 9y ago

sambeau 9y ago

TL;DR: Author confuses Redux for React and then rants about it.

LoSboccacc 9y ago

Without a big push in uniforming and standardizing ways to listen to property changes on both objects and components there won't ever be a sane UI framework in javascript, it's simple as that. They'll either be too limited so that you cannot express the full featureset of html within their bindings without hacks or too convoluted to use and impossible to debug.

mamon 9y ago

Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?

VeejayRampay 9y ago
Because if everything is immutable, it gets very easy to compare two given states and know when and what to update, by using referential equality (if you create a new object every time, then a different "ID" means the data has changed, to grossly simplify the idea behind it).
romanovcode 9y ago
The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.
- joncampbelldev 9y ago
  Immutability in js is awful hence the complexity, a library like immutable.js can make it better, but the language is just not built for it. Because imperative code and persistent, immutable data do not play nicely together.
  - romanovcode 9y ago
    Agree, but the problem is that you need unreal discipline because what I see in projects that are 1+ years old half of the code is using Immutable.JS and half is not - and that is even worse!
- davidmurdoch 9y ago
  Haha. You just made me choke on my coffee with that last line!

romanovcode 9y ago

Some people like immutability, some don't. It's the way of life.

davidmurdoch 9y ago

I started working on a react native+redux project myself recently (after working with react on its own for about 1 year) and have been feeling the same way. And we've just been working on auth, data persistence, and screen navigation. My problem with it is that there is so much abstraction that almost no prior knowledge from using other frameworks or libraries is useful. It seems like everything is magic. Here is a chain of react tech things: React->Flux->Redux->Redux-Persist->PersistGate The latter is talked about in documentation, i.e., "do it like PersistGate does", but I can't find PersistGate anywhere. With so many react extensions and libraries all having their own helper functions to do everything it seems like we are no longer programming, but instead, we are tasked with stringing together configuration functions after searching for hours for the currently relevant documentation. I think react does some pretty amazing things, but the learning curve is too steep because of fragmented documentation (mostly the community created how-tos are the problem here), confusing abstractions, and poor method naming (thinking about redux's `reducer` here). Anyway, I, and several programmers at my company, share your sentiments; you are not alone. This will probably be my last greenfield react project.

hungerstrike 9y ago
This is exactly my experience. Eventually, I skipped redux/mobx/etc altogether by creating a singleton EventEmitter which can hold application state objects, emit events when the state changes and persist it to SQLite. For data that does not need to be in memory, I just access SQLite directly (and I can still use my appState singleton to let the rest of the app know when SQLite data has changed.) Yesterday I spent probably 5-6 hours just trying to figure out how to navigate easily with react-navigation. There are probably over 100 questions on their issue list asking the same thing: How do you easily navigate between nested navigators? They all have the same setup: A StackNavigator that contains a TabNavigator that contains one or more StackNavigators. Nobody knows how to do it without redux and users that do use redux have other complaints. The react-navigation examples all show a `path:` property, but they don't just have a global service that you can use to navigate to all those paths. Instead (I think) you have to wrap all of your navigators and pass around the `navigation` property. When I tried following their example of passing down the navigation property, I just get errors. I blame the people who tried to force their stupid functional programming ideology onto the whole framework.

bauerd 9y ago

>In the react world though you can’t mutate your data. Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library? >If you get 3 people react will end up re-rendering 3 times because of the code above. Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault? >So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays. I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a tree and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for. >Why is the UI library dictating how we store and manipulate our data!!! It does not do this, it's a virtual DOM/diffing library (!!!). >Maybe someone needs to start the browser over. This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least. Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?

BigJono 9y ago
> I've found that deeply nested structures make it more cumbersome to write reducers for. Well, that's kind of his point isn't it? It's no more difficult to update a deeply nested regular Javascript object. But it is more difficult to update a deeply nested Redux data store. > Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is? I'd argue that Redux is not just "not a silver bullet", it's an arrow head shoved into the barrel of a gun. You might kill something with it, doesn't make it any good. I agree completely with the rest of your points though.
stickfigure 9y ago
I'm about 6 months into a React project (coming from Angular1) and honestly I find the OP's rant pretty coherent. React requires a preposterous amount of code to maintain state, and Redux doubles down on boilerplate. In Angular-land you can just mutate some JS objects and the UI magically updates. I really miss that. I picked React over Angular2 because the setup was simpler and I wanted to try out this new thing that everyone has been raving about. I have a lot of misgivings about the choice. There are some things I like about React, but I probably will not choose it for my next SPA. There's just too much typing.

Tade0 9y ago

I think the author may like to consider Vue.js + Vuex. In Vuex in particular the first argument of each mutation is the store state, which you can mutate how you wish and the framework takes care of the rest.

overallduka 9y ago
Yeah. VueJS is powerful, easy, and made based on Javascript principles itself. I recommend for sure for who thinks React overcomplicates stuff, like me.

mariusandra 9y ago

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

davidmurdoch 9y ago
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.
- mariusandra 9y ago
  But that's kind of the point with react: it's just a view library so you're forced to add things to the tech stack until they click together. Of course it helps a lot of you know how all the layers work on their own.

tck30 9y ago

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.

mediumdeviation 9y ago
React feels like a library written for a language that's not JavaScript. JavaScript defaults to mutability by default - there are no immutable primitives that you can easily use, and even in ES6 just maintaining immutability without deep cloning everything takes a lot of effort. In that respect React is heavily opinionated.
- tck30 9y ago
  Yeah, I guess that was a false statement. You're right.
- striking 9y ago
  "there are no immutable primitives" Many array prototype functions work in an immutable way like map and reduce
  - mediumdeviation 9y ago
    Updating an array element arr[3] = 'New content'; Updating an array element immutably arr = arr.map((element, index) => { if (index === 3) return 'New content'; return element; }); It's possible, sure, but it feels terrible. JavaScript objects want to be mutated - it's the most idiomatic way of interacting with them. Whether functional programming paradigm is good (I certainly feel it is) is beside the point - JS wasn't designed for it. When I think of immutable primitives, I think of Python's tuples, which will raise a big fat error when you try to mutate them, or even better, Swift's structs, which gives you a new copy with every mutation.

franzwong 9y ago

Choose the tool which is suitable for you. When your web app grows to a certain scale, you will need "lots of code" to maintain state and prevent rendering.

skilesare 9y ago

I've tried to 'get' redux a couple of times and have reverted back to reflux each time because sanity is nice.

sotojuan 9y ago

Not the biggest JS fan but this is ill-informed and poorly written. Sounds about right for tech blog posts at least.

halayli 9y ago

It doesn't feel op have done their homework well. You should check immutable-js.

amelius 9y ago

Could somebody outline how I can write an efficient rich text editor using the state management techniques of React and Redux? (Not that I want to try this, but I'm interested in how that would work).

chii 9y ago
Tyr https://draftjs.org/ https://draftjs.org/

captainmuon 9y ago

The article has a point. We tend to fix issues with state by avoiding mutability. That is like going to a doctor because it hurts when you laugh, and they just say "don't laugh". I wish there was a language that embraced mutability instead [1]. Mutability is how the computer works at the lowest levels, and how we tend to think about the world. You would use plain old data objects to store everything. Then you would have first class observers, meaning you could have callbacks react to any changes to any object. But you wouldn't use that low-level functionality often. Instead you would e.g. create a listview, and just set it to observe the array. This is like "list adapters" that are in many frameworks, but built into the language. One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion (and occasionally sends mutating messages to the backend thread). You could implement that with read-write locks, but as far as I know no framework supports it directly. Maybe this language would have a special block that takes imperative, mutating code, and lifts it to implement the command pattern [2]. You then could "undo" these blocks, coalesce them, and so on. (That doesn't work with arbitrary code, but with most code that operates on business data.) (Here are some questions I asked on StackExchange, trying to find out if something like that already exists:) [1]: https://softwareengineering.stackexchange.com/questions/229876/language-that-embraces-mutable-state https://softwareengineering.stackexchange.com/questions/2298... [2]: https://softwareengineering.stackexchange.com/questions/351593/automatically-convert-mutations-in-imperative-code-into-functional-actions https://softwareengineering.stackexchange.com/questions/3515...

arcbyte 9y ago
Mutability is actually a kluge.
trgn 9y ago
`One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion` Dojo-stores, observable-collections essentially, were like that. A Dojo-view was a monitor for this. A very simple, elegant model-view design. I agree that we should embrace mutability. The JS-code most people write now has horrible performance characteristics since we do not take advantage of the benefits of mutating objects to manage state. Instead, in JS-world, we recreate and duplicate state all the time, spamming the heap. One library doing this is not too bad, but all libraries doing this is the main cause of slow web apps.

neya 9y ago

I'm one of the laggards - Over the years, based on staying around tech communities (esp. HN) I've learned not to invest time / effort into the hype that surrounds a newly launched tech. I did burn my finger a couple of times, especially with MongoDB back then, so these days I'm pretty cautious. I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework war, purely based on opinions. My opinion is pretty simple and resonates with a lot of people, apparently[1]: ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: [1] This alone makes React a joke for me, let alone the author's post. If it resonates with you, then good for you. I may not be from Facebook or Google to have the authority, but I do know what's good in the long run and what isn't. I couldn't be happier with Vue. [1] https://twitter.com/thomasfuchs/status/810885087214637057?lang=en https://twitter.com/thomasfuchs/status/810885087214637057?la...

TheCoreh 9y ago
I don't see how vue's take on this same issue is significantly or even marginally better: https://vuejs.org/v2/guide/conditional.html https://vuejs.org/v2/guide/conditional.html Instead of getting HTML fragments on your JS, you get JS fragments on your HTML? Whenever you need to programatically generate markup with conditionals and iteration over existing data structures, you end up having to mix a programming language with your markup. (The other option is of course to create an entire programming syntax on top of your markup language.) BTW, I haven't actually used vue, so this post is by no means me saying that it doesn't have its merits or it's not a good framework.
- rhinoceraptor 9y ago
  Having used Angular 1 quite a bit, I think the whole DSL for HTML business is not the way to go. But at least Vue had the good sense to compile them rather than evaluate them at runtime like Angular.
coldtea 9y ago
>~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar. Such separation of HTML/JS/CSS was misconceived. It makes sense for web documents and simple forms, but not for web apps with rich widgets etc (which is what we're trying to do). Tons of problems stemmed from cargo cult adherence to that. Everybody else, including those that add JS instructions (or ad-hoc "templating language" instructions inside HTML tags) are getting it wrong.

thenewvu 9y ago

React does its job fine. I think the good part of the post is pointing out the verbosity of Redux and you don't accept it. According to me, it totally depends on your implementation, Redux is just a concept of data flow, you made your choice when using react-redux. By time and eventually, you will figure out how to minimize the boilerplate, because you didn't accept it.

coldtea 9y ago

Judging from the title I expected one of the usual BS posts like "OMG, React mixes code and html!!!" etc and was ready to post a "No, you just don't get it" comment. But this actually makes several good points on accidental complexity imposed by React/Redux. I know why they impose it, but there must (should) be a better way.

bichiliad 9y ago

There's a lot of comments in here addressing some of the conceptual misunderstandings of "how to use react" (i.e. "use immutable.js", etc). I started writing React within the last year and, while I still find parts of it strange, I've found its real strength comes from the fact that it's easy to reason about, particularly at scale. In a large project, I don't find myself digging around the codebase looking for the place where event listeners are being bound, or where a piece of the DOM is getting mutated. The unidirectional flow of data makes it very easy to jump into a piece of an app. It's not without its complexities, however. Mainly: 1. using JSX, instead of a more transparent templating language, means people with less technical knowledge (i.e. product designers) have a higher barrier to entry when trying to make simple UI changes (I'm looking at you, `className`). 2. it is unclear at times whether a component should have its properties passed in directly from state through `mapStateToProps`, or from a parent component through `props`. 3. there does seem to be an tiring amount of boilerplate when adding a new piece of interaction to a component (an action, an action type, a reducer case, and usually a piece of state all need to be added). 4. to a newcomer, the benefits of immutable.js are apparent, but the benefits of a memoizing layer like reselect.js were less obvious. When you're still trying to wrap your head around How To Write React Things™, it's not apparent that you'd even need memoization ("isn't React supposed to be good at diffing stuff?" you ask yourself after watching large pieces of your app redraw itself over and over). I'm curious to hear how people deal with these particular issues. React was one of the more useful tools I learned about this year, and I'd love to see the process for newcomers to React become less frustrating. Edit: formatting

tboyd47 9y ago

This guy expresses a lot of opinions about React/Redux that I share, but he doesn't understand something fundamental about web development. The look and feel of the page comes first, and the structure and coherence of the code comes second. And you don't really need complicated, fast UI for most web projects.

coding123 9y ago
Yes, but I sense that he's in a similar boat as me right now. I just joined this team that's already using React/Redux, and the code quality is... very sad.
- tboyd47 9y ago
  Code quality was the main issue driving a lot of folks to React. Like lambs to the slaughter...

anilgulecha 9y ago

I get his point -- javascript object observation has been a pain, and causes the stated workaround.s With new API like Proxy [1], we should not be able to just modify data as needed, and any observers can be notified by handlers in the object get/set. This will lead to data being fully mutable. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

styfle 9y ago
The Proxy API is how dot-dom[0] implements a React-like component API [0]: https://github.com/wavesoft/dot-dom https://github.com/wavesoft/dot-dom

obfk 9y ago

WHY would you even considering composing your own diffing structure for updating a components state when that's entirely against the paradigm React proposes. Pass props from the parents and let the tool do the heavy lifting. State is an abused and misunderstood interface in React.

websitescenes 9y ago

Honestly, I don't recommend using React unless you're building realtime web applications. Otherwise, you're correct, React is too heavy. If you're not doing realtime, the idea of state is completely unnecessary. But if you are doing realtime web apps the idea of state and hoops that React make you jump through make sense. Is it hard? Yep. Is it worth it. Yep. Will there eventually be a better way? Yep. With that said I think some of the pain points you identified could be simplified. State is needed but immutability could be made easier.

keymone 9y ago

yep, let's all just get back to mutating everything everywhere and generating dom elements in arbitrary places. because it has worked so well for us in past 12 years. i get a feeling author had no prior experience with js ui whatsoever.

agentultra 9y ago

> This is probably an ill thought through rant but... Everything after the "but" and all. The whole point of Redux is to separate actions and state manipulation. An argument that, "well I want to manipulate variables feely," is not an argument. Just don't use Redux. End of story. The pattern doesn't come from React. There are many patterns in React that are just Monads by a different name. Redux isn't much different.

Nekorosu 9y ago

Somehow author jumps from the problem of convenient data structures updating and immutability to Redux which solves a different problem. There are several things about React, Redux and React based tech stacks: 1. React requires knowledge of basics of functional programming React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. Without this knowledge, a lot of things will be a struggle and won't make any sense. You'll mess up pretty bad. React requires the understanding of its principles which require the understanding of FP essentials. 2. React is not a framework and does only one thing well It does only one thing well, turning your UI into a function of data. Yes, there is a virtual DOM but it's an implementation detail and not the purpose of React. If you think about it everything which is there is needed to make that UI=F(data) possible. However, it's enough for simple apps. Immutability isn't always needed so it's optional. It's not built into JS, you'll have to use an additional library. 3. Building non-trivial apps requires a lot of knowledge and experience Building non-trivial apps with React only is a pain. That's expected because the only thing it does is making a UI a function of data. It's not a framework with a complete set of tools and practices for building a whole SPA. That means you have to assemble your own tech stack for your particular task. This requires a lot of experience but lets you have the tools which are a better fit for your app. Redux is just one of the available choices for solving the problem of complex app's architecture. It isolates state from React components. UI interaction with the outer world is behind actions. Data access is behind selectors. State mutations are centralized in reducers. This is very convenient, you always know where to look for something. Business logic part is very clear because of actions and reducers. Not messing everything up requires knowledge and discipline though. The funny thing is React+Redux isn't a complete framework. For case, there are several solutions for writing asynchronous actions. The main idea is React is ok to use by itself for simple things. You don't need to know much except FP essentials. Using more advanced React based tech stacks requires much more knowledge and experience. If you don't know which of your problems React solves you don't need it. If you don't know which of your problems immutability solves you don't need it. If you don't know which of your problems Redux solves you don't need it.

coding123 9y ago
I completely agree here. and I think if most people followed these last 3 lines, there might be what, 6 projects using React? I find the highlighted article on Facebook's "reason" for inventing Flux/Redux very laughable. - This message unread indicator kept saying (1). And how it went away with bug fixes and came back... Did they ever stop to realize they just had some really bad devs working on the chat app? Any re-write, whether they had to invent flux or not would have fixed that indicator. It's a false story.

williamle8300 9y ago

Seems like the source of his gripes are with functional programming, not ReactJS itself.

Harkins 9y ago

This example doesn’t fit with the React style I’ve seen before, where state is rarely used. This data isn’t flowing (https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_end#c_1z3hjq https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_en...) like I’ve come to expect, but one of my biggest gripes with React is that the docs are no longer very good because they haven’t been comprehensively rewritten for the current design and because the only sentence in the docs to address the crucial distinction between props and state is the distinctly unhelpful: > If you imagine a component tree as a waterfall of props, each component’s state is like an additional water source that joins it at an arbitrary point but also flows down. In this post’s example, I would expect to see a component for an individual Person with the props name and location, then a People component storing the ordered list in props. If the app does a lot of this general “maintain a sorted list with random insertions from over the net”, People would be wrapped by a higher-order component (https://facebook.github.io/react/docs/higher-order-components.html https://facebook.github.io/react/docs/higher-order-component...) managing that. Otherwise there’d probably be a page-level custom component or just random stateful javascript pulling in the data and passing it down to People for rerendering. (I don’t know Redux to address the second half of his example.) It’s ironic that the author advocates for immediate mode GUIs, because normal React looks and works like an immediate mode GUI with memoization. A component is a function responsible for part of the page. Its props are the input to the function and it returns a render of part of the page (possibly by rendering more memoized components). The cache is busted when props changes. There’s also a hack to be used sparingly called state so that small bits of UI state can be managed at a low-level instead of in their parent component.

shafyy 9y ago

I agree that there is some amount of boiler plate code to Redux that doesn't seem to make sense and takes a long time to do when you're new. But I think it really helps with maintenance and scalability of projects down the road and saves you time later on. Of course, as others have said, React and Redux is not a panacea - depending on what you want to achieve and on your personal preferences there might be better tools.

hex13 9y ago
> I think it really helps with maintenance and scalability of > projects down the road and saves you time later on. It's popular argument but I don't think it's completely correct. On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability. Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none). I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.
- shafyy 9y ago
  I see your points and don't disagree. However, Redux is a fairly young concept and I think it has some potential to grow (as is React).

luord 9y ago

After reading so much about it and trying it several times, I think my problem with react (alongside the licensing issue anyway) is that it feels like the perfect example of the fundamental theorem of SE: Everything is full of indirections and, when that isn't enough, then more abstractions in the form of tangentially related libraries (such as immutablejs in this thread) are recommended. I'm sticking with Vue, it's not perfect but it was at least designed to play with js's strengths instead of abstracting them to shoehorn functional principles.