cloudflareAug 7, 2026

Unveiling good and bad behaviors on the Agentic Internet (opens in new tab)

The Internet contains a mix of human, automated, and hybrid traffic, so classifying visitors simply as “good humans” or “bad bots” no longer works. Cloudflare argues that website owners should evaluate continuous behavior and build trust over time, rather than rely only on isolated risk checks. Its strategy combines transparent bot classification through BotBase with behavioral detection through Precursor. ## Risk and Trust Are Different - **Risk** measures how likely a request or action is to be harmful, often based on a momentary event. - **Trust** develops over time through reputation and observed behavior. - A suspicious action should not automatically lead to rejection if the actor has an established, trustworthy identity. - Cloudflare’s goal is to create incentives for safer behavior, from blocking malicious activity to enabling beneficial automated participation. ## Verified Bots and Transparency - Cloudflare defines verified bots and agents through two requirements: - They honestly declare who they are. - They do not abuse the trust they receive. - Transparency helps site owners decide which behaviors and data uses to permit. - BotBase is designed as a directory of all known bots and agents, not just approved ones. - Actors that violate expectations can lose their verified status and become harder to trust across Cloudflare’s network. ## Continuous Detection with Precursor - Precursor is a client-side system that continuously analyzes behavior throughout a session. - Its JavaScript is injected at the CDN, so customers do not need to manually place or rerun detection code. - Unlike CAPTCHAs and other one-time challenges, Precursor evaluates behavior in context over multiple pages. - Continuous analysis makes it more expensive for bot developers to imitate human behavior across an entire session. ## What Cloudflare Has Observed - In a 24-hour snapshot, Precursor processed **206 million evaluation events across 73,438 zones**. - Suspicious behavior frequently begins in the middle of a session, meaning point-in-time checks can miss it. - A single session may shift between human and automated behavior, such as when a user hands part of a shopping journey to an agent. - Site owners therefore need classifications based on use case, purpose, and data usage rather than a simple human-versus-bot decision. ## Understanding Human Cursor Behavior - **Precursor Trace** is an interactive demonstration of part of Precursor’s detection process. - It examines cursor acceleration, corrections, rhythm, and movement texture. - The demo illustrates how behavioral signals can distinguish natural interaction from automated movement. ## Adaptive Intelligence - Cloudflare indicates that its bot detection engines will soon provide more adaptive outcomes for requests identified as automated. - The excerpt ends before detailing how this upcoming capability will work. Website owners should treat automation as a spectrum: verify transparent actors, monitor behavior continuously, and make decisions based on trust, intent, and use case rather than isolated signals.

javascriptcloudflareagentic-aicdn+3

cloudflareAug 3, 2026

Workers RPC now works across Python and JavaScript (opens in new tab)

Workers RPC, originally based on Cap’n Proto RPC, is expanding from JavaScript-only communication to seamless JavaScript–Python interoperability through Cap’n Web. Workers can call methods, pass objects and functions, propagate exceptions, and use native language types without schemas, dependencies, or significant performance overhead. The result is a multi-language system that can be used much like a local library. ## Cross-Language RPC in Workers - JavaScript Workers can call Python Worker methods, and Python Workers can call TypeScript methods. - Objects, functions, streams, and live remote objects can be passed between Workers. - A Service binding is the only required configuration. - RPC calls return promises in JavaScript/TypeScript and futures in Python. - Exceptions propagate back to the call site. - Most calls run in the same thread, providing near-zero overhead compared with local execution. - The implementation is open source through `workerd` and `workers-runtime-sdk`. ## Automatic Type Conversion - RPC supports Structured Cloneable values as parameters and return values. - Common types are converted into native equivalents, such as JavaScript `Date` to Python `datetime`. - JavaScript objects can correspond to Python dictionaries, while Python keyword arguments can represent JavaScript options objects. - Functions can cross the language boundary; invoking a transferred function creates a reverse RPC call to its original Worker. ## Pyodide’s Role - Python Workers use Pyodide, a WebAssembly-compiled CPython runtime. - Pyodide’s Foreign Function Interface translates common values automatically: - Python `int` and `float` → JavaScript `Number` - Python `bool` → JavaScript `Boolean` - Python `dict` → JavaScript `Object` - Python `list` → JavaScript `Array` - Types that cannot be directly converted, such as custom classes and functions, are represented by proxies that forward property access and method calls. ## Handling Worker-Specific Objects - Standard Web API objects such as `Request`, `Response`, `Blob`, and `File` do not have direct Python equivalents. - Pyodide initially exposes these values as JavaScript proxy objects. - Although proxies remain functional, they expose JavaScript implementation details to Python developers and make the API less natural. - The project therefore requires an additional conversion layer to provide Python-friendly representations of Cloudflare Workers objects. ## Practical Implication Cross-language Workers RPC lets teams combine Python and JavaScript services without manually designing APIs or serialization formats. Developers can use each language’s native calling conventions while the runtime handles translation, proxies, and communication behind the scenes.

javascripttypescriptpythoncloudflare-workers+4

cloudflareJul 13, 2026

Introducing Precursor: detecting agentic behavior with continuous client-side signals (opens in new tab)

