标签：#JavaScript

Cloudflare has migrated cdnjs, its open source CDN for JavaScript and CSS libraries, to its Developer Platform. The new architecture uses Workers, R2, KV, Workflows, Queues, Durable Objects and Containers, consolidating publishing and delivery infrastructure while preserving package contents, URLs and SRI hashes at a scale of 9 billion requests per day. By Leela Kumili

GitHub热门项目 | 免费无广告的追剧资源指南，人工精选资源、每天检测资源有效性。收录在线影视、影视APP、网盘搜索、磁力BT、字幕、TVBox / 影视仓空壳软件/配置地址、IPTV直播源、会员拼团、影视相关开源项目。开源，社区共同维护。 | Stars: 5,766 | 71 stars today | 语言: JavaScript

GitHub热门项目 | 🎬 Fully automated YouTube channel management with AI agents. Creates, optimizes & publishes videos 24/7. Works with FREE Gemini API or OpenAI. No coding required! | Stars: 1,937 | 118 stars today | 语言: JavaScript

Floating labels. Inline validation. Custom checkboxes, radios, and a toggle switch. A gradient button with a press-down micro-interaction. Every bit of it below is CSS — no form library, no useState , no event listener wiring up a class toggle. That's form.fscss — the module in the FSCSS ecosystem. Same philosophy each time: solve the hard visual problem once, ship it as importable mixins, let the browser do the actual work. <script src= "https://cdn.jsdelivr.net/npm/fscss@1.1.24/exec.min.js" defer ></script> <style> @import (( * ) from form ) @ form-root () @ form-group (. form-group ) @ form-input (. form-input ) @ form-label (. form-label ) @ form-float (. form-group , . form-input , . form-label ) @ form-checkbox (. form-checkbox ) @ form-btn (. form-btn ) @ form-btn-primary (. form-btn-primary ) </style> <div class= "form-group" > <input class= "form-input" type= "text" placeholder= " " > <label class= "form-label" > Full name </label> </div> <label class= "form-checkbox" > <input type= "checkbox" checked ><span></span> I agree to the Terms </label> <button class= "form-btn form-btn-primary" > Create account </button> The two tricks doing all the work Forms feel like they need JavaScript because most tutorials reach for it immediately. Two native CSS mechanisms cover almost everything a "modern" form needs. Floating labels run entirely on :placeholder-shown . Give the input placeholder=" " — a literal space, not empty — and the browser now knows, purely in CSS, whether the field is empty and unfocused: .form-input :focus + .form-label , .form-input :not ( :placeholder-shown ) + .form-label { top : -9px ; font-size : 11px ; color : var ( --form-accent ); } No state, no class toggling on keyup. The label just reacts to what the browser already knows about the input. Checkboxes, radios, and the switch all use the classic checkbox-hack: the real <input> stays in the DOM (so it keeps native keyboard support and form submission) but is visually hidden, and a sibling

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . The bug When you call @google/genai in streaming mode and the model asks to run a tool, Sentry's JavaScript SDK records that tool call to the span twice. One tool call in, two entries out. The attribute that carries them is gen_ai.response.tool_calls . It should hold one object per call. For a single streamed controlLight call it held two. Worse, the two did not even agree on their shape. Here is a real capture, which I come back to at the end: [ { "id" : "call_2079699" , "args" :{ "colorTemperature" : "warm" , "brightness" : 30 }, "name" : "controlLight" }, { "type" : "function" , "id" : "call_2079699" , "name" : "controlLight" , "arguments" :{ "colorTemperature" : "warm" , "brightness" : 30 }} ] Same id, same call, listed twice. One entry keys the parameters under args , the other under arguments . Anything reading this later sees two tool invocations where the model made one. Following the value The streaming instrumentation lives in packages/server-utils/src/ai/google-genai/streaming.ts . Every chunk of the stream runs through handleCandidateContent . That function wrote tool calls from two places: function handleCandidateContent ( chunk , state , recordOutputs ) { if ( Array . isArray ( chunk . functionCalls )) { state . toolCalls . push (... chunk . functionCalls ); // push #1 } for ( const candidate of chunk . candidates ?? []) { // ...finish reasons... for ( const part of candidate ?. content ?. parts ?? []) { if ( recordOutputs && part . text ) state . responseTexts . push ( part . text ); if ( part . functionCall ) { state . toolCalls . push ({ // push #2 type : ' function ' , id : part . functionCall . id , name : part . functionCall . name , arguments : part . functionCall . args , }); } } } } Push #1 spreads chunk.functionCalls into the accumulator. Push #2 walks candidate.content.parts and pushes every functionCall it finds. They look like two different sources. They

