Front-End Developer Handbook 2017
I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies over the past six years has not involved front-end.  I only recently got back into the scene.  I&#x27;ve dabbled with React and crew in quite a few hobby projects now and, at this point, I just find the whole modern front-end development stack completely wacky.<p>I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits.  Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed.  ES20XX, Babel, webpack, npm.  Wow!<p>To be honest, a lot of the modern stack _is_ nice.  But for every step forward these tools take, they take two steps back.<p>We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`?  Nothing.  Oh sure, it installs it, but how do I _use_ it?  It&#x27;s tossed in node_modules, where there&#x27;s no sane way to reference it.  I ran into this problem immediately, on my very first hobby project.  It&#x27;s now two years later, 2017, and it&#x27;s still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful.<p>Breaking up libraries into manageable sub-packages.  Sounds great.  It&#x27;s fundamental to strong development.  But usually you have a master application&#x2F;library that references all the pieces, if the pieces were meant to be part of a coherent whole.  But front-end devs?  <i>shrugs</i> You just have to include everything by hand.  Has seriously no one looked at their package.json in a simple TODO app and said &quot;Something is wrong here&quot;?  How is a 20-30 line list of dependencies normal for the most basic of applications?  It isn&#x27;t.  It&#x27;s isn&#x27;t maintainable.  No one is going to remember all the packages they need to include each time they start a new project.  They&#x27;re doing what I&#x27;m doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.<p>Fancy new JS language features are nice.  `for of`, `for in`, filter, map, etc.  But seriously I can&#x27;t use `&lt;SomeThing onClick={this.handleClick}&#x2F;&gt;`?  I have to use binding magic, special function definitions, etc?  Because _nobody_ has to register event handlers, right?  Geez.  And why did they spec a standard for classes, finally, but not static methods and types!?  That had to come in another version later, leaving yet another legacy of out-dated documentation?<p>Webpack, like everything else, is an improvement by the numbers.  Writing modular javascript and getting it packed into a bundle is nice.  Almost like a real programming language!  But why do I have to write a cryptic webpack.config.js for every project?  Why do I have to install Babel and webpack separately?  Why do I need to install 3 other babel related packages?  Why do I need a .babelrc?  It&#x27;s just insane.  There should just be one tool, one command.  &quot;modernjs build&quot;.  Done.  Break that one tool into sub-libraries&#x2F;sub-tools underneath, I don&#x27;t care, but when I&#x27;m building fancy Uber-for-breastmilk Web 2.0 SPA, I&#x27;d rather focus on UX than spending my evening configuring compilers to what should be their defaults.<p>The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack.  &quot;Oh, ummm ... how do I export&#x2F;import?&quot;  &quot;How did I configure webpack last time?&quot;  &quot;Errr ... how do you include a bootstrap theme?&quot;  &quot;Was it `in` or `of` to iterate over values...?&quot;  &quot;How do you filter in place?  Oh, you can&#x27;t ... okay...&quot;  A lot of that sounds like basic stuff, like &quot;How do I export&#x2F;import&quot;, but ya know what?  The way it&#x27;s implemented in modern JS is just not intuitive.  Call me dumb if you want, but I&#x27;ve dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing.  And really, that&#x27;s how everything is.  It&#x27;s just cryptic and non-intuitive.  The underlying concepts of any of these major tools or systems is sound.  The implementations are gibberish.<p>As much as I&#x27;d like to say &quot;sorry for the rant&quot;, I&#x27;m not.  Something is horribly wrong with developer culture if this abomination is what we&#x27;ve created.  There&#x27;s no excuse for it.  I&#x27;ve heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years.  But you know what?  Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years.  It was driven by Mozilla, hardly the largest company.  Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the &quot;modern front-end&quot;.  There&#x27;s no excuse for the ecosystem to be in this state.<p>&quot;But you don&#x27;t have to use all those libraries and tools!&quot;  Of course not.  I could just LAMP+HTML+JS+CSS it up like the good ole days.  It worked then, it works now.  But it frustrates me that there exists tools that _should_ be better.  npm _should_ make life easier.  ES2017 _should_ make Javascript a better language.  I tried out these tools for a reason.  Old school development was painful.  Javascript with modules and packages, reactive UI, state management, etc.  It&#x27;s all awesome!  I&#x27;m not messing about with the tools for no reason.<p>Imagine if I sold you an automated potato peeler.  &quot;It&#x27;ll peel the potatoes for you in seconds!&quot;  And it does!  But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way.  That&#x27;s what the modern front-end tools are like.  They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.