Precursor is Cloudflare’s new client-side, session-based system for detecting bots and agentic automation through continuous behavioral signals. Unlike one-time challenges, it evaluates interactions across an entire user journey, making automation harder to imitate while reducing friction for legitimate users. It complements Turnstile by extending behavioral detection beyond sensitive checkpoints such as login, signup, and checkout. ## The Visibility Gap in Bot Detection - Cloudflare analyzes more than 1 trillion requests daily across over 20% of the web. - Turnstile runs nearly 3 billion times per day and provides risk-based verification at important application endpoints. - However, point-in-time challenges offer limited insight into how users and bots behave throughout the rest of a session. - Precursor addresses this gap by continuously observing interactions across an application. ## Why Session Behavior Matters - Modern bots can execute JavaScript, operate real browsers, and pass individual CAPTCHAs. - Sustaining believable behavior over a complete session is substantially more difficult. - Precursor uses accumulated behavioral signals to improve detection precision. - This can reduce unnecessary challenges for legitimate users while increasing the cost and complexity of bot operations. ## Human and Automated Interaction Patterns - Human mouse movement reflects physical and cognitive constraints: - Wrist and forearm movement produce curved paths. - Clicking involves a delay after seeing an interface element. - Hand tremors create subtle physiological oscillations. - Automated interactions often reveal: - Straight-line movement or mathematically ideal curves. - Unusually precise clicks. - Repeated velocities, origins, timing, and movement rhythms. - Individual actions may appear plausible, but patterns across a full session can expose automation. ## How Precursor Works ### Injection and Data Collection - Cloudflare dynamically injects a compact, obfuscated JavaScript bundle into HTML responses passing through its network. - No additional configuration, third-party embedding, or network connection is required. - The script observes signals such as: - Pointer movement - Keyboard timing and activity - Focus changes - Page visibility - Events are serialized, buffered in memory, and periodically sent for analysis. ### Edge-Side Evaluation - Cloudflare deserializes the incoming data and runs multiple evaluators against the behavioral streams. - Evaluators cross-reference signals to identify inconsistencies. - Examples include checking whether: - Pointer activity matches page visibility duration. - Keyboard events occur while a text field is focused. - The results are consolidated into detection signals that influence bot scoring. ### Session Integration - Signals accumulate across the session rather than resetting with a page refresh or new challenge. - Session metadata also supports: - Shadow-mode heuristics - Session analysis - Predicted-versus-actual completion comparisons - Session delinquency heuristics - These observations help improve detection and adjust a session’s bot score. ## Privacy by Design - Precursor collects only information considered necessary for detecting automation and abuse. - Keyboard behavior is recorded as timing and rhythm, not the actual keys pressed. - Signals are evaluated as aggregate behavioral patterns. - Data is used internally by Cloudflare’s detection systems and is not exposed in customer dashboards or linked to accounts, identities, or persistent profiles. ## Session-Based Analytics - Cloudflare is introducing session-oriented views in Security Analytics alongside Precursor. - These views shift analysis from isolated requests to complete visitor journeys. - The provided article excerpt ends while beginning to describe these dashboards. Precursor is best understood as a complement to Turnstile: continuous, privacy-conscious session analysis can detect automation that passes individual challenges while reducing reliance on aggressive interruptions for genuine users.

javascriptbot-managementbot-detectionbehavioral-analysis+3

tossJun 24, 2026

es-toolkit: How a Small Internal Library Became a Global Project (opens in new tab)

es-toolkit began at Toss as a modern alternative to lodash, addressing its outdated architecture, legacy-browser code, lack of native ECMAScript Module support, and inefficient implementations. By removing unnecessary logic and relying on modern browser APIs, es-toolkit achieved 2–10× performance improvements and, in some cases, reduced bundle sizes by more than 30×. Its open-source momentum attracted global contributors, eventually helping it become widely adopted. ## The Beginning of es-toolkit - Toss developers needed dependable utilities such as `throttle`, `debounce`, and `uniq`. - Although lodash was widely used, it had several limitations: - Outdated code structure and implementations. - Defensive logic for legacy browsers such as Internet Explorer. - Little use of native APIs like `Array#map`. - No ECMAScript Modules, making tree-shaking difficult. - `lodash-es` added ESM support but retained much of lodash’s older and inefficient implementation. - Toss’s internal `@toss/utils` library required significant effort to maintain and handle edge cases. - es-toolkit was created to provide a modern, efficient utility library for current web development. - Initial results showed: - At least 2× and sometimes over 10× faster execution. - Bundle-size reductions of more than 30× in some cases. ## Open-Source Adoption and Community Growth - Toss initially announced es-toolkit through its frontend social media channels. - Developers contributed missing functions, bug fixes, and performance improvements. - After gaining attention in Korea, the project was shared on Reddit and received over 100 upvotes and tens of thousands of repository visitors. - International discussions led to coverage in blogs and newsletters. - Community members created bundler plugins and migrated dependencies in established libraries from lodash to es-toolkit. ## From Contributor to Toss Developer - Dayong Lee discovered es-toolkit through Toss’s announcement and began contributing despite not being a Toss employee. - Starting with small pull requests, he gradually became the project’s second-largest contributor. - Code reviews helped him develop stronger skills in: - JavaScript language features. - API and interface design. - Open-source collaboration. - His involvement with es-toolkit eventually contributed to his joining Toss Bank. ## Making Migration Easier with `es-toolkit/compat` - Although the library was becoming more complete, adoption remained slow because many projects depended heavily on older utility libraries. - Migrating individual lodash functions across a large codebase would be tedious and risky. - es-toolkit therefore introduced `es-toolkit/compat`, a drop-in replacement designed to preserve lodash’s interfaces and behavior while modernizing its internal implementation. - This compatibility layer reduced migration effort and allowed projects to gain performance improvements by changing imports rather than rewriting utility usage. - The layer was particularly important because es-toolkit’s streamlined behavior could otherwise differ from lodash in edge cases and cause runtime errors. es-toolkit’s story demonstrates how a focused modernization effort can replace entrenched legacy dependencies. Providing both a faster native-style library and a compatibility layer made adoption more practical while enabling broad open-source participation.

