标签：#web

I built a small index basket app on Robinhood Chain because I wanted to understand the developer path from the first contract deploy all the way to a working frontend. The app is intentionally plain: a user deposits Stock Tokens, which are blockchain tokens that represent real equity exposure, and receives an ERC-20 basket share. ERC-20 is Ethereum's standard token interface, so a compatible token exposes familiar methods like balanceOf , transfer , and approve . The basket share is priced from live price feeds, and the user can redeem it back into the underlying Stock Tokens. That's the part that made this interesting to me. The chain is custom, but the app path is not. I still wrote Solidity, deployed with Foundry, read contract state with viem, and wrote transactions from React with wagmi. If you've built normal web apps, think of the chain's RPC endpoint as the API base URL. A wallet is login plus a signing key. A smart contract is backend code you deploy to the chain, except you should treat it like immutable infrastructure because you don't get to hot-patch it casually later. The demo and source are here: App: https://robinhood-chain-dapp.vercel.app/ Code: https://github.com/hummusonrails/robinhood-chain-dapp-example The custom chain still feels like the EVM Robinhood Chain is a custom Arbitrum Chain, which means it runs as a dedicated chain on the stack of Arbitrum, an Ethereum scaling system. It is also EVM-compatible. EVM means Ethereum Virtual Machine, the runtime that executes Solidity contracts, so the tooling surface looks like the Ethereum developer flow many tutorials already teach. An L2, or rollup, is a chain that executes transactions separately and then posts compressed proof or transaction data back to Ethereum. Robinhood Chain uses Ethereum blobs for data availability, which is a cheaper Ethereum data lane for rollups to publish the data needed to reconstruct chain state. Gas, the metered compute fee you pay to run transactions, is paid in ETH.

Disallow: GPTBot is a wall. Walls don't pay rent, and the crawlers that matter most either ignore them or route around them. If your content is worth training on, the interesting question isn't "how do I keep the bots out" — it's "what do they owe me, and how do I say so in a way a machine can read." That's what RSL (Really Simple Licensing) is for. It shipped 1.0 in December 2025 with around 1,500 publishers behind it — Reddit, Yahoo, Quora, O'Reilly, Medium, Vox. This post is a from-scratch walkthrough of what the format actually is, the six places you can put it, the one mistake that makes crawlers silently ignore your terms, and where the declaration stops and enforcement begins. No tooling required to follow along — it's all plain XML and HTTP. The format is an XML vocabulary, not a config file An RSL document says: for this content, here's what's permitted, what's prohibited, and what it costs. Minimal example: <?xml version="1.0" encoding="UTF-8"?> <rsl xmlns= "https://rslstandard.org/rsl" max-age= "7" > <content url= "/" > <license> <permits type= "usage" > search </permits> <prohibits type= "usage" > ai-train </prohibits> <payment type= "crawl" > <amount currency= "USD" > 0.015 </amount> </payment> </license> </content> </rsl> Read it out loud: search engines may index this; training on it is prohibited; if you want to crawl it anyway, the rate is $0.015. usage tokens include search , ai-train , ai-use (inference/grounding), and a few more. You can scope rules by user and geo too. One rule that trips people up: prohibition wins . If the same token shows up under both permits and prohibits , the content is prohibited. Don't try to express "allowed except for X" by listing X in both — just prohibit X. The namespace is the thing crawlers actually key on The single most common way to publish RSL that quietly does nothing: getting the namespace wrong. It must be exactly: xmlns="https://rslstandard.org/rsl" http instead of https , a trailing slash, or a plausible

