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.

How they work

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-template, ng-container, and a liberal use of *ngIf and *ngFor, you can probably build most single screen applications.

Ignoring parts of Angular

Each of these applications uses a single component, meaning it's ignoring huge swaths of the Angular API.

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.

Better than Vanilla JS

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.

But why not use multiple components?

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.

Feel free to disagree

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.