4 ms·

Why Redux Makes You a Better JavaScript Developer

12 points by rwieruch 7y ago

WorldMaker 7y ago
Guess these ideas are sort of in the air this week. I just blogged last night some thoughts about my use of Redux (and redux-observable) in a Discord bot (no React in sight) I worked on a few months back.
kls 7y ago
While I agree with a lot of the summary of the article, I personally would not call Redux event driven. Events have a fairly familiar context (that is evoked in peoples minds, who are familiar with them) and that is closer to a pub sub of loose events. where a signature is published and possibly data is published, and then subscribes are added vi a reference to a function. I would call Redux and Action based function where an Action is passed into a function and then a switch statement decides what to do with said action. It is a small nuance but there is a difference, I personally prefer event based systems as they tend to produce less boilerplate, but in the grand scheme of things Redux is a great library so it is not that much of an issue to use their Action based semantics as it accomplishes they same end result.
valand 7y ago
Being OOT and throwing in unpopular opinion: Redux fails in recreating the success of elm architecture. Without the static typing of elm, it ends up being painful to use. Redux drives inexperienced developers to put everything into the store, making it a god-object. See: https://news.ycombinator.com/item?id=14669980 https://news.ycombinator.com/item?id=14669980 Redux middlewares allow changing return type, which makes it hard to implement static typing to it. Redux without middlewares needs additional code to work with static typing. See: https://github.com/piotrwitek/typesafe-actions https://github.com/piotrwitek/typesafe-actions Redux expose actions and reducers to developer, which is a state management mechanism that usually are written the same over and over again. I sound harsh on it, but I want devs around the world to not go through the pain of using Redux on large scale project involving a lot of people. Redux is good for education. It introduce the concept of immutability, higher order function. I learn a lot from it. Nevertheless, it is a pain to use on big projects. React's setState is friendlier to devs. Unstated https://github.com/jamiebuilds/unstated https://github.com/jamiebuilds/unstated (but not unstated-next), is a detached version of React's setState with additional `.subscribe` method and Promise as return. It is very good in both developing and communicating business flow. UnstatedContainer method can be treated as counterpart of Redux's action. What is missing now from the client-side web development is an in-app event library. Usually people would put domain-objects to Redux to solve the inter-component communication. This is, against the functional programming (which promotes immutability, higher order functions), introducing the possibility side-effect. In-app event library should replace this behavior so that messages can be passed through events from one component to another that resides on different component-tree, which may want to act differently. This is some sort of implementing mini kafka/rabbit-mq-like behavior inside the your web app with minimum resource required.
- kls 7y ago
  First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. Me personally I don't see it, I have worked on some pretty big JavaScript and LISP codebases and I cannot recall a single instance where static types would have helped us. But can think of a thousand cases where we could not have produce compact, simple and elegant code for solutions to complex problems. I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. Anything beyond that is a religious war as both can be used to build large applications if people know the tool they are working with. I don't disagree with some of your other points, the way Redux is implemented is not the way I would have done it, that being said it is effective, you can build large apps with it and personally it saves me from having to maintain that concern in custom code. As I said in my other comment I prefer an event driven architecture, it is the way Eich originally designed JavaScript and the browser API and it works.
  - valand 7y ago
    > First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. I cannot convince with words, only experience can change one's perspective. Thanks for the reminder. I admit my opinion may spark religious skirmish. I came to love javascript in 2014 when I was making an HTML5 game almost alone. Coming from beginner java and c++, JS' flexibility blew my mind. 4 years later, I came to dislike JS for big projects. Fast-paced gaming industry drives project managers to rotate new developers in and out, leading to low knowledge retention, thus bad code quality. The project was then handed to my team. Iterating was painful. Regression was everytime. Manpower need rose up fast to add feature and tests. Long story short, led a total rewrite. Initially most people objected, now most are satisfied. For me, what's missing from JS is type system. In static-typed languages, types, used correctly, often act as contracts which bind function params and return type. It helped with knowledge retention. Most frontend devs of the company now agrees that Typescript + network and storage contract hardening saved our asses. Some argue that unit tests and documenting with comment helps, they don't. Unit tests allows us to warn future bad code change, while comments are not compiled and often not read, so I limit comments usage to the most complex code only. > I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. True, but it's sometimes the circumstances rather than the developers. I still love to write simple build scripts with JS and bash, but not big projects with people coming in and out. Unfortunately, and fortunately, the priority in my work is now both growing product and people, and that's why it's important for new developers to understand the product knowledge by the code, type helps.

