Forem: shaman-apprentice

The Component Library is dead, long live the Component Library

shaman-apprentice — Tue, 21 Apr 2026 18:05:02 +0000

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.

Software engineering is an interwoven part of the loop

shaman-apprentice — Thu, 22 Jan 2026 14:58:10 +0000

In my computer science studies at university, I learned that about two thirds of all software projects are neither delivered on time nor within budget. At the time, this seemed ridiculous to me. It doesn't anymore, despite having worked with many smart people for ten years since.

How can this be? Poor handovers? Weak business ideas? Broken feedback loops? My overall guess is that we excel within our own specialties but lack interest and insights into the full value chain needed for a successful digital product. Engineering excellence alone is rarely enough.

In this article, I invite you to follow my thoughts and share a set of recommendations for leveling up.

TLDR - My key takeaways

User-centered design is important. The famous DORA 2024 Accelerate State of DevOps report even highlights this as the most important skill.
Socio-technical skills are important.
AI is a rapidly evolving, exciting technology that can help us to get out ideas faster.
I recommend to explore different disciplines along the complete value chain.

1. What are we building?

The obvious goal is to develop a product for customers. In most cases we also want revenue to exceed costs. So, we need to find a problem people are both eager to solve and willing to pay for.

This sounds easy, yet is probably the hardest part. Consider two examples:

If I had asked people what they wanted, they would have said faster horses (Henry Ford)

In retrospect, investing into automobile development, like Ford did, was an obvious call. As contrasting example:

I think there is a world market for maybe five computers (Thomas Watson, chairman of IBM)

In retrospect, this is an obviously ridiculous bad call.

However, at the time these decisions were made, uncertainty was high, information was incomplete, and outcomes were far from obvious. Product development lives in the uncomfortable space between insight, intuition and incomplete data.

How can we improve our chances for those calls upfront? This is a science on its own and one which is still evolving. Three personal recommendations for leveling up:

The Mom Test: How to Talk to Customers & Learn if Your Business is a Good Idea When Everyone is Lying to You
Competing Against Luck
Product Design (UX/UI) Course - my learning journey was really great and all my exercises finally came together into Together, We Choose

2. Exploration and feedback loops

If we do not excel in the previous part - understanding what we are building - software development will suffer. Requirements will change frequently, chosen architecture trade-offs will be based on false assumptions and become anti-trades. Preventing this early drift is paramount!

Therefore, we need to explore and gather feedback as quickly as possible. This can be some user interviews, paper prototypes, digital prototypes, whatever works to evaluate your idea and reduce uncertainty.

At the latest when you are ready to invest in digital prototypes or early versions, software developers usually enter the picture. The goal is not to build the full product with a perfect architecture. Instead, the architecture must support ongoing exploration.

Exploration likely requires collaboration across roles. Business analysts, customers, designers, developers, investors, managers, etc. need to work together: Come up with ideas, hand them over, build experiments, evaluate outcomes and exchange knowledge again and again. For that, engineering excellence alone is obviously not enough. We need short, effective feedback loops and people skills to profit from everyone's expertise. In the bigger picture, it is often beneficial to deliberately accept technical debts as trade-off for faster exploration.

As a side note: AI can help you to generate ideas and lately even generate full prototypes for exploration. However, don't mistake those little generated apps as production ready, secure, bug free, cash-cow apps - if it were that simple, users could prompt the AI themselves instead of giving you their money. And AI-slop, bugs, security incidents, etc. can irreparably damage user confidence in you and your product, like the gigantic nx s1ngularity incident caused by an AI implemented mini feature.

One of the core ideas of the Agile movement is to encourage feedback loops and maximize the amount of work not done aka waste. I strongly agree with these principles. However, in my humble opinion, parts of the surrounding consulting industry have diluted the message over time. I recommend to level up in the terms user-centered design and socio-technical skills, e.g. with:

3. Engineering excellence

Once, we have managed to create a valuable product, we need to maintain and evolve it. In reality, we have likely already sacrificed the cleanliness of a greenfield project in favor of exploration and evaluation. Therefore, we need engineering skills to navigate and improve.