Event-driven architecture is one of the most useful patterns for building applications that need to react to events instead of executing everything in a strict request-response sequence. Instead of thinking: User does something → Server performs everything → Response we can think: User does something → Event is created → Interested services react to it What Is an Event? An event represents something that happened. For example: { type : " USER_REGISTERED " , userId : " 12345 " , timestamp : Date . now () } Other parts of the application can listen for this event and perform their own tasks. For example: Email service sends a welcome email. Analytics service records the registration. Notification service creates a notification. Recommendation service creates initial recommendations. The registration service doesn't necessarily need to know how all of these tasks work. Why Use Event-Driven Architecture? The biggest advantage is decoupling. A traditional implementation might look like: await createUser (); await sendEmail (); await updateAnalytics (); await createNotification (); If the email service becomes slow, the entire operation can become slow. With events: await createUser (); publishEvent ({ type : " USER_REGISTERED " , userId : user . id }); Other services can process the event independently. Where Is It Useful? Event-driven systems are particularly useful for: Payment processing E-commerce Notifications Analytics Microservices IoT systems Background processing Real-time applications The Trade-Off Event-driven architecture isn't automatically better. It introduces additional complexity: Event delivery failures Duplicate events Ordering problems Debugging difficulties Event schema management For a small CRUD application, a simple architecture may be much easier. Final Thoughts Event-driven architecture is less about using a specific technology and more about changing how application components communicate. Once your application grows beyond a simple monolith, u

Your crawl job finished successfully. That doesn't mean it got the data. Every scraping pipeline has a monitoring dashboard, and every monitoring dashboard has the same blind spot: it tracks whether requests succeeded, not whether the content that came back was real. A job that completes with a wall of green 200 status codes looks healthy. It can also be quietly wrong, page after page, for weeks, because a 200 response only tells you the server accepted the request. It says nothing about whether you're looking at the actual page or a version built specifically for visitors the site doesn't fully trust. That gap between "the request succeeded" and "the data is correct" is where most silent pipeline failures live, and it's getting wider as anti-bot systems get more sophisticated about what they serve instead of an outright block. What a "successful" response can actually contain A block used to be simple to detect: a 403, a 429, a connection reset. Modern anti-bot systems increasingly prefer a different approach, because an obvious block tells the requester exactly what happened and invites a fix. A soft block, served with a 200, doesn't. In practice, that 200 can be a challenge page, an interstitial that looks like real content in the raw response but is actually a JavaScript-driven verification step (a "just a moment" style page, a hidden CAPTCHA iframe, a redirect loop disguised as a normal page load). It can be a cached fragment, an old snapshot of the page served to anything that looks automated, so the price, availability, or listing you scraped is stale even though the request itself worked fine. It can be an empty state, a search results page or listing that legitimately returns "no results" to a request pattern the site doesn't recognize, even though a real visitor would see dozens of items. And increasingly, it can be a partial HTML shell: the server response contains the page skeleton, but the actual content only renders after JavaScript executes in a real

npm 12 introduces significant security-related changes, making certain installation behaviors opt-in. Notably, script allowances are now off by default, which requires explicit approval for running scripts, including implicit builds. The update also restricts non-registry sources and addresses community concerns about security risks from automatic script execution. By Daniel Curtis

