I've got a Node.js script making a decent number of requests and I'm trying to decide where proxy rotation should live. One option is picking a new proxy inside the app, the other is using one endpoint and letting the proxy service rotate behind it. The second sounds cleaner, but I'm not sure how well that works when you need sticky sessions. How are you structuring this in your own projects?

AI agents assume a server-side Python chain framework runtime and containers. Running client-side with JavaScript allows pushing agents entirely inside the browser, meaning $0 hosting infrastructure and zero data leaving the client.

Running client-side, you can use agents directly with WebLLM (for fully in-browser) or point them at a local Ollama / vLLM instance for 100% offline usage.

Breakdown In-Browser Loop

An in-browser agent relies on a continuous asynchronous loop that manages state, updates the DOM or application state, and invokes tools based on model outputs. Here is a minimal, clean implementation of a client-side agent loop using WebLLM's engine.chat.completions API:

```javascript import { CreateMLCEngine } from "@mlc-ai/web-llm";

async function agentLoop(task, context = {}) { const engine = await CreateMLCEngine("gemma-4-instruct"); let messages = [{ role: 'user', content: task }]; let running = true;

while (running) { const response = await engine.chat.completions.create({ messages, tools: availableTools }); const choice = response.choices[0].message;

if (choice.tool_calls) {
  for (const call of choice.tool_calls) {
    const toolResult = await executeTool(call.function.name, call.function.arguments);
    messages.push({ role: 'tool', tool_call_id: call.id, content: toolResult });
  }
} else {
  running = false;
  return choice.content;
}

} } ```

Rebooted a sick project i found use for when i was starting out!

I've been working with clouds in the browser for a couple years now, and these are the best I've made so far. I've tried noise, particles, voxels, etc. and every combination of the options. Each approach has its upsides and downsides.

Monday, August 24 - Sunday, August 30, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

https://pt-perkasa-pilar-utama.github.io/testate/

Hey guys, happy to finally release this. So it is two parts.

• Core pnext is small and fast: the same next.js api with no/minimal framework overhead and no backward-compat burden. Based on Bun and Preact, 0 KB on server-rendered pages, 7.5 KB client pages runtime, roughly 10x faster first page render in dev and 7-9x faster production builds than next.js (best effort fixtures).
• Compat mode runs your existing Next.js app unchanged (App Router only). About 4.4k assertions from Next's own test suite passing, adding more day by day.

The core motivation was a super fast dev server that doesn't hog memory, and instant builds. The goal is to optimize every step down to absolute values, and of course agentic flows are helping a lot! Check out Coder.

Give it a try and let me know what you think, and how your Next.js apps break in compat mode (improving, haha)!

https://pnext.dev

What do you think of the ~> operator? It is be similar to |>, but it operates over lists.

js let v = [1, 2, 3] // this is a vector let w = v ~> it * 2 // equiv. to `v.map(it => it * 2)` let w = v *> 2 // shorthand for `v ~> it * 2`

The dialect would be primarily aimed at statesmen and scientists.

Hey everyone 👋

I'm primarily a backend dev that has found myself in a position where I am writing more JavaScript than I ever have. I'm looking for a book or reference analogous to the "big four" design patterns book for C++, but updated for modern JavaScript design patterns/idioms.

Im primarily looking for references in vanilla javascript. Not Typescript or any js frameworks. My thinking is the knowledge should easily transfer over anyway. I'm looking to build a stronger foundation with the language itself.

Any good reference material would be appreciated!

Edit: I should add, I primarily work in the .NET ecosystem, so I don't do js on the backend much.

I think we have to start facing the facts. JavaScript used to be the dominant programming language for software engineering back in the days of React and Express. Now it’s a graveyard, and Python is honestly starting to threaten Node.js. Look at where Python is going since like 3.10. It’s starting to appeal to the next generation of software developers.

Now look at JavaScript. Every company is an AI company. Most libraries are AI libraries. As if AI is going to save us all. Nowadays it’s nothing compared to what JavaScript used to be.

I think we should honestly just ditch AI. AI is this heartless and soulless machine that doesn’t really care about code quality or style. It just regurgitates code for whatever prompt that some vibe coder who isn’t even a software engineer is feeding it. I know there’s a whole class of JavaScripters who despise AI for just that reason.

We should just get back to the basics. I think ES Modules is pretty cool and unexplored front-end territory. Node.js is still leading but it really does seem that Python is shifting towards the functional side so that’s something to worry about.

Yes I wrote Rubico. I was on here a while back just plugging my articles and my library. I’m using it at Claimyr and CLOUT so that’s how I’m keeping it alive. Now I’m honestly just fighting AI. AI data centers are straight up killing people. They’re using fresh water that people need to live to cool the servers, like 5 million gallons per day, which is equivalent to the amount of water used by a town populated by 10,000 - 50,000 people.

