Javascript Fatigue
Today Dan Abramov (original author of redux) wrote a react blog post about a new no-config app starter for react. This couldn’t have come at a better time because a few months ago I started a project in react but became really frustrated that I had to learn all these tools and their APIs when I don’t do it for a day job and it seemed like a big waste of time vs actually building something interesting to me.
He referred to this article about javascript fatigue and I thought “well glad I’m not the only one who feels that the tooling ecosystem is out of hand here.”
This makes me think back to when Rails was having its day; it lumped in a bunch of things it felt were useful for everyone; it was opinionated. That meant ActiveRecord, Webrick, ERB, etc, but you could switch them out for things as your application grew and you realized different requirements.
The react ecosystem approach has been “well only include the things you need” – but sometimes you don’t know what you need and there are 5 competing things that all differ in slight ways that might not actually matter for you but you feel compelled to read their docs and look at their code anyway, and then you have to make a decision which Dan Abramov sums up so nicely:
If your UX asks the user to make choices, for example, even if those choices are both clear and useful, the act of deciding is a cognitive drain. And not just while they’re deciding… even after we choose, an unconscious cognitive background thread is slowly consuming/leaking resources, “Was that the right choice?”
Having to decide between different flux implementations is exhausting. Having to decide between webpack vs (?), requirejs vs (?), babel vs (?), etc etc makes you just want to use Angular and its ecosystem because it’s all-in-one. But then it’s too all-in-one, and you wish you could eject…
Anyway that’s why I’m excited about this new thing, and fwiw I ended up building my first prototype in VanillaJS, smh.