This is a great article. I’ve been working with various JS technologies for about 10 years now, from vanilla JS to jQuery, YUI, Angular, React, and numerous others, including multiple custom frameworks built in-house to achieve certain performance metrics which were proven impossible with the frameworks available at the time.
Having to go from a fully custom front-end framework designed in TypeScript on top of a modified Chromium engine for a desktop app, to building a basic web application using the current version of AngularJS at the time (around 1.6) was an absolutely frustrating and painful experience. Angular did not accomplish one single thing that I had not already learned a design pattern for — in both JavaScript and TypeScript, among other languages — only it did so in a frustrating, inefficient, error-prone, and poorly performing way. A recent comparison of JavaScript frameworks shows just how bad the original Angular fails in this category, and it was certainly no better five years ago.
The only challenge I really faced was usually in convincing people to adopt better tools than what everyone else was using at the time, because people seem to think that popular always means better when really it just means what the bulk of the dev community can manage to get their head around — not necessarily good enough when you need something extremely high-end and years beyond what everyone else is doing. For example, on the AngularJS project I mentioned earlier, I was pushing for the team to adopt the newer and much more promising Angular2 which was about to be out of beta and was already superior in nearly every way to the original Angular. I was told basically that “intermediary languages like TypeScript provided no advantage and there was no point in adopting it” and so along I went, sometimes fixing bugs in the Angular library itself, or finding strange exceptions and building general abstractions for them as global workarounds, to prevent the rest of my team from running into the same problems I did on a daily basis.
Of the dozens of applications and websites I’ve worked on over the years, I have found that in most cases, generally available front-end frameworks are pretty useful as tools to help developers with less JS mastery achieve minimum code standards and provide at least some rudimentary method of doing things instead of letting everyone do whatever they want. However, on performance-critical apps that involved embedding a web front-end into a desktop PC maintenance application for example where microseconds add up fast, the only way to really get 100% potential was to develop a custom framework solution from the ground-up that matched the needs of the application and the team building it perfectly with zero compromise. Everything else though is probably not as demanding and therefore more open to whatever works.
