I’m glad that I don’t work for any of the naysayers bashing this article. If heavy over-engineered frameworks are great for you, that’s awesome, but they aren’t good for everyone or for every use case. I worked on a desktop application built with CEF that had absolutely insane performance requirements to the point where we couldn’t even use jQuery (which was popular and standard at the time in 2013). We ended up developing the entire front-end for our application in TypeScript 0.4 and pruning it down to as few lines of code as possible, while building a custom TS framework along the way. The entire effort was kicked off by our senior C++ developer and we ended up with a superior design that wasted zero clock cycles on loading a framework or having magic components do the work for us. The skills I gained form this experience alone (along with many others) are not common within the developer space where everyone assumes that burning extra clock cycles and RAM on a client machine are acceptable trade-offs for developer productivity. We had to build the absolute fastest thing possible that used literally as few system resources as possible per direction of the CEO and CTO, and had we used the newly-emerging AngularJS at the time, our product would not have met the requirements laid out by the executives, plain and simple. Not everyone’s use case is the same and in some cases you don’t have the option of using fancy XYZ framework regardless of the opinion of others who are not on your specific project and have no context about it.

Thanks for the article.