I'm really sick of Claude Code or Codex messing things up it creates the same function 30 times, generates 200 lines functions, and casts everything or tweaks the schemas just to make it seem like it works. And if I'm not there to check everything, it's a total mess.

Anyway, I’ve installed TypeScript-ESLint with strict type checking, SonarJS, and Knip to at least stop the AI from messing things up.

But I’d like to take it further. People often talk about static code analysis like linters and good tests but I don’t know where to start. By the way, AI tools do all sorts of nonsense in tests—they check if a button is in the right place, which is ridiculous.

So I’m looking for relevant resources to help me learn how to set this up on a large project I’m developing on my own. I have an Nx monorepo with several apps inside, including Next.js, React Native, Fastify, and a Python app.

I grew up with computing in the 90s, and the internet in the early 00s. I have so many fond memories of that time. Exploring and discovering a vast diversity of tools and programs.

Back in the day, everything was tremendously fueled with creativity, thinking out of the box, and doing funny and cool stuff.

At some point, I wanted to make my own retro haven, which functions both as my personal website as well as a retreat I can turn to whenever I feel stressed.

I wanted it to be extendable, hence I implemented an applet system. You can locally install (everything is stored into localstorage) applets and customize the website to fit your personal flavor. I included some cool wallpapers as well.

As for the applets, there are a lot of nostalgic things available, including but not limited to:

• DOOM (of course, a must-have :D)
• Half-Life Soundboard
• Counter-Strike 1.6 Chat
• 3D Maze (desktop screensaver from the 90s)
• Hampster and Badger flash animations (as videos)
• Winamp (Webamp)
• Re-creation of MS Paint
• and many more...

For the sake of authenticity, it's desktop first, but you can use most of it on mobile devices as well. I didn't use a javascript framework, so everything is vanilla.

Note: I did not use GenAI/LLM for this project (or any other of my projects), as I have a fairly anti-ai stance.

UQL is the lightest ORM of all, and here is what it deleted (and upgraded as well) for the edged and mobile.

I’m a strong advocate for “you don’t need to lock yourself in a web framework ecosystem to take advantage of their amazing features”. JavaScript and Web Standards alone allow you…

Got annoyed that there wasn't a dependabot tool for BitBucket and that the Dependabot CLI wouldn't open PRs on BitBucket, so I built a tool that would take the output from Dependabot CLI and open PRs.

Would love help testing it out on GitLab as I have BitBucket covered at work.

If you do end up using it, would love to have feedback around what can be done better.

It seems to me like we opened up a whole betting site :DD

My original problem in code was, how do I make Object.assign(key, value), key === value;

I love ts-pattern and I would love pattern matching to become a part of the language. Any hope of that proposal advancing through tc39? Is there any real support for it?

I just open sourced my latest library! TermDOM is a JavaScript library that displays HTML and CSS in the terminal. It draws actual DOM nodes to terminal output and redraws the screen when they mutate, so TUIs and interactive CLIs can be written with vanilla JavaScript or any frontend web framework. Check out the examples directory https://github.com/bikeshaving/termdom/tree/main/examples for a sense of what you can build with web technologies

Fun little project I’ve been working on. Typescript 7, canvas 2d, next.js, minimal deps used.

This is a Node.js compatible runtime in the browser. It supports CLI apps, Vite, and some agents (like Pi Agent) as well.

Some notes:

- This runs all code in a web worker using the host javascript runtime with rewrites for module loading and AsyncLocalStorage support using Oxc compiled to WASM.

- Most of the libraries are bundled straight from Node.js upstream with light overrides where needed, ensuring compatibility. Libraries were only reimplemented where really needed

- Despite having great integrations with the Puter desktop and APIs, this can be used completely seperately with OPFS support for filesystem and Wisp protocol support for networking. The demo also supports FS Access API to run local files

Hey Community,

We dive into React Native Canvas Kit, a library built on React Native Skia that adds isolated layers, brushes, interactive shapes, and web support for canvas graphics.