Technical perfection in software development does not exist, and even if it did, it would probably be a waste of money. The goal is to improve structure, reduce risk, and increase the system’s ability to change, so we can continuously support the ongoing product exploration and development.

This also has a socio-technical component: If you change something, you may overlook some previous trade-offs which still hold value. Teams can get tired of yet another change. Or you may unintentionally hurt someone’s feelings by questioning decisions they once made under very different constraints.

Resources I recommend for leveling up technical expertise:

Refactoring: Improving the Design of Existing Code
Working Effectively with Legacy Code
Clean Code: A Handbook of Agile Software Craftsmanship
And most importantly: Code your own work, accumulate your own experience and apply your common sense - if you don't see value in the next hype just save your time and energy and don't fall into the fear of missing out trap.

Final call-out

I'm curious about your thoughts. Your feedback is very welcome. Feel free to comment here and connect with me on bsky.

AI-assisted Test Driven Development Experiment Quick Takes

shaman-apprentice — Sun, 26 Oct 2025 21:10:29 +0000

Intrigued by Kent Beck's blog Augmented Coding: Beyond the Vibes, I wanted to experiment with AI-assisted Test Driven Development capabilities. For that, I coded the small library release-parrot.

This blog is a quick personal review - any feedback is very welcome 🤗

Quick takes

Did AI¹ help me to

