DEV Community: Kirill Chernenko

Stop importing locale bundles. The browser already knows how to say "3 hours ago" in Arabic, Japanese, and 200 other languages. "anywhen" wraps native Intl in 800b . Zero deps, zero config. npm install anywhen

Kirill Chernenko — Sun, 29 Mar 2026 08:30:25 +0000

Kirill Chernenko

Mar 29

Your browser speaks 200+ languages.

#webdev #npm #typescript #i18n

Comments

4 min read

Your browser speaks 200+ languages.

Kirill Chernenko — Sun, 29 Mar 2026 08:16:58 +0000

Let's say you're building a chat app. International. You're launching in Germany, Japan, and Brazil next quarter — because apparently that's the plan now, and you found out on a Tuesday afternoon.
You have a timestamp. A user was online 5 hours ago. You want to show that.
Simple.

In English: "5 hours ago"
In German: "vor 5 Stunden"
In Japanese: "5時間前"
In Brazilian Portuguese: "há 5 horas"

Or maybe you have an event. It's in two days. You want to say that.

In English: "in 2 days"
In Arabic: "خلال يومين"
In Turkish: "2 gün içinde"

Or just a date. March 25, 2026. Simple.

In English: "Mar 25, 2026"
In Russian: "25 мар. 2026 г."
In Chinese: "2026年3月25日"

None of this is hard to display. It's hard to display correctly, in the right language, without shipping a dictionary to every user.

The obvious solution that isn't great

You open dayjs. You find the locale system. You import German. Portugal... and over and over more.

import 'dayjs/locale/de'
import 'dayjs/locale/ja'
import 'dayjs/locale/pt-br'

It works. Three locales down, forty-seven to go — and you're not sure which forty-seven, because that depends on where the business decides to expand next.

Then someone asks for Arabic. Arabic has six plural forms — "1 hour ago", "2 hours ago", "3 hours ago" are all different grammatical structures. You import the locale file. Then Serbian. Then Korean.

Then there's a meeting where someone says "we should support all major languages" and you smile and nod and quietly go update your webpack config.

The locale bundle grows. The import list grows. Any better ideas?

My solution

Three functions. That's it. No classes, no configuration objects, no "please read the 40-page migration guide". Just install.

npm install anywhen

And use.

import { anydate, anywhen, anyago } from 'anywhen'

Each function answers one question you already ask yourself when writing UI.

anywhen — just make it readable

This is the one that thinks for you. You give it a date, it figures out what a human would actually say. Recent things get relative time. Yesterday gets "yesterday". Older things get a proper date. Future things get "in 2 weeks". You stop making these decisions in every component.

anywhen(date, 'en')   // "just now"
anywhen(date, 'en')   // "10 minutes ago"
anywhen(date, 'en')   // "today, 2:35 PM"
anywhen(date, 'en')   // "yesterday, 9:00 AM"
anywhen(date, 'en')   // "Wednesday, 11:20 AM"
anywhen(date, 'en')   // "Mar 5, 2016"
anywhen(date, 'en')   // "in 2 weeks"

The switching logic:

< 45 seconds   →  "just now"
< 1 hour       →  "10 minutes ago"
future > 1h    →  "in 2 weeks"
same day       →  "today, 14:35"
yesterday      →  "yesterday, 09:00"
< 7 days       →  "Wednesday, 11:20"
older          →  "Mar 5, 2016"

anydate — what's the exact date, just a formatter?

Maybe, but smart. For when you need a clean, localized date string. A post timestamp. An invoice date. A birthday. Something absolute that doesn't change based on when the user is reading it.

anydate(date, 'en')   // "Mar 25, 2026"
anydate(date, 'de')   // "25. März 2026"
anydate(date, 'ja')   // "2026年3月25日"
anydate(date, 'ar')   // "٢٥ مارس ٢٠٢٦"

Need more control? Pass any Intl.DateTimeFormat options:

anydate(date, 'en', { weekday: 'long', month: 'long', day: 'numeric' })
// "Wednesday, March 25"

