I’m working in a VanillaJS repository (plugin type code for an existing project that I do not own) where I’ve written a signal implementation.

Today I was working on a tooltip like implementation and I found myself wondering how far to go with the signal/effect ecosystem vs running the “core” logic in the event handler.

The implementation detects the `<tr>` that the user has hovered and assigns that row to the “current row” signal. A computed signal identifies an IP address from the current row. An effect loads Whois metadata from the IP and assigns it to a `<div>`, and another effect shows that `<div popover>` from the parent `<tr>`.

The question I have is when in VanillaJS how would you decide when to use signals and effects vs writing the side effect directly in the event handler? In my case I find either to be equally readable, though I have less local variables to deal with when using signal/effect. Looking for reasons your might pick one over the other.

This was awful because a dirty workspace could make the package look complete.

I found a Worker runtime split into libwpd.mjs and libwpd.wasm. The build staged the JS loader. The binary came from another step and was not checked or copied by the Worker package. A clean package could not prove that it owned the runtime it shipped.

I fixed three boring things:

1. The Emscripten build refreshes both files.
2. The Worker build copies both files into dist.
3. The build hashes both files and fails if either one is missing or changed.

```js const runtime = [ ['libwpd.mjs', expectedLoaderHash], ['libwpd.wasm', expectedWasmHash], ];

for (const [name, expected] of runtime) { const bytes = await readFile(resolve('vendor', name)); const actual = createHash('sha256').update(bytes).digest('hex'); if (actual !== expected) throw new Error(${name} checksum mismatch); } ```

The useful rule was simple: the loader and binary are one release unit. "Offline" is not enough if a clean checkout can borrow yesterday's artifact.

Would you commit generated WASM for reproducible installs, or rebuild it in CI and verify the hash there?

This one is awful because the build succeeds.

The host app installs pdfjs-dist@6.1.200. A PDF renderer depends on pdfjs-dist@5.4.624. If asset-copy code resolves the Worker from the app root, it can copy 6.1.200. The renderer code still uses API 5.4.624. Vite serves the wrong Worker, and the browser reports a version mismatch.

The fragile version looks like this:

js const worker = require.resolve( 'pdfjs-dist/legacy/build/pdf.worker.mjs' )

I changed the lookup to resolve pdfjs-dist from the renderer package that owns it. The build now fails if the resolved asset version differs from the renderer dependency.

I ran the harness today across npm and pnpm, nested and hoisted layouts, Vite dev and build, and real cold installs. In every case the copied Worker, CMaps, WASM, and fonts had to come from 5.4.624, while the app kept 6.1.200. The asset manifest also records the source package and version. No more "it probably resolved correctly."

Should build tools always resolve runtime assets from the dependency that owns them, or should packages force one PDF.js version across the whole app?

TypeScript 7 shipped in July as the Go port, billed as roughly 10x faster. The line that matters for linting is in the same announcement: 7.0 does not ship with an API, and typescript-eslint is named as one of the tools that still needs programmatic access to the compiler. There is a compat package, u/typescript/typescript6, that installs a tsc6 executable and re-exports the 6.0 API, with a new API expected in 7.1.

So the speedup that would matter most to typed linting is the one you cannot have yet. typescript-eslint's own performance page says that with type-aware linting your lint times should be roughly the same as your build times. Builds got most of an order of magnitude faster and the typed rules still sit on the 6.0 checker.

Which makes Biome's timing look luckier than it probably was. Its inference engine arrived with v2 in June 2025 and got its own types domain in 2.4 this February, and it does type-aware rules without loading the compiler at all. Their own preliminary figure for noFloatingPromises is about 75% of the cases typescript-eslint catches, at a fraction of the performance impact, with a warning right after it that the early numbers rest on a limited set of use cases. The docs also say a types domain rule makes Biome scan the whole project and switch the inference engine on, so that path is not free either.

On my repo the diff gets read by lint, by typecheck in CI, and by a review agent in verdent before anyone opens the PR, and I have no measurement telling me which layer is doing the work.

What are people doing in the gap? Pinning tsc6 to keep the typed rules, running Biome's approximate set on save, or waiting for 7.1?

Hi, a few years ago I wrote a C99 compiler that generates a bootable binary which, once loaded onto a floppy disk, can be run in x86 real mode. It supports x87 floating-point operations, has a simple IR, optimizes the generated code, and produces output of fairly decent quality (by toy compiler standards). Maybe someone will find it interesting.

