标签：#JavaScript

Perry Mason in: The Case of the Drifting Timer Opening Statement You need a reactive "current time" in your Vue 3 app. A schedule grid with a red line showing "now." A live clock. A dashboard that updates every minute. Every Vue developer reaches for setInterval first. It works. But "works" and "works well" are different things. This is the story of taking a naive timer from "it ticks" to production-grade — and the four iterations it took to get there. The prosecution calls four exhibits. Let's begin. Exhibit A: The Memory Leak const currentTime = ref ( new Date ()) onMounted (() => { setInterval (() => { currentTime . value = new Date () }, 60000 ) }) It works. Sort of. The defense rests — but the prosecution is just getting started. Exhibits of negligence: The interval is never cleared. When the component unmounts, the timer keeps firing every 60 seconds forever — updating a ref nothing reads anymore, and holding its closure (and everything the ref references) in memory for the lifetime of the page. Silent. Invisible. The kind of leak that shows up in production after a user navigates around your app for 20 minutes. Exhibit B: Component-Only Cleanup const currentTime = ref ( new Date ()) let timeInterval = null onMounted (() => { currentTime . value = new Date () timeInterval = setInterval (() => { currentTime . value = new Date () }, 60000 ) }) onUnmounted (() => { if ( timeInterval ) clearInterval ( timeInterval ) }) Now we clean up. The interval is stored in a variable, cleared on unmount. A step forward. But onUnmounted has a scope limitation worth understanding: The limitation: onUnmounted only works inside components. If someone calls this logic from a Pinia store or outside a component's setup() context, onUnmounted never fires. The timer leaks silently. (Composables called synchronously during setup() are fine — Vue's docs recommend exactly that. The problem is when there's no component instance at all.) The timer fires 60 seconds after load , not at the t

When we write: const result = add ( 10 , 20 ); it feels like the computer simply "runs the code." But the CPU doesn't understand JavaScript. There are several layers between the code we write and the hardware actually executing instructions. That's what I wanted to understand first. From JavaScript to the CPU In Node.js, JavaScript is handled by V8 , the JavaScript engine. A simplified view looks like this: JavaScript ↓ V8 ↓ Bytecode ↓ JIT compilation ↓ Machine instructions ↓ CPU V8 doesn't simply "interpret JavaScript" or "compile JavaScript" once and forget about it. It can start with bytecode and progressively compile frequently executed ("hot") code into more optimized machine code. Eventually, the CPU is executing instructions that operate at a much lower level than the JavaScript we originally wrote. What does the CPU actually do? At its core, a CPU repeatedly executes instructions. A simplified mental model is: Fetch → Decode → Execute → Repeat The CPU has several important pieces involved in this process. Registers are tiny, extremely fast storage locations inside the CPU. They're used to hold values the CPU is actively working with. The ALU (Arithmetic Logic Unit) performs many arithmetic and logical operations. The Program Counter (PC) keeps track of where the next instruction comes from. And the CPU runs according to a clock, measured in GHz. A 3 GHz CPU has roughly 3 billion clock cycles per second, but that does not mean it executes 3 billion instructions per second. Different instructions and architectures have different costs. Modern CPUs are far more sophisticated than this simplified model, using pipelining, multiple execution units, branch prediction, out-of-order execution, and more. But the basic model is enough to start reasoning about performance. The CPU doesn't get everything from RAM One of the most important things I learned here is that where data lives matters . A simplified hierarchy looks like: Registers ↓ L1 Cache ↓ L2 Cache ↓ L3 Cache

