Babar Azam
Angular is Costing Companies Billions
I know I’m going to get hate-mail for writing this piece, but, so be it. Someone has got to finally say what many of us as experienced software engineers have been thinking for some time now.
I’ve been a developer for over 20 years working for some of North America’s most prestigious companies. For several years now I’ve been watching the state of UI and how it’s gone from bad to worse. Specifically, I’m talking about “fad-tech”, those cutesy not-so-little pieces of JS and CSS that are supposed to be all the rage with the newbie crowd and now even with some seasoned engineers who should know better.
The snowballing culture of using these frameworks, like Angular, have avalanched us into code hell with no end in sight of when this nonsense is ever going to level off. Everyday I see job postings come into my email, companies of all sizes scrambling for EXPERIENCED Angular 4, 5, 6, 7, 8, 10, 12 developers with at least 5 years of experience building and maintaining this mess we call “state-of-the-art” UI.
It’s not “state-of-the-art”. It’s a mess. Several years ago I had an interview with EA (Electronic Arts) during which I was told that the company was junking all of their UI frameworks and returning to simply writing plain vanilla ECMA (JavaScript) enclosures. (That would be JS “plugins” for us jQuery people.) I was surprised but also curious. Now the rest of us know why.
Keep it Stupid Simple
I don’t like calling people “stupid”, so I’ve sort of rearranged the classic KISS acronym. But the KISS principle has been utterly lost with the latest versions of Angular. It’s no longer just a UI framework, but a backend service as well. Your UI people are now having to write backend code that goes beyond mere HTML templating. Some people would like to say that is a good thing! But it’s not. Yes, Angular has some cool “whiz-bang” features—ALL of which are completely unnecessary to write effective and stunning UI or deliver a professional UX. SPA’s (single-page applications) are out. They are difficult to maintain and wreak havoc with analytics and search engine crawlers which rely on the URL actually changing. Yes, there are work arounds for these issues, but THAT’S THE POINT! You shouldn’t have to write code to “work around” how the web actually works!
Say No to UI Compilers
Another “fad-tech” that’s been around a while that also needs to go is Sass and Less. Honestly, I like the code organization that these CSS frameworks offer. What I don’t like are “mixins” and that they need to be compiled to run. At this point, I don’t know why browsers don’t just natively support SCSS as a standard way to ingest CSS code, but that’s a topic for another time. The bottom line with these CSS pseudo-languages is that they really don’t save time; they’re not easier to use and learn; and at the end of the day, all they really do is generate nice clean well-targeted CSS code that all of us should be writing natively anyway. If you want to use Sass or Less and pre-compile them in your own dev environment, I don’t have a problem with that. But what we should never see are these files entering the CICD pipeline for compiling during deployments. The same goes for any other JavaScript library or framework that eventually compiles to plain vanilla ECMA as well. Every step you add to the CICD pipeline just gums up and bloats what should be a very simple deployment process. We should be looking for ways to decrease the number of steps in the process, not pile on more just because “Jenkins” allows us to do it.
