DEV Community: hardik kuwar

Hearth: I turned my habits into literal fires that die if I ignore them

hardik kuwar — Sun, 12 Jul 2026 14:48:33 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Hearth is a campfire for the things you care about.

Every passion you're tending (the gym, a book, a side project, a skill you keep meaning to learn) is a literal fire on screen. Spend time on it and log the minutes ("add a spark"), and the flame grows. Ignore it and it slowly sinks down to embers. It never fully dies though, which felt important. Real passions don't either. One spark and it's back.

The idea came from the Olympic flame. They light the cauldron at the opening ceremony and it burns for the whole games, and every win along the way feels like it's feeding that one fire. I wanted that for ordinary life: my gym sessions and reading nights as small victories thrown into a flame that's mine. Every habit tracker I've tried does the opposite. It guilt-trips me with grey squares and broken streaks. So instead of a grid, you get a night scene with your fires burning along the ground, and a big central flame (labelled "You") that every one of them feeds, like a personal cauldron.

A few things it does:

Warmth decays on a half-life, in real time. A daily habit cools in about 3.5 days, but a monthly one (like "learn a new skill") stays warm for weeks, because punishing a monthly goal on a daily clock is just mean.
Streaks understand cadence too. Gym counts consecutive days, "build a product" counts consecutive weeks, so a weekly flame doesn't show a permanent streak of zero.
Optional fire crackle sound, and the volume actually follows how warm your hearth is. A dying hearth gets quiet.
Respects prefers-reduced-motion with a calm, still render instead of the particle animation.
Everything lives in localStorage. No accounts, no server, nobody's dashboard.

Demo

https://hardboyyy.github.io/hearth-fire/

Quick tour: open it, and the left panel explains the metaphor. Five starter fires are already laid out (gym, reading, coding practice, building a product, learning a new skill). Click one, log 30 minutes, and watch it flare up.

Code

https://github.com/hardboyyy/hearth-fire

How I Built It
Three files: index.html, style.css, script.js. No framework, no build step, no dependencies. You open the HTML file and it runs.

The fire is a little particle system on a canvas. Each flame keeps spawning glowing dots that rise, drift in a fake wind, and fade out. The more you've tended a fire, the more and bigger the particles, so a healthy fire literally burns taller.

The math is one idea: every logged session is a spark worth its minutes, and that value halves on a schedule (every 3.5 days for daily habits, slower for weekly and monthly ones). Add up the sparks and you get the fire's warmth. Fires cool on their own, old effort never quite reaches zero, and a single fresh spark visibly revives a dying flame.

Streaks work by turning dates into simple numbers (day number, week number, month number) and checking they run consecutively. That's how one loop handles daily, weekly and monthly habits.

A few console.assert checks run on every page load to make sure the decay and streak math still behaves. Not a test suite, but it's caught me twice already.

With another weekend I'd add editing a fire's cadence and maybe a gentle "this fire is getting cold" nudge. But the whole point is that the app doesn't nag you. The fire just gets smaller, and somehow that's more motivating than any notification.

𝗠𝗼𝘀𝘁 𝗖𝗦𝗦 𝘀𝗽𝗮𝗰𝗶𝗻𝗴 𝗯𝘂𝗴𝘀 𝘀𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗼𝗻𝗲 𝗯𝗮𝘀𝗶𝗰 𝗰𝗼𝗻𝗳𝘂𝘀𝗶𝗼𝗻: 𝗽𝗮𝗱𝗱𝗶𝗻𝗴 𝘃𝘀 𝗺𝗮𝗿𝗴𝗶𝗻.

hardik kuwar — Wed, 24 Jun 2026 16:50:41 +0000

At first, both seem to do the same thing —
they both create space.

So it’s easy to assume you can use either one.

But that’s exactly where layout bugs start.

Because if you don’t understand where the space is being added, your UI starts behaving in weird ways.

