JavaScript and Decision Fatigue

JavaScript suffers and imposes Decision Fatigue on developers. I am enjoying working with React and Express, but the search for better tools and techniques is exhausting!

JavaScript [under the Node.js ("Node") ecosystem] has a reasonably well-known limitation: it is prone to cause decision fatigue.

Over the past month or so of free-form investigation, I have juggled the following technologies or tools:

• Typescript
• TDD Jest (Chai/Mocha were considered, but I think Enzyme may better-suit my needs, and Enzyme seems to best-pair with Jest)
• Multiple CI build/configuration/manipulation scripts
• Different code coverage tools (e.g. CodeClimate, inferno-scripts test --env=jsdom --coverage)
• MobX (I tend to use Redux, but I'm exploring MobX with Inferno in building a ResumeBuilder)
• GatsbyJS with accompanying tools Apollo and GraphQL
• Various Functional Programming techniques--I know the theory behind these (thanks, misspent academic youth!), but something like Elm still makes me worry about how I'll run this through Babel to polyfill and present to Webpack
• Performance optimization--how do I definitively prove, aside from either running timing-scripts in the CLI or looking at Chrome's debugging console, that the apps I write are production-ready?

This list, while exhausting, is not exhaustive. I have worked through many technical stacks in my time, and I really like the Node-based stack It has good infrastructure, reasonable-seeming performance (text-file parsing aside--Python beats the daylights out of JavaScript for this), easy deployment out to Heroku and friends, and an active community. Unfortunately, there is something of a paradox of choice here, and this leads to decision-fatigue.

As an example, let's look at a front-end app that runs in the browser and delivers some sort of web content. You want to build this in JavaScript. What are your viable options under Node?

• React
• Preact (React with SSR)
• Inferno (React with SSR options and lack of synthetic event handling)
• Angular
• Others (Ember, Meteor, Vue, NextJS...)

There are lots of options here!

Each of these carries decisions in their own right:

• Testing
• Typescript or Flow for typing--or nothing?
• Linting (ESLint) and/or Polyfill (Babel)
• JS callbacks, Promises, or async/await asynchronous call resolution (or yield, I haven't worked with yield in JavaScript yet)

At least the back-end/server-side of this environment is simpler; we really have two solid choices:

• Express
• Koa

But these two choices themselves carry much of the above decisions ("How do I test this?" "Do I write strongly-typed code that will compile to JavaScript, or do I just write raw JavaScript and be careful about typing?" "Do I want to enable ES2015 syntax?" [Express only; Koa builds this in])

While I tend to work primarily in React [or "React-inspired"] and Express for front- and back-end work, as a long-time developer who is also fairly new to digging into the JavaScript full-stack infrastructure and associated tools, I am always left with a nagging thought: is what I'm building the best way to go? Am I going to get caught out on performance when I go to scale this? These are questions that people new to development as a whole won't even know to ask, and I wonder how frequently this catches up with us, and how much of this is due to having entirely too many options.