I've been working with software for a few years now, and I've noticed something uncomfortable. I can build things. I can work with React, Node.js, databases, APIs, cloud services, and all the usual stuff that comes with being a software engineer. But if I stop and ask: "What is the computer actually doing underneath all of this?" My mental model gets surprisingly fuzzy. I know the concepts. I've used them. I've probably explained some of them before. But knowing how to use something and understanding what is actually happening underneath it are two very different things. And I want to fix that. Why I'm writing this This isn't a course, and I'm not writing this as an expert teaching computer science. These are essentially my notes while rebuilding my computer fundamentals from the ground up . I'm trying to connect the things I use every day as a software engineer with what is actually happening inside the machine. Instead of learning concepts because they're on a traditional CS syllabus, I'm starting with a question: What do I actually need to understand to reason about a production system? For me, that means being able to look at a system and understand what's happening underneath my code. Why is something slow? Where is the bottleneck? What happens when something fails? Why does adding more memory help in one situation but not another? What actually happens when two things execute concurrently? Why does a database query become slow? What happens to a simple HTTP request between two machines? I don't want to just know the answer. I want the mental model that lets me reason about the answer . The path I'm taking I'm roughly following the layers that a typical request passes through: CPU → Memory → OS → Network → Storage → Concurrency → Distributed Systems So the series will go through: 1. What Actually Happens When Code Runs Starting from the bottom: CPU mental model, memory hierarchy, and number representation . 2. Operating Systems Then moving up into processes, th

I have a set of React components that render live telemetry: an attitude indicator, a moving map, tapes and gauges, a scrolling event log. They take a data source, subscribe to it, and paint whatever numbers arrive. That works for a live feed. The obvious next thing you want is replay: load a recorded session, scrub a timeline, watch the same instruments play it back. The naive version of this is a trap, and it took me a wrong turn to see why. My first instinct was that replay is a data problem, load the samples, push them into the components in order, done. It compiled, it ran, and the charts were empty. Not broken, not erroring. Empty. The instruments that show a single current value worked fine. The time-series charts sat blank while correct data flowed into them. That empty chart is the whole story of this post, because the reason it's empty is the reason replay is more interesting than it looks. The components are watching a clock you forgot about Here's the data source interface these components consume. It's small on purpose: interface TelemetryValue { timestamp : number ; // wall-clock, unix ms value : number ; channel ?: string ; } interface AltaraDataSource { subscribe ( callback : ( value : TelemetryValue ) => void ): () => void ; getHistory (): TelemetryValue []; readonly status : ConnectionStatus ; destroy (): void ; } A live source stamps each sample with Date.now() as it arrives. A time-series chart, reasonably, assumes that's what timestamps mean: it anchors its x-axis to Date.now() and draws a moving window of the last few seconds, discarding anything older than windowMs because that's off the left edge of the view. Now replay a session recorded an hour ago. Every sample carries its original timestamp, an hour in the past. The chart buffers them correctly, then asks "is this within the last few seconds of now?", the answer is no for every single sample, and it draws nothing. The data is all there. It's just an hour to the left of the visible window,

As a developer, I constantly end up searching for small tools to do random things. Format JSON, decode JWTs, generate UUIDs, encode URLs, compare text, convert data, and so on. I got tired of opening a different website every time, so I started building my own collection. That's CtrlTool. It currently has 132 free tools for developers and everyday tasks, with a focus on keeping them fast, simple, and easy to use. A lot of the tools process data directly in the browser when possible. https://ctrltool.wtf It's still very new, so I'd love to hear what tools you think are missing.

The React state-management debate has produced more bad takes than any other frontend topic. "Just use Context." "Redux is dead." "Zustand for everything." "Jotai is the future." All four are partially right and partially dangerous, depending on what you're building. So instead of arguing, I built the same shopping cart — derived totals, async fetch, localStorage persistence, three subscribing components — in all four libraries , and benchmarked it. This is the condensed version; the full guide (all four implementations with real code, the complete matrix, and the decision flow) is on my site 👇 Full guide: https://prepstack.co.in/blog/react-state-management-context-redux-toolkit-zustand-jotai-comparison-guide The one benchmark that reframes everything 1,000 components subscribed to one store. Update one value. How many re-render? Library Components re-rendered Wall-clock Context (single value) 1,000 (all) 42 ms Context (split into 5) ~200 12 ms Redux Toolkit (selectors) 1 2.1 ms Zustand (selector) 1 1.8 ms Jotai (atom) 1 1.5 ms Context without splitting re-renders the world. The other three are within margin of each other — meaning the real differences are boilerplate and DX , not render speed. The four, in one line each Context API — built-in, 0 KB, but every consumer re-renders on any change. Right for theme/auth/locale; wrong for anything busy or with many subscribers. Redux Toolkit — ~22 KB, most boilerplate, but RTK Query (caching, dedupe, invalidation), middleware, and time-travel DevTools are best-in-class. Payoff scales with app complexity. Zustand — ~3 KB, no provider, selectors built in, a full store (state + async + persistence) in ~25 lines. The modern default for most 2026 apps. Jotai — state is many small atoms, each with its own subscriber list. Smallest blast radius per update; ideal for forms and derived graphs. Real production migration (same e-commerce app) Metric Context-everywhere Redux Toolkit Zustand Initial JS (gzipped) 412 KB 438 KB 390 KB A

