标签：#JavaScript

Conditional Statements Conditional statements allow JavaScript to execute different blocks of code based on whether a condition is true or false. if - The if statement executes a block of code only if the condition is true. if...else - Use if...else when you want one block of code to run if the condition is true and another block if it's false. if...else if...else - Use this when you have multiple conditions to check. switch statement - The switch statement is used when you have many possible values for one variable. Nested if statement - You can also write an if statement inside another if. Ternary Operator - An optimized one-line shorthand for standard if...else blocks ** If Statement ** let age = 20 ; if ( age >= 18 ) { console . log ( " Eligible to vote " ); } //Output: Eligible to vote ** if else Statement ** let age = 16 ; if ( age >= 18 ) { console . log ( " Eligible to vote " ); } else { console . log ( " Not eligible to vote " ); } // Output: Not eligible to vote ** if ... else if ... else ** let marks = 85 ; if ( marks >= 90 ) { console . log ( " Grade A " ); } else if ( marks >= 75 ) { console . log ( " Grade B " ); } else if ( marks >= 50 ) { console . log ( " Grade C " ); } else { console . log ( " Fail " ); } // Output: Grade B ** switch statement ** let day = 3 ; switch ( day ) { case 1 : console . log ( " Monday " ); break ; case 2 : console . log ( " Tuesday " ); break ; case 3 : console . log ( " Wednesday " ); break ; default : console . log ( " Invalid Day " ); } // Output: Wednesday // Important: The break statement stops the execution after the matching case.We must compulsory to use break statement because if you don't use break, JavaScript will continue executing the next cases even the output is correct. ** Nested if Statement ** let age = 20 ; let hasLicense = true ; if ( age >= 18 ) { if ( hasLicense ) { console . log ( " You can drive. " ); } } // Output: You can drive. ** Ternary Operator ** let isLoggedIn = true ; let systemMessage = is

I’m currently relearning the Core Three — HTML, CSS, and JavaScript — as I work toward becoming a full-stack JavaScript developer. Before I came back to learning software, I spent 22 years working industrial turnarounds. One lesson from that world has followed me into software engineering: Never trust a single point of failure. In industrial maintenance, there’s a safety practice called double block-and-bleed . Instead of trusting one isolation valve, you use two independent valves with a bleed point between them. If one valve leaks, you know immediately. The entire system assumes individual components can fail. Safety doesn’t come from perfect parts. It comes from independent layers of protection. That idea completely changed how I think about CI pipelines. When I first started relearning web development, my mindset was simple: Run Lighthouse. Everything green? Great. 100 across the board locally? Even better. Ship it. Different results after deployment? Uh-oh. Now I see Lighthouse as one checkpoint — not the finish line. A fast website can still have accessibility issues. An accessible site can still have broken metadata. Good SEO won’t catch rendering bugs. Passing unit tests won’t tell you if the generated HTML is malformed. Every tool has blind spots. No single tool should get the final vote. So instead of asking: “Did my tests pass?” I ask: “What kinds of failures could still slip through?” That question naturally leads to layered validation. Formatting Linting Type checking Accessibility checks Performance audits HTML validation SEO analysis Manual review None of these tools is perfect. Together, they’re much stronger than any one of them alone. The more I learn about software, the more I find myself applying lessons from heavy industry. Different environment. Different risks. The same engineering mindset. Assume components will fail. Design systems that fail safely. That’s becoming the philosophy behind every test matrix and CI pipeline I’m designing. What’s

Have you ever wondered how massive modern platforms like Netflix, PayPal, and LinkedIn handle millions of users simultaneously without crashing? The secret weapon behind much of the modern web is Node.js. Traditionally, JavaScript—the language that makes websites interactive—could only run inside a web browser like Chrome or Edge. Node.js changed the game by freeing JavaScript from the browser, allowing it to run directly on your computer. This means you can use it to build backend servers, automate boring computer tasks, or run powerful development tools. If you are intimidated by coding, don't worry. This guide will take you from zero to running your very first Node.js program on Windows, step-by-step. Prerequisites Before we begin, you only need two things: A computer running Windows 10 or 11. An active internet connection to download the installer. No prior coding experience or command-line knowledge is required! Step-by-Step Instructions Download the Node.js Installer First, we need to grab the official installation file. Open your web browser and go to the official website: nodejs.org. You will see two primary options to download. Always choose the LTS (Long Term Support) version. The LTS version is heavily tested, stable, and less likely to give you unexpected errors. Click the Windows Installer button to download the .msi file to your computer. Run the Setup Wizard Once the download finishes, navigate to your Downloads folder and double-click the file to open the setup wizard. Click Next on the welcome screen. Accept the license agreement and click Next. Leave the default installation folder as it is (C:\Program Files\nodejs) and click Next. On the "Custom Setup" screen, leave everything at its default and click Next. Important Step: You will see a checkbox that asks to "Automatically install the necessary tools." Leave this unchecked for now to keep your setup simple and fast. Click Next. Finally, click Install. If Windows asks for permission to make change

