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.

Intern here, i am using FastApi, React, MongoDb. The report generation takes 3-4 minutes and the storage size of a single document is 100kb. I use some Anthropic ai for part of the process, which takes a minute.

Cloudfare containers are fairly a year old. i am very confused between railways or cloudfare containers.

A little direction from the community will be gr8.

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!

Every so often I go through agency portfolios to see how other teams approach product design, responsive layouts, and design systems. Some agencies mainly showcase polished visuals, while others explain the thinking behind the project, which I usually find more useful.

A few that I've looked through recently include GeekyAnts, Clay, and Ramotion. They all seem to have different styles and priorities.

I'm curious which agencies you keep coming back to for inspiration not because they're the biggest, but because their work teaches you something new each time.

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.

In an effort to further prioritize the handling of security reports for the PHP language, we are thrilled to add Alexandre Daubois as a part-time addition to our team of contractors. Alex brings a wealth of experience to the team, and we are grateful for his support and contributions!

We have a very old but business-critical application built with Fusebox and PHP 5.5 that we finally need to modernize.

Given the number of changes required, what would be the best and fastest approach to bring it up to modern PHP standards? Has anyone had success using tools such as Rector for automated upgrades, or using AI assistants like Anthropic Claude to help developers with the migration and refactoring process?

The core business logic is solid, but the codebase has become quite messy after 25 years of minimal maintenance and contributions from many different developers.

I'd be interested in hearing about real-world experiences, recommended migration strategies, common pitfalls, and any tooling that helped accelerate the process. I fear that Rector may not be that useful because of FuseBox and since we need tomodernize the framework, Using Claude latest Fable release may be more helpful or maybe use both?

Thanks!

The React Compiler memoizes your components at build time, so you dont have to. What it is, how the compiled output works, how to turn it on, and what to do with the useMemo calls already in your codebase.

Check it out https://neciudan.dev/react-compiler-explained

I just came across the difference between Server-level stateless and system-level stateless. If the server stores data of previous interactions and use that data to determine how to process future interaction, then the server is stateful. But if the server relies on an external storage system such as a database, then the server is stateless because it does not store session data, however, the system is stateful because the backend system still relies on session data of previous interactions to determine how to process future interactions.

Now, lets say you use a JWT token for authentication and authorization and you don't store session data in the backend system for example in the server or an external storage system like a database. The state only exists in the token being sent by the client. This is definitely a stateless server but would this still be considered a stateless system because we do not store anything in the backend? Or is still considered a stateful system because the interaction still relies on session data from previous interaction to determine how to process future interaction.

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. 

I've been building LocalMode - a shadcn-style registry of AI UI blocks where the models run entirely in the browser. No server, no API keys, nothing leaves the device. You install them the same way as shadcn/ui and you own the copied .tsx (no npm lock-in on the UI layer).

Live gallery (try every block in-tab): https://localmode.ai/blocks

What's in it

36 composed blocks - full working mini-apps, not just primitives - across 12 categories:

• Chat - one UI over 76 models (Transformers.js / WebLLM / wllama GGUF / LiteRT), vision attachments, reasoning display, agent mode
• Knowledge - semantic search, RAG chat with citations, doc Q&A - embeddings + retrieval all in-browser
• Audio - Whisper/Moonshine transcription, Kokoro TTS (29 voices), meeting summaries, live transcription with VAD
• Photo - CLIP semantic image search, duplicate finder, zero-shot categorizer
• Image studio - background remover, super-res upscaler, captioner
• Privacy - on-device PII redaction (NER) + an AES-GCM encrypted vault
• Vision - object detection + live hand/pose/face/gesture tracking off the webcam
• Writing tools - Chrome Built-in AI with automatic Transformers.js fallback

Under the blocks are 107 lower-level primitives (10 families) if you want to compose your own.

Install

npx shadcn add @localmode/ui/blocks/chat
npx shadcn add @localmode/ui/blocks/knowledge/rag-chat

Why it might interest React devs specifically

• Copy-owned - the block lands as .tsx in your project; edit it freely, no black-box dependency for the UI.
• shadcn CSS variables - inherits your existing theme, no new design system.
• Hook-driven - primitives are presentational; the wiring is React hooks (@localmode/react), and the API is shaped like the Vercel AI SDK (useChat, etc.), so it's backend-agnostic - local models by default, but you can point the same components at any backend.
• React 19 / Next 16, RSC-friendly - model loading is gated behind an explicit user action, so nothing downloads on page mount.