GitHub热门项目 | Layer5, expect more from your infrastructure | Stars: 1,096 | 1 star today | 语言: JavaScript

GitHub热门项目 | Source for remoteintech.company — a community-maintained directory of remote-friendly tech companies | Stars: 40,681 | 12 stars today | 语言: JavaScript

Libraries like Valtio and Pinia for Vue use a mutator pattern instead of the actions, dispatch, and...

Your modal is open, centered, perfect. Then someone flicks the overlay and the page behind it scrolls away underneath. Everyone's first fix is the same three lines: useEffect (() => { document . body . style . overflow = open ? " hidden " : "" ; }, [ open ]); It works on your laptop. Then the bug reports arrive: On iPhone the page still moves. iOS Safari rubber-band scrolls the document by touch even with overflow: hidden on <body> . Something else got wiped. "" isn't necessarily what was there before — you just erased whatever your design system or CSS-in-JS had set inline. Two overlays, one frozen page. A drawer and a lightbox both own body.style.overflow ; close them in the wrong order and the page never scrolls again. The layout jumps the instant the desktop scrollbar disappears. useScrollLock from @reactuses/core is those three lines with the hard parts handled: it restores the exact inline overflow it replaced, adds a touchmove guard on iOS that still lets your modal's own content scroll, exposes the lock as React state you can render off, and works on any element — not just <body> . This post covers what it actually does line by line, why overflow: hidden is not enough on iOS, how it compares to the position: fixed and body:has(dialog[open]) approaches, and the six gotchas that show up in real apps. Quick Start npm install @reactuses/core import { useScrollLock } from " @reactuses/core " ; import { useEffect } from " react " ; function Modal ({ open , onClose , children }: ModalProps ) { // a getter, not `document.body` — see the SSR gotcha below const [, setLocked ] = useScrollLock (() => document . body ); useEffect (() => { setLocked ( open ); return () => setLocked ( false ); // release even if we unmount while open }, [ open , setLocked ]); if ( ! open ) return null ; return ( < div className = "overlay" onClick = { onClose } > < div className = "sheet" onClick = { e => e . stopPropagation () } > { children } </ div > </ div > ); } The signature: const [

I kept running into a boring problem that was harder to debug than it should have been: text that looked normal, but behaved wrong the moment I pasted it into a CMS, a spreadsheet, or a code comment. Search would fail. Line breaks would get weird. A heading copied from ChatGPT would drag Markdown markers along with it. Sometimes the only visible clue was that the punctuation felt slightly "off." What finally made this manageable wasn't some big NLP trick. It was going back to the dumb, reliable layer: exact character matching. The tool I built for this is basically a pile of small, deterministic cleanups for the specific junk that copied text tends to accumulate — full-width punctuation mixed into ASCII, invisible Unicode code points, curly quotes, em dashes, leftover Markdown, and whitespace noise. The most useful part is the invisible-character scan, not the cleaning The piece I trust most in the whole component is the part that explicitly names which invisible characters it cares about, then counts them by code point. It's not doing a vague "this text seems suspicious" pass. It has a hard-coded inventory: const invisibleDefs = [ { key : " zwsp " , codes : [ 0x200b ] }, { key : " zwnj " , codes : [ 0x200c ] }, { key : " zwj " , codes : [ 0x200d ] }, { key : " bomZwnbsp " , codes : [ 0xfeff ] }, { key : " wordJoiner " , codes : [ 0x2060 ] }, { key : " softHyphen " , codes : [ 0x00ad ] }, { key : " bidiMarks " , codes : [ 0x200e , 0x200f , 0x202a , 0x202b , 0x202c , 0x202d , 0x202e ] }, ]; const codesToRegex = ( codes ) => new RegExp ( `[ ${ codes . map (( c ) => " \\ u " + c . toString ( 16 ). padStart ( 4 , " 0 " )). join ( "" )} ]` , " g " ); const analyzeInvisible = ( str ) => { const breakdown = invisibleDefs . map (( def ) => ({ key : def . key , count : ( str . match ( codesToRegex ( def . codes )) || []). length , })); const total = breakdown . reduce (( sum , row ) => sum + row . count , 0 ); return { breakdown , total }; }; I like this because it's brutall

