This article mostly seems to be saying &quot;my problems don&#x27;t require your solutions&quot;. So don&#x27;t use them. We all know jQuery still works.<p>A more charitable reading would be &quot;don&#x27;t use complex tools to solve simple problems&quot;. That&#x27;s a fine piece of advice when your problems are simple. Simple problems rarely stay that way. Most of these articles lamenting the state of front end development make a similar concession:<p><i>If I see a section on my app that is really hard to with Pjax&#x2F;Turbolinks and jQuery, I’ll bring in a library&#x2F;framework like Vue.js, React, Angular. All good choices for doing really complex forms(although I find Angular to be the best at this), with a ton of conditional validation. You know what though, these are the outliers in my experience, not the norm.</i><p>Sure, adding a form to your front page can be done with a couple lines of vanilla javascript. But you suffer the cost of a framework or library at the start of a project because it pays dividends at the end of a project. When you have to filter a list of ten thousand items as the user types, you&#x27;ll probably wish you could use virtual DOM diffing. When you have to step through a series of ten asynchronous requests before updating a view, you&#x27;ll probably wish you could use async&#x2F;await. When your site takes five seconds to load over 3G because of your single monolithic codebase, you&#x27;ll probably wish you could tree-shake your dependencies. The tools mocked by the author have real uses, he just refuses to see them.