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

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 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!

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.

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.. :)

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 ❤️

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.

Hey folks. Over at Handle with Care, we've been working on something new: Pitter Patter. We haven't been satisfied with the text editing toolkits that exist right now in the ProseMirror ecosystem, and we've spent a lot of time working on a large variety of rich text editors and seeing what needs they have and how we can try to meet them. So far we have three packages: Shuffle (grid-based drag-and-drop), Collab, and Presence.

Here's some more info from our introduction page in the docs:

What is Pitter Patter?

Who builds it?

That would be us, Handle with Care. We’re a cooperatively owned product development collective, comprised of software engineers and product managers. We are all equal owners and have equal decision-making power.

What is it?

Pitter Patter is a suite of open source libraries for building collaborative rich text editors with React and ProseMirror. We see it as our job to provide turnkey solutions for the hard parts of rich text editing — like collaboration, presence, and version history — so that you can focus on building the editor experience that your users need.

Why does it exist?

We spend a lot of time thinking about and working on rich text editors. In particular, we spend a lot of time helping companies solve the same problems over and over again. There are usually great primitives available for these common building blocks (prosemirror-collab-commit for collaboration, unified.js for Markdown, etc.), but putting them together correctly to build a functioning text editor can be challenging.

There are other solutions, like Tiptap and Remirror, but we think that they’ve made some suboptimal choices that force product developers to make unnecessary compromises.

1. Both attempt to use React portals and effect hooks to integrate with ProseMirror, which lead to irreconcilable state tearing, due to fundamental differences in how React and ProseMirror View handle view reconciliation.
2. Both attempt to use Yjs via y-prosemirror for collaboration. We think that Yjs’s CRDT implementation is ill-suited for rich text editing.
3. Both attempt to hide ProseMirror’s underlying APIs, under the guise of simplicity and abstraction. We think that ProseMirror, low-level though it is, is roughly the correct level of abstraction for a domain as complex as rich text editing. Attempts to abstract it away inevitably lead to more complexity, as the abstractions leak frequently and require constant manual integration with the lower level solutions.

We think we can do better. And more importantly perhaps, we think that you deserve better!

Philosophy

Don’t hide ProseMirror

ProseMirror is an outstanding rich text editing framework. Nearly anything that you can imagine doing with a rich text editor can be accomplished with ProseMirror. Rich text editing is also a very complex domain, requiring a very large number of decisions to be made per feature.

We think that better primitives built with ProseMirror can take us farther than abstractions that attempt to hide away ProseMirror’s internals.

Collaboration should be simple to implement and simple to debug

ProseMirror has first-party collaboration, in the form of prosemirror-collab. Because it just sends steps over the wire, and relies on a single, server-side ordering of operations for conflict resolution, it is very simple to debug. But it is very challenging to implement correctly, and there is very little in the way of guidance or documentation for doing so.

Yjs provides third-party collaboration, in the form of y-prosemirror. Because it is built on Yjs, which has many robust adapters for various protocols and servers, it is very easy to implement. However, because it operates on Yjs’s XML-based Y-doc format, it is very challenging to inspect and debug if something goes wrong.

Pitter Patter’s collaboration, presence, and version history libraries are based on prosemirror-collab-commit. Like prosemirror-collab, prosemirror-collab-commit uses ProseMirror steps as the primary data structure for conflict resolution. But Pitter Patter Collab provides actual guidance and implementation that make it easy to set up a full-stack collaborative editing application, and hard to shoot yourself in the foot.

Correctness is worth it

After trying every other option over the course of several years, we eventually decided that the only way to correctly integrate React and ProseMirror was to reimplement ProseMirror View’s renderer from scratch directly in React. This was itself a massive effort, but the result, in the end, is a React/ProseMirror integration that doesn’t suffer from state tearing and allows developers to use React idioms like context as they normally would, without caveats or compromises. We don’t put side effects in React render functions or ProseMirror plugin apply functions, we don’t use effects to synchronize state with props. We want to enable you to build rich text editors that your users can trust, and that means that we need to build libraries that you can trust.

the core stays small. pick the plugins you need and chain multiple highlighters together.

use the built-in ones or write your own. yace works with any language, theme, or framework

I was researching the JavaScript Excel ecosystem looking for a gap worth building in, and found something wilder than a gap: the whole category is quietly abandoned.

• SheetJS (xlsx) — ~8M weekly downloads — frozen on npm at 0.18.5 since 2022. Security fixes ship only from their own CDN, so npm audit flags it forever. Styling and template editing are Pro-only, quote-only pricing.
• ExcelJS — last release in 2023, open "intent to fork" threads. Top issues: charts deleted on save, pivot tables destroyed, output files Excel offers to "repair."
• xlsx-populate — right idea, dormant for years.

And they all break files the same way. It's not hundreds of bugs — it's one architectural decision with hundreds of symptoms: they parse the workbook into their own object model, then re-serialize that model as a brand-new file. Anything the model doesn't understand (charts, pivot caches, macros, newer OOXML parts) silently doesn't survive the round-trip.

So I built Ironsheet on the opposite bet: the original file is the source of truth. It patches only what you explicitly target — a cell, a named range, a table, an image — and preserves every byte it doesn't touch. Macros survive byte-for-byte.

The part I care about most: it proves the write. Before saving, it validates the OOXML package (relationships, content types, shared strings, formulas, tables, calc chains) and returns a diff of exactly what changed. If validation fails, it refuses to write the file. No output beats corrupt output.

Honest boundaries: it doesn't evaluate formulas (preserves them + marks recalc), chart/pivot support is preservation rather than authoring, ZIP64 writing isn't in yet. It's a 0.1 MVP.

Apache-2.0, dependency-free TypeScript core, Node + browser adapters, JSON-first CLI.

Repo: https://github.com/btahir/ironsheet

If you have a workbook that breaks it, I genuinely want the fixture. And I'm curious what people are actually using for Excel editing in production these days.

Thanks!

I am working on Nerve, a local IPC library that connects Node.js with Rust, Go, and Python.

For the JavaScript client, I focused on native Promises and async/await support so that calling a function in Rust or Python feels just like calling an asynchronous JS function. It uses standard Node.js net modules under the hood for communication.

The library is in its early stages and not entirely complete. I am currently focusing on:

• Improving TypeScript definitions for strictly typed cross-language payloads.
• Adding Stream support for transferring large binary data chunks without memory bloat.
• Optimizing the bundle size and tree-shaking capabilities.

I would love to hear your thoughts on the API design and if you have faced similar challenges when bridging Node.js with other ecosystems.

A tale as old as time. We previously wrote our visualisations in SVG and rewriting them in Canvas along with some other backend factors made our dashboard much faster and smoother. We hope there are a few lessons there for folks to read about.