React Router v8 was released on June 17, 2026, with minimal breaking changes and new baselines. Key updates include an ESM-only build and default middleware settings. React Router v6 and Remix v2 have reached End of Life. Developers should follow specific migration guidelines to update their applications, while some are considering alternatives like TanStack Router. By Daniel Curtis

I didn't want to write another "what's new in Next.js 16.3" post. Enough of those exist. I wanted to...

Hace unos meses empecé a construir Utiligo , una colección de calculadoras en español: horas extras, IVA, aguinaldo, préstamos, IMC. La premisa técnica era simple y me la tomé en serio: cero dependencias de JavaScript en el navegador . Sin React, sin frameworks de UI, sin librerías de gráficos. Ni una. Esto es lo que aprendí construyéndolo. Por qué cero dependencias La mayoría de estas herramientas hacen aritmética. Sumar horas, aplicar un porcentaje, dividir un salario entre 30. Enviar 40 KB de framework al navegador para calcular salario / 30 / 8 es desproporcionado, y en América Latina —donde está mi audiencia— buena parte del tráfico llega por móvil con conexiones irregulares. El stack quedó así: Astro en modo output: 'static' , que genera HTML puro <script is:inline> con JavaScript de toda la vida para la interactividad Cloudflare Pages para servirlo El resultado: páginas que funcionan antes de que termine de cargar cualquier cosa. Lo que sí duele de esta decisión Sería deshonesto contarlo como si no tuviera costes. Los gráficos hay que dibujarlos a mano. El gráfico de pastel del presupuesto mensual es SVG generado con trigonometría: var end = start + pct * 2 * Math . PI ; var x1 = cx + r * Math . cos ( start ), y1 = cy + r * Math . sin ( start ); var x2 = cx + r * Math . cos ( end ), y2 = cy + r * Math . sin ( end ); var large = pct > 0.5 ? 1 : 0 ; svg += ' <path d="M ' + cx + ' , ' + cy + ' L ' + x1 + ' , ' + y1 + ' A ' + r + ' , ' + r + ' 0 ' + large + ' ,1 ' + x2 + ' , ' + y2 + ' Z"/> ' ; Con una librería serían tres líneas. Aquí son treinta y hay que entender el arco elíptico de SVG. ¿Vale la pena? Para un gráfico, sí. Para un dashboard entero, probablemente no. No hay reactividad. Cada oninput actualiza el DOM a mano. Funciona bien con diez campos; con cien sería insostenible. El generador de QR tuve que escribirlo. Codificación Reed-Solomon incluida. Fue el fin de semana más educativo del proyecto y el que menos recomendaría repetir. El bug que me enseñó

I built Suzi Chat to bring back the nostalgic feel of late-90s/early-2000s browser chat rooms. Key Features: Create and customize your own public or private chat rooms instantly from the browser. Built-in multiplayer casual board games (Chess, Checkers, Gomoku). No complicated setup—straightforward web-based access. Built using a NestJS backend and running on a dedicated Linux VPS. Live Platform: https://suzichat.com Looking for feedback from other developers on the UI layout, room creation flow, and multiplayer lobby stability.