A single model can be unavailable, rate-limited, or temporarily slow. If your application already uses an OpenAI-compatible API, a simple fallback can make testing more resilient without introducing another SDK. This tutorial uses Node.js and the official OpenAI JavaScript package. It tries one model first and switches to a second model only when the first request fails. 1. Install the SDK npm install openai 2. Store the API key outside your code On macOS or Linux: export JINZEAI_API_KEY = "your_api_key_here" On PowerShell: $ env : JINZEAI_API_KEY = "your_api_key_here" Never commit a real API key. Rotate it immediately if it appears in a public repository, screenshot, or support message. 3. Create an OpenAI-compatible client import OpenAI from " openai " ; const client = new OpenAI ({ baseURL : " https://jinzeai.cc/v1 " , apiKey : process . env . JINZEAI_API_KEY , }); 4. Add a small fallback function const models = [ " deepseek-chat " , " qwen-flash " ]; async function completeWithFallback ( messages ) { let lastError ; for ( const model of models ) { try { const response = await client . chat . completions . create ({ model , messages , }); return { model , text : response . choices [ 0 ]. message . content , }; } catch ( error ) { lastError = error ; console . warn ( ` ${ model } failed: ${ error . status ?? " unknown status " } ` ); } } throw lastError ; } const result = await completeWithFallback ([ { role : " user " , content : " Explain model fallback in one sentence. " , }, ]); console . log ( `Model: ${ result . model } ` ); console . log ( result . text ); 5. Decide which errors should trigger fallback The minimal example retries on every error so the control flow is easy to see. A production application should be more selective. Fallback may be reasonable for: rate limits; upstream server errors; temporary timeouts; a model that is unavailable to the current account. Do not silently retry authentication errors. An HTTP 401 usually means the key is missing,

Introduction Positioning a tooltip sounds simple. Put a small box next to a button. Done. But anyone who has built one knows that it can quickly turn into: position: absolute calculating coordinates listening for resize events handling scrolling checking whether the tooltip fits on screen and sometimes pulling in an entire positioning library Modern CSS is starting to change that. CSS Anchor Positioning lets us position one element relative to another directly in CSS. Let's look at what that means with a very simple tooltip. What Is CSS Anchor Positioning? CSS Anchor Positioning allows one element to act as an anchor and another element to position itself relative to that anchor. Think about UI components such as: Tooltips Dropdown menus Popovers Context menus Floating labels These elements usually need to appear next to another element. Instead of calculating where they belong with JavaScript, we can now describe that relationship in CSS. Conceptually, we're saying: "This button is my anchor. Position this tooltip relative to it." A Simple Example Imagine we have a button: <button class= "info-button" > More info </button> <div class= "tooltip" > Your changes are saved automatically. </div> We want the tooltip to appear directly below the button. First, let's make the button an anchor. .info-button { anchor-name : --info-button ; } We've now given the button an anchor name. Next, connect our tooltip to it. .tooltip { position : absolute ; position-anchor : --info-button ; top : anchor ( bottom ); left : anchor ( left ); margin-top : 8px ; } That's the interesting part. top : anchor ( bottom ); tells the browser: Position the top of the tooltip at the bottom of the anchor. And: left : anchor ( left ); aligns its left side with the button. No getBoundingClientRect() . No coordinate calculations. No resize listener just to figure out where the tooltip belongs. Why Is This Useful? Before Anchor Positioning, we often had to manage positioning ourselves. A simplified Jav

Hoisting in JavaScript is the engine’s behavior of moving declarations to the top of their scope (global or local) before execution. Because of hoisting, you can reference functions or variables in your code before the lines where they are defined. 1.Function Declaration Function declarations are hoisted in their entirety—both the declaration and the body. This means you can call a function before it appears in the source code. hello (); //Output: hello! function hello (){ console . log ( " hello! " ) } 2.var Declaration When you use var, JavaScript hoists the variable declaration, but not its assignment. Until the execution line reaches the assignment, the variable holds undefined. console . log ( num ); //Output: undefined var num = 10 ; console . log ( num ); //Output: 10

