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

Show us here!

Most people won’t run your project first.

They read your README.

And honestly… writing a good README is annoying.

So I built something for it.

It’s called ReadmeAI.

You just give it your GitHub repo, and it:

analyzes the codebase

understands the structure

generates a clean, structured README

It covers things like:

project overview

setup instructions

features

usage

I mainly built it because I kept procrastinating writing READMEs for my own projects 😅

Would love some honest feedback from devs here:

Is this something you’d actually use?

What would make it more useful?

If anyone wants to try it, I’ll share the link

Licck

I was trying to find an easy tool to just see how much I would get in hand without much effort, couldn't find it so built a quick one with FY 2025-26 rules.

Plug in your base pay, it breaks down your in-hand salary. No login, just the quick numbers.

It's based on what I personally use. If you use or any other common deduction that's missing, drop it in the comments - happy to add it.

The project is still quite early, i'm actively adding new commands. The idea is to provide a bash environment adapted for untrusted processes like autonomous workflows or AI agents.

The legitimate question is "What makes it different from regular bash using docker?" :

First, there's no setup required at all. When you do bash.run('mkdir superfolder') for example, your automation immediately gets:

• The exact filesystem changes (what was created, modified, deleted)
• Direct feedback in stdout without extra commands required

The default runtime uses WebAssembly and works in Node.js. Browser support is possible with a custom runtime (the sandbox layer is pluggable).

I'd love to hear what you think!

you know what's annoying?

every time I build a feature, I have to write:

- useState for state

- useEffect for side effects

- fetch + try/catch for API calls

- event handlers

- manual UI updates

over and over again. same patterns. different features.

so I made AITOS.

now I just write JSON graphs:

```json

{

"order": ["getData", "process", "save"],

"nodes": {

"getData": { "atom": "httpRequest", "url": "/api" },

"process": { "atom": "transform", "data": "{{getData}}" },

"save": { "atom": "set", "key": "result", "value": "{{process}}" }

}

}

```

that's it. no glue code. no boilerplate. just logic.

I built LinkArm (a complete AI chat app) with it to prove it actually works. 50+ JSON graphs. zero traditional code logic.

github.com/hfziqi/aitos

what do you think? am I crazy or is this actually useful?

I'm happy to announce ElementsKit: a toolkit of reactive primitives for building the #web UI. Signals, JSX, custom elements, and utilities. Use them standalone, compose them, or use them inside React, Svelte ...

› Compose, don't configure. signal, computed, on, fromEvent, async. Combine primitives instead of maintaining an overloaded interface. Overloaded interfaces accumulate breaking changes and deprecation every consumer has to track.

› Close to the platform. JSX compiles to document.createElement. promise extends Promise. async is awaitable. A custom element is an HTMLElement. No virtual DOM, no proxies, no build steps.

› Predictable and explicit (no magic). signal/compose are reactive; nothing else is. No heuristic dependency tracking, no hidden subscriptions.

› Designed for the AI age. Code is cheap; maintenance still isn’t. Primitives compose into higher-level blocks. Swap one block at a time instead of maintaining long lines of code.

› Bundler-friendly. Every primitive is its own subpath — elements-kit/signals, elements-kit/utilities/media-query, elements-kit/integrations/react. Import only what you need.

Like a lot of people, I’ve found myself relying more and more on AI tools (Copilot, Claude Code, etc.) for day-to-day coding. They’re useful obviously, and hard to resist, but I’ve started to notice that I’m not always thinking through problems as carefully as I used to.

So recently I decided to try working through a few small JavaScript problems entirely by hand (pen and paper, no editor, no autocomplete, no AI). It was harder than I expected. Not because the problems were advanced, but because I had to think so much more slowly and carefully and remember syntax I haven't had to remember for awhile.

It also reminded me of the research showing that writing by hand improves retention and understanding compared to typing. I’m not sure how strong the analogy is, but it does seem plausible that the same applies to coding—especially now that so much of the “easy” thinking is offloaded to tools.

Out of that experiment, I ended up putting together a small workbook of JavaScript problems specifically designed to be done by hand—not beginner-level syntax drills, but also not LeetCode-style interview problems. More like “everyday reasoning” problems that force you to trace through code and think carefully. (Happy to share a sample if anyone’s interested.)

I'm mostly curious if anyone else has tried something like this, since I hadn't really come across suggestions for writing code literally by hand on paper.

I’ve been using one of those terminal-style static webs for a while, only aesthetics. Recently I started to wonder, how far can we push the illusion of a real shell just with JS and a static web? The content still matters most, so the first renders surface everything important. But I wanted exploration to be rewarded with an interesting filesystem, pipes, globs, programs, permissions and maybe some "privilege escalation" paths.

I've been planning to build this for a while and finally had a reason to get it done. I've been maintaining ember-svg-jar for a few years now. Ember has since moved to Vite, so migrating to an unplugin was the obvious choice which gave me the opportunity to build a plugin that any framework can use. Before building this I evaluated a bunch of different vite svg plugins but found them all lacking one thing or another that left them feature incomplete compared to what ember-svg-jar already offered.

Quick list of features

• Generates sprite sheets for your imported SVGs
• Named sprite sheets so you can collect related SVGs together
• Allows an inline embed as an escape hatch (you should have a good reason to inline)
• URL export when you want to use in an <img> (or some other reason)
• Embedded references are resolved (<use> <image> etc just work)
• DOM and Web Component runtimes in addition to framework components

Currently it supports vite and rollup bundlers, but I do plan on fleshing out support for everything unplugin supports, so if your project is using webpack or one of the newer bundlers like esbuild or rolldown check back soon.

I also plan to add more framework runtimes out the box, and a way to provide your own runtime module so no matter what you're building, SVG Jar will work with it.

This is new code so there is bound to be edge cases, if you run into one, please file an issue :)

In growing JS/TS codebases, I’ve been thinking about structural reach:

• If a file changes, how many parts of the system depend on it?
• Are there modules slowly becoming architectural bottlenecks?
• Is blast radius increasing over time?

Do you use any tooling to track this kind of structural evolution?

I built a small open-source prototype exploring this idea , I’ll link it in the comments if relevant.

Would love thoughts.

I wasted hour debugging CORS.

Turns out the API was correct.

Quick comparison with the Date API, highlighting some of the main improvements.

I used to think CORS was just some annoying backend issue.

Every time I saw: “blocked by CORS policy”

I’d just:

• add origin: "*"
• or disable it somehow

It worked… until it didn’t.

Recently ran into a case where:

• API worked in Postman
• Failed in browser
• Broke again when cookies were involved

Turns out I completely misunderstood how CORS actually works (especially preflight + credentials).

Big realization:

CORS isn’t the problem — it’s the browser trying to protect users.

Do you whitelist origins manually or use some dynamic approach?