The Story: Picture this: It is 10 PM. I was eating my dinner while adding one final touch to my social media app, Vlox. It should just say "Processing..." while generating a card. Simple, right? See the nightmare. 🔥 The Nightmare Scenario 📉 Suddenly, my "Download Card" button broke. htmlToImage started spitting out completely empty 0b images. The hunt was on. Failed Mission Log 🛰️ Attempt 1: Swap to html2canvas 🔄 Result: Error stating the element was not found in the cloned iframe. Verdict: The parent container was completely lost. Attempt 2: Use CoolAlertJS Toast 🍞 Result: It looked ugly and meant loading two different alert libraries for the same job? Not my game. Verdict: Total waste of bundle size. Attempt 3: Append to body + display: none 🙈 Result: The canvas process failed entirely. Verdict: Canvas snapshot engines completely ignore hidden elements. The "Aha!" Moment 💡 Why did the element vanish? Because the card generator lives entirely inside a Swal popup. When you click the download/confirm button, Swal instantly destroys that entire popup DOM tree. You cannot snapshot an element that no longer exists. 👻 The Ultimate Fix 🚀 Inside the new "Processing" popup, I appended the #card-generator-image-preview directly into the new alert container. The element stays alive in the active DOM. The snapshot succeeds perfectly. Clean code. Happy developer. Delicious dinner. Want to see the exact JavaScript code block that fixed it? Drop a comment below or check Vlox on Github .

If you have ever built a custom JavaScript framework from scratch, you know that the line between a smooth, memory-clean engine and a total memory-leak disaster is incredibly thin. With version 1, Levelo-Js proved that lightweight reactive UIs could be fast and intuitive. But as codebases grow, raw JavaScript starts to feel like writing code blindfolded. The dreaded undefined is not a function is always lurking around the corner. Today, we are taking a massive leap forward. Meet Levelo-Js v2 —a complete ground-up architectural rewrite, fully re-born in TypeScript, with enterprise-grade build tooling and absolute bulletproof memory management. Let’s dive into what makes v2 an absolute game-changer. The Pillars of the TypeScript Rebirth 1. Full TypeScript Migration & Modern Bundling We didn't just add types; we transformed the entire runtime engine core and internal modules from .js to .ts . Every piece of code is now strictly type-safe, offering self-documenting APIs and flawless IDE autocompletion (IntelliSense) right out of the box. We also waved goodbye to publishing raw, uncompiled source files. Levelo-Js v2 now ships with production bundles powered by tsup . The engine is now pre-bundled into highly optimized, tree-shakable ES Modules ( compiler/index.js ), making your production build lighter than ever. 2. Hierarchical Tracking Context ( owner.ts ) Handling nested reactive scopes and side-effects can easily lead to chaotic state bugs if not tracked properly. v2 introduces a robust Reactive Ownership Architecture . This creates a clean parent-child tracking hierarchy, ensuring that nested state updates always know exactly where they belong in the application tree. 3. Ownership-Driven Effects & Zero Memory Leaks Memory leaks are the silent killers of Single Page Applications (SPAs). In v2, our core effect() engine has been deeply integrated with the new ownership layer. The breakthrough? It now auto-disposes stale tracking dependencies automatically. We ran heap

