DEV Community: Nikhil Kumar Swain

Why I drew my own icons for a doodle app

Nikhil Kumar Swain — Sat, 24 Oct 2026 14:20:19 +0000

I built Zketch for doodling, and doodles don't follow straight lines. Yet every button around its canvas was drawn with a ruler: dead-straight edges, compass-perfect arcs, corners that meet at exact angles. Replacing them took me from a pile of uneven sketches to 143 brush-drawn icons whose small imperfections are the whole point, and then to zicons, a set anyone can use.

Figure 1. A handful of the 143 zicons icons: one pen, one line, a little wobble.

A doodle app with ruler-straight buttons

Zketch is a drawing app that runs in the browser. You open it, pick a brush and scribble. For a long time, the buttons around that scribbling came from Lucide, a popular open-source icon set, plus a few extra SVGs I added in the same style so they'd match. The undo arrow, for example, used the path from Feather, the set Lucide grew out of: a perfect arc with a radius of exactly 9, ending in an arrowhead bent at a right angle. Everything matched, and that was the problem.

There's nothing wrong with Lucide or Feather. They're made for precise, neutral interfaces, and they're very good at that. But Zketch isn't a neutral interface. It exists for loose, wobbly lines. Everything on the canvas said "draw freely," and everything around it said "measure twice." The icons didn't carry the feel of the reason I was making the app. Put side by side with what replaced them, the difference is small but it's everywhere:

Figure 2. Zketch's toolbar tools in Lucide (top) and zicons (bottom), shown larger than in the app: the same tools, with softer corners and lines that aren't quite straight.

Drawing them by hand, and why it didn't work

The obvious fix was to draw new ones myself, and I had the right tool for it. I sketched icons in Zketch, with its own brushes.

They had plenty of character, and not one came out the same size as the next. Charming on paper. Less charming as a button you're trying to click.

An icon set has a job that a sketch doesn't. Every icon has to sit on the same grid, carry the same weight, and stay readable at 14 pixels as well as at 56. Drawn freehand, each icon was a one-off, and a toolbar of one-offs looks messy rather than playful. None of those files are left, but the lesson stayed: I wanted my pen's feel without my hand's inconsistency.

Imperfect on purpose

Things drawn by hand aren't perfect, and that's exactly why they feel human. A line drawn without a ruler drifts a little. A circle never quite closes the way a compass would. Corners come out soft because a pen can't make a sharp one. Those were the qualities I wanted, so the question became: how do you keep the imperfections and drop the mess?

My answer was to decide in advance exactly where the imperfection is allowed to live, and to make everything else strict. The strict part became a short set of rules:

Every icon is drawn on a 24 by 24 grid and stays roughly inside the middle 18 by 18.
One even line, 1.6 units wide, with round ends and round joins. No fills.
Rounded corners everywhere. Nothing ends in a sharp point.
Few strokes, and each stroke is a single pen movement. Most icons need two or three.

The imperfect part is small. Straight edges bow very slightly, and circles are a little out of round. That's all. But a bow that small, repeated across a whole toolbar, is enough to make the set feel drawn rather than built.

Teaching code to hold the pen

I already had a drawing pipeline in Zketch, and I needed the feel of my brush on these icons. So I split the work in two. I describe each icon as a few pen movements, and code does the actual drawing, the same way every time.

The description is a centerline: the path the middle of the pen travels, before any line width is added. For the pencil icon it's two strokes, a body with five rounded corners and the little line underneath:

packages/icons/defs/core.mjs

pencil: {
  strokes: [
    poly([[14.6, 5.1], [18.8, 9.3], [8.6, 19.2], [4.9, 19.1], [4.8, 15.4]], [1.8, 1.8, 1.3, 1.1, 1.3]),
    path("M3.5 21.5c2.5-1.4 4.4-1.6 6-2.2"),
  ],
},

The first list is where the corners go, and the second is how round each corner is. From there, a small generator takes over. It rounds the corners, bends the straight edges, walks along the result dropping a point roughly every third of a unit, and then thins those points down to the few that actually shape the line. Zketch uses the same trick to keep drawn strokes small. What comes out is one SVG path per icon, whatever the icon looks like. You can follow the pencil through it, left to right:

Figure 3. One icon through the generator: 5 corners and a curve become 135 sampled points, then 24, then a single 1.6-wide SVG path.

A wobble that never changes

