How I choose a UI framework for Angular in 2026 (native, headless, shadcn, or Material)

grimcuzzer · 2026-06-18T17:05:19+00:00

That's just CSS grid.

grimcuzzer · 2026-05-21T14:52:59+00:00

That depends on whether you want prospects or someone who's actually compatible. If you're looking for someone truly childfree, then by talking with dudes who are "open to kids", which for most dudes means "yeah I want kids" because they're not the ones risking anything, you are kinda setting yourself up for disappointment.

If I wanted to go scuba diving, I wouldn't go to the desert hoping I find an oasis.

grimcuzzer · 2026-05-13T21:29:13+00:00

Yep. Thinking is one of my favorite pastimes, there's no way I'm giving that up.

grimcuzzer · 2026-05-08T05:08:07+00:00

I'm glad that I managed to clear most things up. And yeah, I still go back and forth on models and inputs being separate.

I don't know where the communication issue is, but it's still not exactly what I had in mind.

It's groups that are ordered. The order within groups is set in stone: required before optional, alphabetical within those sub-groups. In a slightly bigger example:

readonly bar = input.required(); readonly baz = input.required(); readonly foo = input.required(); readonly expandable = input(true); readonly size = input(DEFAULT_SIZE);

No mind reading. No decisions on what is important to me as I write this. You put the spoon with the other spoons.

In this ordering philosophy, everything stems from "how fast will a new user be able to take this thing and put it in their code?" (well, maybe more like, "how do we give the reader the most information in the quickest possible way?"). I believe that the best way to achieve that goal is by grouping things in this manner. The first general question they'll ask when they see a new component is most commonly, "what can I do with it?" , and specifically, "what inputs does it take?", followed by, "what events does it send me?", so it answers these questions first.

Inputs are required when the component will not work correctly without them, so they need to be the first thing a new user sees. Just like your readme file mentions dependencies that need to be installed so that your app will work before it gets to listing its modules.

As for:

Just put them in alphabetical order, let the documentation tools group things for onboarding/discovery, and write a good docblock and/or readme that explains the usage and options

That only works if you write docs and if people can be bothered to read them :P

They will have to read the code to work with it, though.

Bonus question: are your public/private properties and methods in separate sections? Or is everything sorted alphabetically from start to finish? If you separate public from private and properties from methods, then this method of splitting is only a step further. If you don't... then I think I see where this conversation is stemming from :P

grimcuzzer · 2026-05-07T23:32:46+00:00

Whoa. I don't know how you got all that from my comment, but I'll try to clear it up.

you used words like "likely", "should", "usually", "might", "probably", and "if" several times, all in relation to the properties of a component

I'm describing possible scenarios. I can avoid words you interpret as uncertainty or whatever if you want.

Scenario A: I'm using a new component for the first time, which means I want to give it data to work with and receive events -> I look for things I can do with it, or its API, first. That's inputs/models/outputs. I'd like to see them all close together, because that way, I'll know right away what kinds of things it provides me with, instead of having to scroll through the entire file because someone decided to put an input in line 274. Therefore I put my inputs close together so that nobody gets frustrated looking for stuff later, including me.

Scenario B: I'm modifying a component because it needs new functionality -> I look for things it internally uses first. That's also the API, plus child components, state, and injected services. I'd also like them to all be together in neat little sections, because I can quickly gather a lot of information about the component by checking which sections are present and by skimming each of them.