𝗧𝗵𝗲 𝘀𝗶𝗺𝗽𝗹𝗲𝘀𝘁 𝘄𝗮𝘆 𝘁𝗼 𝘁𝗵𝗶𝗻𝗸 𝗮𝗯𝗼𝘂𝘁 𝗶𝘁 👇

• Padding → adds space inside the element
• Margin → adds space outside the element

That’s it.

But that one distinction solves a surprising number of frontend bugs.

𝗤𝘂𝗶𝗰𝗸 𝗲𝘅𝗮𝗺𝗽𝗹𝗲

Imagine you have a card with a button inside it.

If the text inside the button feels too close to the edges,
you need padding.

If the button itself is too close to the next section or the card below it,
you need margin.

𝗧𝗵𝗲 𝗿𝘂𝗹𝗲 𝗜 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝗳𝗼𝗹𝗹𝗼𝘄

• If the content inside an element feels too tight → use padding
• If two elements are too close to each other → use margin

Simple rule.
But it clears up a lot of CSS confusion.

𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿𝘀

A lot of CSS bugs are not actually “hard CSS problems”.

They come from misunderstanding inside spacing vs outside spacing.

And once you get this right, your layouts become much easier to reason about.

What CSS concept confused you the most when you started frontend?

One of the Most Expensive Engineering Mistakes? Letting Dependency Updates Pile Up

hardik kuwar — Wed, 24 Jun 2026 16:11:00 +0000

Most dependency debt doesn’t start with negligence.

It starts with a project that feels stable.

The app is working, the team is shipping features, and nobody wants to risk touching packages that “already work.” So dependency updates get postponed. Not forever — just until there’s more time.

Then one day someone tries to update a package that’s two or three years behind.

And what should have been a small maintenance task turns into a mini migration project.

One upgrade breaks another.
Peer dependency conflicts start appearing.
Deprecated APIs stop working.
Build issues start eating hours that should have gone into shipping features.

At that point, the problem is no longer “we need to update a dependency.”

The problem is that the team has let dependency debt build up long enough that a routine upgrade is no longer routine.

Why delayed dependency updates get expensive

The cost of delaying updates is rarely visible in the moment.

That’s why teams keep doing it.

Nothing looks broken. The product still works. Customers don’t care that a UI library or test runner is behind by a few versions. So upgrades get pushed below feature work, bug fixes, and deadlines.

The trouble starts later, when the team finally has a reason to update.

By then, the ecosystem around the project has already moved on.

And that’s the key issue: dependencies don’t evolve in isolation.

In frontend projects especially, package ecosystems are tightly connected.

A framework upgrade may affect:

your UI library
testing setup
linting plugins
build tooling
TypeScript compatibility
internal wrappers built around older APIs

So when a project is years behind, you’re rarely updating one package. You’re stepping into a chain of upgrades.

A realistic example of how this happens

Imagine a frontend team working on a SaaS product.

The app has been stable for a while, so dependency updates keep getting pushed. There’s always something more urgent: a launch, a bug fix, a customer request, a redesign.

For two years, the team delays most major dependency work.

Then they decide to upgrade one important package — maybe React, maybe a framework dependency, maybe a UI library they need to modernize.

The expectation is simple: update the package, fix a few things, move on.

Instead, the upgrade starts pulling other work with it.

The newer React version forces changes in the testing setup.
The UI library has breaking API changes.
Some ESLint plugins no longer support the old configuration.
A few internal components were built around deprecated behavior and now need refactoring.
Build tooling starts surfacing compatibility issues that were hidden before.

What looked like a small update becomes weeks of cleanup, retesting, and cautious releases.

Nothing catastrophic happened. The team didn’t make a terrible engineering decision.

They just let routine maintenance drift long enough that the cost came due all at once.

This is why “we’ll update it later” becomes expensive

The real problem with dependency debt isn’t just outdated packages. It’s upgrade shock.

Small, regular updates usually mean you’re dealing with a smaller set of changes:

fewer breaking changes
fewer compatibility issues
less code to refactor at once
lower release risk

