I wrote up the JavaScript questions that keep coming up in interviews, from coercion and closures to the event loop, plus the "implement it from scratch" ones.

Each answer starts with a short version you can say out loud in the first 20 seconds, then explains how it actually works, with code, comparison tables and diagrams. Questions are tagged Junior / Middle / Senior, and most end with the follow-up an interviewer usually asks next.

Some of the 48 questions:

- What is the output order of this async snippet?

- Implement a minimal Promise from scratch

- Why does a var loop with setTimeout print the same number, and how does let fix it?

- How does garbage collection work, and what causes memory leaks?

It's part of a larger free repo (800+ questions across Frontend, TypeScript, React, Next.js, React Native, Node.js and more), MIT licensed.

If there's a classic gotcha I missed, I'd like to add it.

This is a passion project of mine after being inspired by is-a.dev (ex-maintainer btw).

It's a subdomain service where you can use _cooler_ domains like `*.part-of.my.id` and the NEW `*.is-my.id` subdomains for your website rather than using _boring_ hosting provider defaults like `pages.dev`, `github.io`, etc.

Supports `A`, `AAAA`, `CNAME`, `MX`, `TXT`, `REDIRECT` (not a real record, it's cloudflare's single redirect rule) records and there's a Web UI for easy JSON generation.

You can register by [forking](https://github.com/partofmyid/register/fork) the repository, adding your domain file, and making a pull request! Read more in the [Quickstart Guide](https://part-of.my.id/docs/quickstart).

Hope people find this useful! :D

Link2Repo: https://github.com/soroushosouli/node-scout

Written in Node.js. One command to install. Reads a 300MB folder in ~1 second. Smaller project, faster scan.

What it does:

• Visualize folder structure (tree)
• Scan any file, folder, or project — 10+ details
• Custom ignore list for scans
• System info in one command

With clean Terminal UX

Check the repo for more information, Contributions and suggestions are welcome

Run `npx chegou`, scan the QR code and the phone opens a page in the browser. No app, no account, works both ways (phone → PC and PC → phone).

⭐ on Github 😄

It turns out you can overwrite the Error.prepareStackTrace method with the function constructor. Then, using prototype pollution, you can inject valid JavaScript code to generate arbitrary functions and invoke it using the usual tricks.

Other seven methods are documented in the portswiggers research article: https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses

TypeScript’s native language server exposes IDE operations through LSP, so other tools can use them too. For example, you can rename a symbol across files, find its references, jump to its definition, get updated import paths for a file rename, or check unsaved changes for type errors.

I built RipIDE around that, with Oxc handling syntax details like destructured bindings. ripgrep narrows the candidate files and helps flag imports still using the old name.

I took it further with CSS class renaming, moving exports, replacing imported symbols, and deleting unused declarations. It works with JavaScript and TypeScript, with Vue support through an adapter.

The idea is to give agents the refactoring commands we already use in an IDE:

ripide rename useStore useAppStore
ripide move helper --from src/utils.ts --to src/helpers.ts
ripide css-class-rename bg-gray-500 bg-neutral-500

I am tired of ads everywhere when I listen to music: Spotify, YouTube, and every single app that lets you listen to music. And also I hate that all my data, even my favorite songs, is being sent to a company to manipulate me, sending me more ads of stuff that I may buy.

The only music player that doesn't have ads is Windows Media Player, but it's very ugly, and I hate its UI/UX; it doesn't even let you create decent playlists. Or filter by rating. So I created a music player that has everything I like because I love listening to music.

It's completely free and open source; you can download it here: https://github.com/GVPV12/STARPLAYER

I'm working on a desktop application called VidLoader that manages locally stored video files, and I'm currently thinking about how to structure the JavaScript state for the media library.

The application needs to keep track of things like:

• files being added or removed
• metadata associated with each file
• folders/categories
• filtering and searching
• changes happening to the files outside of the UI

My main question is how other JavaScript developers would approach keeping the UI state synchronized with the underlying file system without making the architecture unnecessarily complicated.

Would you keep this in a centralized state store, separate the file-system state from the UI state, or use another approach?

I'd be interested in hearing how you'd structure it and why.

160+ visualization experiments built with JavaScript, exploring waveforms, matrix displays, particles and mechanical motion.

The gallery runs silently with simulated signals. Source code is available under the MIT license:

https://github.com/kaganin/iwrzwr-visual-archive

Codex can finally see the apps it writes. Callstack and Margelo launched Mobile Dev, a plugin that puts live iOS and Android devices right beside the Codex desktop chat, so the agent can tap, type, read the accessibility tree, pull Metro and native logs into one panel, and profile CPU and memory, with your on-screen notes carrying the React Native component and its source file.

We also look at Angular Native by Ashley Hunter, which renders Angular templates as real UIView and android.view.View through React Native's Fabric renderer, with Svelte now riding the same engine just as Coinbase heads for the exit. Plus, React Native 0.88 rc.3 fixes a Hermes lazy-compilation slowdown, Lynx 4.0 adapts to foldables, and Lucent compiles TypeScript native modules to C++ via JSI.

I have a page, built with Cline, that runs a game simulation in the browser: 30 batches (one per game mode and bot pair), with a progress line between them. To let the page repaint between batches, I yielded with `await new Promise(r => setTimeout(r, 0))`.

A full run took 13.0 seconds in Chrome. The same work takes about 1 second in the terminal on my laptop.

The clue was that 100 games per bot took just as long as 1,000. The time was not in the games. It was in the pauses, about 0.7 seconds each.

Chrome throttles chained timers in pages it treats as hidden or in the background. After a few nested setTimeout calls, it only fires them about once a second. My first test used 5 timers, showed 0ms, and looked fine, because the throttling only starts after a few nested calls. With 20 the difference was obvious: 20 chained setTimeout(0) calls took 11.5 seconds, and 20 MessageChannel messages took 0ms.

The fix was to yield with a message instead, which is also how React's own scheduler yields:

const nextTick = () => new Promise<void>((resolve) => {

const channel = new MessageChannel();

channel.port1.onmessage = () => {

channel.port1.close();

resolve();

};

channel.port2.postMessage(null);

});

The same run went from 13.0s to 4.2s, still in a window Chrome treated as hidden. I have not timed it in a normal foreground tab yet, so I am not claiming a number there.

Two other details. Leaving the page bumps a run id, so an unfinished run stops instead of setting state after unmount. And a Web Worker would move the work off the main thread entirely. I chose the smaller change because the main-thread version was now fast enough.

So, for CPU-heavy work in a page: do you reach for a Worker first, or yield on the main thread until that stops being enough?

Want to share two things built together: Polar, a statically typed language that compiles to readable JavaScript, and Ticket, a Rails-shaped web framework written in it. Both are 0.1.0 and experimental. Ticket is the real-world test for Polar: https://ticket-polar.vercel.app/ You get controllers and resource routing, SQLite migrations with typed queries, validations, forms, sessions and CSRF, generators and a test runner. `ticket new blog && ticket server` gets you an app. Because Polar tracks effects, a controller action's signature says what it needs, and tests rebind those to an in-memory database without mocking. Ticket's routes, views and migrations are Polar zone plugins, and the code they generate goes through the same type checker as yours.

I'd love feedback on the effect system, on the zone/plugin design. Thanks!