The bow on each straight edge is random, and that's a problem. Randomness in an icon set means a different icon on every build: the undo arrow you shipped yesterday quietly changes shape today.

So the randomness is borrowed from the icon's name. The generator turns the name into a number with a tiny hash function and uses that number as the seed for its random choices:

packages/icons/lib/catalog.mjs

const d = sampleIcon(mod[name], hash(name)).map(toPathData).join("");

Every icon wobbles in its own way, and each one wobbles the same way forever. Here's the same square drawn with three different names. The inner red dashes are the straight square it started from (the outer ones mark the area every drawing stays inside), and the black line is where the pen went:

Figure 4. One square, three seeds: the bow changes with the name, never between builds.

Important:
Seed the randomness from the icon's name, and a wobbly line becomes as reproducible as a straight one.

Goodbye, Lucide

With the generator doing the drawing, my job changed. I was no longer fighting my own hand to make two icons the same size. I was deciding what each icon should say in two or three pen movements, and the code made sure every one of them said it in the same voice.

I worked outward from the canvas: first the tools Zketch uses most, then the rest of the app, then everyday icons and art tools for whatever comes next. Each new icon went onto a contact sheet beside all the others, at several sizes, because an icon that looks lovely at 56 pixels can turn to mush at 14. On one sheet, an icon that doesn't belong is easy to spot:

Figure 5. Twenty of the 143 icons at 14, 18, 24 and 56 px, all drawn with the same line.

Once the sheet looked like one set, I swapped them in. Every screen in Zketch moved to the brush-drawn icons, and Lucide came out of the project. The buttons around the canvas finally looked like they belonged to the drawing inside it. Zketch's project notes now carry a one-line rule: no Lucide.

Letting the lines breathe

The bow made the icons look drawn. I also wanted them to feel alive.

In old hand-drawn cartoons, every frame was traced again by hand, so the lines shimmer slightly even when nothing moves. Animators call it line boil. zicons fakes it with two SVG filters: one makes a field of noise, and the other nudges each part of the icon's line by the amount the noise says. The noise cycles through three patterns in a 0.36-second loop, so a new one arrives every 0.12 seconds:

packages/icons/runtime/render.js

export const SEEDS = [3, 11, 23];
export const BOIL_RATE = 0.36;

That's about eight new frames a second, which reads as a traced cartoon rather than smooth motion. The drawing itself never changes; only the noise over it does. Here are the three frames, with the real line in red on top:

Figure 6. Three boil frames, 0.12 s apart: the red path is the same in each, only the filter's noise moves.

The hard part was size. A shimmer that looks lively on a big icon makes a small one unreadable, so icons under 32 pixels get a gentler boil than larger ones, and within each group the wobble is scaled so it looks the same on screen at any size. You can have it on all the time, or only when someone hovers the icon or the button it sits in.

In your own project, the boil is off until you ask for it, one icon at a time, so whether it runs, and whether it follows reduced-motion settings, is your call. On the zicons site it's on for everyone, because the boil is how these icons show what they can do. If it's too much, a switch at the top of the page stops it.

From Zketch's toolbar to everyone's

For a while the icons lived only inside Zketch. But I kept thinking about other people who want what I wanted: something fun, a little unusual, with a taste of its own instead of the same neat icons as every other app. So I gave the drawings their own project and called it zicons.

zicons is now where new icons get drawn. One file holds every icon with its name, group, search words and path, and everything else is generated from it: the website, plain SVG files, a sprite, and a component package for each of the big frameworks. Importing one icon adds about 3 KB to a bundle, not all 143.

The future of zicons

The 143 icons cover a drawing app and the everyday basics. That's a start, not a finish. I don't have a target number in mind. What I want is a place where all your icon needs get covered, so you never have to mix in a ruler-straight icon from somewhere else because zicons didn't have one.

Here's what's planned:

A Figma file, so designers can use the icons where they design, not only where they build.
Contributions and icon requests. Right now every icon is coordinates I type into a file. I'd like a way for you to ask for the icon you're missing, and eventually to draw one yourself that follows the same rules.
More icons, steadily, wherever people keep finding gaps.
A playground with small mock interfaces (a toolbar, a sidebar, a card) so you can see the set working together before you use it.

A note before you go

zicons works with React, Vue, Svelte and plain HTML. Everything you need to browse, restyle, copy or install the icons is on zicons.zerro.dev, and the drawings live on GitHub. If you'd rather draw with them than read about them, they're in Zketch's toolbar.