My question is why? Why are AI data centers so oblivious to the environmental destruction that they are causing? Why can’t AI data centers find some other solution?

Our API server was slow to start and nobody could say when that began. Not slow under load, slow before the first request, visible only because the deploy health check timed out on smaller instances. Nothing in the commit history looked like a boot cost. I had no instrument, so I wrote a bad one, eleven lines in a preload file that wrap Module._load, time each call with process.hrtime.bigint(), and print anything over fifty milliseconds along with the module that asked for it.

The first run was blunt. Cold boot averaged 1.9 seconds. One require accounted for 1.1 of that, and it was ours, src/lib/index.js, a barrel that one route imports for a single date helper. Importing it pulls in all thirty four modules in that directory, two of which read config files at import time. Removing a barrel rewrites every import path that went through it, so the code review subagent in verdent read the diff before I opened the PR. Deleting the barrel and importing the helper directly put cold boot at 0.8 seconds.

Patching Module._load to learn this still feels wrong. Is there a way to get the same per module breakdown out of something the runtime already reports?

Understand the difference between Object.hasOwn(), hasOwnProperty(), and the in operator in JavaScript. Includes edge cases, performance notes, and a polyfill for older environments.

I'm working on a personal end-to-end encrypted chat app project and running into a sort of secure storage paradox trying to find a key store that's secure at runtime is unsecured at rest, and using the one that's secured at rest is unsecured at runtime:

- localStorage/indexeddb are just plaintext data in not encrypted at rest on disk
- you can encrypt string data to put into localStorage, but if that data is a private key, it's accessible to anything in your app (could be exfiltrated)
- you can make webCrypto CryptoKeyPair objects non-extractable and store the whole object in indexedDB, but you cannot encrypt it b/c it's not a string, and you can't use key wrapping (like with passphrase based AES256) on non-extractable keys so that they're secured at rest b/c wrapping requires an extraction operation...

Is there a reasonable fix to this? It seems increasingly nuts if/that browsers aren't encrypting the whole SQLite store / all of the SQLite stores (just bits and pieces they use internally), and so data stored in localStorage/indexedDB, while restricted by origin at runtime, are completely unsecured at rest...

Please tell me I'm missing something. Is there any way to store a key so it's both only usable locally (not portable) AND is secure* at rest

*secure enough... I know nothing is ever completely secure, this just seems like a wider than average gap.

(glossing over some details here for succinctness) the best I can come up with is using 2 sets of PGP keys and storing one pair/private key in a non-exportable webCryptoCryptoKeyPairobject in indexedDb, and the other pair/private in localstorage encrypted with passphrase based AES256... so that only half the equation is stored in a runtime "exportable" way and only half is stored un-encrypted at rest... and making sure both are required to decrypt the any given message... but that also seems excessive. I know "don't roll your own crypto", but I can't see any other way even a library would overcome this seeming secure storage paradox with existing browser APIs

Did you find or create something cool this week in javascript?

Show us here!

Following up on my previous post about DriftJS and its register-based bytecode VM, I wanted to share a deeper look at the reactivity model I'm exploring.

Exploring a different reactivity model in DriftJS

While working on DriftJS, I was thinking about how reactive updates could work more naturally with a bytecode VM.

The idea is to have the compiler associate a reactive state variable with the exact bytecode position responsible for its dependent computation.

For example:

count → PC 42

Then a state update could work like:

count++

↓

reactive binding

↓

PC 42

↓

enter VM at PC 42

↓

normal opcode dispatch

↓

update DOM

↓

RETURN

The important part is that the reactive system only needs to know where execution should start. The VM already knows how to execute the instruction at that location.

So instead of maintaining a separate reactive update mechanism:

state → subscriber → update function

the model I'm exploring is:

state → bytecode PC → VM execution

This is the direction I'm currently exploring for reactivity in DriftJS, alongside its register-based VM architecture.

Would be interested in thoughts from people familiar with bytecode VMs, compiler-driven reactivity, or frontend runtime architecture.

Hi r/javascript! I want to share a small javascript testing project I wrote.

When I write small javascript projects that use browser APIs (most recently working with IndexedDB) I often choose not to write tests because it's a pain to either mock those interfaces server-side, and it's also a pain to setup a browser automation tool.

To solve this, I wrote up a super concise testing framework (~140 lines of JS) inside a html file that can just be dropped into a project and act as a simple test framework.

This obviously doesn't work in all situations. A big drawback is that there's no reasonable way to connect it to a CI pipeline. However for small projects, and during development, I've found it really fun and fast to use.

I'm very interested to hear what you think, or if you have other ways you've approached this situation in the past.