I Got Tired of Manually Sizing Skeleton Loaders in Angular, So I Built a Directive for It

Sachin Kizhakkepurath — Tue, 23 Jun 2026 02:47:08 +0000

We've all been there.

You're building a loading state for a page, and you decide to add skeleton loaders to improve the user experience.

The implementation seems straightforward at first.

<div class="skeleton" style="width: 300px; height: 40px;"></div>

Then you add another one.

And another.

Soon you're manually matching widths and heights to buttons, cards, profile sections, tables, and every other UI element in your application.

The problem isn't that it's difficult.

The problem is that it's repetitive.

And repetitive problems usually deserve better solutions.

The Idea

While working on Angular applications, I kept asking myself:

Why should I have to tell a skeleton loader how big it should be when the host element already knows its own dimensions?

Instead of manually configuring every skeleton, what if the skeleton could simply adapt to the size of the element it replaces?

That idea became skedapt.

An Angular directive that automatically generates skeleton loaders based on the dimensions of the host element.

What It Looks Like

Instead of creating separate skeleton components and manually managing dimensions:

<div [skedapt]="isLoading">
  Content goes here
</div>

When isLoading is true, skedapt automatically generates a skeleton loader that matches the dimensions of the host element.

No manual width.

No manual height.

No extra setup.

Goals Behind the Package

When building skedapt, I wanted it to be:

Zero Configuration

Install it and start using it immediately.

Host Element Adaptation

The skeleton should automatically adapt to the element's size.

Minimal Boilerplate

Developers shouldn't have to write extra CSS or duplicate layouts.

Theme Friendly

Support customization through CSS variables so applications can easily match their existing design systems.

Built-in Shimmer Effect

A loading state should look polished without requiring additional configuration.

Technical Challenges

Building the package turned out to be a great learning experience.

Some of the areas I explored included:

Angular library development
npm publishing workflows
Runtime style injection
Directive API design
Theme-aware styling
Reusable UI utilities

One of the most interesting parts was figuring out how to dynamically generate skeleton styles at runtime while keeping the developer experience simple.

Why Open Source?

I originally built this to solve a problem for myself.

But after using it across multiple projects, I realized other Angular developers might be dealing with the same frustration.

Publishing it as an npm package felt like the natural next step.

Try It Out

If you're interested in giving it a try:

npm

https://www.npmjs.com/package/skedapt

GitHub

(Add your repository link here)

I'd love to hear feedback, suggestions, or ideas for future improvements.

Final Thoughts

This is my first published npm package.

It's a small project, but it represents something bigger for me.

Not just writing code for applications.

Building tools that help other developers write less code.

And that's a journey I'm excited to continue.

Thanks for reading 🚀

After 3 months of AI doomscrolling, I realized most developers are worried about the wrong things.

Sachin Kizhakkepurath — Mon, 01 Jun 2026 09:21:27 +0000

For the last few months, I've been reading AI papers, watching demos, testing ChatGPT, Claude, Cursor, Copilot, and generally trying to figure out what AI actually means for developers.

Like a lot of people, I started from a place of anxiety.

Every week there seemed to be a new headline:

AI writes code
AI builds apps
AI replaces engineers
One developer can now do the work of ten

The more I dug into it, the more I noticed something interesting.

AI is incredibly good at generating answers.

It's much less good at figuring out what question should be asked in the first place.

That's the part many discussions miss.

In my day-to-day work, the hardest problems are rarely about writing code.

They're usually things like:

Understanding vague requirements
Figuring out what stakeholders actually want
Deciding between multiple imperfect solutions
Navigating technical debt
Balancing business constraints with engineering quality

These are fundamentally context problems.

AI can help with them, but it doesn't own them.

Another thing I realized is that experienced developers often underestimate how much domain knowledge they've accumulated.

When I look at a piece of code, I'm not just reading syntax.

I'm thinking about maintainability, edge cases, customer impact, previous incidents, team conventions, performance tradeoffs, and future changes.

A language model can generate code.

It doesn't have years of accumulated context about why a particular decision matters.

Ironically, AI has made me value human skills more, not less.

Communication.

Judgment.

Problem framing.

Understanding people.

Those things have become more important because the mechanical part of coding is getting cheaper.

My current view is that developers who learn to use AI effectively will probably become much more productive.

But I don't think the biggest risk is AI replacing developers.

I think the bigger risk is developers assuming that writing code was the entirety of their value.

Curious how other people are thinking about this.

Have AI tools changed your view of what makes a good developer?

DEV Community: Sachin Kizhakkepurath