The Quest Begins (The "Why") Hey friend, picture this: you’re happily writing JavaScript, tossing objects around like confetti at a parade, and then you decide to give Rust a spin. You open the compiler, write a simple function that returns a slice of a vector, and boom— error[E0505]: cannot move out of … because it is borrowed . Your brain does a double‑take. “Wait, I didn’t even touch anything!” you mutter, staring at the screen like you just missed a plot twist in Inception . That moment was my dragon. I’d spent years trusting the garbage collector to clean up after me, and Rust’s ownership system felt like a strict sensei who wouldn’t let you leave the dojo until you bowed correctly. I was frustrated, curious, and honestly a little scared. But once I grasped the core ideas, the whole language started to click like a well‑oiled machine. So why does ownership matter? Because it gives you memory safety without a runtime garbage collector. No surprise pauses, no hidden allocations—just compile‑time guarantees that your program won’t dereference null or use‑after‑free. For a JS dev used to “it just works”, that’s a superpower worth earning. The Revelation (The Insight) The big surprise? Ownership isn’t just about who “owns” a value; it’s about how that value can be accessed, moved, or borrowed at any point in the program. Three rules govern everything: Each value has a single owner. When the owner goes out of scope, the value is dropped. You can either have one mutable reference or any number of immutable references to a value, but never both at the same time. Sounds simple, right? The gotcha is that Rust treats references as a separate kind of value with its own lifetime. If you try to store a reference beyond the lifetime of what it points to, the compiler says “nope”. This is where many JS devs stumble because in JavaScript a reference (or variable) just points to an object that lives as long as something else holds it—garbage collection decides when it’s gone. Le

I used to think a bulk date converter was basically a dropdown wrapped around a date library. Paste a bunch of rows, pick YYYY-MM-DD , done. Then you look at real exports from spreadsheets, CRMs, logs, and old internal tools and realize the problem isn't "formatting" at all. It's triage. Some rows are obvious. Some are malformed. Some have month names. Some came from a CSV with five unrelated columns. And then there's the classic cursed input: 01/02/2024 , which is either January 2 or February 1 depending on who produced the file. The Vue component behind this tool is interesting because it doesn't pretend that ambiguity goes away if you call the right parser. It models that ambiguity explicitly. It starts by assuming uploaded files are messy, not clean One thing I liked in the source is that it doesn't treat file input as a single happy path. If you upload a TXT file, it works line by line. If the upload looks CSV-ish, it switches into a tiny parser and then tries to figure out which column is actually the date column. The CSV split logic is manual instead of using a naive line.split(",") , which matters because quoted commas are a real thing in exports: const splitCsvLine = ( line ) => { const result = []; let cur = "" ; let inQuotes = false ; for ( let i = 0 ; i < line . length ; i ++ ) { const ch = line [ i ]; if ( ch === ' " ' ) { if ( inQuotes && line [ i + 1 ] === ' " ' ) { cur += ' " ' ; i ++ ; } else { inQuotes = ! inQuotes ; } } else if ( ch === " , " && ! inQuotes ) { result . push ( cur ); cur = "" ; } else { cur += ch ; } } result . push ( cur ); return result . map (( s ) => s . trim ()); }; After that, it doesn't ask the user to map columns immediately. It scores each column by counting how many cells look like dates, then auto-selects the best candidate: for ( let c = 0 ; c < maxCols ; c ++ ) { const count = dataRows . filter (( r ) => isLikelyDateCell ( r [ c ])). length ; columns . push ({ index : c , header : headerRow ? headerRow [ c ] : "" }); i

MergePDF is a 100% client-side PDF tool. No backend, no uploads, no sign-up. Here's the architecture, the tricky parts, and why privacy is a feature, not a setting. Every tax season, the same thing happens. Someone in my family asks me to merge a few PDFs. They Google "merge PDF." They click the first result — a slick, friendly-looking site. They upload their tax returns to a server they've never heard of. That bothered me. So I built MergePDF. It merges, splits, rotates, and rearranges PDF pages — and your files never leave your browser. No backend. No sign-up. No ads. No tracking. iLovePDF uploads your tax returns. We don't. This post is about how it works, the parts that were harder than I expected, and why "client-side only" is a design philosophy, not just a technical choice. The pitch in 30 seconds Drop one or more PDFs onto the page. You get a grid of page thumbnails — real, rendered previews of every page. Drag to reorder. Click to select. Rotate, delete, extract a range. Merge everything into one file, or split into single-page PDFs zipped up. Download. Done. Your browser does all of it. There is no server processing documents. There isn't even a server to process documents. The stack It's a Next.js app, but honestly Next.js is just the host here. The interesting parts are all client-side libraries doing real work: No database. No API routes. No auth. No analytics. The only thing in localStorage is your theme preference. Drag-to-reorder that doesn't fight tap-to-select This one took three attempts. The requirement: Tap a thumbnail → select it (emerald ring) Shift-tap → select a range Long-press + drag → reorder Swipe on mobile → scroll the grid (don't drag) The conflict: if the whole card is the drag handle, taps get swallowed. If only a tiny grip icon is the handle, nobody finds it (especially on mobile, where there's no hover). So split produces a ZIP. fflate's zip packages every single-page PDF into one download. Rotations are honored here too — each spl