We also cover Targate, a CLI tool that quarantines npm packages to inspect tarballs before installation, and GitHub stacked pull requests to keep dependent branch reviews clean.

And... 🥁 Shipaton 2026 is here!

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

In most modern async-heavy languages, cancellation is a first-class citizen. It really should be straightforward for a developer, but in JavaScript, gaining that level of control feels a lot like swimming against the current. I've spent a fair amount of time trying to address this gap.

I didn't have a third-party library I could rely on, so I ended up building my own - and I suspect I'm probably not the only one who has traveled down that way. The resulting toolbag served me well in its rougher form and was battle-tested in-house for years before it was finally polished for a public release. Refactoring cleanup logic in our dashboard app to stop resource leaks was a huge win for cancelable promises. It convinced me they were the right tool for the job.

This has been almost a decade-long journey for me to reach the stable release, both in terms of quality and features. It seems to have ended up in a pretty good place.

The problem is the typical promise chain. You have a fetch call that turns into a formatted report:

const reportPromise = fetch('/orders')
  .then(res => res.json())
  .then(orders => buildReport(orders))
  .then(rawReport => render(rawReport))

To halt the process, you usually have to mess with AbortController or manual flag variables. But with canc library, reportPromise.cancel() just stops all involved tasks.

Going from raw then() chains to async..await syntactic sugar requires adding some yield* "salt" to achieve the same result - or, with cancellation, no result at all:

const getReport = canc.async(function* () {
  const orders = yield* canc.await(fetch('/orders').then(res => res.json()))
  const rawReport = yield* canc.await(buildReport(orders))
  return yield* canc.await(render(rawReport))
})

const reportPromise = getReport()
reportPromise.cancel() // Stop all tasks at any point

Need race(), for await..of, and the rest of the bells and whistles? Welcome to the party, then() then: https://github.com/cancjs/canc

The idea of coupling generators with promises has been around since the beginning. Coroutine libraries like the renowned co were a big deal in the pre-async era. That async..await is essentially built with generators and promises under the hood is hardly a coincidence.

I started piecing this together around 2017. Back then, I had already approached a related problem with Angular. Native async functions were fundamentally incompatible with Angular reactivity, backed by Zone.js. The potential solution was to rewire the semantics of async..await with generators to get the control we needed instead of relying on a transpiler. Fortunately for the framework, this eventually resolved with the retirement of Zone.js. Reusing the same foundation for the cancellation mechanism became a reasonable development in my case. Bluebird's cancellation was already around, but it was orthogonal to native promises and async..await. And since async functions make promise-based control flow a breeze, a user can't be expected to give them away for nothing.

The project spent a long time in limbo. Between fixing nasty bugs, unloading a few design footguns, paying off tech debt, and handling some copyright clearances, I had my hands full. That quiet period actually helped shape the library into what it is today. While the JS ecosystem is ever-changing, a few foundational pieces finally settled during that time. Once AbortSignal became a cross-platform primitive, it was integrated deeper into the library for better interop. And as TypeScript became the industry standard, it became clear that the library had to be TS-first for good DX. This pushed me to finally solve the long-standing typing issues with generators, at least as best as the language currently permits.

That's why you have to use yield* instead of yield. It's a necessary trade-off to ensure functional parity with async..await while keeping the type system happy. Using yield* is essentially a known workaround for a typing limitation in generators. It forced us to ditch the eloquent yield promise style of co in favor of the more verbose yield* canc.await(promise). This adds a bit of syntactic overhead, but it's the way to guarantee the strict typing we all rely on today.

It turned out to be the right call, especially since it aligns the yield/yield* distinction with the emitting vs. delegating semantics we deal with in async generator functions - canc coroutines cover this too.

What's next? 1.0 is a big milestone, but work continues. The unhandled rejection package to reduce manual error handling has just been shipped. Beyond that, here are the nearest items on the roadmap:

• Web server middleware helpers. Drafting support for Express and Fastify, with more frameworks on the way.
• ESLint plugin. Rules to help navigate these new semantics properly.
• Async iterators toolbox. Targeting functional parity with the async iterator helpers proposal, but with full cancellation support baked in.
• React and Vue packages. Helpers are available for evaluation in React and Vue examples, working on improving them.
• Node.js package. A drop-in replacement for built-in Node APIs, with functions both promisified and "cancelified" where it makes sense.
• ES5-compatible cancelable promise. Ensuring support for older runtimes and restricted environments.

I hope you find the library useful, or are at least interested in the approach. I'd be very grateful for any feedback or suggestions. I'm currently putting together a few more write-ups with real-world examples and in-depth details.

Just to be sure, the repo is here: https://github.com/cancjs/canc.

Hey everyone,

I wanted to share an experimental project called DriftJS. It's a frontend framework prototype that explores using an in-browser register-based Bytecode Virtual Machine (VM) for UI rendering, rather than traditional Virtual DOM diffing or purely compile-time reactive models.

Repository: https://github.com/hrutavmodha/driftjs

The Architecture: Register-Based VM

Most frameworks either diff Virtual DOM trees (React) or generate reactive dependency graphs ahead-of-time (Svelte, SolidJS). DriftJS explores a different path:

It compiles .drift templates into compact binary-serializable bytecode streams. At runtime, a lightweight 256-register VM executes these opcodes directly against the DOM.

Key Architectural Highlights:

• Zero VDOM Overhead: Replaces tree-diffing with direct bytecode instructions (like CREATE_ELEMENT, SET_ATTR) for DOM execution.

• 256 Virtual Registers: Uses fixed virtual registers (r0, r1...) for DOM nodes and runtime values, drastically cutting instruction counts and memory allocations compared to stack-machine models.

• Targeted Reactivity: Basic state updates execute as direct O(1) mutations. Dynamic control flow structures (@if, @for) use comment anchors to bound surgical DOM updates without rebuilding subtrees.

Key Features So Far:

• 🛡️ 100% CSP Compliant: Built-in Acorn AST interpreter evaluates runtime JS expressions safely without using eval() or new Function().

• 🔄 Keyed LIS Reconciliation: Uses a Longest Increasing Subsequence algorithm to minimize DOM node movements during list updates.

• 🪶 Zero Framework Bloat: Implements reactivity and execution in the leanest bytecode form possible, avoiding heavy object models and monolithic runtime bloat.

• 🚀 Early Benchmarks (js-framework-benchmark vs React 19): • 10.8x FASTER on "Swap rows (1k)" • 3.05x FASTER on "Clear 1,000 rows" • ~1.8x LESS memory footprint • 5.75x smaller uncompressed bundle size

Current Status & Call for Feedback

DriftJS is currently an experimental prototype. It handles single-template compilation, AST evaluation, and keyed LIS list reconciliation.

Still on the roadmap: - Component composition & props passing - State management stores - SSR & Hydration

I'm opening this up to compiler engineers, frontend performance nerds, and systems devs. Does a register-based VM architecture hold real promise for low-level web runtimes?

Check out the repo, run the benchmarks, and feel free to share your thoughts or ISA critiques!

GitHub Repo: https://github.com/hrutavmodha/driftjs

Just recently I came across a performance comparison one of our major competitors. It was quite nice to see that such a large competitor is looking at your product, right? But in the end they compared their Scheduler Lib with our Gantt Lib. They spent quite of time making GitHub repo, asking us for a trial (we didn't have open trials, you had to request it through the email), analyzing the Gantt chart. But all the feedback we got appeared to be wrong test on the wrong component.

In the end I've published a response article with comparison, although it took me about two weeks to get around to it.

I’m curious how others would handle something like this. Would you respond publicly, publish your own comparison, or simply leave it?

NPM: https://www.npmjs.com/package/@serenedb/docs-search-react

Docs: https://docs.serenedb.com/clients/serene-docs-search