Delayed upgrades do the opposite.

Now you’re crossing multiple release cycles in one shot. You’re dealing with several rounds of breaking changes, deprecated APIs, tooling shifts, and migration requirements all at once.

A normal maintenance task turns into a project.

That’s why delayed upgrades feel so expensive: not because updating is bad, but because you compressed too much change into one event.

That doesn’t mean you should update everything constantly

This is where the conversation usually gets oversimplified.

I’m not saying teams should blindly update every dependency every week. That creates a different kind of noise.

Updates still need time, testing, and judgment. Some packages matter far more than others. And sometimes a major version bump genuinely deserves planning instead of being merged casually.

The goal isn’t “always be on the latest version.”

The goal is to avoid letting dependency maintenance become a once-a-year rescue mission.

A practical team approach that works better

What has worked much better for teams in the long run is a simple rule:

treat dependency maintenance as recurring engineering work, not cleanup work.

That usually means a few things.

1. Watch the dependencies that can create real upgrade pain

Not every package needs the same attention.

Focus more on dependencies that are deeply tied to the app:

framework dependencies
UI libraries
build tooling
test tooling
TypeScript / linting ecosystem
data/state libraries that are widely used across the codebase

These are the packages most likely to create upgrade debt if ignored for too long.

2. Prefer small regular updates over rare catch-up upgrades

A lightweight monthly or quarterly dependency review is usually far safer than waiting until the project is years behind.

Not because every update is urgent.

But because smaller upgrade windows keep the surface area of change manageable.

3. Budget a little maintenance time before it becomes emergency work

If dependency work only happens “when there’s time,” it usually won’t happen until there’s pain.

Teams don’t need a huge maintenance program for this. They just need enough recurring space that upgrades don’t get ignored indefinitely.

4. Don’t batch everything into one giant modernization effort unless you have to

When multiple major upgrades move together, testing gets harder, rollback gets harder, and the blast radius gets bigger.

If you can keep upgrades more isolated, you keep control.

The real value of staying reasonably up to date

Yes, you get the obvious benefits:

newer features
performance improvements
security fixes
better docs and ecosystem support

But the bigger benefit is flexibility.

A codebase that stays reasonably current is easier to evolve when product priorities change. You’re not forced into a painful dependency catch-up project every time you want to adopt a newer tool, upgrade your framework, or modernize a part of the stack.

You preserve momentum.

And in long-lived products, that matters a lot.

Final takeaway

Small dependency updates feel annoying because the app already works and there’s always something more urgent to do.

But when those updates keep getting postponed, the cost doesn’t disappear. It compounds.

And eventually, a routine version bump turns into a migration project that steals time from the roadmap.

So no — I’m not arguing for constant dependency churn.

I’m arguing against waiting so long that a normal upgrade becomes a painful one.

Small regular updates feel annoying.
Big delayed upgrades feel brutal.

The mistake is assuming data shape and state shape should always match

hardik kuwar — Mon, 22 Jun 2026 16:32:07 +0000

When you first build a form in React, putting everything into one big state object feels like the cleanest option.

It mirrors the UI nicely.
Personal info goes under personalInfo.
Address fields go under address.
Education, projects, company details — each section gets its own nested object.

At that stage, it feels organized. Maybe even “well structured.”

Then you try to update a single field.

Not the whole form. Not even a section. Just one field — say city.

And suddenly a simple update doesn’t feel simple anymore.

To change that one value, you often have to recreate the top-level form object, then the nested address object, and only then the city field itself. What should have been a tiny change starts feeling oddly heavy.

That’s the point where many React forms begin to feel harder to maintain than they should.

And usually, the problem isn’t React. It’s the shape of the state.

Why this happens so often

Nested form state usually comes from a reasonable instinct.

If the form has clear sections, it feels natural to model the state the same way:

personal information
address
company details
education
projects

From a data modeling perspective, that looks neat. Related fields stay grouped together. The state object resembles the structure of the form on the screen. If you log it in the console, it looks clean and easy to understand.