javascriptfrontend-developmentes-toolkitlodash+3

tossJun 22, 2026

es-toolkit: How an Internal Little Library Became a Global Library (opens in new tab)

es-toolkit began as Toss’s effort to create a modern alternative to lodash, removing legacy code and optimizing for current JavaScript environments. By focusing on common use cases, it achieved 2–10× faster performance and reductions in bundle size of more than 30×. Community adoption, compatibility tooling, and contributions to major projects eventually pushed it beyond 20 million weekly npm downloads. ## Why es-toolkit Was Created - Developers frequently needed utilities such as `throttle`, `debounce`, and `uniq`, but existing options had drawbacks. - lodash contained legacy implementations, Internet Explorer workarounds, and limited ECMAScript Modules support. - Even `lodash-es` mainly added ESM support without modernizing the underlying code. - Toss had maintained its own `@toss/utils`, but handling utility-function edge cases internally was burdensome. - es-toolkit’s goal was to remove unnecessary logic, improve performance, and produce smaller bundles for modern web applications. ## Performance and Bundle-Size Improvements - Reimplementing core lodash-style functions produced: - At least 2× faster execution for some functions. - More than 10× faster execution for others. - Using modern built-ins such as `Array#map` eliminated compatibility code. - Bundle sizes were reduced by more than 30× in some cases. - The project was designed around the most common use cases rather than every historical edge case supported by lodash. ## Growth Through the Open-Source Community - The first release was shared through Toss’s frontend social channels and quickly attracted users and contributors. - Contributors added missing functions, fixed bugs, and optimized implementations. - After promotion on international developer communities, the project received more than 100 recommendations and tens of thousands of repository visitors. - Blogs and newsletters helped extend its reach. - Community members created migration plugins and independently replaced lodash dependencies in other libraries. ## From Contributor to Maintainer - Toss Bank developer Dayong first joined as an external contributor, submitting small pull requests. - Reviewing and designing interfaces for es-toolkit provided valuable experience with JavaScript and API design. - Continued contributions eventually made her the project’s second-largest contributor and helped lead to her joining Toss Bank. - The project also demonstrated how an open-source initiative can connect contributors across companies and countries. ## Lowering the Migration Barrier with `es-toolkit/compat` - Adoption was initially slow because applications often imported many lodash functions throughout their codebases. - Replacing every import manually would make migration expensive and risky. - es-toolkit’s standard implementations also differed from lodash in some edge cases. - `es-toolkit/compat` was introduced as a drop-in replacement: - It preserves lodash-compatible interfaces and behavior as much as possible. - It modernizes the internal implementations. - Projects can gain performance and bundle-size benefits with minimal code changes. - This helped major projects such as Storybook, Mermaid, Yarn Berry, and Recharts adopt es-toolkit. ## Future Direction - es-toolkit plans to help more JavaScript libraries reduce their bundle sizes and improve efficiency. - It aims to add modern utilities, including: - `filter`-style functions for `Map` and `Set`. - Promise-based helpers such as `delay`. - Server-oriented utilities for Node.js, Deno, and Bun. - New functions such as `exec` are intended to provide essential functionality with smaller implementations than competing libraries. - The project plans to maintain its core principle: optimize for more than 80% of common use cases while remaining small, fast, and high quality. es-toolkit’s success shows that a focused, modern implementation can replace widely used legacy utilities when it combines measurable technical benefits with strong migration support and active community participation.

javascriptopen-sourcetypescriptnpm+3

figmaJun 11, 2026

Improving Performance in the Layers Panel | Figma Blog (opens in new tab)

Figma rebuilt its layers panel to handle files containing tens of thousands of layers. The old architecture recomputed too much data too often, slowing both panel interactions and broader editor operations. A two-pass computation model and cached derived properties now make some interactions 30–50% faster. ## Why the Original Architecture Slowed Down - Figma files are trees of nodes with properties and children. - The panel previously built a large JavaScript object in one recursive pass. - Every expanded node—and often all of its descendants—had its display data recomputed after changes. - This created two problems: - Data was computed for hundreds of thousands of nodes even though only 20–30 rows were visible. - Small changes, such as expanding a node, triggered broad recomputation because incremental results were rarely cached. ## Two-Pass Computation - The first pass computes only the ordered list of row IDs shown in the panel. - Determining that order still requires handling complex rules, including: - Reversed child ordering in autolayout frames. - Node types such as widgets and FigJam stickies that hide children. - Fixed and scrolling headers that divide prototype-frame children. - Sticky top-level frames and components. - The second pass gathers display data—names, icons, lock and visibility state, and selection state—only for rows inside the visible window. - This makes windowing effective: previously, Figma computed data for off-screen rows even though they were not rendered. ## Caching Derived Data - Figma introduced its “derived properties” platform primitive to avoid recomputing unchanged data. - Nodes store mutable fields, while other values are calculated from those fields and related properties. - For example, a node’s absolute position can be derived from its parent’s absolute position and its relative position: ```text Self.AbsolutePosition = Parent.AbsolutePosition + Self.RelativePosition ``` - Derived properties: - Track their dependencies through an optimized dependency graph. - Support different caching strategies balancing speed and memory. - Are lazy by default, computing values only when they are read. - Because the layers panel is itself a tree, this dependency-aware system lets Figma update only affected rows while keeping stable portions cached. Figma’s results show the value of combining virtualization with incremental, dependency-based computation: large hierarchical interfaces can remain responsive when they calculate only visible data and preserve everything that has not changed.