anydate(date, 'en', { hour: '2-digit', minute: '2-digit' })
// "2:35 PM"

anyago — how long ago? how far ahead?

For when the exact date doesn't matter — the distance does. A comment was posted. An event is coming. A subscription expires. You want to say "3 hours ago" or "in 2 days", not "March 25, 2026 at 14:35:00 UTC".

anyago(date, 'en')   // "5 hours ago"
anyago(date, 'de')   // "vor 5 Stunden"
anyago(date, 'tr')   // "5 saat önce"
anyago(date, 'ru')   // "5 часов назад"

// works for the future too
anyago(date, 'en')   // "in 2 days"
anyago(date, 'ar')   // "خلال يومين"

Sometimes you don't want "yesterday" — you want "1 day ago". Just add flag true:

anyago(date, 'en', true)   // "1 day ago" instead of "yesterday"
anyago(date, 'en', true)   // "1 week ago" instead of "last week"

anywhere — same locale everywhere

If you're formatting multiple dates in one component, passing the locale every time gets old fast. anywhere binds it once.

import { anywhere } from 'anywhen'

const d = anywhere('de')

d.anydate(date)   // "25. März 2026"
d.anywhen(date)   // "heute, 09:00"
d.anyago(date)    // "vor 5 Stunden"

Locale set once and forgotten.

800 bytes. That includes every language.

What it doesn't do

Honest section. I like these.
No custom format strings like DD/MM/YYYY. No timezone handling (at least now).
No date arithmetic. No parsing of whatever creative format your backend decided to use in 2013.

The 7-day cutoff in anywhen — after which it shows an absolute date instead of a weekday — is fixed. If you need custom logic, use anyago and anydate directly and wire it yourself.

This library is for one specific thing:

displaying dates to humans in their language.

Chat timestamps. Event countdowns. Comment dates. Notification feeds. If that's what you need, it's 800 bytes and you're done. If you need to parse timezones or do date math — use date-fns. No shame in that.

Try it

Live demo where you can pick any method, any date, any locale and see the output: Demo page

Source is on GitHub. The whole thing is small enough to read in one sitting. If something is broken or missing — open an issue. I built this because I needed it, and I'm really curious whether other people do too.

Wrote up the whole process of rehabilitating an npm package I forgot for 5 years — TypeScript migration, CSS-in-JS regrets, Intl API revelation and why I now check bundle size more than my messages.

Kirill Chernenko — Fri, 27 Mar 2026 19:22:13 +0000

Kirill Chernenko

Mar 27

NPM Archaeology: 5 Years in the Ground, Still Breathing

#webdev #npm #react #opensource

Comments

4 min read

NPM Archaeology: 5 Years in the Ground, Still Breathing

Kirill Chernenko — Fri, 27 Mar 2026 19:05:37 +0000

Let me set the scene: It's a Saturday. Nothing particularly dramatic is happening. I'm just sitting there, scrolling through my old GitHub repos kinda digital archaeologist, and I find it
— react-calendar-datetime.
My old and abandoned calendar package.
Version 1.3.1 Last update: five years ago. ~100 downloads a month. A couple of themes. A moment.js dependency that probably weighs more than the entire package should.

I don't know what came over me. Maybe it was lazy weekend. Maybe it was nostalgia. Maybe I just wanted to feel something. Either way, I opened it up and thought: let's see how bad this is.

State of Things

Honestly? It wasn't that bad. The core worked. The calendar rendered dates correctly and didn't catch fire when you clicked on it. By the standards of "abandoned weekend projects", this was actually in pretty good shape.

But I cannot look at working code and leave it alone. I wanted to try to optimize it, pour in everything I'd learned over the past 5 years — and if that didn't work out, at least break something :D

So what started as "let me just poke around" turned into a two-week sprint that took the package from v1.3.1 all the way to v3. I have no one to blame but myself.

The First Boss: TypeScript

