Why Redux Makes You a Better JavaScript Developer
robinwieruch.de
robinwieruch.de
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.
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
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
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 (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.
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.
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.
I wholeheartedly agree, about unit tests and comments, I have come to find unit test to be a cargo cult, and that they may actually cost more cycles than they save in the way most orgs implement them.
And comments while great are not code, they don't thrown stack traces when they are out of date.
I am very good at team building and maintaining developers in my organizations for a long period of time. This helps in our preference for using dynamic and flexible languages like LISP and Javascript.
That is very nice. Hope I can learn a lot from people like you.