javascriptcachingvirtualizationdependency-graph+2

cloudflareJun 4, 2026

VoidZero is joining Cloudflare (opens in new tab)

VoidZero, the company behind Vite, Vitest, Rolldown, Oxc, and Vite+, is joining Cloudflare, with its entire team moving over. The projects will remain open source, MIT-licensed where applicable, vendor-agnostic, and community-driven. Cloudflare says the acquisition will provide more engineering resources while preserving portability and independent community governance. ## Open Source and Vendor Neutrality - Vite and the other VoidZero projects will continue to be developed in the open. - Applications built with Vite will remain deployable anywhere, not only on Cloudflare. - Evan You and the VoidZero team will continue leading the projects. - Cloudflare plans to invest engineering resources rather than redirect the projects toward its own platform. - Cloudflare is committing $1 million to a Vite ecosystem fund for maintainers and contributors, administered by the Vite core team. ## Vite as a Shared Foundation - Vite underpins a broad range of frameworks and tools, including Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, and TanStack Start. - The authors describe Vite as a neutral foundation for the JavaScript ecosystem rather than a framework tied to one provider. - Cloudflare’s earlier investment in Astro is presented as an example of how it intends to support open-source projects while keeping them portable. ## The Environment API and Cloudflare Integration - Cloudflare and Vite began collaborating in 2024 on the Vite Environment API. - The API allows server-side code to run in non-Node.js runtimes during development. - Cloudflare’s Vite plugin runs application code locally inside **workerd**, the same open-source runtime used by Workers in production. - Services such as Durable Objects, D1, KV, R2, Workflows, Workers AI, Agents, Service Bindings, and Workers RPC can therefore be tested locally using the production runtime model. - The approach keeps Vite’s integration generic: other runtimes can implement their own provider-specific plugins without requiring a Cloudflare-specific development server. - Vite reportedly reaches about 129 million weekly downloads, while the Cloudflare Vite plugin approaches 14 million. ## AI-Driven Development - AI agents now use development tools directly, including project scaffolding, dev servers, testing, linting, formatting, error handling, and deployment workflows. - Agent-driven development increases the importance of: - Fast builds and tests - Fast linting and formatting - Structured, actionable errors - Consistent command-line interfaces - VoidZero’s tools—Vitest, Rolldown, Oxc, Oxlint, and Oxfmt—are designed for repeated, automated feedback loops. - Vite+ combines these tools behind a unified CLI and configuration model, reducing complexity for both developers and agents. - Cloudflare is using the tools internally: its dashboard runs on Vite, Oxlint is reducing engineering effort, and the Flue agent framework is adopting Vite and the official Cloudflare plugin. Cloudflare’s stated priority is to preserve the trust and portability that made Vite widely adopted. The practical takeaway is that the acquisition is intended to expand Vite’s resources and runtime integrations without turning it into a Cloudflare-only platform.

javascriptcloudflareopen-sourcecloudflare-workers+4

gitlabMay 13, 2026

GitLab Patch Release: 18.11.3, 18.10.6, 18.9.7 | GitLab Docs (opens in new tab)

On May 13, 2026, GitLab released patch versions 18.11.3, 18.10.6, and 18.9.7 for CE and EE. The releases address multiple high-severity security vulnerabilities, including cross-site scripting, denial of service, authorization, and access-control issues. GitLab strongly recommends that all affected self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - Patch releases may be scheduled or issued urgently for critical vulnerabilities. - Security vulnerability details are published publicly 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## Cross-Site Scripting Vulnerabilities Several authenticated-user XSS vulnerabilities could allow arbitrary JavaScript to execute in other users’ browsers: - **CVE-2026-7481**: Affects EE Analytics dashboard chart rendering; exploitable by users with Developer permissions. - **CVE-2026-5297**: Affects global search in CE and EE. - **CVE-2026-6073**: Affects EE Duo Agent output rendering. - **CVE-2026-7377**: Affects customizable EE Analytics dashboards. - Each issue received a **CVSS score of 8.7** and resulted from improper input sanitization. ## Denial-of-Service Vulnerabilities The release fixes multiple unauthenticated denial-of-service issues involving malformed requests or files: - **CVE-2026-1659**: Specially crafted requests to the CI/CD job update API could disrupt service. - **CVE-2025-14870**: Malformed JSON payloads targeting the Duo Workflows API could cause a denial of service. - **CVE-2025-14869**: Certain internal API endpoints were vulnerable to specially crafted payloads. - **CVE-2026-1184**: A specially crafted file uploaded through Insights Configuration could cause service disruption. - The API-related issues were rated **CVSS 7.5**; the Insights issue was rated **6.5**. ## Authorization and Access-Control Issues - **CVE-2026-1322**: An authenticated user with a `read_api`-scoped OAuth application could create issues and comment on private projects through GraphQL, due to improper token-scope enforcement. It received a **CVSS score of 6.8**. - **CVE-2026-4524**: Authenticated users could access confidential issue content in public projects through the Issues API without proper authorization checks. It received a **CVSS score of 6.5**. ## Recommended Action Self-managed GitLab administrators should upgrade to the latest supported patch release—18.11.3, 18.10.6, or 18.9.7—as soon as possible, particularly because several vulnerabilities are remotely exploitable and require little or no authentication.

