Why It’s Time to Kill Angular
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.
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!
Just 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.
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.
Angular is Bloating the UI
Call me a UI purist, but the current state of UI is not “art”—it’s a cluster-(expletive omitted). I get that people at Google are bored and need something to do, but Angular and other similar frameworks are destroying the simplicity of the UI, not making it easier.
The point is you don’t need a bloated framework to write clean, elegant UI or build an effective UX. You can use whatever native templating engine your backend provides without bloating the frontend with incomprehensible and un-debuggable compiled JS.
Angular is Costing Companies Billions
At the end of the day, a framework is supposed to make coding easier, not harder. It’s supposed to save companies money with that ease of use, not cost them more.
But this is exactly what is happening—Angular is expensive to run.
Unfortunately, Angular (and other UI frameworks as well) cost companies more money, lots of money, to train and re-train employees to learn and re-learn a framework that keeps changing versions every year or so. Yes, Angular has now promised that all new versions will be backward compatible, but again, that is just going to add to the already bloated complexity when the next new “really cool” component needs to change everything again.
And God help you if you’re a contractor who works with several enterprises who are all using different UI frameworks. You now need to learn and know not just 12 different flavors of Angular, but various versions of Vue and React as well that some newbie programmer saddled the company with 4 years ago but has now left to ruin someone else’s technology stack.
It’s time to relegate Angular (and the others) to the junk pile of failed experiments where it belongs.
What Should Replace Angular?
I’m not opposed to using open source libraries like jQuery, or other UI components, or CSS frameworks like Bootstrap. These can be “included” with one or two lines of code and they actually do make our lives as developers a lot easier!
But if the framework needs Node.js to run, like Tailwind, or you need to train and re-train people to use it because the maintainers keep updating it year after year, that stuff is just costing you money—and for what? It’s “super-cool” to use?
The bottom line is Angular is gumming up the works; it’s costing your company thousands, perhaps tens of thousands, and if you’re a Fortune 1,000 enterprise, it’s likely costing you millions each year in maintenance, updates, training, and lost time just finding experienced people (or people who even want) to support the monstrosity.
Whenever I see a company desperate for UI engineers, invariably now they NEED someone with 3 to 5 years of Angular experience. That’s nonsense. I can build elegant, fully functional UI in less time with plain JS, and without all of the Angular frontend and backend complexity.
If something breaks in production with an enclosure written in plain JS, it takes seconds to find the problem within any browser’s dev tools, and I don’t need to install or include yet another layer of bloat to tell me how to debug the compiled code.
The Holy Grail of writing code, any code, lies within its simplicity. However, as modern engineers, we’ve all but totally lost sight of that simplicity. We’ve gotten caught up in the fad of whatever shiny new tech has gotten released from which ever fav tech giant or college has shoved in our face as “state-of-the-art”.
Well, Google or whichever university isn’t paying your staffing bills. It’s time CTO’s took charge of the technology stack, deprecated the fad-tech, and returned all of us to rational reasoned UI that is simple, maintainable, and beautiful.
This article first appeared on Medium.
- Posted by Beau Beauchamp
- On July 18, 2021