"We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development."

I was using Javascript for around 6+ years and always despised TS because of the errors it would throw on my VS Code because of not handling the types correctly. I recently learned TS with help from AI. Now I am struggling to go back to plain Javascript.

Edit : Some comments make it look like I wasn't competent enough to learn TS initially which isn't true to be honest. I work in multiple technologies and the apps (in Vue/React/Express) I was part of were never larger than 40k LOC. I felt like TS was not required. I did experiment with TS on smaller projects and every time I used a library I used to get TS-related errors on VS Code, but the app would work fine. It's those red underlines that were irritating , since the job was getting done regardless, I did not look into those type-implementation errors that were displayed by VS Code.

It's so helpful dealing with API data and their types with those type hints.

A friend of mine at Michigan TypeScript spent a full year getting the game to boot and show the first frame in an intellisense popover. He kept trying to prove it couldn't be done, but ended up doing it instead. YouTube links aren't allowed, but seriously, go find it. What an accomplishment.

In fact, it's 22% 11% faster on median across all 14 dtypes, all tested array sizes, and across Node/Deno/Bun!

When I started building numpy-ts in October, matching NumPy's C/BLAS backend with TypeScript & WASM seemed impossible. At 1.0.0 it was ~18-20x slower than NumPy. Then I moved 90 of the heaviest ops to Zig kernels compiled to WASM with SIMD, which got it to 2-2.5x. The remaining gap came down to eliminating the JS->WASM->JS copies on every operation.

Over the past three weeks I reworked the memory architecture so NDArrays live in WASM linear memory from the start, with a custom free-list allocator. This is all in numpy-ts 1.3.0: 1.2x 1.1x faster than native and 2.2x faster than NumPy on Pyodide.

I realize this is a bold claim, so I've spent a lot of time building the benchmark harness to ensure it's a completely fair comparison. You can read more about the methodology here.

numpy-ts is still zero-dependency, tree-shakeable, and under 500kB gzipped (<20kB tree-shaken for a single function).

I'm planning to publish a writeup on my journey optimizing numpy-ts. Is there anything in particular I should cover?

This post was written by me, a human, and numpy-ts was written with some AI assistance. Here's my AI disclosure.

Edit: u/zzzthelastuser pointed out the benchmark was measuring dispatch overhead, not just NumPy ops. After switching to O(1) hash-map dispatch, the advantage is ~11% on median. See this comment for details.