There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them.This is true, but the fundamental argument Frank makes in this article is just as applicable to web applications, if not more so.
We are now building significant software that happens to be written in JavaScript and to run in a browser. We call the results web applications, but it’s still just software. The basic principles of building software well are still the same: using modular design to decompose a large system into more manageable parts, separation of concerns, choosing the right data structures and algorithms, being systematic about covering different cases... These are all as relevant to developing front-end web applications as any other non-trivial software.
None of those things implies a need for overcomplicated tooling. None of those things implies a need for dependency trees with an unmanageable level of complexity. None of these things requires a combination of trial-and-error coding and rapid deployment. You can build large, complex, robust, useful web applications perfectly well without those things.
Usually, good tools are simple and do one job well. The tools that have stood the test of time in my web programming toolbox — things like jQuery, Lodash, SASS, Babel, Browserify, Mocha and React — almost invariably fall into that category. I find much less benefit in tools that require more than a few seconds to set up, depend on anything not obviously related, introduce any non-trivial boilerplate that I’m not almost always going to need, or introduce any sort of non-standard changes to source files that aren’t all but guaranteed to work in the long term.
Of course there are no absolute rules here, but it has been my experience that heavyweight frameworks, scaffolding generators, build process and the like often trade off short-term convenience against stability and longevity (and often, worse, understanding what is really happening). Like the current emphasis on continuous/rapid everything, that isn’t necessarily a good trade to make if you’re interested in building larger, more complicated, longer-lived software, as we increasingly are in front-end web development.