hi, i am Aniruddha Adak, a full-stack developer from kolkata who spends way too much time building things with ai tools, shipping apps, and reading way too many github readmes at 2 am. i built 27 apps in 45 days using no-code and ai tools last year. that experience taught me one thing very clearly: the landscape of ai tooling for developers is moving insanely fast, and it is genuinely hard to keep up. so i sat down and did something about it. this is my deep research post on every ai tool, agent, builder, reviewer, and framework that developers, software engineers, and ai engineers should actually know about right now. i have organized it into categories so you can find what you need quickly. no fluff. just the tools, their sites, and what they do. why i wrote this i keep seeing developers waste time because they do not know the right tool exists. someone is manually reviewing pull requests for a week straight, not knowing coderabbit exists. someone else is hand-writing supabase schemas when emergent can do it in seconds. another person is spending days on a landing page when v0 can scaffold it in one prompt. this post is my attempt to fix that. i went through github repositories, dev communities, product hunt launches, and research aggregators to compile this. it is long. that is intentional. bookmark it. section 1: ai-native ides these are not just editors with a chatbot plugged in. these are environments built from the ground up around how language models think and work. tool site what it does cursor https://www.cursor.com forked vscode, codebase-aware context windows, multi-file edits with copilot-style background indexing windsurf https://windsurf.com cascade ai agent that writes files, runs terminal checks, and fixes things in real-time zed https://zed.dev built in rust with gpui, super low latency, native multiplayer coding support replit https://replit.com cloud ide with a full autonomous agent that runs inside serverless virtual workspaces google antigravit

Most things that ship under "browser MCP" are the same thing wearing different names: an autonomous agent with a do-anything tool, pointed at your browser, told to figure it out. The pitch is capability. The unspoken cost is that a runtime which can do anything can be steered into doing anything. We just published the opposite, and we published it in the open. github.com/e2llm/e2llm-sifr is now the canonical home for SiFR - the format spec, the taxonomy, the MCP server manifest, real page captures, per-client configs, and the model skill. MIT-licensed. The capture engine and the server stay a hosted product; the format and the interface are open. This post is about why that split is the whole point. E2LLM is not an agent This comes first because everything else follows from it. An agent decides and acts on its own. It plans, it loops, it takes steps toward a goal with you out of the path. That autonomy is the feature - and it is also the attack surface. A runtime that can do anything is a runtime that can be talked into anything. E2LLM is a perception layer, not an agent. It gives whatever model you already use senses for the browser: structured sight, and a small set of narrow, individually-gated actuators. It does not plan, does not loop, does not decide. Your model does the reasoning. E2LLM reports what a page is and carries out one explicit instruction at a time. Nothing runs while you look away. Perception substrate versus autonomous runtime. That line is the design, not a disclaimer on top of it. What SiFR is - and the three things it isn't SiFR (Salience-Indexed Flat Relations) is the capture format at the center of E2LLM. From a distance it can look like a tidy DOM dump or an accessibility tree. Mechanically it is neither, and the difference is the entire value. Not a DOM dump. A dump serializes the tree as-is: everything, in document order, noise included. SiFR selects and ranks. It scores every node by salience, drops scaffolding, and flattens the survivor

Playing the game of writing technical post was funny two years ago. Now, I am a mod and it is...

Earlier this month I shipped two premium templates — a SaaS landing page and a developer portfolio. Not a startup, not a SaaS, just templates. This post is about the two constraints I built them under, why they made the code better, and a few things I learned launching as a solo dev with zero audience. Constraint 1: zero dependencies beyond next, react, and tailwind Open the package.json of most templates and you'll find 20+ packages: icon libraries, animation libraries, carousel plugins, UI kits, utility libraries. Every one of them is a version conflict waiting to happen for the buyer, and most are replaceable with a few lines of code in 2026. What I used instead: Icons → inline SVG components. An icon component is ~10 lines. You need maybe 15 icons for a landing page. Animations → plain CSS. Scroll-blur navbars, gradient glows, an animated "typing" terminal — all doable with keyframes and transitions. No framer-motion. The dashboard mockup in the hero → pure CSS. Divs, borders, gradients. It looks like a product screenshot but it's ~80 lines of JSX and weighs nothing. Result: both templates land at ~100KB first-load JS, npm install takes seconds, and there is nothing to break when Next.js 16 arrives. Constraint 2: every piece of content in ONE typed config file The thing I hated most about templates I've used: content is smeared across 30 components. Changing a headline means hunting through JSX. So both templates keep all content in a single file — lib/content.ts for the landing page, site.config.ts for the portfolio. Headlines, nav, pricing tiers, testimonials, project lists, even the lines that animate in the fake terminal. Components are pure renderers of that config's TypeScript type. Two things surprised me here: TypeScript becomes your content linter. Forget an alt text, malform a link, give a pricing tier three features when the type expects a non-empty array — the build fails. Content mistakes surface at compile time. It forces better component design. W

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