finish the project quicker? I assume no
write a better test suite?² I assume no
improve the code quality? I assume no
improve the documentation? Yes! It relieved me of the (for me) tedious task of documentation and did it well. For example, before publishing I reviewed everything myself. Afterwards, I simply asked AI 'Is the project ready for its first release?' And AI found two errors in the documentation, that I had overlooked (it had forgotten to update a section when it had made some changes. But I hadn't caught them either at the time). In the final review, AI did a better job than me - nice!
level up? I assume yes
- I used Node.js' native test runner for the first time and tried out JSDoc instead of TS for strong typing. At the beginning, it was nice to have AI write the code, so that I didn't have to look up everything first. However, I read some docs anyway. I honestly don't know, if I would have been equally fast and had gained a deeper and more lasting understanding, if I had read the related documentation first.
- The opportunity to ask questions and get detailed answers (which should be critically examined), to ask differently or more in-depth again and get further detailed answers, was nice brain-food for me, which I used for further information retrieval.
- The AI-generated code tended to differ from my code-style and it was educational to think about the pros and cons in comparison.

Why do I sometimes only assume a yes/no answer? I love coding myself. Waiting for AI and reading all its stuff was exhausting for me. I think, I know, how I would have done it without AI. But I didn't actually do it. So I feel, that an honest, objective comparison is not possible by me.

Did the project create real value?

I don't think so. Probably, I could utilize something already battle-tested like semantic-release instead of writing my own library.

Can AI produce production code from start to finish without senior supervision?

For now, I have strong doubts. Even in this small project, AI sometimes got stuck in its loop and produced hundreds of lines of not working as intended code for a simple 3-lines-like change I wanted to do. Bad prompting? Bad luck? How much would that worsen in a bigger code base - amplified by accumulated amounts of AI-code which got not crushed down by senior supervision?

For the time being, I think AI is a great tool! But it is not (yet?) ready to be a senior developer by itself.

Footnotes

[1] I used GPT-5-Codex (Preview), Claude Sonnet 3.5 and 4. You can find my basic TDD prompt here.
[2] I strongly believe more tests or higher test coverage have nothing to do with test quality. Tests which give me confidence for refactoring, or serve as documentation are good tests. Tests which help me to define an interface or to verify that my logic works as expected are good tests. However, tests have to be maintained and IMHO can even have a negative total effect on the maintainability of a code base.

AI is amazing — but let's keep our critical thinking on

shaman-apprentice — Wed, 10 Sep 2025 13:09:40 +0000

There is a lot of financial investment and hype about AI. I have heard many different assessments of the impact of AI, especially regarding the value of AI for the software development industry. Here are two examples:

"my basic assumption is that each software engineer will just do much, much more for a while. And then at some point, yeah, maybe we do need less software engineers."
(Sam Altman)

"We know with near 100% certainty that this bubble will pop, causing lots of investments to fizzle to nothing. However what we don’t know is when it will pop, and thus how big the bubble will have grown, generating some real value in the process, before that happens. [...] We also know that when the bubble pops, many firms will go bust, but not all. When the dot-com bubble burst, it killed pets.com, it killed Webvan… but it did not kill Amazon"
(Martin Fowler)

Even if you, as a developer, don’t believe in the long-term quality of AI-generated code - and even if you’re right - it will still affect you. Why? Because most decision-makers, up to the C-level, think otherwise.

So, I think every developer should look into the AI hype. In this blog post, I will first share my thoughts on productivity gains through AI. In addition, I want to point to some aspects of AI, I believe we should talk more about.

My thesis about productivity gains by AI

I believe, AI has the capability to make us more productive. It can support brainstorming, offer implementations and architecture ideas, or give hints for issues in code. It can speed up the actual coding with auto-completions and do stuff in agent mode.

However, the initial coding is only a small part of software development. I am curious to see how the maintenance and further development of AI-assisted code will turn out. Will technical debts become a huge burden, requiring time-consuming and expensive software modernization projects? Or will AI become so good that it can still implement new features in its own mess? I suspect the former.

From my point of view, it is still a good trade-off. I believe, the biggest hurdle for software development is to create useful, impactful software and evaluate it as early as possible in the market. Once, the market is better understood and software is adopted by customers, software modernization projects are doable and economical viable. AI helps us, to do the first part faster, which is very valuable. For the second part, it probably is also a helpful tool.

Further resources I recommend reading:

In MIT Economics, Nobel-winning economist Acemoglu "estimates that over the next decade, AI will produce a “modest increase” in GDP between 1.1 to 1.6 percent over the next 10 years, with a roughly 0.05 percent annual gain in productivity."
According to DORA 2024 Accelerate State of DevOps "Early adoption is showing some promising results, tempered by caution." Organization-level performance is estimated to increase 2.3% per 25% increased AI adaption and team-level performance to increase 1.4% per 25% increase in AI adoption. However, software delivery performance seems to be negatively impacted by AI adoption. Effect on product performance seems to be unclear.
Based on a randomized controlled trial study AI might not increase performance at all for complex systems with experienced developers who are already familiar with the code.
Results of latest Stack Overflow's 2025 Developer Survey show increase in technical debts due to AI usage.
No, AI is not Making Engineers 10x as Productive

Points I think we should talk more about

Let's dive into points, I think we should watch critically.

Availability and purchase price?

AI usage for consumers is currently unbelievable cheap, as multiple companies are competing for market share. I assume that this is only a brief, temporary situation. Based on an estimation in cnbc Microsoft has lost $5 billion in 2024 with OpenAI. At some point, they will monetize their investment or stop offering it. There Is No AI Revolution is the most negative article I found, as a contrast to all the positive hype, expecting the latter.

Indirect costs of AI investments?

In addition to the direct costs, I also see indirect costs.

Resources could have been spent elsewhere

Research time and funding are limiting factors in the software industry. Putting a lot of time and money into AI tooling and adaption takes away resources from other projects. Are those AI initiatives really the best investment of time and budget? Or are we neglecting more impactful alternatives out of fear to miss the AI train and be left behind?

As a side note: Personally, the fear of being left behind, if we don't adopt AI right now, is fascinating to me. The barrier to entry for AI tools is amazingly low. Just write what you want to your AI chat. Read one or two blogs about best prompting practices, maybe watch a few videos and experiment what gives you the best results - that's it.

Not all (AI) features are good features

Some features just clutter up the user experience and negatively impact product value. For example, when I am looking for a new microwave, I immediately rule out those with more than 2 buttons; I just want to heat up my stuff and having to go through multiple button combinations is annoying.

AI opens the door to a lot of possible features. But just because you can integrate AI, doesn't mean you should. Let me point to Firefox's AI-enhanced tab groups. For me, it adds exactly zero value. On some computers, it led to massive CPU usage and energy drain. That does not only clutter up the user experience but actively hurts the usability.

Duolingo's AI-first bet

In April 2025, Duolingo announced plans to become an AI-first company. The immediate impact was a big increase in share value and a media shitstorm (designerly.com). Since then, the increase in share value has reverted, but the real revenue and user count seem to be stable, for now. How much of future change in revenue, user count, share value etc, can be tracked back to this decision is hard to tell. Certainly, the product decision is a fundamental change and it is unclear whether it will increase profitability, or cause users to leave the platform in the long-term. I prefer a more risk-less product development, when you already have a very successful product.

Security

AI agents enable a complete new spectrum of security attack vectors. For example as reported by msn.com, emails can contain invisible font instructions to tell the user, that his password was leaked and he should go to a malicious site and reset his password there. The user won't see nor read it. But an AI summarizing this email might alert the user to do as instructed. Even worse, if the AI can act on its own, it might directly leak your password as instructed. The underlying core problem is also called the the lethal trifecta for AI agents.

Besides some beliefs, AI-generated code is not free of security issues - quite the contrary: As summarized in this security incident a vibe coded feature led to a malicious release of well-established Nx build tool, leading to at least hundreds of infested computers.

Environmental and societal costs?

Research on the environmental impact of AI is in its early stage. But it is undeniable, that AI training and usage consume a lot of energy, critical raw materials and water, as for example reported in MIT News.

Research on the societal impact of AI is also in its early stage. But you don't need much imagination to see that misinformation strengthened by AI can disrupt democratic processes or that the accumulation of capital and power in the hands of a few AI companies can worsen global inequality. See for example originality.ai/blog for more on it.

Legal risks

In a landmark copyright case, Anthropic has agreed to pay $1.5 billion to authors as compensations for using pirated content as training data. This settlement is focused on the pirating part and does not resolve the general copyright issue around generative AI. But it does point toward a direction, that compensation for copyright is needed and that it will costs billions of dollars.

Another open question is whether the creator of an AI can be held legally accountable for the output of the AI. A Professor from Aarhus University shares in this article his concern "that probability of the hypothesis of generative artificial intelligence chatbots fueling delusions in individuals prone to psychosis being true is quite high. If it is indeed true, we may be faced with a substantial public (mental) health problem". A recent, most tragic case is a lawsuit filed by the parents of a 16-year-old against OpenAI's ChatGPT. Their son chatted about his suicidal condition for two weeks. He got reinforced by the chat and ChatGPT even gave further tips how to take his life. The boy sadly, finally took his own life.

With all those challenges and uncertainties, why the mega hype?

I value AI as another tool and look forward to working with it more in the future. Am I afraid of missing out on something important, or am I afraid of being overtaken by AI technologies? No, I view the hype with great confidence and distinguish between a "good" and a "bad" hype.

The "good" hype

Products with AI's current capabilities already have the ability to earn a lot of money:

I use AI almost daily at work and have experimented with agent coding. It already makes me more productive and I am curious about future improvements. So, I happily pay for the services. Right now, I am paying a small amount of money for it. Imagine at what price I, you or your company would stop paying for the services and hire expensive employees instead?
semruch.com predicts AI search visitors to surpass traditional search visitors in 2028 and the average AI visitor is worth more than 4x the traditional organics search visitor. To make these figures more tangible: Google ad revenues from search alone in 2023 is reported by oberlo.com to be over $175 billion.
Imagine, AI can analyse biological patterns better than humans and help with research for new medicine. Maybe even cure more types of cancer. As summarized in Wikipedia the healthcare industry is one of the world's largest industries consuming over 10 percent of GDP of most developed nations - a huge financial potential.
...

The "bad" hype

My thesis is, that the great progress of LLMs arrives at a time, when many managers are frustrated that their software projects are neither on schedule nor within the budget, while developers are a major cost driver. That is why there is a great desire for LLMs to actually get the job done much cheaper and better than the current status quo.

In addition, our free market demands growth. AI promises exactly that, making it very attractive to investors.

As a further booster, content creators on social media earn money by content views. Click-baits like "This new model is so unbelievable, all developers will be unemployed soon" seem to generate a lot of clicks and can be done again almost every week with the next unbelievable model.

All this over-fuels the hype surrounding the promises of AI.

Final words

In my opinion, AI offers amazing new capabilities and we would be fools to not embrace them and experiment with them. However, AI is not a free, magic tool, which will make all our expertise worthless.

What are your thoughts? I am looking forward to your comments!

My opinion about opinionated Prettier: 👎

shaman-apprentice — Thu, 02 May 2024 21:12:39 +0000

Let's first remember, that there is not only black and white. Like almost everything, Prettier comes with pros and cons. If it's a good or bad trade-off depends on you and your environment.

This blog post has the following structure:

Gains I see
Costs I see
Return on investment I see (only blurry)
My conclusion

Gains I see

Consistent, well formatted code is easier to read.
Consistent formatting reduces diffs in pull requests, speeding them up.
Creating a custom formatting style guide in your team is an investment of time. Even worse, it can lead to personal frustration when your preferred style gets rejected. Different custom style guides in different teams are annoying. When you use Prettier, you don't have to invest any time, as Prettier enforces its style. Formatting will be the same for every team. Furthermore, personal frustration should be reduced, as you get overruled by a library with a huge community.
Prettier can be your one solution for formatting all your web stack (.ts, .html, .css, .json, ...).
Every formatting violation can be automatically fixed by Prettier.

Costs I see

Prettier enforces rules without mercy and common sense. Sometimes, it makes formatting worse for me. For example, the following snippet is kept by Prettier:

ngOnInit(): void {
  fromEvent(document, "click").pipe(
    scan((count) => count + 1, 0),
    filter((count) => this.magicDocument.isMagicNumber(count)),
    tap((count) => this.magicDocument.pullBlueMagicRabbitOutOfTheHat(count)),
  );
}

But when I subscribe, it gets formatted to:

ngOnInit(): void {
  fromEvent(document, "click")
    .pipe(
      scan((count) => count + 1, 0),
      filter((count) => this.magicDocument.isMagicNumber(count)),
      tap((count) =>
        this.magicDocument.pullBlueMagicRabbitOutOfTheHat(count),
      ),
    )
    .subscribe();
}

Why is the pipe now on its own line, giving every operator within an extra level of indentation? Is it really an improvement, that the max line length is honored, but now, the tap has a different horizontal and vertical alignment than the other operators? No matter what the answers to those questions are, it's not helpful, that Prettier forces me to switch the formatting depending on the existence of the subscription in the last line.

Or let's look at the following two snippets formatted with Prettier:

<section class="user-container">
  <section class="...">...</section>

  <section class="user-privacy-settings">
    @for (privacySetting of privacySettings; track privacySetting.identifier) {
      <div>...</div>
    }
  </section>
</section>

and

<section class="user-container">
  <section class="...">...</section>

  @if (user.isAuthenticated) {
    <section class="user-privacy-settings">
      @for (
        privacySetting of privacySettings;
        track privacySetting.identifier
      ) {
        <div>...</div>
      }
    </section>
  }
</section>

Because I decided to only show the privacy settings, when the user is authenticated, the for loop now spans 4 lines. I find the one-liner easier to read, although it is one character over the max line length.

Of course, you might argue, that I should refactor the code anyway. So, Prettier puts pressure on me when to refactor and when to go quick and dirty. Which might be a good or a bad thing depending on context, in my opinion.

Prettier is a further tool in your toolchain. Every used tool has a risk of impacting your development. For example,
- when I wanted to use Angular's new template syntax, I was initially blocked by Prettier, as it formatted the new syntax horribly.
- the technical decision how Svelte should treat self-closing html elements was hindered by Prettier:
  
  Ideally we would also disallow self-closing void elements (i.e. rather than ), but whether or not this is realistic depends on whether Prettier's current habit of adding an unnecessary /> to void elements prevents us from doing that.
- From my point of view, Prettier doesn't work well for styling with utility classes. For a discussion see Prettier#7863 or Prettier#5948.

Return on investment I see (only blurry)

How much time and energy can be saved by good formatting? How much time and energy do you have to invest for the savings?

I think the gains are pretty low. That spacing, quotes, etc. are formatted uniformly is nice. But the extra complexity added by non-uniform formatting for reading code or pull requests is marginal.

The costs are also pretty low. A tool like Prettier is performant enough to run every time you save a file. When you manually honor the formatting, the time is negligible compared to your overall working time. The only risk I see is, that you might burn emotional energy for potential marginal savings with discussions about something like single or doubled quotes.

My conclusion

When a project has already decided to use Prettier, I wouldn't rebel against it. I think the potential gain from reopening the topic isn't worth the energy used for the discussion.

But when I have free choice, I will not use Prettier. I claim, that I can do a better job with formatting code to be well readable than Prettier. At the latest when a technical decision is influenced by Prettier, I am convinced that freedom in any technical choice is more valuable than the advantages of Prettier.

Currently, I am using ESLint for formatting of basic things like spacing and quotes. However, those rules were deprecated with v8.53.0 and moved to @stylistic/eslint-plugin. But they recommend Prettier or dprint.

I am curious for new best practices. All trade-offs might change over time with new tools, new experiences and inputs from following developers. So please share your thoughts in the comments.

My journey and experienced trade-off with Tailwind CSS

shaman-apprentice — Thu, 21 Mar 2024 19:02:29 +0000

In this article I will summarize my experience with Tailwind CSS. Why I have chosen it and why I have ejected it again after a while.

Motivation

I was in the lucky position to start a new web project. For styling I want to utilize utility classes.

My expectations for utility classes were:

Naming things is hard. It takes time and effort. Bad chosen names make maintenance harder. Don't have to think about names like some-wrapper-for-whatever-reason and have to maintain them, should save time and energy to be more productive.
Switching contexts and mapping between them is exhausting. Switching from and mapping between an HTML and a CSS file seems like a small thing. But I believe that the amount of contexts a programmer has to manage in his head is a bottleneck for good coding. Every little bit helps.

My expectations for Tailwind CSS were:

It should help to get started quickly, as I don't have to create all utility classes by myself.
It should ensure a standardized naming scheme for utility classes, as it is a well battle-tested library.
It should protect me against zombies of once created but after a while unused utility classes, littering my CSS.

Experienced pros

So let me wrap up my experienced pros:

Utility classes let me code quickly new components and glue them together.
IDE support in VS Code is great. Tailwind CSS IntelliSense supports autocomplete, linting and inline translation of applied CSS rule.
It offers more than plain utility classes. For example, instead of box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1) you can apply class name shadow or for box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); you can apply class name shadow-md. This is nice for two reasons. First, shadow and shadow-md are good short names. Second, the resulting shadow looks nice and saved me a few minutes of experimenting for myself with shadow values.
The integration of Tailwind CSS into the build system ensures, that only class names, that are actual used, are included in the production build. A view observed falsely integrated class names are negligible.