The first real challenge was migrating to TypeScript. I'd been putting this off for years — not because I don't like TypeScript (I really do), but because migrating an existing JS project to TS is exactly as fun as it sounds. You think you're just adding types. You are not just adding types. You start finding every lazy shortcut you ever took with your data, all at once, while the compiler just stares at you and judges.

It took a while. But once it was done, everything felt more solid. Like the project had grown a spine.

The Dependency Problem (Or: My Obsession With Bundle Size)

Here's something I didn't expect to become a personality trait: I got absolutely fixated on bundle size.
It started innocently. The original package had moment.js. Classic. I migrated to dayjs, felt very smart about it, moved on. Then I started actually measuring the bundle.

Then I couldn't stop.

Then I started resenting every single byte that wasn't mine.
So I removed dayjs too :D
Wrote my own date utilities. They're not fancy — no one's going to write a blog post about my addMonths function — but they work, they're pretty small, and they belong to me.

Final score: zero external dependencies. Bundle stayed around: ~5-7kb gzipped. I check this number more often than I'd like to admit.

The CSS Saga

I moved all styles from SCSS to goober, a CSS-in-JS library. Felt modern. Felt good. 1kb of injected code. Shipped it.

But I couldn't stop thinking about zero dependency library.

And what we have now: CSS Modules. No more goober. I slept better after this decision and I'm not joking. At least for next few weeks :D

The Localization Rabbit Hole

This is my favorite part of the whole story, because it went from "annoying problem" to "surprisingly elegant solution" in a way that felt like cheating.
Originally, locales were only supported for presets — "Today", "Yesterday", etc. and just for few languages.
Then I added dayjs locale support for month names, weeks...
This was... fine, but the list of supported locales was limited, and every new locale added weight to the bundle. (Remember my obsession?)

The more languages I wanted to support, the fatter the package got.

It was a trap.

Then I discovered Intl — the native browser internationalization API. And I just... used that instead.

400+ locales. Month names, weekday names, relative time formatting for presets — all of it, natively, with zero extra bytes. No dictionaries. No JSON files. No dependencies.

I just sat back and stared at the ceiling for a moment. Sometimes the platform just gives you what you need and you've been ignoring it.

The Theme System (My Proudest Weird Thing)

At some point I started making themes. Then I made more themes. Then I couldn't stop making themes. The package now has 18 of them — dark, light, brutalist, pastel, neon — and I love each one like a slightly chaotic parent.

But more importantly: trying to manage all these themes efficiently (bundle size!) pushed me to design a proper theming system based on CSS variables.
Seven variables per theme, one lookup table, predictable output. That system ended up being clean enough that I extracted it into a separate npm package

We all need more NPM packages :D

That's just what happens when you get bored on a weekend.

The Easy Win I Didn't Expect

Migrating from rollup to tsup, and later to tsdown — I expected this to be a nightmare. Build tooling migrations have a reputation, and it's not a good one.
It was fine. It was suspiciously fine. The authors of these tools did a great job and I got to just... configure a few things and move on. After weeks of one thing leading to another, this was a nice surprise.

Where Things Stand

Two weeks of obsessive weekend coding later:

v3.1.2 is out

Fully modular: toggle time picker, month grid, year selector, presets independently
18 themes with a CSS variable system, gradients, shades.
400+ locales via Intl
Week numbers, weekend highlighting, swipe gestures, jelly mode (don't ask, just try it)
~5.9kb gzipped
Accessibility work in progress (there's always more to do here, I know)

Downloads went from 100/month to... more than 100/month. I'm not going to oversell it. But people are using it, filing issues, and occasionally saying nice things, which is more than I had before.

The Honest Conclusion

Open source has always made me nervous — I've tried before and it never really clicked. This time feels different, maybe because I'm not trying to make something important. I'm just trying to make something good.
If you have an old project collecting dust somewhere: maybe don't let it sit for five years. Or do.

Get bored on a Saturday.

See what happens.
The package is react-calendar-datetime if you want to take a look. PRs welcome. Issues welcome. Gentle feedback about my themes collection absolutely welcome.