I spend a ton of time vibe coding and one of my gripes is coding agents have a hard time finding the element I'm talking about. I wished I could say "fix this" and the agent would know.
React Grab basically fixes this by copying the selected element's information (like React component name, source, and html) for the agent as context. This makes the element faster to locate.
It's available for free, open source on GitHub: https://github.com/aidenybai/react-grab
Let me know what you think!
For a bit of context: React represents UI as a tree of "fibers," which hold data like props, state, and context. React updates UI in two phases: render (building the fiber tree) and reconciliation (scheduling & diffing fibers to update the DOM).
My tool works by simulating __REACT_DEVTOOLS_GLOBAL_HOOK__ to expose React internals without using DevTools:
import { instrument, traverseFiberRoot} from 'bippy';
instrument({
onCommitFiberRoot: traverseFiberRoot({
onRender(fiber) {
console.log(fiber);
},
}),
});
I’ve found it pretty useful for detecting re-renders (I made a separate tool to highlight renders on the page https://github.com/aidenybai/react-scan), but there are plenty other use cases for toy projects or learning how React works.Happy hacking!
Fixing web performance issues is hard. Every developer knows this experience: we insert console.log everywhere, catch some promising leads, but nothing happens before "time runs out." Eventually, the slow/buggy code never gets fixed, problems pile up on a backlog, and our end users are hurt.
We started Million to fix this. A VSCode extension that identifies slow code and suggests fixes (like ESLint, for performance!) The website is here: https://million.dev/blog/lint
I realized this was a problem when I tried to write an optimizing compiler for React in high school (src: https://github.com/aidenybai/million). It garnered a lot of interest (14K+ stars) and usage, but it didn't solve all user problems.
Traditionally, devtools either hinge on full static analysis OR runtime profiling. We found success in a mixture of the two with dynamic analysis. During compilation, we inject instrumentation where it's necessary. Here is an example:
function App({ start }) {
Million.capture({ start }); // inject
const [count, setCount] = Million.capture(useState)(start); // inject
useEffect(
() => {
console.log("double: ", count * 2);
},
Million.capture([count]), // inject
);
return Million.capture( // inject
<Button onClick={() => setCount(count + 1)}>{count}</Button>,
);
}
From there, the runtime collects this info and feeds it back into VSCode. This is a great experience! Instead of switching around windows and trying to interpret flamegraphs, you can just see it inline with your code.We are still in the very early days of experimentation! Million Lints focuses on solving unnecessary re-renders right now, and will move on to handling slow-downs arising from the React ecosystem: state managers, animations, bundle sizes, waterfalls, etc. Our eventual goal is to create a toolchain which keeps your whole web infrastructure fast, automatically - frontend to backend.
In the next few weeks, we're planning to open source (MIT) the Million Lint compiler and the VSCode extension.
To earn a living, we will charge a subscription model for customized linting. We believe this aligns our incentives with yours: we only make money when we make your app faster.
We'd love to know your thoughts – happy to answer :)
Recently, I released automatic mode, which detects slow React components and automatically optimizes the reconciliation phase. It's still in beta but chugging along. It's around 70% faster than React on the JS Framework Benchmark and you can see how I did it here: https://million.dev/blog/virtual-dom
Interested? Check it out here: https://million.dev