I Got Tired of Hunting for Free Online Tools. So I Built 1000+ of Them — All Client-Side, Zero Backend. Every time I needed a simple tool — format JSON, resize an image, generate a QR code — I'd open Google, search for a "free online tool," and land on some sketchy site with 47 pop-up ads, a 10MB file size limit, and a $9.99/month "premium" upgrade staring me in the face. Sound familiar? I knew there had to be a better way. So I built one. And then another. And... well, 1000+ tools later (1052 to be exact, across 2130+ bilingual pages), here we are. What started as a weekend project turned into an obsession: a completely free, ad-light, privacy-first toolbox that does everything in your browser. No uploads. No servers. No accounts. No BS. 🚀 The Self-Imposed Constraints The most interesting part? I gave myself some pretty extreme constraints: Constraint Why 100% static HTML/JS No server, no database, no build step $0 hosting GitHub Pages — literally free forever Works offline Everything runs client-side, so once loaded, it just works Bilingual Every tool has an English + Chinese version No frameworks Vanilla HTML, CSS, and JavaScript — no React, no Vue, no build tools SEO-first Every page has Schema.org structured data, OG tags, and sitemap integration Why these constraints? Because I wanted to prove that you can build something genuinely useful without any recurring costs, complex infrastructure, or venture capital. Just pure engineering. 🔧 The Architecture (If You Can Call It That) The whole thing is beautifully simple: webtools-cn.github.io/tools-site/ ├── index.html ← Homepage with category filtering ├── en/index.html ← English homepage ├── sitemap.xml ← Auto-generated, ~2130 URLs ├── llms.txt ← AI search optimization ├── [tool-name]/ ← Each tool is a standalone folder │ └── index.html ← Self-contained HTML + JS + CSS └── en/[tool-name]/ ← English version of each tool └── index.html Each tool is a completely standalone HTML file . No build process, no framework,

I built LiveShop , a mini live-shopping stream UI, to answer a question I kept running into as a frontend-curious grad: tutorials teach you how to render a list, but they never teach you what happens when that list gets hit with the kind of traffic a real live stream produces. So I built something that would force the problem to show up, then fixed it, then measured whether the fix actually worked. The setup LiveShop simulates a live-shopping broadcast - the kind of interface a small merchant might use to sell products while streaming. A mock event engine fires chat messages, reactions, and purchase notifications on an interval, standing in for what a real WebSocket connection to a streaming backend would deliver. On top of that sits a chat feed, a scrollable product carousel, and a floating reaction animation layer. None of that is unusual. The interesting part started once I asked: what happens when message volume spikes? Where it breaks A naive chat feed is just messages.map(m => <ChatRow key={m.id} {...m} />) . It's the first thing anyone reaches for, and it's fine — right up until it isn't. At 50 messages, nothing looks wrong. At a few hundred, every new message triggers a full re-render pass across every row in the DOM, including the hundreds that have already scrolled out of view and that nobody can see. The browser is doing layout and paint work for pixels that aren't on screen. In a real live stream, this is exactly the wrong failure mode, because message volume doesn't arrive evenly. It spikes — right after a product drop, right when something funny happens on stream, right when a popular creator says something quotable. That's precisely the moment a chat feed can't afford to stutter, and precisely the moment a naive implementation is most likely to. What I measured Rather than guess whether this mattered, I built a way to test it directly. LiveShop has a "Simulate spike" button that fires 500 messages instantly, plus a live FPS readout using requestAnimat

The Complete TypeScript Mastery Guide Navneet Verma Navneet Verma Navneet Verma Follow Jul 10 The Complete TypeScript Mastery Guide # typescript # webdev # systemdesign # tutorial 5 reactions Add Comment 54 min read