You set up Puppeteer, navigate to a page, call page.screenshot() , and the bottom half of your image is blank placeholder boxes. Welcome to lazy loading. Most modern sites defer images and heavy content until the user scrolls. Your headless browser never scrolls. So those elements never load. Here's how to deal with it. The scroll trick The most common fix is to programmatically scroll down the page before taking the screenshot: async function scrollToBottom ( page ) { await page . evaluate ( async () => { const delay = ms => new Promise ( r => setTimeout ( r , ms )); const distance = 300 ; while ( window . scrollY + window . innerHeight < document . body . scrollHeight ) { window . scrollBy ( 0 , distance ); await delay ( 150 ); } window . scrollTo ( 0 , 0 ); }); } await page . goto ( " https://example.com " , { waitUntil : " networkidle2 " }); await scrollToBottom ( page ); await page . waitForTimeout ( 1000 ); await page . screenshot ({ fullPage : true }); The 150ms delay between scrolls gives IntersectionObserver -based lazy loaders time to trigger. Too fast and you'll scroll past elements before they start loading. That final waitForTimeout after scrolling back to top lets any remaining images finish rendering. Not elegant, but necessary. Why networkidle2 isn't enough You'd think waitUntil: "networkidle2" would handle this. It waits until there are no more than 2 network connections for 500ms. But lazy-loaded images haven't even been requested yet at that point — they're waiting for a scroll event that never happens. networkidle2 only helps with content that loads on page init. For scroll-triggered content, you need the scroll. The loading="eager" override Some sites use the native loading="lazy" attribute. You can override it before images load: await page . evaluateOnNewDocument (() => { Object . defineProperty ( HTMLImageElement . prototype , " loading " , { set : function ( val ) { this . setAttribute ( " loading " , " eager " ); }, get : function () { retu

Hi, my name's Ibrahim, I'm a university student, and I have a problem: I love fragrances way more than my bank account loves me for it. It started small, the way these things always do. A cheap Middle Eastern attar someone gave me as a gift, the kind that costs less than a coffee but somehow smells like it belongs in a much fancier bottle. Then another. Then I started actually reading about notes, pyramids, accords, sillage, the whole rabbit hole. Fast forward through a lot of saved-up allowance and skipped nights out, and I've now got about 20 bottles on my shelf. Mostly affordable Middle Eastern gems (some of them genuinely punch way above their price), with a small handful of designer pieces I saved up for and treat like trophies. If you're a fellow fragrance enthusiast, you already know the feeling: you don't just "wear" a scent, you collect them, you study them, you have opinions about whether a note is top, heart, or base and you will absolutely fight someone about it. That obsession is basically the entire reason this project exists. So when I saw the DEV Weekend Challenge's "Passion" prompt, there was only one thing I could possibly build. What I built: recommendmeafragrance recommendmeafragrance is a browser arcade for fragrance nerds: six small daily games built around real perfume data (notes, brands, years, price tiers), plus an AI Concierge you can actually talk to about what you're in the mood for. Every game feeds into a personal "shelf" that tracks which fragrances you've discovered, plus streaks so you have a reason to come back tomorrow. Here's the tour. 🧪 Scentle: Wordle, but for your nose A new fragrance is picked every day (the same one for everyone, worldwide, no matter your timezone). You get 6 guesses, and after each one you get Wordle style feedback: was the brand exact or just the same house family, did the real answer come out earlier or later than your guess, is it pricier or cheaper, same gender, same concentration, how many notes do you

This is a submission for Weekend Challenge: Passion Edition What I Built I built Passion...

This is a submission for Weekend Challenge: Passion Edition (#weekendchallenge #devchallenge #ai #googleai #gemini #webdev #showdev) What if your GitHub could roast you harder than your teammates ever would — and then remind you why you keep building? What I Built 🔥 roaster0 — an AI that roasts your GitHub profile, then redeems you. Drop in any public GitHub username and it pulls your real repo data — commit habits, abandoned projects, lazy repo names, language choices — and turns it into a savage, hyper-specific roast using Gemini's structured output and multimodal reasoning. Then it ends with one sincere, earned compliment pulled from something genuinely good in your data. The idea started from a simple thought: your GitHub is an involuntary diary of what you were obsessed with. The eleven repos with no description. The final-v2-FINAL commit. The side project you lived and breathed for three weeks in March before abandoning it. That's passion — messy, obsessive, usually invisible unless someone points a spotlight at it. There's also a second mode, 🎭 Roast Anything : submit a name, bio, links, and/or images, and Gemini reads all of it — text, links, photos — to generate the same experience for anyone, not just developers. Demo 🔗 Live app: roaster0.netlify.app Try it on any public GitHub username, or switch to Roast Anything mode and paste in a bio + an image to see the multimodal analysis at work. Once your roast is generated, you can: 🔊 Listen to it — full audio narration via Web Speech API, paced and pitched differently depending on roast intensity 🖼️ Download the card — every roast renders as a shareable PNG on HTML5 Canvas, ledger-paper aesthetic, ready to post 📋 Share the record — copy a formatted text version straight to clipboard for any platform A couple of examples from testing: GitHub mode — roasted DEV's own founder using nothing but his real public repo data: (screenshot: Ben Halpern roast card — graveyard count, repo names like oceanic-giraffe and test

You've got a JSON API response and you want TypeScript interfaces for it. Here's how to generate them fast — and where the auto-generators quietly get it wrong. The fast path Paste your JSON, get interfaces: { "id" : 1 , "name" : "Ada" , "roles" : [ "admin" ], "profile" : { "active" : true } } → interface Root { id : number ; name : string ; roles : string []; profile : Profile ; } interface Profile { active : boolean ; } jsonviewertool.com/json-to-typescript does this in the browser (client-side), nesting objects into their own interfaces. Where generators trip up A generator only sees the ONE sample you give it, which causes predictable gaps: Nullable fields. If your sample has "avatar": null , the generator infers null — but the real type is probably string | null . Feed it a populated sample, or fix it by hand. Empty arrays. "tags": [] infers any[] — the element type is unknowable from an empty array. Optional fields. A field missing from your sample won't appear at all. If the API sometimes omits middleName , mark it middleName?: string . Unions. A status that's "active" in your sample becomes string , not the literal union "active" | "banned" | "pending" . Narrow it manually for the safety. Numbers that are really enums or IDs. "currency": 840 types as number ; you may want an enum or branded type. When to use a schema instead If the JSON has a JSON Schema or OpenAPI spec, generate types from that ( json-schema-to-typescript , openapi-typescript ) — it encodes nullability, optionality, and unions the raw sample can't. Sample-based generation is for quick throwaway typing; schema-based is for anything you'll maintain. Rule of thumb Generate from a sample to skip the boilerplate, then read every field — the generator gives you a draft, not a contract. Nullability and optional fields are where the runtime bugs hide.

I built a chat widget for my portfolio. One script tag, drop it on a page, and recruiters can ask questions about my projects, my AWS internship, what I actually know, and what kind of roles I'm looking for. I named the assistant Scout. <script src= "https://bradleymatera.github.io/ProjectHub/ProjectHub.js" ></script> That's the whole pitch from the outside. What it took to get there is a lot messier than one script tag suggests. The current version has a vanilla JS frontend, a Node backend on a Google Cloud e2-micro VM, a knowledge base pulled from GitHub, a network of free LLM providers, a response cache, per-tab memory, safety checks, a self-improvement loop, and an analytics dashboard. It also has six test suites and more documentation than I expected. The one rule I kept coming back to: it had to stay useful without me paying for AI traffic. Why I built this in the first place My portfolio is scattered. Projects live on GitHub, demos live on various subdomains, blog posts are on the site, certifications are listed somewhere, and my actual AWS internship experience is explained in a few different places. A motivated recruiter could piece it all together, but most recruiters are not motivated. They are busy. I realized I was asking them to do homework. That seemed backwards. So I thought, what if they could just ask? Scout is supposed to answer straight questions like "What is Bradley's strongest project?" or "Does he actually have production AWS experience?" or "What does he want to be paid?" It doesn't pretend to be me, doesn't inflate my title, and doesn't try to sell me as a senior engineer when I'm not one. It just answers from verified stuff. The architecture Three layers. Site loads one script. The script hits the backend. The backend either answers from the knowledge base or falls through to free LLM providers. flowchart TD A[Website or portfolio] -->|loads one script| B[ProjectHub widget on GitHub Pages] B -->|POST /api/chat| C[Node.js API on a GCP e2-mi

Everyone can type "use client" . Almost nobody can say what survives the trip across it — and then something breaks: next build dies at prerender, the error names no file and no import chain, and the prop that killed it was an arrow one level down inside an object called options . Here's the uncomfortable secret: the boundary is one serializer . React walks every prop you hand a client component, encodes each value it has a branch for, and throws on the first one it doesn't. This post reads those branches out of React 19's Flight source — one file, no framework — and shows the two traps that pass code review and fail the build anyway. What crosses A prop is legal if the serializer has a branch for it. Everything else falls into one prototype check and throws. The whole contract fits on a screen: // app/page.tsx — a Server Component. Every comment is the serializer's verdict. export default function Page () { return ( < Chart title = "Q3" data = { { rows : [ 1 , 2 , 3 ] } } when = { new Date () } seen = { new Set ([ 1 ]) } index = { new Map () } rows = { fetchRows () } // an un-awaited Promise; the client calls use(rows) bytes = { new Uint8Array ( 8 ) } // ArrayBuffer, DataView, every typed array upload = { new File ([], ' a.csv ' ) } // there is no File branch — a File is a Blob form = { new FormData () } stream = { new ReadableStream () } kind = { Symbol . for ( ' chart ' ) } // global symbols cross; Symbol('chart') throws Slot = { Legend } // a client component: a function, and a client reference save = { saveRow } // a "use server" function: a server reference err = { new Error ( ' boom ' ) } // crosses — and arrives empty in production // no branch — every one of these throws at render match = { /q3/ } href = { new URL ( ' https://x.dev ' ) } cache = { new WeakMap () } user = { new User ( ' ada ' ) } bare = { Object . create ( null ) } onPick = { ( id ) => select ( id ) } /> ); } Four of those lines are the ones people get wrong: new Error() crosses, and product

Have you ever wondered why your most personal health queries need to travel across the globe to a centralized server just to get a simple answer? In an era where privacy-preserving AI is becoming a necessity rather than a luxury, the paradigm of Edge AI is shifting the landscape. By leveraging WebLLM and the raw power of WebGPU , we can now execute high-performance Large Language Models (LLMs) directly within the browser sandbox. No API keys, no server costs, and most importantly—zero data leakage. Today, we are building a private health consultation bot that runs 100% client-side. Why Browser-Native LLMs? 🥑 Before we dive into the code, let’s talk about why this matters. Traditional AI architectures rely on heavy GPU clusters. However, with the advent of the WebGPU API, we can tap into the user's local hardware. This approach offers: Ultimate Privacy : Data never leaves the browser. Cost Efficiency : $0 server bills for inference. Offline Capability : Once the weights are cached, you're good to go. If you are interested in more production-ready examples and advanced architectural patterns for decentralized AI, I highly recommend checking out the deep dives over at WellAlly Tech Blog . The Architecture: From Weights to Wasm To make this work, we use TVM (Apache TVM) as the compilation stack, which allows models to run on different backends, and WebLLM as the high-level interface for the browser. Data Flow Diagram graph TD A[User Input] --> B[React Frontend] B --> C[WebLLM Worker] C --> D{WebGPU Support?} D -- Yes --> E[TVM.js Runtime] D -- No --> F[Fallback/Error] E --> G[IndexedDB Model Cache] G --> H[Local GPU Inference] H --> I[Streamed Response] I --> B Prerequisites 🛠️ To follow this tutorial, ensure you have: A browser with WebGPU support (Chrome 113+, Edge, or Arc). Node.js and npm/pnpm installed. The tech_stack : React , WebLLM , TVM , and Vite . Step 1: Setting Up the WebLLM Engine First, we need to initialize the MLCEngine . Since LLMs are heavy, we should

Headline: React Compiler — formerly React Forget — shipped stable with React 19 and automatically memoizes components, hooks, and callbacks by analyzing data flow at build time. No dependency arrays to write; the compiler infers them. Here is what it handles, when it opts out, and whether you should delete your useMemo calls. Key takeaways React Compiler inserts useMemo , useCallback , and React.memo automatically at build time — no dependency arrays to maintain. Enable it in Next.js 15/16 with experimental.reactCompiler: true in next.config.ts . The compiler is conservative: if it cannot prove memoization is safe, it emits the component unchanged. "use no memo" is the escape hatch for functions the compiler should not touch. Run npx react-compiler-healthcheck@latest before enabling to see coverage and violations. What does React Compiler actually do? React Compiler transforms component and hook code at build time to insert memoization automatically. Instead of useMemo(() => expensiveCalc(a, b), [a, b]) , the compiler analyzes data flow, determines which values are stable across renders, and emits equivalent memoized code. The compiled output uses React's memo infrastructure at runtime. The compiler is babel-plugin-react-compiler — it works with any Babel-based build pipeline. How do I enable it in Next.js? // next.config.ts const nextConfig = { experimental : { reactCompiler : true , }, }; export default nextConfig ; Before enabling, run the healthcheck: npx react-compiler-healthcheck@latest The healthcheck reports optimizable component count, files with violations, and blocking patterns. Fix violations first for more coverage on day one. What does the compiler memoize? Components — equivalent to React.memo ; re-renders only when props change. Values — equivalent to useMemo ; computed results, derived arrays, objects. Callbacks — equivalent to useCallback : event handlers, functions passed as props. Dependencies are inferred from escape analysis — n

Headline: Partial Prerendering (PPR) in Next.js serves a static HTML shell from the CDN edge instantly, then streams Suspense-wrapped dynamic children from the origin in the same HTTP response. No full-page ISR staleness, no full-page origin latency. I shipped it on two production routes — here is the model. Key takeaways PPR serves a static HTML shell from the CDN edge , then streams dynamic Suspense children from the origin in the same response. The static shell is built at build time — outside <Suspense> renders statically; inside renders dynamically per request. PPR replaces the ISR vs. dynamic tradeoff for pages that are mostly static with isolated personalized sections. No changes to Server Components or Suspense — just experimental.ppr: 'incremental' in config and export const experimental_ppr = true per route. PPR and use cache are complementary : CDN delivery for the shell, origin memoization for dynamic islands. What does PPR actually do? PPR splits a page into two rendering phases within the same HTTP response. At build time, Next.js freezes everything that does not read dynamic request data into a static HTML shell on the CDN edge. At request time, the CDN delivers the shell at edge latency while the origin streams each <Suspense> boundary's content into the same response. On a product page: navigation, title, and description arrive at CDN speed. The in-stock badge and personalized recommendations stream from the origin a fraction of a second later. The user sees a nearly-complete page immediately. How is PPR different from ISR and streaming Suspense? Strategy First byte Dynamic freshness Staleness ISR (revalidate: N) CDN edge Whole page up to N seconds stale Full page Dynamic rendering Origin 100% fresh; waits for slowest query None Streaming Suspense (no PPR) Origin Fresh; TTFB includes origin latency None PPR CDN edge Dynamic islands 100% fresh Static shell only How do I enable PPR? // next.config.ts export default { experimental : { ppr : ' inc

Check this out: migrating Off OpenAI: A Backend Engineer's Notes From Production I still remember the morning I opened our team's monthly invoice and nearly spilled cold brew on my mechanical keyboard. We were burning through OpenAI credits like it was nobody's business — specifically, north of $500/month for what amounted to a chat-completion endpoint and some embedding lookups. As the backend engineer who had inherited the LLM integration six months prior, I felt personally responsible. So I did what any self-respecting engineer does at 2 AM with too much caffeine: I benchmarked alternatives. What I found annoyed me. DeepSeek V4 Flash was sitting there at $0.25/M output tokens while GPT-4o charges $10.00/M. That's a 40× price difference for output that, in my blind tests, 80% of users couldn't distinguish. The $500/month bill could plausibly become $12.50. My CFO would weep tears of joy. This post is the migration journal I wish I'd had before I started. fwiw, I've already done the swap across three production services. Here's what worked, what didn't, and exactly how much coffee I drank. The Math That Made Me Pick Up a Keyboard Before I show you code, let's talk numbers — because if you're going to convince your team or your boss, you'll need a slide that fits on one screen. I pulled together the pricing for the models I actually considered routing traffic through. All figures are per million tokens, USD: Model Provider Input $/M Output $/M Relative to GPT-4o GPT-4o OpenAI $2.50 $10.00 1× (baseline) GPT-4o-mini OpenAI $0.15 $0.60 16.7× cheaper DeepSeek V4 Flash Global API $0.18 $0.25 40× cheaper Qwen3-32B Global API $0.18 $0.28 35.7× cheaper DeepSeek V4 Pro Global API $0.57 $0.78 12.8× cheaper GLM-5 Global API $0.73 $1.92 5.2× cheaper Kimi K2.5 Global API $0.59 $3.00 3.3× cheaper Let me be clear about something: those numbers come straight from the provider's pricing pages at the time I ran the analysis. I have not invented, rounded up, or "adjusted" anything her

Headline: Tailwind v4 is the most significant rewrite since the framework launched — CSS-first config, Lightning CSS under the hood, container queries built-in, and no more tailwind.config.js . I migrated two production projects and here's what actually broke and what the upgrade tool misses. Tailwind CSS v4 arrived with a steeper upgrade curve than most version bumps in the JS ecosystem. The configuration story changed completely. The build engine changed. Several features that previously required plugins are now built-in. The headline change: no more tailwind.config.js In v3, configuration lived in a JavaScript file — theme extensions, plugins, content paths. In v4, it moves into your CSS: @import "tailwindcss" ; @theme { --color-brand : #6366f1 ; --spacing-18 : 4.5rem ; } Theme tokens become CSS custom properties under @theme , and Tailwind generates utility classes automatically. The content array is gone — v4 detects source files automatically. The new engine: Lightning CSS Tailwind v4 ships with Lightning CSS replacing PostCSS as the default: Build times drop significantly (cold rebuild went from ~8s to under 3s on the dashboard) CSS nesting works natively without a plugin Modern CSS features like color-mix() , @starting-style , oklch are transpiled automatically autoprefixer is no longer needed New features built-in Container queries — native in v4, no plugin needed: <div class= "@container" > <div class= "grid grid-cols-1 @sm:grid-cols-2" > ... </div> </div> 3D transforms — rotate-x-45 , rotate-y-12 , perspective-1000 for card flip effects without inline styles. Dynamic spacing — p-13 , mt-22 work without explicit definition. Migration: the upgrade tool and what it misses npx @tailwindcss/upgrade@next The codemod handles the mechanical parts. What it missed: Custom plugins — the JS plugin API changed; non-trivial v3 plugins need a rewrite to the new @plugin / @utility API theme() calls in CSS — replace theme('colors.zinc.900') with var(--color-zinc-900) ; gr

I've been building apps with IndexedDB for years. The local part works fine — store data, query it, show it on screen. The hard part is keeping that data in sync with a server when the network comes and goes. Most tutorials show you how to build an offline app with a framework. Firebase, RxDB, WatermelonDB. Those work, but they bring their own abstractions, their own sync protocols, their own opinions. I wanted something simpler. A database with a sync API that doesn't dictate how my backend works. Here's the setup I landed on. npm: npm install ctrodb Docs: ctrodb.vercel.app/docs/sync/overview What We're Building A notes app that works offline. Create and edit notes on the train, in a tunnel, on a plane. When the network comes back, everything syncs automatically. The database is ctrodb (zero-dependency, browser-based). The backend is anything that speaks HTTP. Step 1: Database Setup import { Database , syncPlugin , HttpTransport } from " ctrodb " const db = new Database ({ name : " notes-app " , schema : { version : 1 , collections : { notes : { fields : { title : { type : " string " , required : true }, body : { type : " string " }, updatedAt : { type : " string " , default : () => new Date (). toISOString () }, }, indexes : [{ field : " updatedAt " }], }, }, }, }) await db . connect () Every collection you want to sync needs a timestamp field. The sync engine uses it to order changes and detect conflicts. Plugins are passed in the Database constructor via plugins array: const transport = new HttpTransport ({ url : " https://api.myapp.com/sync " , }) const db = new Database ({ name : " notes-app " , schema : { ... }, plugins : [ syncPlugin ({ transport })], }) await db . connect () The transport takes a single base URL and appends /push and /pull automatically. The sync plugin hooks into every write operation and records it in the change log. The plugin exposes devtools that take the database instance as their first argument: import { inspectSyncQueue , retryFaile