Four years after we started development on @docusaurus 2, we're so happy to announce that v2 is officially released thanks to the good work by @sebastienlorber, @SidaChen63 and many others. Not to forget @endiliey who's no longer with us but laid the amazing groundwork for v2

Amazed at the high-quality contributions to Void in the first week since release. Void has a huge surface area across SDK, CLI and the Platform – and we already have more than 10 contributors.

Big thanks to @yangshun for his awesome perf improvements!

github.com/voidzero-dev/v…

Rusty’s law: Anything that can be rewritten in Rust, will be rewritten in Rust.

something that keeps bothering me is how some people see slop as something that is happening to them, like they're some kind of helpless bystander powerless to do anything about it

excuse me but you are a software engineer, you literally learned how to make sand think and make computers do your bidding?! and now you can't do anything about it? please

the 2 things you should know to cut through all the noise:

1. you need to give your agent a way to verify its own work (i just posted about this so won't rehash)
2. your codebase is memory

the 2nd is not new either, we have always had lint rules, compilers with good diagnostics and strong type systems, LSPs, etc to help us write better code. there is no difference when agents write the code instead, you just need more of them, and stronger ones.

forget rules and skills. you can add those later.

yes, your codebase is a form of memory to agents! agents love extending what already exists. so every nit and every annoyance you've ever seen, every mistake and bad pattern you observe from agents, needs to turn into a constraint, or the agents will just keep repeating those same mistakes like a virus in your code. then you keep observing and repeating this process until your codebase is locked down enough that even agents with little context can one shot a high quality PR.

an even better direction is to refactor/rewrite your code such that agent anti-patterns become categorically impossible. use type systems to your advantage, use libraries/frameworks that reduce the architectural search space, or heck, create your own framework like we did for grok bot and design high quality primitives and well thought out APIs

Conventional wisdom in software engineering has long treated "big bang" rewrites as a career-ending trap.

Joel Spolsky famously called it "the single worst strategic mistake a company can make". But IMO this isn't fully true these days as AI has fundamentally changed the economics and mechanics of writing software.

The old arguments against rewrites no longer hold:

- Original developers are gone -> AI can ingest the entire repository and explain every edge case to you
- Missing specifications and lack of safeguards -> AI can generate specs from the existing system as well as tests
- Required huge manpower, people to maintain the legacy system, others to do the rewrite -> AI can do both, without needing to sleep or go on PTO

@GreatFrontEnd's coding workspace is around 3 years old now, it was built incrementally by the team. There were layers and layers of hacks and obscure logic.

Yesterday, I used Codex to rebuild GreatFrontEnd's workspace within a few hours. AI first examined the code and generated a spec + proposed a new architecture. I reviewed the document, added/removed a few things, and let it rip.

The result was -26% lines of code (19.6k down to 14.4k), with a cleaner architecture and more edge cases covered.

The important thing here is that the contracts remain unchanged – shape of the data read/written stayed the same. I also made Codex compare screenshots of the various states of the workspace with the rewritten versions.

Rewrites allow you to redesign from the ground up, backed by years of accumulated domain knowledge. That used to only sound good in theory, but now it's also a practical move.

It's time we rethink traditional dogmas, many of which were born out of human bandwidth as the bottleneck.

Being a "10x engineer" is becoming much less exceptional.

The term "10x engineer" refers to an engineer who is perceived to be ten times more productive or effective than their peers.

With AI, one engineer can now write, debug, test, research and prototype at a pace that would have required multiple engineers last time.

Instead of asking "How can I become a 10x engineer", I think we should now ask "How do I make the people around me 10x their productivity?"

If you can help 10 other people use AI much more effectively, by improving their tools, workflows, context, prompts, agents, evals, or simply teaching them what works, you've created something closer to 100x leverage.

The best engineers have always had impact beyond their own output.

That hasn't changed with AI, AI simply allows the multiplier to increase greatly.

localStorage is very limited, I built something better.

Introducing ultrastorage, a library that supercharges your browser storage.

- Store anything directly: Set, Map, Date, RegExp, BigInt, circular references, and more. No need for JSON.stringify() / JSON.parse()

- TTL / expiration: Make browser storage expire Redis-style

- Namespacing: Isolate keys with a configurable prefix

- Schema validation: Validate retrieved values against any Standard Schema with synchronous validation (Zod, Valibot, ArkType, etc.)

- Subscribe: Listen to changes and update your UI

Alternative implementations exist, but I believe ultrastorage has a good balance between features vs bloat (6.8 kB minified and gzipped).

I'm using it in all my projects right now, hope you'll find it useful as well!

GitHub repo: github.com/yangshun/ultra…
Website: ultrastorage.dev

#16 Defaults Matter

I still remember how much everyone at Facebook hated Jest back then. It was awesome when it launched, but the JavaScript ecosystem moved so fast – and engineers working on it moved on so quickly as well – that it kept falling behind, and there was nobody who my manager asked me to work on it, I refused initially. I did eventually explore the codebase and make a few initial fixes, after which I realized: There are a few thousand engineers here, code quality and production bugs are becoming a massive problem, and somehow nobody is working on this. It ended up being a massive opportunity!

I initially focused on making Jest good for Facebook. That meant actually providing great testing APIs and improving Jest's performance. It was so bad that it was actually possible to make Jest 100x faster! (When somebody makes software more than ~5x faster, it usually means the existing implementation was bad, not that the new solution is so amazing.)

Another advantage of working on a testing framework over other developer tooling is that you can usually just run the full test suite to see if your changes are working or not. This made me - and a bunch of other folks I was able to recruit from across the company - feel like we were moving super fast!

Next, I turned my attention to open source. There were several serious JavaScript test frameworks in the community by this time, and each of them had one or two standout features that were better than their counterparts in Jest. While I felt that Jest wasn't good enough yet, it was definitely close. One major gap was the initial setup: At Facebook, Jest only had to be set up once, by the JS Infra team. Every other engineer could simply write tests. In open source, the story was different because even though the framework was great, few people knew how to set it up correctly.

`create-react-app` was starting to become popular, and it didn't yet come with a testing framework. At the same time, Dan Abramov and I spent a few nights in London hacking on Jest together. Some folks contributed Mocha as a default, and Dan wanted me to add Jest for comparison. I honestly didn't even consider creating a PR like this - he literally had to drag me to do it. Understandably, this led to a lot of pushback and gave me the greatest opportunity of all time to change the perception of Jest, in PR #250: github.com/react/create-r…

This led Jest to become the most popular testing framework for almost a decade. And while it is no longer the most used testing framework (as it was a testing framework for a different era), it still has about 46 million downloads a week!

It was a lot of hard work to get there: Jest had to be good, fast, stable and feature-rich. But what I learned most is that defaults matter.

Used GPT-5.6 Sol to updated a 10-year-old script for bulk-deleting GitHub forks into a simple local app powered by React, Vite, Hono, and the gh CLI.

Simply run `npx delete-github-forks@latest`

It reflects the idea of 小而美. Small tools can be elegant, easy to understand, and g to become a platform.

github.com/yangshun/delet…

Why I love being a frontend developer

Today, VoidZero joins Cloudflare.

Vite remains MIT, vendor-neutral, and stewarded by the same wider team.
The same goes for Vitest, Rolldown, and Oxc.

Cloudflare is also committing $1M to an OSS fund to support independent development in the Vite ecosystem.

From Claude to Prod.

Superblocks is now the only enterprise vibe coding platform that gives AWS customers a secure, in-VPC RDS database spun up for every app.

Inherit your AWS security policies, cost management, audit trails, networking, encryption and backup policies.

Let your business users vibe code, safely.

We just open-sourced Simulang, a JavaScript library that gives you and your coding agents the ability to fully control computers.

Simulang is our scripting framework for desktop automation. It allows you to write deterministic computer use code that can be replayed dozens if not faster and cheaper, compared to LLM agents.

It ships with a skill out of the box. That means you can turn natural language prompts into Simulang code directly, and your agent can now see the screen, click, type, and navigate.

It gives your AI agents eyes and hands to control the computer like humans do.

Try these things with Simulang:

- upload your pile of invoices to the expense platform
- find 50 people with specific criteria on LinkedIn
- open your calculator app and do some math
- find all buttons on your favorite app using accessibility tree
- or draw a bunny with MS paint 🐰

In this demo, we show how Simulang took over when the coding agent couldn’t open and click on the target LinkedIn profile page.

Give it a try: simulang.simular.ai/?utm_source=x&…

Experimenting with using @OpenAI codex and @claudeai CLIs within @greatfrontend workspace

Vibe coding in a nutshell:

Each change looks good in isolation.

Turns into a frankenstein monster if you don't take a step back to look at the bigger picture.

How I got better at optimizing web performance:

Wallet-driven development 💸

Be the one paying the infra bills.

Be charged for:

- Every byte sent over the wire
- Every function invocation
- Every edge request
- Every build minute

Once you feel the pain you'll optimize the heck out of it.

I'm sick of the way we write classes in React

className(), clsx(), cn(), again and again, all over the code.

So I built reclassify, it lets you write composite classes directly in JSX.

Angular (the OG), Vue, Svelte, Solid had this built-in for the longest time. Now you can Link to repo: github.com/yangshun/recla…

Thanks for the invite @boshen_c

Gonna try writing some Rust for @vite_js tasks!

Say goodbye to localhost:3000 and localhost:5173

If you recognize these port numbers, high-five! 🙏

I recently discovered Portless (port1355.dev) by @vercel

It's a command that wraps your dev command and gives it a named .localhost URL

Run portless my-app next dev app.localhost

How it works under the hood:

→ Assigns your app a random port (4000–4999) via the PORT env var
→ Registers a route mapping in ~/.portless/routes.json
→ Runs a reverse proxy on port 1355 that forwards myapp.localhost:1355 to the actual port (use port 80 if you don't want to use any port numbers in the URL)
→ Starts your app using that randomly-assigned port number

The .localhost TLD auto-resolves to 127 .0 .0 .1 in browsers. No /etc/hosts editing required.

This is useful because:

→ No longer have to remember ports
→ Cookies and localStorage are isolated per domains
→ Servers started by agents get their own domain (worktree-aware)
→ Browser history will be clearer with named URLs

Another project solving a similar problem is slim [.] sh, but it requires more setting up.

Introducing Void, the Vite-native deployment platform:

🚀 Full-stack SDK
⚙️ Auto-provisioned infra (db, kv, storage, AI, crons, queues...)
🔒 End-to-end type safety
🧩 React/Vue/Svelte/Solid + Vite meta-frameworks
🌐 SSR, SSG, ISR, islands + Markdown
🤖 AI-native tooling
☁️ tps://t.co/sczgQ0A9S1

Thank you @OpenAI, I'm going to just build things!