The issue is that forms are not static data structures. They are interactive systems.

Users don’t update forms section by section. They update them field by field.

They type into one input.
They clear one dropdown.
They add one entry to a repeatable section.
They toggle one checkbox that changes another part of the form.

So the real question isn’t just “Does this state look organized?”
It’s “Does this state make small, frequent updates easy?”

That’s where deeply nested form state starts working against you.

The problem is bigger than verbose update code

The first pain point is obvious: nested state makes updates more annoying.

A small change often means copying multiple layers of objects just to preserve immutability. That alone is enough to make a form feel clunky to work on.

But the bigger problem is what comes after that.

As the form grows, nested state doesn’t just make updates verbose. It makes the entire feature harder to evolve. The complexity starts leaking into validation, rendering, component boundaries, and day-to-day maintenance.

In practice, it usually shows up in three ways.

1. Small changes start touching more state than they should

A user updates one field, but the code has to recreate multiple layers of the object tree to make that happen safely.

Technically, that’s expected. React state updates are immutable, so changing a deeply nested value means recreating every object on the path to that value.

The problem is not that React requires this. The problem is what it does to the developer experience once the form stops being small.

A simple update no longer feels local. It feels structural.

Instead of focusing on the actual behavior — updating a city, changing a salary, editing a project title — you spend more time thinking about where that field lives in the object and how much of the path needs to be recreated around it.

That friction gets expensive quickly because forms are one of the most frequently updated parts of a UI.

2. The mental model gets worse as the form becomes a real product feature

This is where the problem usually stops being “a bit annoying” and starts becoming architectural.

Small forms are forgiving. Product forms are not.

A form that begins with a few inputs often grows into something much more complex:

field-level validation
conditional sections
repeatable groups
draft saving
edit flows
autosave
live summaries
API transformations before submit
role-based or account-based behavior

Now imagine all of that sitting on top of one deeply nested formData object.

At that point, every new requirement has to fit into a structure that was probably designed around how the form looked in version one, not around how it behaves now.

And that’s when the mental overhead increases.

You’re no longer thinking only about what changed. You’re also thinking about:

where that value lives
which parent objects need to be recreated
which components receive that section of the form
whether another part of the screen depends on the same object
how much of the form is being passed around just to update one small part

That is the kind of complexity that doesn’t show up immediately. It accumulates quietly, then suddenly every small change feels more expensive than it should.

3. It can also become a rendering problem

This is the part that often gets oversimplified, so it’s worth being precise.

Deeply nested state does not automatically make a form slow. React is perfectly capable of handling nested objects, and not every nested update is a performance issue.

But nested state does make it easier to create unnecessary rendering work.

When you update a deeply nested value, you create new object references along the path to that value. Any component that depends on those recreated objects may re-render, even if most of the data inside them hasn’t meaningfully changed.

In a small form, that may not matter at all.

In a larger product form, it starts to matter more.

Think about a screen that has:

multiple sections mounted at once
inline validation running while the user types
a sidebar showing a live summary
conditional sections appearing based on previous answers
autosave in the background
reusable child components receiving slices of the form state

Now the cost of each update becomes more visible.

Changing one field should ideally affect the smallest possible part of the UI. But when state is deeply nested, it becomes easier for that one change to ripple through larger objects than necessary.

Again, the point isn’t “nested state is bad.” The point is that nested state often makes it harder to keep updates isolated.

A real example: where this starts hurting

Imagine you’re building a candidate profile form for a hiring platform.

The form includes:

personal details
current location
salary expectations
work experience
skills
education
notice period
portfolio and social links

At first, storing all of that inside one nested formData object feels reasonable. It’s one candidate profile, so one object sounds perfectly fine.

Then the product gets more sophisticated.

Salary validation changes based on location.
Work experience becomes repeatable and reorderable.
Notice period influences job recommendations.
A profile summary updates live on the side.
Autosave runs every few seconds.
Some fields are only shown for certain roles or account types.

