larlet-fr-david-cache/cache/f41d0be1b419e16d37b415958dab7339/index.md.orig

title: Javascript Fatigue
url: https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4
hash_url: f41d0be1b419e16d37b415958dab7339

<div class="section-inner layoutSingleColumn"><p name="d098" id="d098" class="graf--p graf--first">For starters, consider that <a href="https://medium.com/u/3b799f227b58" data-href="https://medium.com/u/3b799f227b58" data-anchor-type="2" data-user-id="3b799f227b58" data-action="show-user-card" data-action-type="hover" class="markup--user markup--p-user">Pete Hunt</a> asked why React is overwhelming for beginners:</p><figure name="9845" id="9845" class="graf--figure graf--iframe graf-after--p"><p class="iframeContainer"/></figure><p name="65dc" id="65dc" class="graf--p graf-after--figure">If you use React, you probably share the same experiences with <a href="https://medium.com/u/46fa99d9bca4" data-href="https://medium.com/u/46fa99d9bca4" data-anchor-type="2" data-user-id="46fa99d9bca4" data-action="show-user-card" data-action-type="hover" class="markup--user markup--p-user">Vjeux</a>:</p><figure name="6014" id="6014" class="graf--figure graf--iframe graf-after--p"><p class="iframeContainer"/></figure><blockquote name="9f35" id="9f35" class="graf--pullquote pullquote graf-after--figure">There is a major problem in the React community that cripples beginners and hinders experts alike.</blockquote><h4 name="9c77" id="9c77" class="graf--h4 graf-after--pullquote">Too Many Tools.</h4><p name="5670" id="5670" class="graf--p graf-after--h4">At work this past quarter, we <strong class="markup--strong markup--p-strong">painstakingly</strong> started three new projects at work. I say “painstakingly” because <em class="markup--em markup--p-em">every</em> project required decisions to be made around tooling depending on the scope &amp; needs.</p><p name="31c8" id="31c8" class="graf--p graf-after--p">Ultimately, the problem is that <strong class="markup--strong markup--p-strong">by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, &amp; time-sinks to deal with before you ever get to <em class="markup--em markup--p-em">create</em> anything.</strong></p><h4 name="014f" id="014f" class="graf--h4 graf-after--p">Boilerplates &amp; Generators Are Not The Answer.</h4><figure name="41cb" id="41cb" class="graf--figure graf--layoutOutsetLeft graf-after--h4"/><p name="d1c5" id="d1c5" class="graf--p graf-after--figure"><a href="http://yeoman.io/" data-href="http://yeoman.io/" class="markup--anchor markup--p-anchor" rel="nofollow">Yeoman</a> &amp; <a href="https://github.com/amwmedia/plop" data-href="https://github.com/amwmedia/plop" class="markup--anchor markup--p-anchor" rel="nofollow">Plop</a> can alleviate the amount of copy &amp; pasting you do between projects.</p><p name="6d10" id="6d10" class="graf--p graf-after--p">However, generated is <em class="markup--em markup--p-em">never </em>a one-to-one match, nor can it be.</p><p name="c1c1" id="c1c1" class="graf--p graf-after--p">At scale with enough projects, it is exceedingly difficult to back-port features &amp; improvements from one application to the rest, since <strong class="markup--strong markup--p-strong">the common code is not abstracted into an independently updatable dependency.</strong></p><blockquote name="5982" id="5982" class="graf--pullquote pullquote graf-after--p">When a generator is good solution for repetitious code, a better solution is to abstract it into a simpler API.</blockquote><p name="606d" id="606d" class="graf--p graf-after--pullquote">Otherwise, the generator becomes a confusing, logic-riddled application itself due to permutations of possible use-cases, forever in a race to stay relevant with the applications it created.</p><p name="45e5" id="45e5" class="graf--p graf-after--p">I’ve experienced this first-hand with several generators, including my own <a href="https://github.com/evolution/wordpress" data-href="https://github.com/evolution/wordpress" class="markup--anchor markup--p-anchor" rel="nofollow">evolution/wordpress</a>.</p><h4 name="90df" id="90df" class="graf--h4 graf-after--p">Too Many APIs. Too Much Configuration.</h4><figure name="e2e3" id="e2e3" class="graf--figure graf--layoutOutsetLeft graf-after--h4"/><p name="bae2" id="bae2" class="graf--p graf-after--figure">An example of this can be seen in <a href="https://medium.com/u/d7225e72eea" data-href="https://medium.com/u/d7225e72eea" data-anchor-type="2" data-user-id="d7225e72eea" data-action="show-user-card" data-action-type="hover" class="markup--user markup--p-user">Mark Dalgleish</a>’s excellent <a href="https://github.com/markdalgleish/react-fetcher#example-usage-with-react-router-and-redux" data-href="https://github.com/markdalgleish/react-fetcher#example-usage-with-react-router-and-redux" class="markup--anchor markup--p-anchor" rel="nofollow">react-fetcher</a>, libraries such as <a href="https://github.com/rackt/redux" data-href="https://github.com/rackt/redux" class="markup--anchor markup--p-anchor" rel="nofollow">Redux</a>, <a href="https://github.com/rackt/react-router" data-href="https://github.com/rackt/react-router" class="markup--anchor markup--p-anchor" rel="nofollow">React Router</a>, <a href="http://webpack.github.io/" data-href="http://webpack.github.io/" class="markup--anchor markup--p-anchor" rel="nofollow">Webpack</a>, and the React ecosystem have, largely, opted for discrete modularization at the cost of terse APIs by <strong class="markup--strong markup--p-strong">offloading their architectural underpinnings to the user and, as a result, worsen the developer experience in aggregate.</strong></p><p name="5adc" id="5adc" class="graf--p graf-after--p">Alone, the APIs are small, but even less than a handful yield a nearly incomprehensible mess of code to each new set of eyes.</p><p name="d96f" id="d96f" class="graf--p graf-after--p">Even if contained in a “boilerplate” project, scaffolded by a generator, or tucked away in a <em class="markup--em markup--p-em">finalCreateStorev3SeriousThisTime.js</em> file, we’ve created a rat’s nest of wiring that would make WordPress plugins blush.</p><h4 name="4b8b" id="4b8b" class="graf--h4 graf-after--p">More Abstractions. Less Code.</h4><p name="2d9a" id="2d9a" class="graf--p graf-after--h4">Of course, these APIs are a requirement for having smaller, decoupled, testable, and therefore, <em class="markup--em markup--p-em">high-quality</em> libraries.</p><p name="2058" id="2058" class="graf--p graf-after--p">However, we <strong class="markup--strong markup--p-strong">need an abstract middle-ground between wiring dependencies and generating boilerplates<em class="markup--em markup--p-em">.</em></strong></p><blockquote name="62fd" id="62fd" class="graf--pullquote pullquote graf-after--p">Abstractions are necessary to reduce the cognitive load of how things work so you can focus on creating.</blockquote><h4 name="bf89" id="bf89" class="graf--h4 graf-after--pullquote">Fight Against Lines of Code.</h4><p name="a5c4" id="a5c4" class="graf--p graf-after--h4">Any significantly-scoped project will already have a substantial amount of code behind it.</p><blockquote name="10fc" id="10fc" class="graf--pullquote pullquote graf-after--p">Application developers should not have to become experts in the underpinnings of the library just to use it.</blockquote><p name="781a" id="781a" class="graf--p graf-after--pullquote">Therefore, instrumenting tooling should aim to be <em class="markup--em markup--p-em">as minimal as possible</em>.</p><p name="2ae1" id="2ae1" class="graf--p graf-after--p">Consider this <strong class="markup--strong markup--p-strong">hastily-compiled list of alternatives</strong>:</p><ul class="postList"><li name="bcbc" id="bcbc" class="graf--li graf-after--p">Provide an opinionated, <em class="markup--em markup--li-em">author-endorsed</em> wrapper API or library for the theoretical 90% of use-cases.<br/><em class="markup--em markup--li-em">(Cutting the boilerplate for React + Router + Redux alone would be a </em><strong class="markup--strong markup--li-strong"><em class="markup--em markup--li-em">huge</em></strong><em class="markup--em markup--li-em"> improvement for many.)</em></li><li name="cec8" id="cec8" class="graf--li graf-after--li">Publish use-case <em class="markup--em markup--li-em">presets</em> akin to Babel’s (e.g. <a href="https://www.npmjs.com/package/babel-preset-es2015" data-href="https://www.npmjs.com/package/babel-preset-es2015" class="markup--anchor markup--li-anchor" rel="nofollow"><em class="markup--em markup--li-em">es2015</em></a>,<em class="markup--em markup--li-em"> </em><a href="https://www.npmjs.com/package/babel-preset-react" data-href="https://www.npmjs.com/package/babel-preset-react" class="markup--anchor markup--li-anchor" rel="nofollow"><em class="markup--em markup--li-em">react</em></a>, etc.) presets.</li><li name="33b7" id="33b7" class="graf--li graf-after--li">Leverage folder &amp; file-naming conventions for automatically discovering application-specific routes, actions, tests, and more.<br/><em class="markup--em markup--li-em">(This is already common-place for testing (e.g. </em><a href="http://mochajs.org/" data-href="http://mochajs.org/" class="markup--anchor markup--li-anchor" rel="nofollow"><em class="markup--em markup--li-em">Mocha</em></a><em class="markup--em markup--li-em">) &amp; serving public assets, but somehow every project magically requires a unicorn-configuration.)</em></li><li name="d7d1" id="d7d1" class="graf--li graf-after--li">Community-driven Rapid Application Development (RAD) tooling to significantly delay the need for explicit configuration until scope is solidified.</li></ul><p name="7198" id="7198" class="graf--p graf-after--li">Until a large part of the ecosystem adopts terse APIs, conventions, and strives for significantly reducing implementation details for end-users, abstract tooling may be our only outlet.</p><h4 name="f07e" id="f07e" class="graf--h4 graf-after--p">RAD Tooling</h4><p name="8b76" id="8b76" class="graf--p graf-after--h4">Following the Twitter threads above, many rightfully concede that there is no one-size-fits-all solution.</p><blockquote name="cd93" id="cd93" class="graf--pullquote pullquote graf-after--p">However, if we start with the intent to just build a prototype, the underlying abstractions don’t matter.</blockquote><p name="ea3b" id="ea3b" class="graf--p graf-after--pullquote">Related, <a href="https://medium.com/u/46fa99d9bca4" data-href="https://medium.com/u/46fa99d9bca4" data-anchor-type="2" data-user-id="46fa99d9bca4" data-action="show-user-card" data-action-type="hover" class="markup--user markup--p-user">Vjeux</a> <a href="http://blog.vjeux.com/2015/javascript/challenge-best-javascript-setup-for-quick-prototyping.html" data-href="http://blog.vjeux.com/2015/javascript/challenge-best-javascript-setup-for-quick-prototyping.html" class="markup--anchor markup--p-anchor" rel="nofollow">challenged the community to devise tooling for quick prototyping</a>, even at the cost of customization.</p><p name="c8b0" id="c8b0" class="graf--p graf-after--p">In the meantime, I’m aware of a few options you can use <strong class="markup--strong markup--p-strong">today</strong> to jumpstart your next project:</p></div>