🚀 How We Built an Instant AI Security & Code Auditor in Next.js & Convex When building security or code auditing tools, speed is everything . Developers won't wait 45 seconds for a bloated PDF report—they want instant feedback on potential bugs, security leaks, or bad practices. Over the last week, we've been building BugZ AI , a lightweight scanner designed to analyze code repos and security links in under 5 seconds . Here is a breakdown of our stack and the architecture choices behind keeping real-time scans ultra-fast. 💡 Build in Public Update: We hit 175 total developer visits today on Day 4 of building out in the open! 🛠️ 1. The Tech Stack Frontend: Next.js 15 (App Router) + Tailwind CSS Backend & Database: Convex (for real-time reactive updates without manual polling) Auth: Clerk Mobile Sync: Capacitor (wrapping web assets into native Android) ⚡ 2. Solving the Speed Bottleneck The biggest challenge was stream handling. Instead of waiting for the entire LLM response to complete before rendering analysis to the UI, we used Convex's real-time mutations paired with edge streaming. This lets the user paste a link or snippet and see initial vulnerability checks pop up in real-time within < 20 seconds . 📈 3. What We Learned Building Out in the Open Keep the UI distraction-free: Developers hate bloated dashboards when a single search bar will do the job. Real-time > Batch: Showing progress indicators reduces drop-off rates significantly compared to static loader spinners. 🧪 Try it out & Drop Your Feedback! If you want to run a quick audit on your project or test a link, check out the live demo here: [INSERT YOUR BUGZ AI LINK HERE] I'd love to hear your feedback on the scanning speed and response accuracy. What features would make this a daily part of your dev workflow?

Here is a pattern that shows up in almost every codebase: const lastActive =...

A browser game has an unusual constraint: the first level begins before the player reaches the first level. The download, parsing, asset setup, input initialization, rendering pipeline, and first interactive frame are all part of the experience. When building an isometric action game with Three.js, architecture has to account for that startup path as carefully as the gameplay loop. Keep rendering and game state separate Three.js provides scene, camera, materials, geometry, animation, and WebGL abstractions. It does not prescribe a game architecture. Avoid making the scene graph the only source of truth. Gameplay systems should reason about entities, movement, combat, health, and interactions in a form that can be tested without requiring every object to be a rendered mesh. A clean boundary lets the renderer reflect state while simulation code remains understandable. Treat asset loading as a pipeline GLTF is a useful delivery format, but imported assets still need conventions: scale and orientation; origin and pivot placement; animation naming; material expectations; collision representation; texture compression and dimensions; fallback behavior when an asset fails. Write validation tools or loading assertions early. One inconsistent model can create hours of debugging across animation, collision, and camera behavior. Design for mobile constraints from the start A desktop GPU can hide expensive decisions. Mobile hardware and thermal limits expose them. Watch: draw calls and material switches; overdraw from transparent effects; shadow-map cost; texture memory; object churn that triggers garbage collection; high-resolution rendering on dense displays; touch input and viewport changes. Adaptive quality is usually more useful than one rigid “high” setting. Resolution scale, shadow quality, particle counts, and effect density can respond to device capability. Make the camera part of gameplay An isometric camera must balance readability and atmosphere. Occlusion handling,

I have been an avid privacy advocate for quite some time now. It started with outright rejecting all "Big Brother" tech, and being hyper paranoid with every little detail, willing to sacrifice ease of use, in exchange for added privacy. However, as time went on, I slowly understood what is that I actually consider my "threat model" , and what exactly is my "sweet spot" between privacy and ease-of-use. I'm now back on multiple "Big Brother" tech, with some extra steps, to ensure I get the facilities they provide, while also being wary of my data. However, while I did make this compromise, I was very annoyed I had to make this compromise in the first place. In an ideal world, I would want the tech where everyone actually is, and is the standard for that particular domain, to have privacy features by default, and not be treated as a niche, or a luxury you have to go out of your way to avail. It was this annoyed version of myself, with my strong belief of privacy features and tools being the new norm, I started looking at everything with that lens. And that is how I got concerned about tracking in links and URLs. Try sharing any Instagram post, or YouTube video, by copying its URL, and you will see a bunch of garbage (garbage to you) in the link. Take for example this (fake) link: https://www.instagram.com/p/Cxyz123/?igshid=AbCdEf123456 These links contain something along the lines of utm_* (marketing attribution), or in this case, Ad-Click Identifiers, such as fbclid (Meta), gclid (Google), or igshid (Instagram). These pesky trackers help collect information regarding you, your device, and also help connect you across the internet, mapping your movement as you browse the web. The thing is, while there are good Samaritans who have built tools and websites to get rid of these trackers, and many privacy oriented browsers have introduced a "Copy Clean Link" option while copying the link from the browser, I believe there should be a tool which should not be restricted to a