javascriptgitlabgraphqloauth+3

cloudflareApr 13, 2026

Dynamic, identity-aware, and secure Sandbox auth (opens in new tab)

Sandboxes for AI agents need more than isolation: they also require fast startup, platform control, and safe access to external services. The post introduces outbound Workers, programmable egress proxies that intercept sandbox traffic and can authenticate, restrict, modify, log, or cancel requests. This approach combines zero-trust security with identity-aware, flexible, observable, and dynamic authorization without exposing secrets to untrusted agents. ## Sandbox Requirements Sandboxes provide three core benefits: - **Security:** Untrusted users or agents can run code without compromising the host or neighboring sandboxes, often through microVM isolation. - **Speed:** Users can quickly start new sandboxes and restore existing state. - **Control:** The trusted platform can mount files, execute commands, and control network access inside the sandbox. Outbound Workers add network-level control to this model by acting as programmatic egress proxies for Sandboxes and Containers. ## How Outbound Workers Work - A sandbox can define handlers for all outbound requests or for requests to specific hosts. - For example, requests to `github.com` can be intercepted through `static outboundByHost`. - The handler can: - Add authentication headers. - Log requests. - Modify request data. - Reject or cancel requests. - Secrets remain outside the sandbox and can be accessed by the Worker through its environment. - Workers run near the sandbox, can access distributed state, and can be updated using ordinary JavaScript. A sample handler copies the request headers and injects `x-auth-token` from `env.SECRET` before forwarding the request. ## Challenges with Existing Agent Authentication Agent workloads cannot be fully trusted, even when the underlying language model is not intentionally malicious. Credentials must therefore limit accidental misuse and prevent data exfiltration. ### Standard API Tokens - Tokens are commonly passed through environment variables or mounted secret files. - They are simple to implement but expose credentials to the sandboxed workload. - A compromised or misbehaving agent could leak the token. - Expiration and rotation are required, creating operational overhead. ### Workload Identity Tokens - Systems such as OIDC provide an identity assertion rather than a general-purpose service token. - The agent can exchange the identity token for a short-lived access token. - Tokens can be invalidated when a workflow ends, simplifying expiration. - The drawback is limited upstream support: many services do not natively accept OIDC, forcing platforms to build custom token-exchange services. ### Custom Proxies - Proxies provide maximum control and can enforce granular permissions even when an upstream service has weak RBAC. - They can be combined with workload identity tokens. - However, intercepting all sandbox traffic and building an efficient, dynamic, programmable proxy is difficult. ## Characteristics of an Ideal Agent Auth System The post argues that agent authentication should be: - **Zero trust:** Never expose a reusable token to an untrusted workload. - **Simple:** Avoid complicated token minting, rotation, and decryption systems. - **Flexible:** Enforce permissions independently of the upstream service. - **Identity-aware:** Apply rules based on which sandbox is making the request. - **Observable:** Record and inspect outbound calls. - **Performant:** Avoid slow, centralized authorization round trips. - **Transparent:** Require no changes to the sandboxed application. - **Dynamic:** Allow authorization rules to change while systems are running. Outbound Workers are presented as a way to satisfy all of these requirements. ## Restriction and Observability A basic outbound handler can enforce network policy with only a few lines of JavaScript: - Inspect each outgoing HTTP request. - Log requests using disallowed methods. - Return a `405 Method Not Allowed` response for anything other than `GET`. - Forward permitted requests with `fetch(req)`. This demonstrates that outbound Workers can enforce restrictions and provide observability without modifying the application running inside the sandbox. ## Practical Recommendation Use outbound Workers as a trusted egress layer for agent sandboxes. Keep sensitive credentials outside the workload, inject or exchange them only at the proxy, and use the Worker to enforce identity-specific policies, logging, and request restrictions dynamically.

javascriptzero-trustauthenticationhttp-requests+4

githubApr 3, 2026

The uphill climb of making diff lines performant (opens in new tab)

