This article mostly seems to be saying "my problems don't require your solutions". So don't use them. We all know jQuery still works.
A more charitable reading would be "don't use complex tools to solve simple problems". That'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:
If I see a section on my app that is really hard to with Pjax/Turbolinks and jQuery, I’ll bring in a library/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.
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'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'll probably wish you could use async/await. When your site takes five seconds to load over 3G because of your single monolithic codebase, you'll probably wish you could tree-shake your dependencies. The tools mocked by the author have real uses, he just refuses to see them.
Something like http://rollupjs.org which statically analyzes your ES6 dependency graph and creates a bundle with only the parts you need. The author included an image that rips at ES6 syntax, including the new import statements. A tool like Rollup couldn't work with dynamic exports like `module.exports = foobar`.
While I'm not a huge fan of the tone, I do agree with a few points. The ES6/ES7 syntax is freaking awful... I still write almost all of my JavaScript code in ES5 because I don't really want to have to deal with all of the magical stuff Babel/Traceur/TypeScript/whatever is doing behind the scenes.
That being said, it's not all bad. System.js/JSPM has improved my front-end workflow quite a bit and the SPAs I've made with the new workflow have been both stable, compatible and fast (very few end user complaints, lots of praise, quick development). So while some things have become convoluted, not everything is dire.
This makes me so glad I don't work on anything near web development. You know there about two dozen other major areas in software if you ever want to something different. Just saying. On the other hand, the labor shortage in the other areas is so much more pronounced thanks to the popularity of the web (and mobile) that I really should be more thankful for it.
Think about all the different computers connected together it took to get this web page to your eyes. All those network nodes, routers, the billing for your ISP, the CDN, all the security related, etc. How did those things even come into existence? Think of the tools the humans used to work on those things. Think of the energy it takes to run all those systems. Think of the entire fuel supply chain, power generation, transmission and distribution. All that takes millions of computers. Think of transportation, defense, biotech, astronomy, music, film, games, litigation support, to education. Computers run everything. "Basic" agriculture and land management is even wholly revolutionized by software. The world is a big place. Applied computing is unfathomably far reaching. Further, applied computing relies on development tools, operating systems, microprocessor design, fabrication advancements. Don't settle for a career in something that you find boring.
Outside of Reagent for clojurescript, I'm not that interested in using React. It does seem like a step back in readability and 9 times out of 10 you don't need to use virtual dom because you know exactly what is changing and where.
With clojurescript it was a no brainer since the effort to make it reactive was functionally 0 compared to default hiccup data structures.
Have you worked extensively in Javascript and other dynamic languages? In my experience, Javascript is at least 10x worse on nearly every major point he raises than anything else I've seen. The library creators don't have a fucking clue what they're doing, and blindly cargo-cult what the rest of the community is doing (example: micro-libraries). This happens a bit in ruby, but NOTHING on the scale that it happens in javascript.
A more charitable reading would be "don't use complex tools to solve simple problems". That'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:
If I see a section on my app that is really hard to with Pjax/Turbolinks and jQuery, I’ll bring in a library/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.
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'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'll probably wish you could use async/await. When your site takes five seconds to load over 3G because of your single monolithic codebase, you'll probably wish you could tree-shake your dependencies. The tools mocked by the author have real uses, he just refuses to see them.