One of the best ways to learn React is by building small, practical projects. A currency converter is an excellent example because it introduces state management, user input handling, calculations, and performance optimization—all in a single application. I built a simple currency converter using React that converts from USD to EUR, GBP, and JPY. For simplicity, I used fixed exchange rates instead of calling a live exchange rate API. React applications are interactive because they can respond to user actions. The useState hook allows components to remember values between renders. For this project, I declared it as thus, const [amount, setAmount] = useState(1); const [currency, setCurrency] = useState("EUR"); The amount stores the value entered. The setAmount() updates it. The currency variable stores the selected currency. The setCurrency() changes the selected currency. Whenever either value changes, React automatically re-renders the component. Now, to calculate the conversion, I stored the exchange rate in an object const RATES = { USD: 1, EUR: 0.92, GBP: 0.79, JPY: 157.3 }; The interface contains: A number input. A dropdown menu. A heading displaying the converted amount. Example: ```return ( Currency Converter <input type="number" value={amount} onChange={(e) => setAmount(Number(e.target.value))} /> <select value={currency} onChange={(e) => setCurrency(e.target.value)} > <option value="EUR">EUR</option> <option value="GBP">GBP</option> <option value="JPY">JPY</option> </select> <h2> {amount} USD = {convertedAmount} {currency} </h2> );```

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: The Cleanup That Failed 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 the prosecution has three more objections: Further evidence: This 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 top of the minute

GitHub热门项目 | Virtual Machine for the Web | Stars: 17,219 | 14 stars today | 语言: JavaScript

👉 TL;DR: Frontend applications (SPAs, mobile apps, desktop clients) cannot securely store secrets: any embedded API key is extractable by users and attackers. The Backend for Frontend (BFF) pattern solves this by placing a server-side layer between your frontend and third-party APIs. The BFF holds the secrets; the frontend never sees them. For production deployments, use a secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than environment variables to enable rotation and auditing. A BFF adds infrastructure complexity, but for any API key with financial or administrative implications, the tradeoff is worth it. Frontends are notoriously leaky environments. Cybernews found in 2022 that 56% of Android apps on the Google Play Store contained hardcoded secrets extractable through basic automation. A similar study in 2025 concluded that iOS apps are not better, with over 815,000 secrets harvested from 156,000+ apps (71% leaking at least one credential). These studies plainly expose the widespread issue of hard-coding secrets in production-deployed frontend code. This article aims to warn developers about this risk and present a simple, reusable pattern for safeguarding their applications: the Backend for Frontend (BFF) pattern. Before we start, let's be clear on the crucial point: Whether you are building a React Single Page Application (SPA), a mobile app, or a desktop client, if the code runs on the user's device, the user (and potential attackers) can always inspect it. The solution isn't to try and hide the keys better ; it's to move them somewhere safe. "Public Clients" vs. "Confidential Clients" In OAuth terminology, there are two types of clients, with completely different security models : Confidential Clients : Applications running on a secure server (e.g., a Node.js backend, Python API) that can securely store secrets (like a CLIENT_SECRET) because end-users don't have access to the server's file system or memory. Public Clients : Applications running

Astro 7 focuses on build performance, utilizing native tooling and a rewritten compiler in Rust. The new version includes faster Markdown processing and stricter HTML rules. Recent updates introduced advanced routing and incremental builds, while issues around legacy file compatibility and dependency counts were raised in feedback. Astro targets content-driven sites with minimal JavaScript. By Daniel Curtis