MOKSHA — v0.1.1 Devlog Date: 2026-08-18 Milestone: v0.1.1 — https://github.com/weirdcodesofficial/MOKSHA/milestone/11 Highlights Major mobile-focused performance work: reduced per-frame CPU/GPU cost in render path. Replaced hot trig math with a lookup table (LUT) to remove repeated Math.sin/cos calls. Cached per-frame gradients and reduced expensive shadowBlur calls to lower GPU blur passes. Added quality-tier controls and explicit render-state resets for more predictable mobile behaviour. v0.1.1 release PR merged. Merged pull requests (summary) PR #147 — perf(render): replace remaining Math.sin/cos with lutSin/lutCos Replaced ~25 per-frame trig calls in drawScene() with reads from the existing 2048-entry radian LUT (affects ring ticks, pulses, orbit waves, arc heads, timer pill pulses, etc.) — reduces CPU trig cost significantly. https://github.com/weirdcodesofficial/MOKSHA/pull/147 PR #145 — render: Done gradient caching. Implemented caching/baking for commonly created gradients and offscreen sprites (pickup glow, naama, chakravaata, rein gradient buckets) to avoid per-frame gradient allocations and GPU work. https://github.com/weirdcodesofficial/MOKSHA/pull/145 PR #144 — render: quality tier control, explicity reset, 40 shadowBlur calls wr… Added device/quality-tier checks to disable or lower shadowBlur on low-end devices; isolated shadowBlur via save()/restore() and explicit ctx.shadowBlur = 0 resets to avoid leaks. GPU blur pass count reduced. https://github.com/weirdcodesofficial/MOKSHA/pull/144 PR #146 — V0.1.1 (release PR) — bump / release merge. https://github.com/weirdcodesofficial/MOKSHA/pull/146

TypeScript 6.0 Strict Function Types: Why Contravariance Breaks Your Existing Callbacks This article was written with the assistance of AI, under human supervision and review. Most TypeScript migration failures stem from a single misunderstood compiler flag: strictFunctionTypes . The pattern that breaks production is deceptively simple—a callback that accepts a base type where the consumer expects a derived type. TypeScript 6.0 enables strict mode by default, which means codebases that never configured contravariance checking will fail to compile overnight. The failure mode here is subtle but expensive. A callback registered to an array method expects Animal , but the implementation passes Dog . Pre-6.0 TypeScript allowed this through bivariant parameter checking. Post-6.0, the compiler rejects it as unsafe. Teams scramble to fix hundreds of type errors without understanding the underlying variance rules, often choosing any or incorrect casts that introduce runtime bugs. The distinction between function properties and method signatures becomes critical—one enforces contravariance, the other permits bivariance for historical reasons. %% alt: Bivariant checking allows derived types where base types are expected The correct approach requires understanding contravariance: function parameters must accept types that are the same or less specific than what the function signature declares. When strictFunctionTypes activates, TypeScript enforces this rule for function properties but not method signatures. The solution is not to weaken types with any , but to restructure callbacks using proper variance-aware patterns or switch to method syntax where bivariance is intentional. %% alt: Contravariant checking enforces parameter safety at compile time This matters because the TypeScript 6.0 ecosystem assumes strict mode. Third-party libraries ship types built for contravariance. Disabling strictFunctionTypes to silence errors creates a type system that diverges from reality, wher