How it feels to learn JavaScript in 2016
In my experience, the developers who fall into this trap of despair almost always do so because they aren&#x27;t consciously choosing what tools to use; instead they are letting the tools choose them.<p>They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don&#x27;t want to feel left behind.<p>Choose a library or tool because it improves your development process. If it doesn&#x27;t appear to improve it, don&#x27;t use it (at least not unless external forces compel you to). Especially don&#x27;t use it if it appears that it will retard your performance (<i>cough</i> Angular <i>cough</i>).<p>For example, after months (years?) of finding ever more efficient ways of enforcing object interfaces (or even basic types) at runtime, I eventually reached the limits of what JS and unit testing alone could acomplish and found myself researching Typescript, Flow, and the like.<p>That&#x27;s not to say I&#x27;m a user of either of those, but if I do choose to adopt one in a project, I will know exactly what performance gain I am expecting from it. I&#x27;m still very productive without them.<p>In fact, I&#x27;ve successfully avoided a lot of fads in the industry for most of my career.  It turns out that being able to explain why I <i>don&#x27;t</i> use a tool makes me look like I know what I&#x27;m talking about and not just cargo culting. Employers quite like that.<p>Incidentally, this isn&#x27;t unique to the front-end.  I&#x27;ve seen the same thing happen with the SQL-&gt;ORM-&gt;Mongo-&gt;Couch-&gt;SQL nonsense, or the myriad of templating engines written for PHP, a language that itself <i>is</i> a templating engine.