0 reactions
Did anyone else move away from TypeScript and feel like it was obviously the right call?
I moved away from TypeScript years ago, and honestly, I’d do it again without hesitation.
I know TS has a lot of fans and that’s fine. But I don’t think it’s the unquestionable improvement it’s often presented as. For some codebases and teams, sure, it helps. For others, it adds bloat, friction and a false sense of safety that makes even bugs more common than in standard JavaScript.
In most cases, I’d rather migrate a codebase away from TypeScript than keep doubling down on it.
For those of you who also moved away from TS: what made you do it, and how has that decision aged?
#technology #programming #js #dev
I moved away from TypeScript years ago, and honestly, I’d do it again without hesitation.
I know TS has a lot of fans and that’s fine. But I don’t think it’s the unquestionable improvement it’s often presented as. For some codebases and teams, sure, it helps. For others, it adds bloat, friction and a false sense of safety that makes even bugs more common than in standard JavaScript.
In most cases, I’d rather migrate a codebase away from TypeScript than keep doubling down on it.
For those of you who also moved away from TS: what made you do it, and how has that decision aged?
#technology #programming #js #dev
0 reactions
Large in-memory caches were causing GC pauses in our Node service, so I built an off-heap cache addon for it
If you've ever run a Node service with a big in-process cache (tens of thousands of entries, JSON blobs, that kind of thing) you've probably seen p99 latency spike during V8 garbage collection — the more live objects sit in the heap, the longer mark-sweep takes, and there's not much you can do about it from JS land since the GC doesn't know your cache entries are "just cache" and safe to deprioritize.
I built OffHeap to get around this: it's a cache that stores its data outside the V8 heap entirely (native memory managed from a small Rust layer via NAPI-RS), so the objects never show up in V8's GC graph at all. The JS-facing API is a normal cache — get/set/delete/TTL — with LRU, ARC, and W-TinyLFU eviction policies to choose from.
Under a synthetic GC-pressure test (500k keys, 1M ops), the worst single GC stop-the-world pause dropped from \~300ms (plain in-heap cache) to \~11ms. Average per-op latency is a bit higher than a pure in-heap Map (it's crossing an FFI boundary, that's not free), but the tail latency and memory behavior under load is the whole point.
It's on npm (\`offheap\`), dual-licensed MIT/Apache-2.0, docs at the repo. Full disclosure, this is my project — I actually shipped a broken cross-platform install for a bit (CI wasn't publishing the per-platform binaries correctly) and just fixed that, so if anyone tries it and hits install issues, please tell me. Genuinely looking for people to poke holes in it before I call it stable.
#dev #js #technology #programming
source
If you've ever run a Node service with a big in-process cache (tens of thousands of entries, JSON blobs, that kind of thing) you've probably seen p99 latency spike during V8 garbage collection — the more live objects sit in the heap, the longer mark-sweep takes, and there's not much you can do about it from JS land since the GC doesn't know your cache entries are "just cache" and safe to deprioritize.
I built OffHeap to get around this: it's a cache that stores its data outside the V8 heap entirely (native memory managed from a small Rust layer via NAPI-RS), so the objects never show up in V8's GC graph at all. The JS-facing API is a normal cache — get/set/delete/TTL — with LRU, ARC, and W-TinyLFU eviction policies to choose from.
Under a synthetic GC-pressure test (500k keys, 1M ops), the worst single GC stop-the-world pause dropped from \~300ms (plain in-heap cache) to \~11ms. Average per-op latency is a bit higher than a pure in-heap Map (it's crossing an FFI boundary, that's not free), but the tail latency and memory behavior under load is the whole point.
It's on npm (\`offheap\`), dual-licensed MIT/Apache-2.0, docs at the repo. Full disclosure, this is my project — I actually shipped a broken cross-platform install for a bit (CI wasn't publishing the per-platform binaries correctly) and just fixed that, so if anyone tries it and hits install issues, please tell me. Genuinely looking for people to poke holes in it before I call it stable.
#dev #js #technology #programming
source
0 reactions
Looking for a solid vanilla JS datepicker. Am I completely out of options?
I'm looking for a datepicker for a vanilla JS project, and somehow this seems much harder than it should be.
No, input masks aren't enough.
No, the native `<input type="date">` isn't enough either.
My checklist:
* Accessible
* Localized
* Flexible formatting options
* Range picker support
* A decent set of events/hooks for integration
What I've looked at so far:
* flatpickr: hasn't been updated in about 4 years
* vanilla-js-datepicker: hasn't been updated in about 3 years, and the range functionality is pretty weak
* Vanilla Calendar Pro: Russian-maintained, which is ruled out by our dependency policy
* Air Datepicker: same issue, and it also hasn't been updated in about a year
* Litepicker: dead
* Easepick: dead
Most of the other options I've found are React-based, which is a non-starter for this project.
Am I missing something, or are there really no good options left?
#js #programming #technology #dev
source
I'm looking for a datepicker for a vanilla JS project, and somehow this seems much harder than it should be.
No, input masks aren't enough.
No, the native `<input type="date">` isn't enough either.
My checklist:
* Accessible
* Localized
* Flexible formatting options
* Range picker support
* A decent set of events/hooks for integration
What I've looked at so far:
* flatpickr: hasn't been updated in about 4 years
* vanilla-js-datepicker: hasn't been updated in about 3 years, and the range functionality is pretty weak
* Vanilla Calendar Pro: Russian-maintained, which is ruled out by our dependency policy
* Air Datepicker: same issue, and it also hasn't been updated in about a year
* Litepicker: dead
* Easepick: dead
Most of the other options I've found are React-based, which is a non-starter for this project.
Am I missing something, or are there really no good options left?
#js #programming #technology #dev
source
0 reactions
TS Compiler Graph, 10x fewer tokens in Claude Code and Codex, by TypeScript-Go toolchain
#js #technology #programming #dev
#js #technology #programming #dev
0 reactions
I created a zero dependency JavaScript framework that is a React alternative
Places.js is a lightweight Javascript framework for creating interactive websites promoting in person interaction. The framework supports the following features and has no external JS dependencies.
* Asynchronous data fetching.
* Components with Shadow DOM to encapsulate styles and deter bot scraping.
* State management that integrates with components and data fetching logic.
* Support for creating pages that are a combination of static HTML and islands of interactivity.
To get started, download the places-js-latest.js file https://codeberg.org/createthirdplaces/places-js/src/branch/main/places-js-latest.js from this repo. See the places.js documentation at https://createthirdplaces.org/tech/placesjs.html for a more detailed guide
* This repo https://codeberg.org/createthirdplaces/DMVBoardGames/src/branch/main/src/ui has an example of how places.js is used.
* This website https://dmvboardgames.com/ has shows how places.js is used in a production environment
#js #technology #dev #programming
Places.js is a lightweight Javascript framework for creating interactive websites promoting in person interaction. The framework supports the following features and has no external JS dependencies.
* Asynchronous data fetching.
* Components with Shadow DOM to encapsulate styles and deter bot scraping.
* State management that integrates with components and data fetching logic.
* Support for creating pages that are a combination of static HTML and islands of interactivity.
To get started, download the places-js-latest.js file https://codeberg.org/createthirdplaces/places-js/src/branch/main/places-js-latest.js from this repo. See the places.js documentation at https://createthirdplaces.org/tech/placesjs.html for a more detailed guide
* This repo https://codeberg.org/createthirdplaces/DMVBoardGames/src/branch/main/src/ui has an example of how places.js is used.
* This website https://dmvboardgames.com/ has shows how places.js is used in a production environment
#js #technology #dev #programming
0 reactions
Javascript TUI Network Throughput Inspection
Hey everyone I recently built this TUI for inspecting network throughput per interface, I found it useful so figured I'd share.
Its open source feel free to check it out and run it yourself: Github Repo https://github.com/yeet-src/netwatch
#dev #js #technology #programming
Hey everyone I recently built this TUI for inspecting network throughput per interface, I found it useful so figured I'd share.
Its open source feel free to check it out and run it yourself: Github Repo https://github.com/yeet-src/netwatch
#dev #js #technology #programming
0 reactions
I built a JS/TS Web SDK for AI Agent to handle frontend-to-kernel streaming
Hey everyone,
Just publishe`ineerajrajeev/aios-web-sdk`. If you’ve been building local or remote computer-use agents, this SDK handles the transport layer between web frontends and the agent kernel.
It abstracts agent system calls, streams agent execution states in real-time, and includes structured hooks for building user-in-the-loop authorization gates (crucial for verifying actions before an agent executes them). Would love some feedback on the SDK design!
#js #technology #dev #programming
Hey everyone,
Just publishe`ineerajrajeev/aios-web-sdk`. If you’ve been building local or remote computer-use agents, this SDK handles the transport layer between web frontends and the agent kernel.
It abstracts agent system calls, streams agent execution states in real-time, and includes structured hooks for building user-in-the-loop authorization gates (crucial for verifying actions before an agent executes them). Would love some feedback on the SDK design!
#js #technology #dev #programming
0 reactions
Your console.log Is Lying to You
# A couple ways console.log() and browser DevTools can mislead you. Covers live object references, promises changing state before inspection, logs affecting timing-sensitive bugs, stale React state after updates, and source maps pointing at misleading line numbers.
#programming #dev #technology #js
# A couple ways console.log() and browser DevTools can mislead you. Covers live object references, promises changing state before inspection, logs affecting timing-sensitive bugs, stale React state after updates, and source maps pointing at misleading line numbers.
#programming #dev #technology #js
0 reactions
I built a zero-dependency CLI tool to validate and repair missing .env variables before startup
You run `npm run dev` or `node server.js`, and the app crashes because a teammate added a new required key to `.env.example` but forgot to tell you.
I wanted a tool that would catch this before startup, prompt me for the missing values, and append them without wiping out my `.env` formatting or comments. Since existing tools either crash on startup (dotenv-safe) or wipe out file layout (sync-dotenv).
To solve this, I built **envrepair**, a zero-dependency CLI tool that wraps your startup command, compares `.env` against your template, and interactively prompts you to fill in missing variables in the terminal before launching your process.
### How to use it:
1. Install:
```bash
npm install -D envrepair
```
2. Prepend your startup command in `package.json`:
```json
"scripts": {
"start": "envrepair node server.js"
}
```
Optional type annotations in `.env.example`:
```env
#
PORT=3000
#
API_BASE_URL=
```
### Key Features:
* **Zero code changes**: No schema imports or application-level setup required.
* **Layout preservation**: Appends missing values while keeping comments, blank lines, and formatting intact.
* **Signal forwarding**: Transparently passes `Ctrl+C` (SIGINT) and exit codes.
Written in TypeScript with zero runtime dependencies. The repo is fully open-source.
* **GitHub**: https://github.com/avenolazo/envrepair
* **NPM**: https://www.npmjs.com/package/envrepair
#js #dev #programming #technology
source
You run `npm run dev` or `node server.js`, and the app crashes because a teammate added a new required key to `.env.example` but forgot to tell you.
I wanted a tool that would catch this before startup, prompt me for the missing values, and append them without wiping out my `.env` formatting or comments. Since existing tools either crash on startup (dotenv-safe) or wipe out file layout (sync-dotenv).
To solve this, I built **envrepair**, a zero-dependency CLI tool that wraps your startup command, compares `.env` against your template, and interactively prompts you to fill in missing variables in the terminal before launching your process.
### How to use it:
1. Install:
```bash
npm install -D envrepair
```
2. Prepend your startup command in `package.json`:
```json
"scripts": {
"start": "envrepair node server.js"
}
```
Optional type annotations in `.env.example`:
```env
#
PORT=3000
#
API_BASE_URL=
```
### Key Features:
* **Zero code changes**: No schema imports or application-level setup required.
* **Layout preservation**: Appends missing values while keeping comments, blank lines, and formatting intact.
* **Signal forwarding**: Transparently passes `Ctrl+C` (SIGINT) and exit codes.
Written in TypeScript with zero runtime dependencies. The repo is fully open-source.
* **GitHub**: https://github.com/avenolazo/envrepair
* **NPM**: https://www.npmjs.com/package/envrepair
#js #dev #programming #technology
source
0 reactions
History of JavaScript: Browser wars, ECMAScript, Node.js, TypeScript, and React
We took a look back at the history of JavaScript to explore its development from the earliest days to the present. This retrospective article is a good read for novice JavaScript enthusiasts who want to learn about the origins of the language, as well as for experienced ones who'd like to refresh their memories.
#js #programming #technology #dev
We took a look back at the history of JavaScript to explore its development from the earliest days to the present. This retrospective article is a good read for novice JavaScript enthusiasts who want to learn about the origins of the language, as well as for experienced ones who'd like to refresh their memories.
#js #programming #technology #dev