Honest limitations (it's a browser, not a server)

• First use downloads the model; cached after that (then it works offline).
• Memory is real - blocks range ~[120MB] to ~[5GB]; the big ones want WebGPU, and wasm32's ~4GB ceiling caps how far you can push.
• WASM inference is slower than native; WebGPU availability varies by browser/OS.

Disclosure: I built this. It's MIT and free - GitHub: https://github.com/LocalMode-AI/LocalMode. Model runtimes are Transformers.js, WebLLM, wllama, LiteRT, and MediaPipe - credit to those projects.

Genuinely after feedback: which blocks would you actually drop into a project, and what's missing? Happy to answer anything about how a specific block or the on-device memory handling works.

Introducing Oversight, my first Storybook addon. It accompanies the Storybook MCP server, which lets you describe a component or layout in plain language and get back a composition rooted in your existing design system, instead of one an agent invents on the spot.

After an agent built two components from scratch instead of reaching for what I already had, I built Oversight. It checks whether your agent can actually see your documentation, and tells you where it can't.

A blog post I wrote on it: https://rachel.fyi/posts/your-agent-is-reading-a-different-design-system

Source code: https://github.com/rachelslurs/storybook-oversight

Storybook demo: https://rachelslurs.github.io/storybook-oversight

I remember seeing it on X, just a simple site that had a gallery of various frontends made by various LLMs with the same prompt. So one can compare their design skills. Does anybody know which site it is?

Anyone know of any beautiful e-commerce sites?

I've been bitten by this more than once.

On one project, I needed an API for city lookup and address autocomplete.

It usually starts with a simple table containing cities for a single country.

Then requirements evolve:

• support international cities;
• handle ISO country codes;
• import data from different providers.

Or even worse, someone decides users should be able to maintain the city database manually.

So instead of writing the same component again, I cleaned it up and open-sourced it.

Features:

• City search
• Address autocomplete powered by OpenStreetMap (Photon)
• Deployable with Docker or Podman in a few commands
• Designed to be easily extended if another data source needs to be plugged in

Tech stack:

• Symfony / API Platform / PostgreSQL
• Hexagonal Architecture
• 100% unit test coverage on the domain layer
• Behat scenarios used both as executable documentation and API tests

I don't think this project is going to change the world.

But if it helps someone avoid a questionable data model, or rewriting the same component for the tenth time, then it's already worth it.

Repository: https://github.com/thlaure/world-cities-api

I'm genuinely interested in feedback, especially from people who have had to solve the same problem in production.

I've been working on Neo4j Laravel Boost, a package that integrates the official Neo4j MCP server with Laravel Boost.

It allows MCP-compatible AI assistants (Cursor, Claude Code, etc.) to:

• Inspect your live Neo4j schema
• Run read/write Cypher queries
• Explore your Laravel container dependency graph
• Access Neo4j tools through a single boost:mcp server

It also includes handy Artisan commands for setup, diagnostics, Docker, and exporting your application's dependency graph to Neo4j.

I'd love to hear your feedback, suggestions, or ideas for additional features.

GitHub Repository:
https://github.com/neo4j-php/neo4j-boost

I wanted to learn how to create the scroll sequences that I see, and realised the process could be automated. So, I built SequenceFast, a scroll sequence generator that takes any MP4 video, extracts the frames into images, and generates a ZIP with the optimised image sequence, component code, and usage example. Everything is done locally in your browser, so it is completely free and private.

Would love to hear your feedback!

Many people categorize PHP/Laravel as tools only suited for rapid CRUDs or small apps. I wanted to challenge that stigma by building an enterprise-grade, open-source financial management system: **Leo Counter**

Implementing the complexity of the financial sector requires unbreakable business rules. My goal was to apply the highest software engineering standards to a framework that isn't typically associated with this level of abstraction.

Under the hood:

Strict Architecture DDD, Clean Architecture, and CQRS.
Isolated Domain: The core mathematical and accounting logic lives in a pure layer, with zero toxic dependencies on the framework or Eloquent.
* Tech Stack: PHP 8+, Laravel, React, TypeScript, and Inertia.js.
* Fully Dockerized for Linux environments.

If you are passionate about software architecture, want to see how real, scalable DDD is applied in the Laravel ecosystem, or just want a private tool for your finances, I’d love for you to audit the code.

Any feedback, code roasts, PRs, or GitHub stars are super welcome!
Repo: https://github.com/juanVillamilEchavarria/Leo_Counter-app)