Hello Dev Community! 👋 It is officially Day 128 of my software engineering marathon! Today, I tackled an essential lifecycle design challenge in modern frontend development: managing persistent browser loops, orchestrating ticking background workers, and mastering Timer Cleanups inside the useEffect Hook ! ⚛️⏱️💻 I put these architectural paradigms into action by engineering a lightweight, responsive Real-Time Clock Application that tracks exact server-client time down to the second without triggering rogue background processor spikes! 🛠️ Deconstructing the Day 128 Asynchronous Scheduler As captured across my clean system workspace configurations in "Screenshot (286).png" and "Screenshot (287).png" , the scheduling mechanism enforces strict resource allocation: 1. Initializing Reactive Temporal State Managed our standard state anchor using native JavaScript runtime Date models to trigger instant re-renders upon completion of each interval cycle: javascript const [time, setTime] = useState(new Date());useEffect(() => { let intervalId = setInterval(() => { setTime(new Date()); }, 1000);

Hello Dev Community! 👋 It is officially Day 125 of my software engineering marathon! Today, I crossed an elite milestone in frontend data architecture: moving completely away from local hardcoded mock lists by connecting my centralized state management infrastructure to live third-party servers using the Fetch API alongside Async/Await ! ⚛️🌐⚡ Now, the social media feed dynamically handles server-side data models, passes payloads to an active state reducer, and broadcasts states down to presentation layers via a custom Context portal! 🛠️ Deconstructing the Day 125 Async Network Lifecycle As shown inside my development setup across "Screenshot (279).png" , "Screenshot (280).png" , and "Screenshot (281).png" , the application state engine is clean and modular: 1. Extensible Central State Reducers ( PostList.jsx ) Engineered explicit structural actions inside the reducer core to seamlessly support both user generation and full-scale network array overriding: javascript } else if (action.type === "NEW_INITIAL_POSTS") { NewPostValue = action.payload.posts; }

Bonus round. Parts 1–3 covered why Node exists, what's happening inside it, and the full request journey. This part mops up the pieces that didn't fit anywhere else — the Express plumbing, error handling, and a checklist to test yourself against. Saturday, Round 4 Nephew: Uncle, one more round? I promise this is the last one for a while. Uncle: pours chai — you said that last time too. Fine, what's bugging you now? Nephew: Small things, actually. express.json() , cookie-parser , express.Router() — I use all of them, copy-pasted from old projects, but I couldn't explain any of them if you asked me directly. Uncle: That's exactly the right instinct — the things you copy-paste without understanding are always the things that break at 2 AM. Let's fix that. Part 4.1 — Two Directions Node Never Confuses Uncle: Before plumbing, one small but important idea that ties Parts 2 and 3 together. Everything Node does falls into exactly two directions . DIRECTION 1 — Incoming Events "The outside world is telling Node something happened" OS → libuv → Event Loop → Your JavaScript Examples: HTTP request arrives, TCP connection opens, WebSocket message arrives DIRECTION 2 — Outgoing Async Operations "Your JavaScript is asking Node to go do something" JavaScript → libuv → Worker Thread → OS → Disk/DB ↓ result comes back through libuv → Event Loop → your callback Examples: fs.readFile(), crypto.pbkdf2(), dns.lookup() Nephew: So an incoming HTTP request and a fs.readFile() call both eventually pass through libuv and the event loop — but they enter from completely opposite directions? Uncle: Exactly. One is the world pushing something at Node. The other is Node reaching out to go get something. Same event loop handles both, but the journey to get there is different — an HTTP request never touches the thread pool; a file read almost always does. Incoming HTTP Request: File Reading: Browser JavaScript | | OS libuv | | libuv Worker Thread | | Event Loop Operating System | | JavaScript Disk |

AI coding agents are now part of the developer workflow. Whether we like that shift or hate it, users...

👋 Welcome to Chapter 9! Imagine a user typing in a search box. They type "i", "ip", "iph", "ipho", "iphon", "iphone" — 6 keystrokes in 2 seconds. Do you really want to make 6 API calls ? Of course not! You want to wait until they stop typing and then search once. That's what timing operators solve. They control when and how often values flow through your stream. ⏱️ debounceTime() — Wait for the Silence debounceTime(ms) waits until there's a pause of ms milliseconds, THEN lets the latest value through. Think of it like this: "Ignore everything until they stop for a moment." Like a person who waits for you to finish talking before responding. import { debounceTime } from ' rxjs/operators ' ; // User types fast: 'i' → 'ip' → 'iph' → 'ipho' → 'iphon' → 'iphone' // debounceTime(400) waits 400ms of silence, then sends 'iphone' only searchControl . valueChanges . pipe ( debounceTime ( 400 )) . subscribe ( term => { this . searchProducts ( term ); // Only called ONCE with 'iphone'! }); Timeline: Type 'i' → [400ms timer starts] Type 'ip' → [reset timer] Type 'iph' → [reset timer] Type 'iphone'→ [reset timer] ... 400ms silence ... EMIT: 'iphone' ✅ Real Angular Example — Smart Search Box import { Component , OnInit , OnDestroy } from ' @angular/core ' ; import { FormControl } from ' @angular/forms ' ; import { Observable , Subject } from ' rxjs ' ; import { debounceTime , distinctUntilChanged , switchMap , startWith , takeUntil } from ' rxjs/operators ' ; @ Component ({ selector : ' app-search-box ' , template : ` <div class="search-wrapper"> <input [formControl]="searchControl" placeholder="Search products..." (keyup.escape)="clearSearch()"> <span *ngIf="isLoading" class="spinner">🔄</span> <button *ngIf="searchControl.value" (click)="clearSearch()">✕</button> </div> <div class="results-count" *ngIf="(results$ | async) as results"> Found {{ results.length }} results </div> <div class="results"> <div *ngFor="let item of results$ | async" class="result-item"> <strong>{{ item.nam

New parents obsess over percentile numbers. I get it. I built a tool that plots your baby measurements against official WHO and CDC growth standards. What it does: Weight, height, and head circumference percentiles for ages 0-36 months Visual growth chart showing where your baby falls on the curve Uses WHO Child Growth Standards (0-24 months) and CDC reference data (24-36 months) 35 pages, all pre-rendered for fast loading The hard part: Parsing the WHO growth standard tables into usable JSON. Those tables are dense and not designed for programmatic use. That took more time than building the actual calculator UI. ?? Try it: babypercent.com Built with Next.js, no database, no tracking. Just a calculator that respects your privacy.

The dirty secret of online dev tools Every dev tool lives on a different website. jwt.io for JWT decoding. regex101 for regex testing. Some random site for JSON formatting. Another for diff checking. Another for curl → code. Another for SQL formatting. You end up with 10 bookmarks, 10 different UIs, and 10 different servers that just received your most sensitive data — and you never think twice about it. I didn't either. Until I did. What actually happens when you use these tools Let's take jwt.io as an example. Your JWT contains: Your auth algorithm Your user ID Your roles and permissions Your token expiry Sometimes your email, name, org ID When you paste it into jwt.io — it hits their server. It's in their request logs. Maybe forever. The same goes for regex101. Your regex patterns often encode business logic — validation rules, data formats, internal naming conventions. That goes to their database. And every online JSON formatter, diff checker, SQL tool, .env checker you've ever used? Same story. You're not just sharing data. You're sharing the shape of your system. Most of the time nothing bad happens. But "most of the time" is a terrible security posture for a developer who knows better. I got tired of it The more I thought about it, the more it bothered me. I was pasting production JWTs. Real API keys. Actual .env files with database URLs. Into random websites I knew nothing about. So I built DevTab - devtab.in One tab. 110+ dev tools. Zero server calls. Everything runs 100% in your browser via client-side JavaScript and WebAssembly. Open DevTools → Network while using it. Nothing fires. That's not a marketing claim. It's verifiable in 10 seconds. What's inside JSON tools JSON formatter & validator — real-time, error highlighting with line numbers JSON minifier JSON stringify & parse JSON → TypeScript / Pydantic / Go / Zod types Auth & security JWT decoder — header, payload, expiry countdown, issued-at in human time. Zero network requests. .env diff checker —

Here is a question that sounds simple until you've actually shipped a UI: how many files does it take...

One creative studio for images, video, music, audio, editing, upscaling, and motion control. 50+ models, one credit balance. This is mostly about how we built it and what went wrong along the way. The problem (from a dev perspective) The models are good now. That's not really the issue anymore. The issue is everything around them. Different providers, different UIs, different billing. No shared history across modalities. No easy way to go from "generate image" to "animate it" to "add music" to "upscale" without opening four tabs. We wanted one place where you could actually finish something. What the product is Picturesque has a few main pieces: Studio - tabs for image, video, audio, edit, motion control Projects + Explore - save your work, browse what other people made Workflows - node canvas where you chain models together and run the pipeline in one go Director - an agent that plans multi-step creative work, quotes credits, and runs generations for you The studio covers a lot on its own. 4K images, cinematic video with audio, Suno music, ElevenLabs TTS, Topaz upscaling, motion control, talking avatars. The annoying engineering showed up once we tried to make all of that feel like one product instead of a folder of integrations. Stack (kept boring on purpose) Frontend is React, TypeScript, Vite, React Router. Backend is Node + Express. Socket.IO for real-time updates. Supabase for Postgres and auth. S3-compatible storage for outputs and uploads. For the actual model calls we built a service layer that normalizes inputs, maps our internal model IDs to provider APIs, and handles retries/errors in one place. Media stuff runs through FFmpeg and Sharp. Nothing fancy. When you're wiring up dozens of models with different schemas and pricing rules, you don't want your infra adding more chaos. We also refactored the backend out of a single 7,700-line server.js into routes + services. Painful refactor. Would do it again immediately. The unglamorous part: 50 models, one UI

Open source has always been at the heart of what we do at Omnikon. Today, we're excited to share a milestone that means a lot to our entire community. Our repository, maintained by Sourabh, has been officially selected for GirlScript Summer of Code (GSSoC) 2026. For us, this isn't just another achievement—it's a step toward building a stronger open-source ecosystem where students and developers can learn, collaborate, and create meaningful software together. About Omnikon Omnikon is a student-led open-source organization focused on building high-quality developer tools, educational resources, and community-driven projects. Our mission is simple: Build impactful open-source software. Help new contributors get started. Create projects that solve real problems. Foster a welcoming developer community. Every repository we build is designed with collaboration in mind, making it easier for contributors of all experience levels to participate. What GSSoC Means GirlScript Summer of Code is one of India's largest open-source programs. Every year, thousands of contributors participate by solving issues, improving documentation, fixing bugs, and implementing new features across selected repositories. Being selected means our project will become part of this collaborative ecosystem, giving contributors an opportunity to make meaningful contributions while learning industry-standard development workflows. A Special Thanks This achievement wouldn't have been possible without Sourabh, who maintained and prepared the repository throughout the selection process. A huge thank you to everyone who contributed ideas, reviewed code, reported issues, improved documentation, and supported the project. Open source is never the work of one person—it grows because of a community. What's Next? We're preparing the repository for contributors by: Organizing beginner-friendly issues. Improving documentation. Creating contribution guides. Enhancing project structure. Mentoring new contributors thro

Introduction Chrome's Built-In AI APIs allow applications to perform selected AI workloads directly within the browser. Unlike traditional AI integrations, developers do not need to deploy or operate model infrastructure. This guide walks through the major APIs currently available. Getting Started: API Availability and Chrome Flags Chrome's Built-In AI APIs are at different stages of maturity. Some APIs are available in stable Chrome, while others remain experimental. The required setup therefore depends on the API you want to test. Available in Chrome Stable The following APIs are available in stable Chrome on supported desktop devices: Language Detector API Translator API Summarizer API These APIs do not require experimental flags for normal use in supported Chrome versions. The Prompt API has different availability requirements depending on whether it is used from a web page or a Chrome Extension. Check the current Chrome documentation for the environment you are targeting. Experimental APIs The Writer, Rewriter, and Proofreader APIs remain experimental and may require developer trials, origin trials, or Chrome flags for local development. Because these APIs are evolving, refer to the official Chrome documentation for the current setup requirements rather than relying on a static list of flags. Engineering recommendation: Use feature detection and availability() checks at runtime rather than relying on Chrome version numbers or assuming that a particular flag is enabled. Language Detector API Use cases: Dynamic localization Query routing Analytics Content classification Example const detector = await LanguageDetector . create (); const result = await detector . detect ( " Bonjour tout le monde " ); console . log ( result ); Architecture Notes Low latency Task-specific model Suitable for client-side execution Complete runnable example: Language Detector API on GitHub Gist Translator API Use cases: Localization Offline translation International applications Example

I’ve been thinking about a small image-processing problem lately: how to reduce an image to a limited palette without making it look muddy. This comes up in a lot of places: pixel art tools printable pattern generators low-color previews LED matrix displays icons and small thumbnails craft or grid-based workflows The easy version is: pick the nearest color for every pixel. The hard version is: keep the important shapes readable after the palette gets much smaller. Nearest color is only the baseline A simple nearest-color pass usually works like this: Take each pixel. Compare it with every color in the target palette. Pick the closest one. Replace the pixel. That gives you a valid output, but not always a good one. The problem is that closest is local. It does not know whether the whole image still reads well. A face can lose warm midtones. A shadow can turn into a flat dark blob. A small highlight can disappear. Skin, fur, fabric, and background colors can collapse into the same bucket. So palette reduction is not just a color problem. It is also a structure problem. RGB distance can be misleading A common first attempt is Euclidean distance in RGB: function rgbDistance(a, b) { return Math.sqrt( (a.r - b.r) ** 2 + (a.g - b.g) ** 2 + (a.b - b.b) ** 2 ); } This is easy to implement, but it does not match human perception very well. Two colors can be numerically close in RGB and still feel different. Other colors can be farther apart numerically but visually acceptable. A better approach is to compare colors in a more perceptual color space, such as Lab or OKLab. You still have to be careful, but the distance metric starts closer to what the eye notices. Dithering helps, but it changes the style Error diffusion, like Floyd-Steinberg dithering, can preserve gradients and perceived detail with fewer colors. That is useful when the output is meant to look like a low-color image. But dithering is not always desirable. In grid-based outputs, it can create scattered single-p