Experienced contras

Unfortunately, as far as I know, there is no golden bullet to catch them all in Software Architecture no matter the topic, but everything is a trade-off. Here are the contras I experienced with Tailwind CSS:

Let me start with an example: <section class="grid w-full grid-cols-[1fr,min(var(--width),100%),1fr] place-items-center gap-y-4 [&>*]:col-start-2">...
- This is quite long. I have to read my code many times (and yes, HTML is code as your JavaScript is or as your CSS is). Every time I am looking for something in my HTML, I get distracted a little by this amount of code.
- How should I format this code? In general I think a line length of 80 character is good for readability. We have already crossed that limit without even adding colors, colors for dark mode, ... So how do we split it up? How is it compatible with my existing formatting tooling like Prettier? So formatting is something I have to spent more time and energy on.
- One alternative for too many utility classes is to use them only, when you need a few. Use traditional classes otherwise or even combine them. For now, I think this is a good idea. But to be honest, it's a trade-off. You have to wonder how many are too much and you have to search for styles in two places.
- grid-cols-[1fr... or [&>*] are extra syntax I have to learn and remember, when writing and later reading this code.
- When some styles don't work as expected, the output in the DevTools is bloated. The rule [&>*]:col-start-2" gets compiled to .\[\&\>\*\]\:col-start-2>* { grid-column-start: 2; }. In addition, there are a lot of small rules in the styles section and a ton of never used CSS variables.
Tailwind CSS adds build complexity (as a side note, I now think Tailwind CSS is a framework and not a library, as it forces you to integrate a specific build configuration):
- It needs a configuration file, which feeds a PostCSS plugin under the hood.
- It increased my build time by almost 10 seconds.
- I have a shared Angular component library and a consuming app. Enabling sharing of generated class names needed extra thought. Hot reload of Tailwind CSS class names doesn't always work, decreasing my development feedback cycle. I am not sure, if this is a misconfiguration on my side, or a problem with Angular's and Tailwind CSS's compatibility. No matter what, debugging a "it works sometimes" problem always sucks and I haven't figured out that one so far.
- Native CSS Nesting requires an extra Tailwind plugin - what makes it not very native to me.
I am not perfectly happy with all Tailwind CSS naming schemes. For example, I think content-center should be named align-center to align with the other flex direction, which is named justify-center in Tailwind CSS. Or I think text-base should be named text-4 to align with p-4.

Sum up

I think utility classes speed up your development and can help you with maintenance, if you don't overuse them. My opinion to Tailwind CSS is, that it adds more contras than pros and therefore, I am going to eject it from my project.

Final kudos to Tailwind CSS

I am grateful for Tailwind CSS. It helped me to get quickly started with utility classes. There is a lot of good documentation and reasoning about utility classes in Tailwind CSS's documentation and related resources.

And the best part is, I always knew that I can eject it easily. I can just generate all current class names via npx tailwindcss -o utility.classes.css, include the plain CSS file in my project and refactor class names however I want later.

ADR applied exemplarily to the choice of frontend framework

shaman-apprentice — Sun, 03 Mar 2024 19:00:53 +0000

What the heck is an ADR? Do we really need to deal with another buzzword? Why should we create yet a further document?

Motivation

Let's consider the following fictitious and simplified scenario as motivation: After 15 years, a customer wants to have his desktop application available as web page. This is a huge project. A new dev is hired for this and future projects. There is a kickoff with the customer's dev and PO, as well as sales and the new dev from your company. Among others, there is this little dialogue:

Customer PO: In which framework will you implement the web page?
Sales: Angular, right?
New dev: Yes.
Customer's dev: Really? But Angular is old and insert your favorite framework is much better nowadays!
Sales: Yeah, but Angular is a great fit for our needs, because *he looks intensively at the new dev
New dev: Uhm, we already have two internal applications written in Angular, right? So we will use Angular for this project as well.

Probably no one is really satisfied with this answer. The new dev asks his colleagues afterwards about the choice of Angular:

Colleague 1: I don't care about the framework, as long as you get the job done. Using another framework than the one we already use needs probably time. So, I don't think it's feasible to use another.
Colleague 2: We have always used Angular. But I am not too happy with it and I would love to try out another, newer framework.
Colleague 3: I don't like frontend development in general. I don't want to work with Angular and I don't know why we have chosen it. The guy who picked it, has already left the company.

All this feels frustrating. Although there weren't any real arguments against Angular so far. Let's make an ADR (Architectural Decision Record) and see how it helps us.

ADR 2023-12-30: Choice of frontend framework

Status: Accepted
Decision: We will use Angular
Contributors: Dev 1, dev 2, dev 3, sales colleague 1

Context

We need to choose a frontend framework for the new project. Further web projects are expected in the near future. All those web projects will be long-lived products, meaning we expect to add features and maintain them for the next 10 years at least.

Our team has already developed two small to medium sized Angular applications.

Decision's reasoning and consequences

Angular is a modern frontend framework with stability and long-time support at its core. We already have Angular expertise in our team. It is easy to extract code from our existing Angular applications into a shared library for code reuse in new projects. The existing applications will likely also benefit from the development of new code for the new project, which can be done in a shared library as well.

The fact that React has more third-party libraries available is not a problem for us. Our customers have very specific requirements and we expect that we have to develop most components by ourselves for maximal customization.

We are excited about Angular’s upcoming renaissance. Whether the renaissance will defend Angular's current second place as most used frontend framework is too early to tell. However, based on Angular's long road so far, we assume that Angular will continue to release new features, which will be easy to integrate in our code and keep our web development competitive for a long time.

We accept a high learning curve for new colleagues, which can be neglected compared to overall project time.

Options

Angular

Angular has been around since 2010 and new versions are regularly released. It is Open Source although it is developed by Google. Backwards compatibility and upgradeability have always been an important goal of Angular. It has a big community and is adopted by many big companies. Its two-way data binding and dependency injection model provide good modularity and testability.

In terms of developer interest, Angular wasn't the most famous in 2022. It has a high learning curve for beginners. Angular's default testing framework Karma was deprecated and there is no stable official replacement yet. Angular 17 addresses many of recent critics and describes itself as a renaissance.

React

React has been around since 2013 and new versions are regularly released. It is Open Source although it is developed by Meta. It has a huge community and probably the most third party libraries of all frontend frameworks. Its JSX based syntax is easy to learn. As Facebook is build upon React, it is obviously possible to build a large long-lived application with it.

Apart from a component-based approach, architectural decisions are left to developers. The state has to live within the React lifecycle, which can make separation of concerns harder. The hook based API is elegant to write but can become challenging to debug and maintain. Backwards compatibility between versions is not a major concern.

Other frameworks

We are aware that there are many other frameworks such as Vue, Svelte, Qwik, Preact, LitElement, ... Each has its own advantages and disadvantages. We don't want to invest much time in them for now, because: First, we believe that every modern frontend framework has the features we need for our projects. And second, long-term support is very important to us. Regarding the second, React and Angular are the longest available modern frontend frameworks and therefore the most interesting fits on first sight.

What have we gained through above ADR?

So we invested time in creating the ADR and added another document to our pile of documents somewhere. Let's evaluate the return to make sure this was a good investment.

An ADR makes a decision explicit. Furthermore, it gives everyone the opportunity to contribute, as it is a public document forged by or at least accepted by the full team. The dialog from the motivation section will not bother much. The feeling that maybe it wasn't a good choice, becomes an informed decision, that everyone can look up.

It also helps with future evaluation. When the expected advantages don't materialize, or the context changes, you can do a new ADR superseding the previous one, based on your learnings.

Two final things to note

First, the options were obviously not complete nor an in-depth analysis. The question of how much time you should invest is difficult to answer and depends on the context. E.g. frontend technologies are rapidly developing. New hyped frameworks frequently occur. If you spent too much time in your research, chances are high that a new framework was published in the meantime. Jokes aside, depending on the context, expected gain and your resources, I think it is OK to spend a few hours for an ADR or even a full sprint.

Second, when searching the internet, there are tons of different templates for ADRs. Some claim ADRs should be in plain texts. Others prefer tables and yet others bullet points. I think it is nice to have a common template, as it will help you to read them faster - just stick with a format that suits you.

Forem: shaman-apprentice

The Component Library is dead, long live the Component Library

The starting situation

AI tools for the rescue?

How will the future evolve?

Software engineering is an interwoven part of the loop

TLDR - My key takeaways

1. What are we building?

2. Exploration and feedback loops

3. Engineering excellence

Final call-out

AI-assisted Test Driven Development Experiment Quick Takes

Quick takes

Did the project create real value?

Can AI produce production code from start to finish without senior supervision?

Footnotes

AI is amazing — but let's keep our critical thinking on

My thesis about productivity gains by AI

Points I think we should talk more about

Availability and purchase price?

Indirect costs of AI investments?

Resources could have been spent elsewhere

Not all (AI) features are good features

Duolingo's AI-first bet

Security

Environmental and societal costs?

Legal risks

With all those challenges and uncertainties, why the mega hype?

The "good" hype

The "bad" hype

Final words

My opinion about opinionated Prettier: 👎

Gains I see

Costs I see

Return on investment I see (only blurry)

My conclusion

My journey and experienced trade-off with Tailwind CSS

Motivation

Experienced pros

Experienced contras

Sum up

Final kudos to Tailwind CSS

ADR applied exemplarily to the choice of frontend framework

Motivation

ADR 2023-12-30: Choice of frontend framework

Context

Decision's reasoning and consequences

Options

Angular

React

Other frameworks

What have we gained through above ADR?

Two final things to note

Interesting Sources