Now the problem isn’t whether the object looks organized.

The real question is whether the state shape makes frequent, isolated changes easy to update, easy to validate, and easy to reason about.

That’s the moment when the original nested structure often starts feeling expensive.

The mistake is assuming data shape and state shape should always match

This is one of the most common traps in React form design.

Because the UI is grouped into sections, we assume the state should mirror those sections exactly. If the screen has an Address section, we create an address object. If it has Company Details, we create a companyDetails object.

That seems logical, and sometimes it is.

But form state should not be designed only around how the data is grouped. It should also be designed around how the data changes.

Those are not always the same thing.

A form may be visually divided into sections, but user interaction doesn’t happen section by section. It happens one field at a time.

That distinction matters more than it seems.

If the most common operation in a form is “update one field,” then your state structure should make that operation cheap and obvious. If it doesn’t, there’s a good chance the state is optimized for appearance rather than behavior.

Why flatter state often works better

A flatter state shape reduces the amount of state you need to touch for a small change.

That has a few practical benefits.

Simpler updates

Field updates stay closer to the actual change. You spend less effort recreating object paths and more effort implementing the behavior the form actually needs.

Easier maintenance

As validation, conditional rendering, and submission logic grow, flatter state is usually easier to debug and refactor because updates remain more localized.

Cleaner component boundaries

When you avoid passing large nested objects through the tree, it becomes easier to split the form into focused components that only depend on the data they actually need.

Better control over rendering

Flatter state doesn’t magically solve re-rendering problems, but it gives you more control over which references change and why.

That said, the goal is not to flatten everything blindly.

Some nesting is perfectly reasonable. If a piece of data truly belongs together, changes infrequently, and is always consumed as a group, nesting can be fine.

The problem is unnecessary nesting in parts of the form that change constantly.

A better rule of thumb: structure form state around change

One of the most useful frontend habits is this:

Don’t structure form state only around how the data looks. Structure it around how the data changes.

That changes the questions you ask.

Instead of only asking:

How should I model this form as one object?

Ask things like:

Which fields change most often?
Which sections are validated independently?
Which values are conditionally shown?
Which parts of the form are reused in multiple places?
Which updates should stay isolated from the rest of the UI?
If this form doubles in size, what becomes painful first?

Those questions usually lead to a more practical state shape than simply mirroring the visual structure of the form.

You may not notice this in a small form. You’ll notice it in a real one.

This is why nested form state can feel harmless at first.

A small demo form doesn’t put much pressure on the state structure. With a handful of fields and a single submit action, almost any approach can look fine.

Production forms are different.

They collect edge cases.
They accumulate validation rules.
They gain conditional logic, edit flows, partial saves, analytics events, and product requirements that were never part of the original plan.

That’s when state design starts to matter.

Not because React can’t handle nested objects.
Not because flattening is a universal best practice.
But because the cost of a state shape becomes visible when the form becomes a real feature rather than a tutorial example.

The simplest sign your form state needs a rethink

If updating one field feels more complicated than the value of the change itself, it’s probably worth revisiting your state structure.

Not because the code is ugly.
Not because every nested object is wrong.
But because that kind of friction tends to spread.

It shows up in validation logic.
Then in component boundaries.
Then in rendering behavior.
Then in future refactors.
Then in the time it takes a new developer to understand why changing one input touches three layers of objects.

That’s when a form stops being just a form problem and becomes a maintainability problem.

Final takeaway

Deeply nested state often feels like an organizational win at the start of a project. It keeps related data together and mirrors the form structure nicely.

But React forms are not static data models. They are interactive systems built around frequent, isolated updates.

And that changes what “good structure” actually means.

If a form is updated field by field, validated field by field, and rendered in pieces, then the state should support that reality.

So the next time a one-line change in the UI turns into a surprisingly awkward state update, don’t just blame the syntax.

Look at the shape of the state.

Because in React, if updating one field feels harder than it should, the form usually isn’t the real problem. The state structure is.