Icons are the smallest things on a screen, so it's easy to grab them off the shelf without a second thought. But they're on every page, and they tell people what kind of place they've walked into before a single word does. Zketch is a place for loose lines, and now its buttons look like someone held a pen. Whatever you're making, it's allowed to have a hand in it too. A little wobble never hurt anyone.

Originally published on zerro.dev.

Scroll-scrubbed video that stays smooth with any video file

Nikhil Kumar Swain — Fri, 09 Oct 2026 15:01:53 +0000

A video that moves with the page is one of the nicer effects on the web. A product turns as you scroll, or a scene plays out at the reader's pace. It looks like a few lines of JavaScript, and with the right file it is. With a video exported straight from an editor, the same few lines stutter, and scrolling backwards is worse. This article explains where that stutter comes from, what the usual fixes cost, and the approach I ended up building into a small library, vidscroll, so that any video file scrubs smoothly.

Figure 1. A scroll-scrubbed video: it moves only as fast as the page scrolls. Animation by roenais.

The obvious approach: set `currentTime` on scroll

My first version was the obvious one. Pin a <video>, put a tall spacer behind it, and on each animation frame map the scroll position to a time in the video. Simplified, it comes down to this:

const onScroll = () =>
  requestAnimationFrame(() => {
    const max = spacer.scrollHeight - innerHeight;
    const progress = Math.min(Math.max(scrollY / max, 0), 1);
    video.currentTime = progress * video.duration;
  });

window.addEventListener("scroll", onScroll, { passive: true });

With a video prepared for scrubbing, this keeps up with the scroll. With a typical export, the same code stutters.

Nothing in the handler changes between those two cases. The only difference is the file, so that's where the problem is. Rewriting the scroll logic won't fix it.

Why exported videos stutter when you scrub them

A video file doesn't store every frame as a picture. Every so often it stores a complete one, a keyframe, and the frames in between only store what changed. To show any frame, the browser starts at the keyframe before it and decodes forward.

Normal playback never notices, because it only moves forward. Scrubbing jumps to a new point many times a second, in both directions, and every jump pays for the walk from the previous keyframe.

Most exported videos have keyframes a few seconds apart, because that keeps files small. A 60-second 1080p export I tested had 8 keyframes in total, one every 8.3 seconds. On the demo clip I measured, the median seek took 287 ms. That's under four new frames per second, however fast the rest of the page runs.

For scrubbing, keyframe spacing matters more than resolution, bitrate or codec. Lowering the resolution of a file with sparse keyframes rarely fixes the stutter.

You can check a file with ffprobe, which lists the time of every keyframe:

ffprobe -v error -select_streams v:0 -skip_frame nokey -show_entries frame=pts_time -of csv=p=0 hero.mp4

Gaps of up to about half a second scrub well. Anything much longer and every seek gets expensive.

Figure 2. The same clip as exported (top) and prepared for scrubbing (bottom).

Two common fixes, and what they cost

Prepare every file

Re-encode the video with keyframes close together, for example one every 10 frames. Scrubbing becomes smooth, because any frame is at most about 10 frames from a keyframe. With ffmpeg, for a landscape video, the flags that matter are these:

ffmpeg -i hero.mp4 -an -vf scale=-2:720 -c:v libx264 -preset slow -pix_fmt yuv420p \
  -g 10 -keyint_min 10 -sc_threshold 0 -crf 22 -movflags +faststart hero.scroll.mp4

-g 10 -keyint_min 10 puts a keyframe every 10 frames, and -sc_threshold 0 stops the encoder adding extra ones at scene cuts.

The cost is that someone has to do it for every video, every time the video changes, and the files get bigger:

The same 60 s clip	Size	Keyframes
Original export, 1080p	4.7 MB	8, one every 8.3 s
Prepared, 720p	11.9 MB	180, one every 0.33 s
Prepared, 1080p	22.4 MB	180, one every 0.33 s

Decode every frame up front

Decode all frames into images ahead of time and draw them to a canvas. Scrubbing is then instant, whatever the file.

The cost is memory. A decoded 1080p frame is about 8 MB, so 10 seconds at 30 fps comes to about 2.5 GB. That works for a few seconds of small video, and not for a minute of HD on a phone.

A third route: fix the file only when it needs fixing

The third route is to take whatever file you're given, keep it compressed, and fix it only when its keyframes are too far apart. That takes four pieces, and vidscroll is built from them.

Read the keyframe layout without decoding

