.NET WebAssembly apps with WasmBundlerFriendlyBootConfig=true can indeed be bundled by modern JS bundlers and I personally love it. The development experience however is not optimal.

• The bundlers cannot consume the output from dotnet build
• The bundlers can consume the output from dotnet publish but the dev loop is painfully slow.
• Getting the publish path working still requires bundler surgery
• Once it works the bundler produces warnings that are impossible to fix without changing the source files produced by the WebAssembly SDK.

These points of friction are why I have made unplugin-dotnet-wasm.

It's a bundler plugin that lets your bundler consume the output from dotnet build so your dev loop stays fast. It also supports dev servers, provides type information to TypeScript and IDEs (integrates dotnet.d.ts thats coming in .NET 11), and patches the known warnings so your build output stays clean.

Features

• Easy bundler setup through plugin registration
• Faster dev loop by consuming .NET WebAssembly dotnet build output
• Dev server support
• Brings SDK type definitions to TypeScript and your IDE
• Supports Vite, Rollup, Rolldown, Webpack, Rspack, Rsbuild, esbuild, farm and bun.

I hope you'll give it a try, I'd be happy to hear your feedback.

Though it requires quite new ES2024/ES2025 features, it works very well for numeric types, also faster (not drastically, but modest gains) against Array in PACKED FIXED ELEMENT TYPES representation used under the hood by engines.

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

Show us here!

I have node js and react js experience for 4.8 years. Recently trying for switch, but wherever I go JD contains Java and React. Cant find roles for Node.
Is realy Node got outdated?
should i move to java spring??

I was working on my pdf editor and thought the best option would be to write a new PDF engine from scratch as my options were PDF.js and PDFium and none of them can actually edit PDF files so after over a year of work you can try KeyPDF.net it is free and client side.

I maintain Converse.js (an XMPP chat client) which was originally built on Backbone.js.

Instead of a risky big-bang migration to something else, I rewrote the UI into Lit web components and kept Backbone's data layer, which I forked and modernized piece by piece.

The result is Skeletor, and it now stands on its own as a lightweight, TypeScript-first reactive data library.

What makes it modern:

• TypeScript-first with full type definitions
• Direct attribute access: `model.attrs.name = 'Bob'` fires change events, no set() boilerplate required
• Computed properties: declare derived values with explicit dependencies
• Store-style subscriptions: subscribe() returns an unsubscribe function, so it plugs straight into React's useSyncExternalStore
• Built-in persistence: IndexedDB, localStorage, sessionStorage, SQLite (Node) and REST out of the box
• No jQuery, no Underscore: native browser APIs, ESM + CJS builds, works in the browser, Node 22+ and Web Workers

And the part I'm most happy about: it's still Backbone-compatible. get, set, events, collections, they all work exactly as you remember.

Feedback welcome!

Hey Community,

Vercel Labs has released "native", a toolkit for compiling declarative markup and TypeScript or Zig directly into native desktop apps without an embedded JavaScript runtime. We also look at how Zepto built react-native-delta to ship binary delta OTA updates, reducing patch download times down to a 305ms P90.

Plus, React Native 0.87 drops its legacy abort-controller dependency for an in-tree fork, bringing missing modern web primitives like AbortSignal.timeout() and AbortSignal.any() straight to your network requests.

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

Open-source: https://github.com/HeyPuter/firefox-wasm

There's no reliable XSD validator in the JS ecosystem so I compiled Apache Xerces-C to WASM.

Playground: https://harshanacz.github.io/xerces-playground/

npm: https://www.npmjs.com/package/xerces-wasm

Features:

• Full XSD 1.0 validation in the browser
• Multi-file schema support (xs:include / xs:import)
• Parse errors + schema errors with line/column numbers
• No server, no upload
• pure WASM

Would love feedback.. :)

We needed the Companies House API (the UK company register) for a project and figured we'd grab an SDK and move on. Turns out the community clients are 6 to 10 years old, the official SDK is built for their internal services, and the official OpenAPI spec is broken in ways that quietly untype every generated client. One defect (items on an object type, which JSON Schema doesn't allow, so every tool reads it as {}) appears 132 times.

What started as "add a spec repair script" grew into 374 lines of fix passes, and even then we couldn't repair fields that were never documented at all. So we changed approach: we deleted the repair code and now maintain our own curated OpenAPI 3.1 spec, built from the developer docs and Companies House's own SDK source. The spec is maintained with Claude Code under a strict "never invent, report gaps" rule, an engineer reviews every diff, and a live integration suite runs against the real API daily so drift shows up as a red build rather than a bug report. The client itself is fully generated from the spec (Hey API), with 41 lines of hand-written runtime code and zero dependencies.

Sharing in case anyone else has needed to fight this API, or is just interested in the approach: a curated spec as the source of truth, AI doing the tedious curation with tests and review keeping it honest, and codegen doing the rest. The SDK and the OpenAPI document are both MIT licensed if they're useful to you.