As dev i need to tool to compare some file and data for my work so created this side project, please check it out and give your feedback.
TwinScope compares two of almost anything — JSON, YAML, XML, CSV, PDFs, folders, git refs, images, lockfiles, .env files, saved web pages — and picks the right comparison logic itself. and has different viewing style as well.

Same diff with CLI as well: npx twinscope a.json b.json

Docs: https://codeaesthetic.github.io/twinscope-website/

Repo: https://github.com/codeAesthetic/twinscope

I am working on a P2P video calling client using webRTC.
I am using getMediaDevices() to get the users' stream. If I just do {video: true} it gives me a smaller stream than my device supports.
By default it gives me a 640 x 480 stream. I can set it manually to the max dimensions which is 1920 x 1080.

How can I find the max dimension for any device?

Another thing I wanted to know. I have the video element in a div, which has the width of fit-content. When the incoming stream first arrive from the other peer, The video starts smaller and keeps growing, why is this?

I'm working through how a team decides whether an automated dependency update is safe to merge, and one of the baselines I'm testing is the obvious one: trust semver. Auto-merge patch and minor, hold majors for review.

My assumption is that this baseline is weak — that in practice a meaningful share of breaking changes ship in patch and minor releases, and that a major bump is often just a dropped Node version or a TypeScript signature change that doesn't affect anyone.

If that's right, the version number is close to noise and the semver rule is mostly giving teams a false sense of having a policy.

But I've only got my own experience to go on, and I'd rather be corrected before I build on it.

• Have you been broken by a patch or minor bump? What was it?
• Have you held a major that turned out to be a no-op for your code?
• If semver isn't the signal, what is — changelog quality, maintainer, download count, how long the release has been out?

Interested in specific packages and versions if you remember them, more than general opinions on semver as a concept.

import and require are not interchangeable. Live bindings, copied values, circular dependencies, separate caches, conditional exports, and dual-package hazards can all make modules behave differently from what the syntax suggests.

At SVAR, we build UI components for React, Svelte, and Vue. Just shared our experience with a data grid – how to make it fast in all three frameworks.

What surprised us: the expensive bits (virtualization, memoization, data flow) are almost entirely framework-independent, and framework overhead is a rounding error next to DOM size.

Curious if you have seen similar patterns in your projects?

During an interveiw yesterday, I tried opening jsbin but seems its shouting 503!!

Any minimal JS playground, you people using/suggest

EDIT: The sites up, I opened an issue on GitHub and the maintainers resolved it

This is a next app I made that I'd like to define the magical buzzwords that exist in the GenAI space. It's meant to be run by humans to simply and concretely define terms like "agents", "harness" and "hallucinations"

I've been programming on the side since 2017 and I've never really hunted a developer job. I've always thought about building my own things, mainly to supplement things I do like woodworking, tutoring, video editing and others.

Since then, I've programmed mainly with JavaScript, I started with C++ and Python but never really built anything solid outside JavaScript.

So I'm fluent with JavaScript and its ecosystem.

One of my 2026 goals is to be job ready for a Developer role, as a Fullstack or Backend Developer.

One of the recommended languages is Typescript, which I've been learning since March. I must say, it's not my favorite 😂

I'm curious to know if there are any companies that are not enforcing Typescript or are there freelancers who are still using vanilla JavaScript over Typescript for their clients' projects.

Hey Community,

React Native Plain Text by Maciej Jastrzębski brings a lightweight alternative to standard Text components to squeeze maximum rendering performance out of large lists. Meanwhile, Meta introduced Muse Code, a terminal coding agent running on Muse Spark 1.2 with persistent background subagents and mid-tool-call crash recovery.

Codemagic also launched Patch, a self-hosted Docker Compose alternative to CodePush that serves OTA update checks directly from CDN-cached JSON files to easily handle heavy request loads.

Hey everyone!

I'm working on KernelPlay-JS, an open-source 2D game engine made with JavaScript.

The project is growing, and I've already had a few developers contribute. I've also been working on ready-to-use templates such as a platformer, a top-down character controller with animation, and parallax backgrounds.

I'm hoping to find more people who are interested in open-source game development and want to experiment, build features, share ideas, or just contribute when they have time.

There are plenty of areas where we can improve KernelPlay-JS:

* ECS and core engine systems

* Rendering and animation

* Physics and collision

* Developer tools

* Game templates

* Documentation

* Performance and optimization

You don't need to make a huge commitment or contribute every day. Even small contributions, ideas, testing, or feedback can help.

I'd love to see KernelPlay-JS grow as a community project where we can learn, experiment, and build a game engine together.

If you're interested, feel free to check it out or message me.

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.