GitHub rebuilt the pull request **Files changed** experience to keep diff reviews responsive across everything from tiny fixes to massive changes. The core conclusion is that no single optimization solves performance at scale; instead, targeted rendering improvements, virtualization, and simpler components must work together. Early results show that even small reductions in DOM size can have substantial effects on memory usage and interaction latency in large pull requests. ## Performance Challenges at GitHub’s Scale - Pull requests may contain thousands of files and millions of lines. - In extreme cases, the old experience reached: - More than **1 GB of JavaScript heap usage** - Over **400,000 DOM nodes** - Unacceptably high Interaction to Next Paint (INP) scores - Large reviews became sluggish or nearly unusable, despite the experience remaining fast for most smaller pull requests. ## A Strategy Based on Pull Request Size GitHub concluded that different pull request sizes require different performance strategies: - **Optimize diff-line components** so medium and large reviews remain fast without losing expected browser behavior, such as native find-in-page. - **Use virtualization for the largest reviews**, rendering only the content currently needed to preserve responsiveness and stability. - **Improve foundational components and rendering**, allowing performance gains to benefit every pull request size. ## Problems with the Original Diff Architecture The first React implementation made each diff line unnecessarily expensive: - Unified view used roughly **10 DOM elements per line**; split view used about **15**, before syntax highlighting added more `<span>` elements. - Each unified diff line typically involved at least **eight React components**, while split view involved at least **13**. - Additional states—such as comments, hover, and focus—could add still more components. - Small components often registered five or six React event handlers each, resulting in **20 or more handlers per line**. - These costs multiplied across thousands of lines, increasing JavaScript heap usage and worsening INP. - The component-heavy design was initially reasonable when React was introduced, but proved unsustainable for unbounded data sets. ## Incremental Improvements in the New Design GitHub’s second version focused on simplification and removing unnecessary structure: - Reduced state, JavaScript, React components, and DOM elements. - Removed redundant `<code>` tags from line-number cells. - Eliminating just two nodes per line saves approximately **20,000 DOM nodes across 10,000 lines**. - The example demonstrates how seemingly minor changes compound into meaningful improvements at large scale. The practical lesson is that performant large-scale interfaces require layered optimizations: simplify every repeated element, reduce per-item overhead, and use virtualization when rendering everything at once is no longer viable.

javascriptreacthtmlweb-performance+3

figmaApr 2, 2026

Build With More Context and More Control in Figma Make | Figma Blog (opens in new tab)

Figma’s Make kits and Make attachments add structured context to AI-generated prototypes, helping them start closer to production reality. Make kits provide design-system guidance through code packages, libraries, styles, and tokens, while attachments bring in project-specific data and requirements. Together, they reduce cleanup and make generated designs more consistent with how products are actually built. ## Make Kits Teach Make About the Design System - Make kits are reusable packages that combine components or styles with guidelines explaining how they should be used. - They can use: - JavaScript components from public npm packages - Packages from Figma’s secure private registry - Styles and design tokens from Figma libraries - Guidelines tell Make not only which components exist, but also how to apply them. - Instead of starting with generic UI and repeatedly correcting spacing, patterns, and components, Make can begin with production-aligned structures. - This helps: - Maintain consistency across forms, dashboards, settings, and onboarding - Let teams generate work in parallel without drifting from the design system - Reduce preparation and correction before review - Engineers can more easily recognize familiar components and focus on evaluating the proposal rather than translating it into their system. - Figma plans to expand kits to represent more design-system structure, including component structures from Figma libraries. ## Make Attachments Ground Prototypes in Project Context - Design systems do not capture every project-specific constraint, such as: - Real data - Migration requirements - Edge cases - Compliance rules - Legal copy and content - Make attachments allow users to provide source material directly instead of describing everything in a long prompt. - Supported materials include: - PDFs and Markdown files - CSV and JSON datasets - Screenshots and images - Brand guidelines - Legal copy - Media and SVG files - Code and other project assets - Attachments help Make create prototypes that reflect actual data, validation states, content, and requirements rather than producing an idealized version that omits complexity. - For example, an onboarding flow can be grounded in real user data, complete legal requirements, and multiple validation states instead of shortened copy and simplified edge cases. ## A More Production-Aligned Starting Point - Make kits provide the reusable design and code foundation. - Attachments add the details and constraints unique to a specific project. - The combination is intended to shorten the distance between an AI-generated prototype and a shippable product, allowing teams to spend less time rewriting and more time refining the experience.

javascriptdesign-systemsreactfigma-make+3

cloudflareMar 30, 2026

Cloudflare Client-Side Security: smarter detection, now open to everyone (opens in new tab)

