<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>javascript on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/javascript/</link><description>Recent content in javascript on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 26 Sep 2026 21:31:14 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/javascript/index.xml" rel="self" type="application/rss+xml"/><item><title>React Native's Built-In URL Does Not Resolve '../x'</title><link>https://blog.yusukeikoma.com/posts/react-native-builtin-url-does-not-resolve-dot-dot/</link><pubDate>Sat, 26 Sep 2026 21:31:14 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/react-native-builtin-url-does-not-resolve-dot-dot/</guid><description>A client library shared between a website and a React Native app usually fails on the boring parts of the Web platform, not on fetch. Reading React Native 0.87.1 and Expo 57 sources shows three layers of runtime, a URL class that returns &amp;lsquo;/b/c/d/../x&amp;rsquo; where the web returns &amp;lsquo;/b/x&amp;rsquo;, and a fetch with no response stream unless Expo replaces it. A small client that checks what it needs, tested against four simulated runtimes.</description></item><item><title>A Durable Object Alarm Retries 6 Times, Then Stops</title><link>https://blog.yusukeikoma.com/posts/durable-object-alarm-retries-six-times-then-stops/</link><pubDate>Thu, 24 Sep 2026 21:33:45 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/durable-object-alarm-retries-six-times-then-stops/</guid><description>A Durable Object has one alarm, runs it at least once, and retries a failing handler with backoff up to six times. After that nothing wakes the object again. A walkthrough of a lease-expiry ledger that survives all three: a table as the source of truth, a constructor that re-arms the alarm, and an effect that tolerates being run twice. Run on local workerd, with the documented limits quoted from Cloudflare.</description></item><item><title>Durable Object Hibernation Keeps the WebSocket and Drops Every Class Field</title><link>https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/</link><pubDate>Tue, 22 Sep 2026 13:39:45 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/</guid><description>Cloudflare&amp;rsquo;s docs say hibernation keeps WebSocket connections open and discards in-memory state. This post runs a small Durable Object under local workerd and watches exactly what that means: the socket stays OPEN, the constructor runs again on the next message, class fields reset, attachments survive only if you serialize them, and a pending timer or the standard WebSocket API quietly turns hibernation off. Production behaviour and billing are not tested.</description></item><item><title>Cancel the Stream, Not the Connection, When One HTTP/2 Request Times Out</title><link>https://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/</link><pubDate>Tue, 08 Sep 2026 12:56:00 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/http2-timeout-stream-vs-connection/</guid><description>A request deadline fired on a connection that carries many requests at once. Do you close the connection, or only the request? In a small Node lab, closing the HTTP/2 session failed two innocent requests, while cancelling only the stream let them finish on the same TCP connection. The same lab shows the one case where cancelling is not enough: a lost packet stalls every stream on a TCP connection, and a connection-level PING is the right way to tell.</description></item><item><title>Waiting for bufferedAmount Protects the Sender, Not a Slow Consumer</title><link>https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/</link><pubDate>Sun, 06 Sep 2026 20:54:24 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/</guid><description>WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.</description></item><item><title>Enable Refresh Token Rotation and Parallel Requests Can Log Users Out</title><link>https://blog.yusukeikoma.com/posts/refresh-token-rotation-concurrent-requests/</link><pubDate>Sun, 30 Aug 2026 13:34:18 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/refresh-token-rotation-concurrent-requests/</guid><description>Refresh token rotation turns a reused token into a theft alarm. A client that fires three requests with an expired access token and refreshes once per 401 presents the same refresh token three times, and trips that alarm on itself. This post breaks a naive client on purpose, fixes it with single-flight refresh and a stale check, and compares the alternatives: a server grace window, request gating, proactive refresh and sender-constrained tokens.</description></item><item><title>Batching and Bounded Frames on a Metered Relay</title><link>https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/</link><pubDate>Wed, 19 Aug 2026 12:47:53 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/</guid><description>When every WebSocket message costs money and every frame has a hard cap, you need batching with independent flush triggers, a single-frame threshold below the cap, bounded chunking, and capability flags that survive mixed-version rollouts. The sharp edges are ordering on shutdown and a zero value that disappears from the wire.</description></item></channel></rss>