12 points by rwieruch 7y ago

Guess these ideas are sort of in the air this week. I just blogged last night some thoughts about my use of Redux (and redux-observable) in a Discord bot (no React in sight) I worked on a few months back.

kls 7y ago

While I agree with a lot of the summary of the article, I personally would not call Redux event driven. Events have a fairly familiar context (that is evoked in peoples minds, who are familiar with them) and that is closer to a pub sub of loose events. where a signature is published and possibly data is published, and then subscribes are added vi a reference to a function. I would call Redux and Action based function where an Action is passed into a function and then a switch statement decides what to do with said action. It is a small nuance but there is a difference, I personally prefer event based systems as they tend to produce less boilerplate, but in the grand scheme of things Redux is a great library so it is not that much of an issue to use their Action based semantics as it accomplishes they same end result.

valand 7y ago

Being OOT and throwing in unpopular opinion: Redux fails in recreating the success of elm architecture. Without the static typing of elm, it ends up being painful to use. Redux drives inexperienced developers to put everything into the store, making it a god-object. See: https://news.ycombinator.com/item?id=14669980 https://news.ycombinator.com/item?id=14669980 Redux middlewares allow changing return type, which makes it hard to implement static typing to it. Redux without middlewares needs additional code to work with static typing. See: https://github.com/piotrwitek/typesafe-actions https://github.com/piotrwitek/typesafe-actions Redux expose actions and reducers to developer, which is a state management mechanism that usually are written the same over and over again. I sound harsh on it, but I want devs around the world to not go through the pain of using Redux on large scale project involving a lot of people. Redux is good for education. It introduce the concept of immutability, higher order function. I learn a lot from it. Nevertheless, it is a pain to use on big projects. React's setState is friendlier to devs. Unstated https://github.com/jamiebuilds/unstated https://github.com/jamiebuilds/unstated (but not unstated-next), is a detached version of React's setState with additional `.subscribe` method and Promise as return. It is very good in both developing and communicating business flow. UnstatedContainer method can be treated as counterpart of Redux's action. What is missing now from the client-side web development is an in-app event library. Usually people would put domain-objects to Redux to solve the inter-component communication. This is, against the functional programming (which promotes immutability, higher order functions), introducing the possibility side-effect. In-app event library should replace this behavior so that messages can be passed through events from one component to another that resides on different component-tree, which may want to act differently. This is some sort of implementing mini kafka/rabbit-mq-like behavior inside the your web app with minimum resource required.

kls 7y ago
First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. Me personally I don't see it, I have worked on some pretty big JavaScript and LISP codebases and I cannot recall a single instance where static types would have helped us. But can think of a thousand cases where we could not have produce compact, simple and elegant code for solutions to complex problems. I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. Anything beyond that is a religious war as both can be used to build large applications if people know the tool they are working with. I don't disagree with some of your other points, the way Redux is implemented is not the way I would have done it, that being said it is effective, you can build large apps with it and personally it saves me from having to maintain that concern in custom code. As I said in my other comment I prefer an event driven architecture, it is the way Eich originally designed JavaScript and the browser API and it works.
- valand 7y ago
  > First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. I cannot convince with words, only experience can change one's perspective. Thanks for the reminder. I admit my opinion may spark religious skirmish. I came to love javascript in 2014 when I was making an HTML5 game almost alone. Coming from beginner java and c++, JS' flexibility blew my mind. 4 years later, I came to dislike JS for big projects. Fast-paced gaming industry drives project managers to rotate new developers in and out, leading to low knowledge retention, thus bad code quality. The project was then handed to my team. Iterating was painful. Regression was everytime. Manpower need rose up fast to add feature and tests. Long story short, led a total rewrite. Initially most people objected, now most are satisfied. For me, what's missing from JS is type system. In static-typed languages, types, used correctly, often act as contracts which bind function params and return type. It helped with knowledge retention. Most frontend devs of the company now agrees that Typescript + network and storage contract hardening saved our asses. Some argue that unit tests and documenting with comment helps, they don't. Unit tests allows us to warn future bad code change, while comments are not compiled and often not read, so I limit comments usage to the most complex code only. > I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. True, but it's sometimes the circumstances rather than the developers. I still love to write simple build scripts with JS and bash, but not big projects with people coming in and out. Unfortunately, and fortunately, the priority in my work is now both growing product and people, and that's why it's important for new developers to understand the product knowledge by the code, type helps.