Cloudflare is making its Client-Side Security Advanced product self-serve and offering domain-based threat intelligence free to users of its basic bundle. The service detects malicious browser-side JavaScript through browser reporting, AST-based behavioral analysis, and a new LLM review layer. Its goal is to catch sophisticated skimming attacks while reducing false positives and avoiding performance impacts on customer applications. ## Growing Threat of Client-Side Attacks - Browser skimmers can steal credentials, payment data, and personal information without disrupting page loads or checkout flows. - Recent examples include: - A browser keylogger placed on a major U.S. bank’s employee merchandise store. - Malicious npm package releases capable of enabling browser-based crypto theft when bundled into front-end applications. - These attacks often exploit trusted first-party or third-party scripts rather than obvious server vulnerabilities. ## Broader Access to Client-Side Security - Client-Side Security Advanced, formerly the Page Shield add-on, is now available to self-serve customers. - Domain-based threat intelligence is complimentary for customers using the free Client-Side Security bundle. - Advanced capabilities include: - Machine-learning and LLM-assisted malicious script detection. - Continuous code-change monitoring for compliance requirements such as PCI DSS v4.0 requirement 11.6.1. - Proactive positive security rules maintained through ongoing monitoring. ## Browser-Based Monitoring Without Application Changes - Cloudflare evaluates approximately 3.5 billion scripts per day, with enterprise zones averaging about 2,200 scripts. - The system gathers signals through browser reporting mechanisms such as Content Security Policy. - Customers do not need scanners or application instrumentation. - Traffic must be proxied through Cloudflare. - The approach adds no latency to web applications. ## Detecting Script Intent - Enterprise sites may contain thousands of scripts, and roughly one-third change within a 30-day period. - Manually approving every DOM interaction or outbound connection would create excessive operational overhead. - Cloudflare instead analyzes what scripts are attempting to do. - JavaScript is represented as an Abstract Syntax Tree (AST), allowing the system to identify behavioral patterns even when code is minified, renamed, or obfuscated. ## Reducing False Positives - Client-side compromises are relatively rare but potentially severe, unlike the high-volume attacks typically handled by a WAF. - Because genuine incidents are uncommon, even accurate detection systems can produce more false alarms than real alerts. - False positives contribute to security-team fatigue and can obscure actual compromises. - Legitimate but heavily obfuscated code—such as bot challenges, tracking pixels, advertising bundles, and minified frameworks—can resemble malicious code structurally. ## GNN and LLM Detection Pipeline - Cloudflare’s primary detector is a Graph Neural Network (GNN) operating on JavaScript ASTs. - The GNN learns structural representations of code and can recognize similar behavior despite syntactic changes. - It is optimized for high recall to detect novel and zero-day threats. - Although fewer than 0.3% of analyzed traffic is incorrectly flagged, Cloudflare’s scale makes that percentage a significant number of alerts. - An LLM provides semantic context, recognizing common JavaScript frameworks, domain-specific coding patterns, and benign forms of suspicious-looking obfuscation. - The LLM complements rather than replaces the GNN: - Scripts classified as benign stop after the fast GNN evaluation. - Scripts exceeding the GNN’s risk threshold are sent to an open-source LLM hosted on Cloudflare Workers AI for a second opinion. Cloudflare’s approach combines low-overhead browser telemetry, structural machine learning, and semantic LLM review. For organizations handling payments or sensitive user data, enabling these controls can improve visibility into third-party scripts, detect unexpected code changes, and reduce the chance that false alarms overwhelm security teams.

javascriptllmmachine-learningabstract-syntax-tree+4

cloudflareMar 27, 2026

How we use Abstract Syntax Trees (ASTs) to turn Workflows code into visual diagrams (opens in new tab)

Cloudflare uses Abstract Syntax Trees (ASTs) to turn code-based Workflows into visual diagrams. Because Workflows execute dynamically—supporting parallel promises, awaits, loops, and conditionals—the system analyzes code structure and relationships to infer execution order. The resulting diagrams help developers understand workflow shape, especially as coding agents generate more application code. ## Why Code-Based Workflows Are Difficult to Visualize - Unlike declarative workflow builders, Cloudflare Workflows are ordinary code. - Workflows may contain: - `Promise` and `await` relationships - `Promise.all` for parallel execution - Loops and conditionals - Steps nested inside functions or classes - The runtime discovers and executes steps as it encounters them, rather than following a predefined sequence. - Unawaited steps can execute in parallel, while `await` establishes blocking dependencies. ## How Workflow Execution Works - A supervisor Durable Object, called the engine, starts for each workflow instance. - The engine dispatches execution to the user Worker. - When the Worker encounters `step.do`, control returns to the engine. - The engine executes the step, persists its result or error, and invokes the Worker again. - Since the engine does not inherently retain the complete intended order of steps, diagram generation must reconstruct those relationships from the source code. ## Parsing and Building the Workflow Graph - Cloudflare fetches the bundled Worker script at deployment time. - A parser converts the script into an Abstract Syntax Tree. - An internal service: - Identifies `WorkflowEntrypoints` - Finds calls to workflow steps - Builds and traverses an intermediate graph - Produces the final diagram through Cloudflare’s API - AST analysis tracks promises and `await` expressions to determine: - Which steps depend on one another - Which steps block execution - Which steps can run concurrently ## Handling Bundled and Minified JavaScript - Workers are generally bundled with tools such as esbuild and may be minified. - Minified output can obscure the original TypeScript structure and vary between bundlers. - The diagram system therefore has to recognize workflow patterns in dense, transformed JavaScript. - For example, several agent steps—such as summary, correctness, and clarity agents—may be created without awaiting them, indicating parallel execution. - The generated graph makes that concurrency visible even when the deployed code is difficult to read. Cloudflare’s AST-based approach provides a practical way to visualize dynamic, code-defined workflows. Developers can inspect how steps connect, branch, and execute in parallel directly from the dashboard, though the beta diagrams will continue to improve as more workflow patterns are supported.

javascriptcloudflaretypescriptworkers+4

cloudflareMar 24, 2026

Sandboxing AI agents, 100x faster (opens in new tab)

