The Boundary ActiveAdmin Forces: HTML Admin vs API Controllers
ActiveAdmin needs a full Rails web boundary, while API-only endpoints need a lean controller. Compare the two paths to see where sessions, assets, and browser protections belong.
Loading…
Topic
36 posts about JavaScript. Every summary links to the original.
See the idea
ActiveAdmin needs a full Rails web boundary, while API-only endpoints need a lean controller. Compare the two paths to see where sessions, assets, and browser protections belong.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
VoidZero has open-sourced Void, a toolkit for building and deploying full-stack Vite applications to Cloudflare. The release includes three products: Void Platform, Void SDK, and Void CLI, which integrate into a single Vite workflow. The SDK provides file-based routing, database integration via imports, and end-to-end type safety from the database to the user interface. The CLI handles building, migrating, provisioning resources, and deploying with a single command, automatically inferring bindings like databases or AI services. The Platform offers a shared deployment environment with access controls and resource limits, enabling teams to prototype and ship internal apps in minutes.
Sentry JavaScript SDK v11 replaces OpenTelemetry-based tracing with a code transformer from the apm-js-collab packages that injects diagnostics channels into supported modules at load time. The transform wraps target functions in tracingChannel() calls, and Sentry integrations subscribe to those channels to create native spans directly from the events. This approach works both at runtime via Module.registerHooks and at build time through bundler plugins for Vite, esbuild, webpack, and others, with no risk of double-wrapping. The previous OpenTelemetry instrumentation required Node-specific loader hooks, could not instrument bundled dependencies, and had ordering issues with ESM imports, limiting support to Node.js. v11 extends automatic tracing to Cloudflare Workers, Deno, Bun, and bundled server deployments while offering three OpenTelemetry integration modes: Sentry only, OpenTelemetry-compatible, or custom OTel with OTLP export.
WebRTC provides browser APIs for real-time voice, video, and data sharing without plugins, with mandatory encryption via DTLS-SRTP and DTLS; the standard became a W3C Recommendation in January 2021. The core APIs are getUserMedia for capturing audio/video from user devices, RTCPeerConnection for peer-to-peer media exchange via offer/answer and ICE candidates, and RTCDataChannel for arbitrary data transfer. WebRTC is supported by all major browsers and used by services like Google Meet, Discord (which uses media servers for group calls to avoid expensive peer-to-peer), and AI voice agents. Twilio offers Video and Voice JavaScript SDKs that handle signaling and media relay, enabling calls to phone numbers and SIP endpoints. The post includes a camera preview example using getUserMedia that requires a secure origin and can be served with Python, then directs readers to Twilio’s quickstart tutorials for building video and voice applications.
The back/forward cache (bfcache) allows instant page restores by freezing snapshots, yet its hits register no events in traditional telemetry, creating a blind spot for teams. Sentry’s bfcacheMetricsIntegration fills this gap by modeling three browser-provided signals as application metrics: a navigation counter with hit/miss outcome, a per-reason counter for misses via the notRestoredReasons API, and a distribution of fallback reload duration. The integration is opt-in and launched in JavaScript SDKs v11; detailed miss reasons are currently Chromium-only due to browser API support. Users can query these metrics to break down bfcache health by route, release, or browser, enabling discovery of regressions caused by unload listeners, cache-control headers, or third-party scripts. This turns the bfcache from an invisible performance feature into a measurable, trackable signal that teams can monitor and improve.
Anthropic announced the acquisition of Bun, a JavaScript runtime, as Claude Code reached $1 billion in run-rate revenue six months after becoming publicly available. Bun is an all-in-one toolkit that combines a runtime, package manager, bundler, and test runner, and the post says its focus on speed, reliability, and developer experience has made it important to Claude Code’s infrastructure. The companies had collaborated for months, with Bun helping scale Claude Code and contributing to its native installer; Anthropic says the acquisition will bring faster performance, improved stability, and new capabilities. Bun will remain open source and MIT-licensed, while Anthropic continues investing in its JavaScript and TypeScript tooling, which has more than 7 million monthly downloads and over 82,000 GitHub stars.
Cloudflare has rebuilt the module registry in workerd, the open-source core of the Workers runtime, to improve speed, standards compliance, and alignment with Node.js. The change addresses compatibility beyond runtime APIs by making module resolution, loading, and caching behave more like Node.js across ESM, CommonJS, and WebAssembly. The new registry uses URLs as specifiers, supports import.meta.url, import.meta.main, and import.meta.resolve(), distinguishes modules by query strings and fragments, validates import attributes, follows require(esm) rules, and compiles modules lazily while sharing caches across isolates. It also supports WebAssembly source phase imports and consistent loading errors; the existing registry remains in place, and the new implementation must be enabled with the new_module_registry compatibility flag.
Hugging Face’s WebAI team is releasing @huggingface/kernels, a JavaScript loader for optimized WebGPU kernels hosted on the Hub, alongside an initial collection of 207 Apache-2.0 kernels. Each kernel repository packages a versioned contract, metadata, correctness cases, benchmark cases, and parameterized WGSL shader templates, while the loader derives outputs and selects variants for a request and device. Fleet adds browser-based correctness and performance testing, with consent-based private evidence used to identify failures, compare variants, and guide optimization. In comparisons against ORT WebGPU on an Apple M4, matching cases showed a 2.57x geometric-mean speedup and a 1.90x median speedup, though the measurements cover individual GPU operations and exclude setup costs. The project is also intended as a shared foundation for browser inference and future integration with higher-level tooling.
The tutorial shows how to use Twilio Lookup Identity Match to confirm that a person is linked to a submitted phone number and reduce sign-up fraud. It describes a zero-knowledge match against authoritative sources such as mobile carrier records, with possible use during sign-up, login, account changes, or checkout. The implementation starts from an international telephone input project, collects first and last names alongside an E.164 phone number, and passes them to the Lookup API with the identity_match field; the response exposes per-field statuses and a summary score. The sample JavaScript treats the check as successful when the phone is valid and both names are exact or high partial matches, then displays the result, while the post also notes approval requirements outside the US, test parameters, and alternative Lookup packages.
This tutorial builds a browser-based video chat application using Python, Flask, vanilla JavaScript, HTML, CSS, and Twilio Programmable Video. It adds text chat through Twilio Conversations and screen sharing, allowing participation on modern desktop and mobile browsers without installed software. The implementation covers Twilio account and API-key setup, environment variables, a Python virtual environment, client-side event handlers, and ngrok, which exposes the local Flask server through an HTTPS public URL for testing on other devices. The refreshed project targets Flask 3.x, twilio-python 9.x, Twilio Video JS 2.35.x, and Twilio Conversations classic JS 2.x, and the completed flow supports live calls, screen sharing, and text chat. Participants must use unique names because Twilio identifies them by token identity.
This tutorial builds a basic browser-based video conferencing application with JavaScript, HTML, and CSS using Twilio Programmable Video. It targets desktop and mobile web browsers, requiring no installed client, and uses the Twilio Serverless platform to provide hosting and a public URL. The setup creates a Twilio Serverless project, configures ACCOUNT_SID, API_KEY_SID, and API_KEY_SECRET in .env, runs npm start locally, and deploys with twilio serverless:deploy; the client manages joining, participant video streams, disconnection, and participant counts. After deployment, users can open the generated index.html URL on separate devices or share it with others to see participants appear dynamically, while the conclusion notes additional Twilio Video capabilities such as recording, custom data tracks, screen sharing, and virtual backgrounds.
Medium built a new Table of Contents feature after an existing Chrome extension demonstrated demand, while its approach of inserting a static list into post content created revision, maintenance, navigation, and reading-experience problems. The shipped implementation derives a nested list from the rendered post body at runtime: H2 and H3 become top-level entries, H4 headings nest beneath the latest top-level heading, and lead title, subtitle, and kicker are excluded. It appears as a right-margin indicator that scrolls with the reader, highlights the current heading, supports smooth scrolling, and uses a sliding window for posts with many headings. Full-width images receive a translucent background, one-heading posts hide the feature, and mobile needs a separate solution because desktop indicators overlap content; the feature took a couple of days, mostly for UX testing and design iteration.
Google announces LiteRT.js, a JavaScript binding of LiteRT that runs .tflite AI and ML models directly in web browsers. It targets local inference for JavaScript and TypeScript applications, with privacy benefits, zero server costs, and low latency, while providing smoother deployment for existing .tflite models. Through WebAssembly, it exposes LiteRT’s optimized runtime across XNNPACK CPU, ML Drift with WebGPU, and experimental WebNN for NPUs; LiteRT Torch supports one-step PyTorch conversion, and AI Edge Quantizer enables layer-specific quantization. The initial release includes the @litertjs/core npm package, demos, and examples covering YOLO26, depth estimation, and Real-ESRGAN upscaling. In controlled benchmarks on a 2024 Apple MacBook Pro with M4, it outperformed other web runtimes by up to 3x, while WebGPU or WebNN delivered 5–60x speedups over CPU execution; results may vary with hardware, thermal conditions, and browser drivers.
This tutorial shows how to customize an Okta-hosted sign-in page for a fictional to-do application while retaining the Okta Identity Engine and Sign-In Widget (SIW). It starts with a custom domain and brand configuration, then uses the page code editor, SIW design tokens, custom text, Tailwind CSS via CDN, and external JavaScript behavior to create a responsive layout, branded footer, and terms-and-conditions modal. The modal uses Alpine.js transitions and a MutationObserver watching the authentication container so it appears after SIW elements render; Google Fonts also require CSP allowlist entries for googleapis.com and gstatic.com. The post notes that browser manipulation can bypass the modal, recommends accessibility testing after customization, and describes connecting the brand to an Okta React sample through an OIDC custom issuer URL.
This tutorial shows how to customize the Okta-hosted Sign-In Widget (SIW) for a fictional to-do application while retaining Okta Identity Engine authentication flows. It covers configuring a custom domain and enabling SIW Gen3, then using brand settings, design tokens, custom CSS properties, and page code to change fonts, colors, layout, and background treatment. The implementation uses the widget’s afterTransform method and FormBag to revise the identify form, remove help, unlock, and divider elements, change the title, and add a custom blog link. It also explains the default HTML and JavaScript rendering configuration and describes updating an OpenID Connect application to use the brand’s custom sign-in URL as its issuer.
The supplied material consists of the title “An Internship on Ramp’s Forward Deployed Engineering Team” and page markup, but it does not provide narrative details about the internship, the team, responsibilities, technical work, or outcomes. The markup identifies the site as “Ramp Builders,” supplies an RSS feed titled “Ramp Builders Blog,” and includes standard icons, social metadata, and a JavaScript application entry point. It also states that JavaScript must be enabled to run the app, while linking a stylesheet and several favicon assets. Analytics configuration includes Google Analytics and Segment, with a Ramp-hosted Segment endpoint and Sprig (Actions) disabled; these details describe the page infrastructure rather than the internship.
Print on Demand presents a resource-conscious alternative to scaling an application by separating PDF generation from the main server. The post explains how a Fly.io PDF appliance uses Fly-Replay to route a PDF request to a machine running headless Chrome, which requests the original page without its “.pdf” extension and converts the returned HTML into a PDF. Each machine reuses one Chrome instance across requests, while auto_stop_machines allows idle machines to stop and restart on demand. Integration requires cloning the GitHub repository, creating and configuring an app, deploying it, and returning a fly-replay response header for PDF-directed requests. The extracted production code is packaged for deployment with existing applications, supports session, cookies, and basic authentication through passed-back HTTP headers, and can serve applications using different languages and frameworks.
The page identifies the item with the title “Picking Low Hanging Fruit,” but provides no accompanying article narrative or technical subject matter. Instead, it consists of HTML metadata, favicon and RSS references, JavaScript and stylesheet asset links, a notice that JavaScript must be enabled, and analytics snippets. The metadata names the site “Ramp Builders” and labels its RSS feed “Ramp Builders Blog”; the scripts reference Segment analytics and a Google Analytics configuration. No problem, implementation, experiment, outcome, or conclusion is described, so the title’s meaning and the post’s intended subject cannot be established from this text. There is no basis in the available material for a more specific technical classification.
Fly.io is preparing support for Bun as Bun 1.0 approaches, expanding beyond its ongoing Node.js work because Bun aims for complete Node.js API compatibility. With flyctl 0.1.54 and @flydotio/dockerfile 0.3.3, users can launch and deploy Bun applications through fly launch and fly deploy if Bun 0.5.3 or later is installed and package.json includes an eligible start, module/type, or main configuration. The post says applications following Bun’s Quickstart and Fly’s hands-on walkthrough can be deployed, and provides a sample. Support is beta, with noted compatibility issues including bun install lacking --prune, unsupported throwIfNoEntry in fs.statSync, and readline-based programs failing to exit; shared Dockerfile generation means fixes for either runtime generally benefit both.
The post explains why the JavaScript ecosystem is “delightfully weird,” arguing that its defining feature is not JavaScript’s oddness but the layers of transformation surrounding it. Bundlers first changed source boundaries by minimizing, tree-shaking, code-splitting, and producing executable files different from those developers wrote; CoffeeScript, Babel, TypeScript, JSX, Svelte, and esbuild extended that pattern. Frameworks and tools also make the ecosystem a “Big Tent,” allowing imports of CSS or PNG files and adding semantics outside ECMAScript, such as Svelte’s reactive labels and TypeScript annotations. React Server Components push this further: “use server” and “use client” are valid no-op statements whose placement changes code meaning, while RSC compiles into a stream of tagged JSON and depends on bundlers. The post presents this cooperation among languages, frameworks, routers, and bundlers—including the server/client interaction demonstrated in Dan Abramov’s React talk—as profound and beneficial, especially for geographically distributed application styles.
Fly.io proposes a general-purpose way to deploy JavaScript and Node.js applications despite the ecosystem’s many frameworks, package managers, runtimes, and TypeScript conventions. Its dockerfile-node project uses package.json, lockfiles, and dependency metadata to generate a baseline Dockerfile, .dockerignore, and optionally a docker-entrypoint script; users can invoke it with npx @flydotio/dockerfile. Conditional EJS templates accommodate framework-specific requirements, with initial templates for Express, Fastify, Gatsby, Nest, Next, Nuxt, and Remix, though current support may extend only to a splash screen. Future plans include replacing Fly.io’s existing flyctl scanners, integrating deployment-time secrets, volumes, databases, and health checks, and adding customization such as build caching, swap, Docker Compose generation, browser setup, and non-root execution.
The best engineering reads, once a week.