AI is changing a lot in our industry - but there's no rose without a thorn. For example, open source is having a tough time, as discussed in Open source is dying due to:
pr spam/slop
dumber/angrier users
install vs prompt
funding problems
Another thorn is discussed in From Technical Debt to Cognitive and Intent Debt:
With generative AI automating more development work, knowing how much debt is acceptable in a particular organization or project remains uncertain.
In contrast to the shadows of those thorns, I want to shine on one of the rose's beauties: The Component Library is dead, long live the Component Library.
I think this is a perfectly fitting snowclone. Component libraries have been reinvented (died and crowned again) many times and AI is changing the cost-benefit trade-off. Follow my train of thoughts and I'd really appreciate your perspective!
The starting situation
Imagine you are working at a small company in 2024 that offers a collection of excellent niche products for a specialized market. The company wants to migrate large parts of its digital solutions to the web and you get hired to get the job done. You are not building a single static web product, but migrating a collection of solutions. Naturally, you will need a component library and more (1).
Building your own component library from scratch is out of scope. Existing code uses different Angular versions, so you decide to stick with Angular. There are strong requirements for heavy table usage. This essentially narrows your choice down to PrimeNG. So, you build upon it.
Two years later, you are somewhat disappointed with PrimeNG:
- Migrations from v17 -> v18 -> v19 -> v20 -> v21 were painful and always including undocumented breaking changes (2)
- The PrimeNG Team announces to shift away from PrimeNG in favour of a new library PrimeNGX (3) - yay, more migration work to do - and revised the announcement later (4)
- In 2024 and 2025, you were able to contribute a bug fix and some docu improvements (5); however in 2026 there are over 200 open pull requests. Will even your latest simple docu typo fix get merged soon?
For your next feature, you need to select data in a nested select box and re-use that data for a nested table. PrimeNG's tree select and tree table seem to be a perfect match, at first glance. But you soon realise, that the data models between tree select and tree table require a bridge layer and you run into multiple bugs like 6, 7 or 8.
Offering to fix those bugs does not promise quick results, especially since your last offering was ignored. Time is a precious resource. You have already spent some time in upgrading legacy code from Angular 13 to latest Angular, removing old Angular Material usages, introducing PrimeNG next to Bootstrap... You don't want to ask for additional time to work on a custom component library, or integrate yet another external library.
AI tools for the rescue?
Trying out the new magic AI toolbox is cheap. Others have also already come up with the basis idea (9, 10), which is encouraging. What we basically can do is prompt a coding agent:
We need to select data of the format X in a nested select box. In another place we want to display the selected data in a nested table. PrimeNG's tree table and tree select seem like a good fit. However, the current implementation here has run in bugs within PrimeNG like bug 1, bug 2 or bug 3. The required data bridge in ref:myCode adds maintenance overhead and is a source for bugs.
Therefore, write a reusable tree-table and tree-select component in my components folder. The interface should look like Y. The look and feel should integrate smoothly with PrimeNG's components. Feel free to ask PrimeNG's MCP server.
... and after some iterations ...
Now migrate my feature F to use the newly created tree-table and tree-select components.
Within two working days, there was a customized tree-table and tree-select and the feature was migrated to use them. It now works as expected - without having had to ask for extra time.
How will the future evolve?
Creating the skeleton took about two hours. Most of the time was spent understanding the generated code, fixing hidden bugs, and refining the UI/UX.
Of course, it would be ideal if open source component libraries made this kind of effort not needed at all in the future - maybe they will improve and we should wait it out?
How much time will be consumed by those custom components for future upgrades of Angular and PrimeNG? Will it become more cost-effective in the future to go with a coding agent as "component library team" gradually replacing PrimeNG until we completely eject PrimeNG and maintain everything ourselves?
How will our own component age? Will it look vintage in five years’ time, while PrimeNG components will have latest best practices? Or will it basically be the same, but PrimeNG changes forcing some look and feel changes on our users, being annoying without real improvements?
How will the next crowned component library look like and how long will it reign? I am looking forward to your thoughts in the comments.
Top comments (0)