Cloudflare argues that AI-generated code needs secure execution, but traditional containers are too slow, memory-intensive, and difficult to scale for consumer-scale agents. Its Dynamic Worker Loader uses lightweight V8 isolates to create disposable, isolated sandboxes in milliseconds, with controlled access to APIs and no internet connectivity. The result is a sandbox roughly 100 times faster and substantially more memory-efficient than containers, provided agents can write JavaScript. ## Why Containers Fall Short - AI-generated code cannot safely run directly through `eval()`, since prompts could cause the model to introduce vulnerabilities. - Containers provide isolation but typically: - Take hundreds of milliseconds to start - Consume hundreds of megabytes of memory - Require warm instances to reduce latency - May encourage unsafe container reuse - These limitations make containers poorly suited to running a fresh sandbox for every request or user agent. ## Dynamic Worker Loader - Cloudflare’s Dynamic Worker Loader lets a Worker instantiate another Worker dynamically from runtime-provided code. - The host can: - Supply generated JavaScript modules - Expose selected APIs through RPC stubs - Disable or intercept outbound internet access - Invoke methods exported by the dynamically loaded Worker - The feature is in open beta for paid Workers users. ## Faster, Smaller Isolates - Dynamic Workers use V8 isolates, the same sandboxing technology underlying Cloudflare Workers. - Isolates: - Start in a few milliseconds - Use only a few megabytes of memory - Are approximately 100 times faster and 10–100 times more memory-efficient than typical containers - A new isolate can be created for one request and discarded afterward without maintaining a pool of warm sandboxes. ## Scalability and Latency - Dynamic Worker Loader has no container-style global concurrency or sandbox-creation limits. - It relies on the infrastructure that already scales Cloudflare Workers to millions of requests per second. - Each request could theoretically load its own isolated sandbox, even at very high concurrency. - Dynamic Workers commonly run on the same machine or thread as their parent Worker, avoiding network round trips and warm-sandbox lookup delays. - They are available across Cloudflare’s global network. ## JavaScript as the Agent Runtime - The main limitation is that agent-generated code should generally be JavaScript. - Workers also support Python and WebAssembly, but JavaScript is faster to load for short-lived snippets. - Cloudflare argues this is acceptable because: - LLMs can generate major programming languages - JavaScript has extensive training data - JavaScript was designed for web-based sandboxed execution ## TypeScript APIs for Agent Tools - Agents still need access to external capabilities such as chat systems and APIs. - TypeScript interfaces provide a concise way to describe these programming APIs. - Compared with MCP’s flat tool schemas or verbose OpenAPI specifications, TypeScript can express: - Methods and parameters - Return types and promises - Objects such as messages - Subscription and disposal behavior - This gives agents precise API knowledge with fewer tokens and lets them write direct code rather than issuing numerous tool calls. Dynamic Worker Loader is presented as a practical foundation for secure, disposable AI-agent execution: use V8 isolates for low-latency sandboxing, expose only narrowly defined TypeScript/RPC capabilities, and block network access unless explicitly required.

javascriptllmtypescriptcloudflare-workers+4

cloudflareFeb 27, 2026

We deserve a better streams API for JavaScript (opens in new tab)

Web Streams established a cross-runtime standard for handling streaming data, but their design reflects constraints from 2014–2016 rather than modern JavaScript practices. James M. Snell argues that the API’s reader, lock, and controller machinery creates unnecessary complexity and performance costs. He presents an alternative based on JavaScript language primitives that reportedly runs 2× to 120× faster across browsers and major runtimes. ## Historical Design Constraints - The WHATWG Streams Standard aimed to provide portable APIs for creating, composing, and consuming streams. - It was adopted by browsers, Cloudflare Workers, Node.js, Deno, Bun, and APIs such as `fetch()`. - The design predates JavaScript async iteration, which was standardized in ES2018. - Because `for await...of` did not yet exist, Web Streams introduced a separate reader/writer acquisition model. ## Excessive Ceremony for Basic Reads - Reading a stream to completion traditionally requires: - Calling `stream.getReader()`. - Repeatedly awaiting `reader.read()`. - Checking `{ value, done }` on every iteration. - Releasing the reader lock in a `finally` block. - These steps are API choices rather than inherent requirements of streaming. - Modern async iteration reduces the same operation to: ```js for await (const chunk of stream) { chunks.push(chunk); } ``` - However, async iteration was added after the original design, so it does not eliminate the underlying reader, lock, and controller complexity. - Advanced features such as BYOB reads still require developers to use the lower-level APIs. ## Problems with Manual Locking - Calling `getReader()` places an exclusive lock on the stream. - While locked, other code cannot read, pipe, or cancel the stream directly. - Forgetting `reader.releaseLock()` can permanently prevent later consumers from using the stream. - The `locked` property indicates that a lock exists, but not who owns it, why it exists, or whether the reader remains usable. - Internal operations such as piping also acquire locks, which can make stream behavior surprising. - Lock-release behavior with pending reads was historically unclear and varied between implementations before being clarified by the specification. - Async iterables improve the user experience by handling reader and lock management automatically, but the underlying model remains complex. ## Proposed Direction - The post argues that Web Streams’ limitations are fundamental design consequences, not isolated bugs easily fixed through incremental changes. - A better API should be built around modern JavaScript primitives, especially async iteration. - The author’s alternative reportedly achieves between 2× and 120× the performance of Web Streams across Cloudflare Workers, Node.js, Deno, Bun, and major browsers. - The claimed gains come from different architectural choices rather than narrowly optimized implementations. A more modern streams API should make common operations natural, avoid exposing fragile manual lock management, and use JavaScript’s native asynchronous iteration model from the start.

javascriptapi-designnode.jsweb-streams+3