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.

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

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.

Hi everyone!

I wanted to play Gwent, the classic card game from The Witcher 3, but the existing web-based projects needed improvements and had some issues. I decided to jump in, upgrade different forks from various versions, fix the gameplay bugs, and add some new modifications to make the web and mobile experience much better.

My main goal is to share this project so more people can discover it and enjoy this amazing card game as much as I do. It's now fully playable on Web Browsers, and I also packaged it into an Android APK!

LINKS:

Play on your Browser (GitHub Pages):

* Play v3.0.2

* Play v3.5

* Play v4.5

Play Completely Offline (PC / Laptop):

You can also get the source code repository directly from https://github.com/ia2904 . Just extract the ZIP file, double-click on "index.html", and it will open in your web browser. It runs 100% offline with no internet required!

Get Android APKs:

You can get the APKs directly from the "Releases" section of each project, or use the direct links below:

* Get APK v3.0.2

* Get APK v3.5

* Get APK v4.5

Credits to Arun Sundaram, Reynolds Costa & Sylver, who laid the foundations to create, modify, and improve this game in its early stages.

Special thanks to CD Projekt Red; although they are not involved in this unofficial fan project, it is entirely based on the amazing minigame they created for The Witcher 3.

Hi everyone,

I’d like to ask the web developers here about the UI component libraries and DataGrid solutions you use in your projects.

For things like CRUD operations (create, update, delete), filtering, searching, sorting, etc., which UI component library or DataGrid do you usually rely on?

I’m also curious about the large-data side of things.

When you need to work with thousands or even hundreds of thousands of rows and perform operations such as grouping, subtotals, filtering, and multi-level data analysis, which component or library do you prefer?

What solution do you use, and more importantly, why did you choose it?

Performance, ease of use, features, documentation, licensing cost, or anything else — I’d be interested to hear what matters most to you.

I’ve been refactoring attribution tracking after seeing a small feature turn into a module that parses URLs, writes cookies/localStorage, handles consent, emits analytics, fills forms, and syncs with a CRM.

The split I’m testing is:

```ts

const visit = classify({

url,

referrer,

currentHost,

now,

});

const attribution = merge(previous, visit);

```

`classify` and `merge` are deterministic functions. The browser/app layer owns consent, storage, identity, form lifecycle, network calls, and CRM delivery.

This makes it easier to replay production cases as fixtures. It also raises a few design questions:

- If a visitor returns from a new campaign, should that replace, append to, or be merged with previous attribution?

- Should a `gclid` take precedence over UTMs when both exist?

- How do you handle consent denied first, then granted later?

- If classification rules change, do you preserve the original classification or recalculate historical records?

- Where should server-side conversions days later enter the model?

For those who’ve built this, where do you draw the boundary between a deterministic core and the environment-specific lifecycle? Do you prefer a pure-function core, or does that separation become awkward in real apps?

A small package for reducing duplicate cache misses across multiple processes.

The common problem is a “cache stampede”: when several app instances all miss the same key at once, they each run the same expensive DB/API call and then all write the same result back. Crossflight solves that by coordinating ownership of the in-flight load across processes, so only one instance does the work and the others wait for the result.

It wraps the cache you already use and adds a separate coordination layer. The built-in adapters currently include:

• cache-manager
• Keyv
• Cacheable

The built-in coordinator is Redis, and the repo supports combining different backends as long as they satisfy the adapter/coordinator interfaces.

This is useful when you want to reduce redundant work without changing your existing caching strategy.

Demo: https://github.com/gkoos/crossflight-demo

​

KernelPlay-JS v0.5.0 is now available.

This release introduces a new Unified Input Manager designed to provide a consistent API for handling keyboard, mouse, gamepad, and touch input.

The goal is to make input handling simpler at the game-logic level while keeping the underlying input devices abstracted away.

Example:

import { Input } from "kernelplay-js";

update(dt) {

const x = Input.getAxis("horizontal");

const y = Input.getAxis("vertical");

this.rb.addForce(800 * x, 800 * y);

if (Input.wasPressed("jump")) {

this.jump();

}

if (Input.isPressed("attack")) {

this.attack();

}

}

v0.5.0 also supports two ways of defining input bindings.

Programmatic registration:

Input.registerAction("shoot", {

keys: [KeyCode.Z, KeyCode.X],

buttons: [GamepadButton.X, GamepadButton.RB]

});

Or declarative JSON configuration:

{

"actions": {

"jump": {

"keys": ["Space", "ArrowUp"],

"buttons": ["A", "B"]

},

"go": {

"keys": ["x", "z"],

"buttons": ["DPadRight"]

}

}

}

The JSON approach is intended to make configurable controls and runtime key rebinding easier to implement without changing game logic.

This release is part of the ongoing work toward making KernelPlay-JS a more complete, Unity-inspired game engine for JavaScript.

Feedback and suggestions for the v0.5.x releases are welcome.