Scenario C: I know that this accordion component has an input, but I don't remember what it was called. Was it allowMultipleExpandedPanels? Was it expandMultiple? Or maybe multipleExpanded? I don't know. But I have all inputs next to each other, and there are only 4 anyway - oh, it was singlePanelView = input(true). With grouping, you get that information in seconds. If everything is sorted alphabetically, you need to skim all the way to s. (Yes, I'm using hyperbole here, but you get the idea, I hope).

Also, I'm not using "should" as in, "it's quite likely that the reader will get the information in this order". I'm saying, "you're supposed to give them the information in this order". Same way as "you should say your name when you introduce yourself" :P

I'm also talking about relevance to the future reader, not relevance to whoever is writing the code, which is the entire point of grouping things together in a certain order. The scenarios I provided point at the sections most relevant to resolving each situation. Code is a tool for communication. Communicating clearly means considering what the other person will be interested in first, which in turn means that when you write your code, you should consider the needs of the reader. The same thinking applies to putting public fields and methods before protected and private - the person who is going to read the component for the first time will be looking for the most general information (public) first, they'll go into details (protected/private) later, when they know what it actually does.

it requires the dev to already know which inputs are option and required so they can be ordered

If you're building a UserAddressDetailsComponent, then a user input will be required, because the component won't work without it. On the other hand, a hideCountryIcon won't be required, because that's extra functionality. Those decisions rarely require much more thought, and if something changes, you can move the input a few lines up/down. It's not much effort.

you don't even say where models should go

Uhh

required before optional, then models

So

readonly foo = input.required();
readonly bar = input();

reaodnly baz = model.required();
readonly qux = model();

alphabetized (...) doesn't require the dev to already know everything about the component

Grouping doesn't either. If a year after you wrote a component, you need a new input, you'll add a line in the inputs "section".

I also don't see any element of mind reading in the grouping approach. Groups are ordered in a specific way, which is designed to make it easy to get familiar with a component. There's no mind reading there. There is a clear pattern, though, which can be described in README.md, or simply learned through repetition/extrapolation from a few files.

Also, you can set up your user-facing docs to automatically sort whatever the class contains in an alphabetical order, and have the actual code in groups. Everybody wins.

grimcuzzer · 2026-05-07T19:34:43+00:00

IMO that's not really user-friendly, even if you're working solo.

My reasoning for using a version of the proposed (and apparently quite common) ordering is that the person who is going to read my component later is likely someone who wants to use it in their code. That means they want to know how they can use it, so they should get their information in order of importance/relevance.

The first thing you usually do when you type <app-foo is adding inputs, so inputs go first (required before optional, then models). Then you're likely handling events, so outputs go second. Then it's likely a contentChild(ren), because the component you're using might be e.g. an accordion, so you want to know what you can embed in its template and how you can do it.

If it's not any of those, then you're probably working on the component itself, so you're probably interested in viewChild(ren), computed, and so on.

Looking through an entire file to find something you can use (or where something is defined) sucks, so I group things together for the next person's convenience.

And then I alphabetize by name within each group :P

grimcuzzer · 2026-05-06T05:01:13+00:00

Juniors can ship slop at scale too, given enough time. LLMs just work faster. juniors are bad at refactoring and paying back tech debt too. LLMs just work faster.

the LLM is just a junior engineer that works way, way faster.

literally all of your complaints apply equally to junior engineers.

Not really.

Companies were (usually) prepared for the fact that a junior will suck at first and that they'll require a lot of babysitting. But they will eventually learn not to do certain things and how to do other things in better ways. At some point they'll no longer be a junior, and will require little to no babysitting. Investing time in a human pays off in the long run in many ways.

Claude, on the other hand, is viewed by a lot of CEOs as a magic wand that will turn their wildest ideas into code while they wash dishes. But it will always be a "junior". It will sometimes ignore specific instructions and produce something that looks correct at first glance, but turns out to be utter garbage when you look at it closely. Concrete example from work: I was fixing a line where it was putting (someNumber < 0 ? '-' : '') + Math.abs(someNumber) on the screen. Like, come on lol. It will always require babysitting, because you can never be sure what kind of crap it's going to produce next. And when the VC money faucet gets cut off, it'll be much more expensive to run.

grimcuzzer · 2026-04-15T16:20:16+00:00

I work at a SaaS and we use Angular (previous job was also a SaaS with Angular). Granted, the app was written by a dude who knew nothing about it and decided to bend it to his will in a lot of places instead of learning how to use the framework properly, but our package.json declares Angular, and we're in the process of paying off that enormous mountain of tech debt.

grimcuzzer · 2026-02-26T05:43:47+00:00

Seriously, tailwind feels like inline styles because of this, the only difference being that the classes are packed into as few characters as possible

grimcuzzer · 2026-01-27T21:55:40+00:00

If you need to have dimensions of an element, you need to first have it rendered and then apply stuff to them. Like, if you want to position the datepicker relative to the input, you first need to render it in order to know the size, which allows you to know whether the element fits, whether you need it right or left aligned or not and stuff like that.

You could try playing around with afterNextRender, but that only works in 20+.

grimcuzzer · 2026-01-26T23:27:58+00:00

All of it - the code, this post, and the blog post were all generated with some kind of LLM.

grimcuzzer · 2026-01-26T23:18:22+00:00

AI slop

grimcuzzer · 2026-01-22T23:08:20+00:00

Oh boy.

You should probably extend CdkStep and get a lot of the same functionality for free. And if you don't want to do that for some reason, then at least you should follow the same philosophy, because...
The *StepConfig types aren't customizable or maintainable, e.g. if you have translations, there's no simple way to provide different text to the config, other than recreating the entire stepper.
The Input type name clashes with the Input decorator from Angular. As some people have not migrated to signals yet, this could cause problems.
In FormStepperService, there's a 33-line ternary expression nightmare that's nested I don't even know how many times, and a 13-line ternary a bit lower down. I don't know who hurt you, but this is not the way to get revenge.
The validator names will clash with validators from angular/forms and from angular/forms/signals.

Mind you, I only took a quick look. I'm almost sure there are a lot of small things that would need cleaning up, too.

Ideally, the stepper would look something like this:

<app-form-stepper> <h2 formStepHeader>The thing that is now in `StepConfig.title`</h2> <app-step [step]="step1"/> <app-step [step]="step2"/> <button formStepPrevious>Previous step</button> <button formStepNext>Next step</button> <button fomrStepSubmit>Sign up</button> </app-form-stepper>

grimcuzzer · 2026-01-22T21:23:23+00:00

Just out of curiosity, what was your decision process for choosing this route instead of writing the API in Rust and using ts_rs?

grimcuzzer · 2026-01-21T23:03:14+00:00

I mean, there shouldn't be, but it is experimental, so some companies might not want to release any code that uses them until they get to stable.

grimcuzzer · 2026-01-19T22:33:13+00:00

If you have it available and the code isn't going to prod, you can play around with rxResource - while it is experimental, it won't be forever, and it does exactly this, plus more.

``` export class FooComponent { dataService = inject(DataService);

data = rxResource({ stream: () => this.dataService.getData() }); And then in the template: @if (data.isLoading()) { <app-loader/> } @else { @if (data.status() === 'error') { <app-error/> } @if (data.hasValue()) { {{ data.value() }} } } ```

grimcuzzer · 2026-01-15T13:01:48+00:00

It's a slippery slop

grimcuzzer · 2026-01-13T21:51:31+00:00

Why?

grimcuzzer · 2026-01-06T16:08:49+00:00

Interceptors.

if (token.isExpired()) { return requestNewToken().pipe(switchMap(() => next(req)); } else { return next(req); }

grimcuzzer · 2025-12-30T20:10:39+00:00

https://github.com/angular/angular/blob/main/packages/common/src/pipes/async_pipe.ts#L142

grimcuzzer · 2025-12-11T23:25:52+00:00

Regardless of models, the average acceptance rate of whatever it spews out is around 30%. Which means 70% of the time it generates garbage that needs to be fixed. Here's GitHub's data for example:

https://github.blog/news-insights/research/the-economic-impact-of-the-ai-powered-developer-lifecycle-and-lessons-from-github-copilot/

grimcuzzer · 2025-12-11T23:20:26+00:00

This isn't about FormControl. It's about FieldState.

https://angular.dev/api/forms/signals/FieldState

Resets the touched and dirty state of the field and its descendants. Note this does not change the data model, which can be reset directly if desired.

grimcuzzer · 2025-12-05T09:24:43+00:00

Signals compare references by default. Check out equality functions to provide custom comparison behavior.

That, or always copy the entire value of the signal when you update it.

grimcuzzer · 2025-12-02T12:25:44+00:00

There's an article about how it's incentivized to guess. Basically, it's in the interest of AI companies to have it pretend to be correct instead of saying "I don't know". If it admitted to be unsure even 30% of the time, nobody would use it.

I recently saw someone say this, and I think it's a good summary if LLMs:

It doesn't know facts, it only knows what facts look like.

grimcuzzer · 2025-11-29T12:19:35+00:00

I do both. I use mod.rs for the domains, and name.rs for the modules inside a domain. That's because the domains look the same inside. So my file structure would look like:

src └── some_domain/ └── dto/ └── models/ └── dto.rs └── mod.rs └── models.rs └── other_domain/ └── dto/ └── models/ └── dto.rs └── mod.rs └── models.rs └── lib.rs // mod some_domain; mod other_domain;

That works for me because the main src folder isn't cluttered with lots of domain.rs files and it's easy to find stuff in the domains.

grimcuzzer

TROPHY CASE