
Why Redux Makes You a Better JavaScript Developer - rwieruch
https://www.robinwieruch.de/redux-javascript
======
kls
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
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
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
> 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.

~~~
kls
I see your perspective, I started in small teams doing flight simulator
development splitting my time between C and Assembly for 3D and Lisp for AI. I
don't disagree that static typing can band-aid over bad process and churn, but
it is but good process can eliminate the need for it and empower a good team
of knowledgeable developers the ability to outperform a larger team.

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.

~~~
valand
> 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.

------
WorldMaker
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.

