The Angular documentation outlines best practices and patterns that most developers will need when creating large scalable applications.
But what if there were a whole class of apps that didn't need this power and flexibility? I call these Single Component Apps, and I build them every day.
Here's two examples that I built or worked on recently:
- update.angular.io - the interactive Angular update guide
- baby.fluin.io - an app I built for tracking my infant son
I'm also working on several others (like my Hex grid game) that will ship eventually.
Generally I have a single template with a lot of containers and divs that look like this:
<ng-container *ngIf="data | async as result">. With
ng-container, and a liberal use of
*ngFor, you can probably build most single screen applications.
I can use any of the features I want, but I don't feel compelled to use them until they make sense. This helps me avoid over engineering. I can naturally create services, pipes, queries only when I feel the need, creating an application that I can iterate quickly on in the beginning.
These apps aren't sophisticated, and I could have built them with Vanilla JS, but then I would be writing a custom DOM manipulation / rendering methods, when the look and feel of a declarative template really meets my needs and make sense to me.
Angular is valuable in these apps due to the template syntax, change detection, pipes. It's also valuable simply due to the awesome build system that you get out of the box with the Angular CLI. TypeScript, minification/uglification, great live reload, and more all come by default.
If you need multiple components, go for it! As each of these applications grow, I expect I will eventually want to extract out some of my rendering logic and in the long run, components are fantastic for isolating parts of your application and making your code more reusable, and easier to reason able.
I generally like to start with a single component until its template violates DRY principles, or until it starts being a couple hundred lines of code.
If I ever want routing in these apps, I'll also go for components, as the Angular Router is wired for this functionality out of the box. Additionally, file level separation between routes is very logical.
Don't like single component apps? That's okay! Most of these apps have a single developer, meaning they face very different challenges than any true enterprise or scaled app. But I think that we need to acknowledge that a lot of the apps we all write look like this, or at least start like this. By acknowledging they exist and look like this for a valid reason, maybe we create space where writing this type of app is OK.
There are a lot of people who love both JS and UX/CSS. If we stop labeling people just as “JS developers” or “UX developers”, we can achieve a ceasefire in the current “JS vs. CSS” war and achieve a mutually benefiting peace.