An MP4 already says where its keyframes are. The sample table in the file's index lists which frames are keyframes (the stss box) and how long each frame lasts (stts), and fragmented MP4s carry the same information in their moof/trun boxes. Reading those boxes takes a small parser and no decoding at all; in vidscroll it's src/core/probe.ts. Other containers, such as WebM, need a demuxer instead.

From that list, the largest gap between keyframes tells you whether the file is fine as it is. vidscroll uses 0.5 seconds as the limit.

Re-encode in the browser with WebCodecs

If the gaps are too long, the WebCodecs API lets the page re-encode the video with the browser's own encoder. vidscroll uses Mediabunny on top of it, loaded only when a re-encode is needed, so pages with prepared files never download it.

The copy has a keyframe every quarter of a second, a short side of at most 720 px, at most 30 frames per second, and no audio. In my tests, a 60-second 1080p clip took about 8 to 10 seconds to re-encode on a desktop computer and about 20 seconds on a phone. Shorter clips are proportionally faster.

Cache the result

Re-encoding on every visit would waste those seconds each time. The copy goes into the browser's Cache Storage, so later visits load it straight away, with no download and no re-encode.

The cache key has to change whenever the result would. vidscroll ties each entry to the video's URL, the re-encode settings, and the file's ETag, Last-Modified or Content-Length, so replacing the file on the server starts over.

Let people scroll while it works

Waiting behind a spinner would leave the page blank for the whole re-encode. Instead, the downloaded original goes on screen straight away.

Scrolling forward plays it, with playbackRate following the scroll speed. Playing forward never goes back to a keyframe, so it stays smooth even on a badly encoded file. Scrolling backwards still has to seek, so it's choppy for those few seconds.

When the copy is ready, a second <video> stacked underneath seeks to the current time and then takes over. It lands on exactly the frame on screen, so the switch isn't visible.

Using it on a page

In React, a <ScrollVideo> is a block in your page, and each <Section> is active over part of the scroll:

import { ScrollVideo, Section } from "vidscroll";

export default function Hero() {
  return (
    <ScrollVideo src="/videos/hero.mp4" length="400vh" smoothScroll>
      <Section start={0} end={0.33}>
        <h1>Intro</h1>
      </Section>
      <Section start={0.33} end={0.66}>
        <h1>Middle</h1>
      </Section>
      <Section start={0.66} end={1}>
        <h1>Outro</h1>
      </Section>
    </ScrollVideo>
  );
}

src is any URL to a video file: your public folder, a CDN, or a bundler import. Without React, the experimental <vid-scroll> element does the same on any page.

For production, the package's CLI runs that same kind of ffmpeg command for you, so visitors never wait for a re-encode:

npx vidscroll encode public/videos/hero.mp4

I built it for landing pages, homepages and storytelling sites, the kind of scrollytelling where text is tied to scenes and the reader sets the pace.

Where it doesn't fit yet

Long videos, especially at 1080p. Anything over about two minutes or 100 MB gets slow to download and to re-encode, and vidscroll warns in the console. Trim the video, or prepare it with the CLI.
The browser's copy is bigger than the CLI's. For the 60-second clip, the in-browser re-encode made 18.6 MB where the CLI makes 11.9 MB at the same resolution. It only lives in the visitor's browser, but it's one more reason to prepare videos for production.
The first visit to an unprepared video. Scrolling backwards is choppy until the smooth copy arrives.
Videos with sound. Scroll-driven video is always muted, and the re-encode drops the audio.
Caching needs the right headers. Without ETag, Last-Modified or Content-Length, there's no way to tell whether the file changed, so the re-encode runs on every visit. Caching also needs HTTPS or localhost.

Before you build your next scroll video

Whatever you build it with, three things decide whether it feels smooth:

Check the keyframes before the code. If scrubbing stutters, look at the file first. Gaps over half a second will hurt, however good the scroll handler is.
Prepare the files you control. One ffmpeg command with closely spaced keyframes beats fixing it at runtime: a smaller download and smooth scrubbing from the first visit. Use 720p unless the video fills a large screen.
For the files you don't, fix them once and remember it. Read the container instead of decoding it, re-encode only when the gaps are too long, cache the result, and keep the page scrollable while that runs.

That's the whole idea behind vidscroll, and you can try it without installing anything. Drop one of your own videos into the video checker: it shows every keyframe, times seeks on your device and gives you the command to fix the file. The video is read in the page and never uploaded.

Figure 3. The checker on the 60-second export from earlier: keyframes 8.3 s apart and seeks too slow to scrub smoothly.

If the result looks like the one above, you've found your stutter, and fixing it is one command. To see the rest, there are demos, a playground for the options, and a longer explanation of how it works. The code is on GitHub, and the package is on npm:

npm i vidscroll

Scroll-driven video is one of the few effects on the web that hands the pace of a story to the reader. When it stutters, the whole effect falls apart, and it's easy to blame the scroll code, the framework or the device. Often the cause is sitting in the file: keyframes a few seconds apart. Once you know that, it stops being a mystery and becomes a fixable problem, whether you fix it with one ffmpeg command, build the runtime fix yourself, or let a library do it.

If you try it on a video that doesn't behave, open an issue with the checker's report. Odd files make the best test cases.

Originally published on zerro.dev.

5 Famous Array Methods in JavaScript.

Nikhil Kumar Swain — Mon, 16 Sep 2019 15:03:03 +0000

map() , reduce() , filter() , some() , every() .

JavaScript provide us lots of useful methods to ease our work.In this article we will take a closer look at some JavaScript famous Array methods that will help us to code efficiently.

Array.prototype.map() The map() method creates a new array with the results of calling a function for every array element.It accepts a callback function as a parameter and we have access to a ccurrent value of an array, current index and array itself as well. Syntax : array.map(function(currentValue, index, arr), thisValue)

const array = [2,4,6,8];

const newArr = array.map(val => val*2);

// [4, 8, 12, 16]

You could also pass a callback function as a parameter.

const callbackFunc = val => val + 2;

const array = [2,4,6,8];

cons newArr = array.map(sum)

// [4, 6, 8, 10]

Chaining is also available in so we can do something like this :

const sum = val => val + 2;

const mul = val => val * 2;

const array = [1, 2, 3, 4, 5];

const newArray = array.map(sum).map(mul);

// [6, 8, 10, 12, 14]

2. Array.prototype.reduce()

The reduce() method executes a reducer function (that you provide) on each element of the array, resulting in a single output value.

The reducer function takes four arguments:

Accumulator
Current Value
Current Index
Source Array

Your reducer function’s returned value is assigned to the accumulator, whose value is remembered across each iteration throughout the array and ultimately becomes the final, single resulting value.

Syntax :

array.reduce(function(total, currentValue, currentIndex, arr), initialValue)

function myFunc( total, num ) {
return total + num ;
}

const numbers = [30, 20, 10];

numbers.reduce(myFunc)
// 60

We can also provide an initial value instead of taking the first value as an accumulator by default :

const num = [5, 10, 15, 10];

const sum = num.reduce(( acc, val ) => acc + val, 100);

// 140

3. Array.prototype.filter()

The filter() method creates a new array with all elements that pass the test implemented by the provided function.

Syntax :

const newArray = arr.filter(callback(element[, index[, array]])[, thisArg])

callback : Function is a predicate, to test each element of the array. Return true to keep the element, false otherwise.

It accepts three arguments:

element : The current element being processed in the array.

index : (Optional) The index of the current element being processed in the array.

array : (Optional) The array filter was called upon.

thisArg : (Optional) Value to use as this when executing callback.

const band = ['Against', 'the', 'current', 'is', 'my', 'favourite', 'band'];


const newBand = band.filter( word => word.length > 5 );

// ["Against", "current", "favourite"]

Let’s look at another example.

const isGreater = (val) => {
return val > 12;
}

const realNumbers = [3,6,12,15,18,21].filter(isGreater);

// [15, 18, 21]

4. Array.prototype.some()

As the name suggest the some() method tests whether at least one element in the array passes the test implemented by the provided function. It returns a Boolean value .

Syntax : array.some(function(currentValue, index, arr), thisValue)

const names = [const names = ['sheldon', 'lenoard', 'raj', 'howard', 'penny'];

names.some(having => having === 'sheldon');

// true

names.some(having => having === 'chrissy');

// false

Another example of some() method

const number = [5,7,10,12,15,17,20];

number.some(mulOfFive => mulOfFive % 5 === 0);

5. Array.prototype.every()

Unlike some() the every() method tests whether all elements in the array pass the test implemented by the provided function. It also returns a Boolean value.

Syntax : array.every(function(currentValue, index, arr), thisValue)

const band = ['ATC','ATC','ATC','ATC'];

band.every(having => having === 'ATC');

// true