React
React Over Everything: How I Choose a Frontend Stack
By Vivek Jalondhara · 2 min read
Published May 2026 · Updated
The framework matters less than the ecosystem around it. Here's the checklist I run before committing.
React is my default, but not out of habit — it's the gravity of the ecosystem. Data fetching, forms, tables, animation, and design systems all have mature, battle-tested libraries that compose well. That ecosystem is what ships features fast.
When I evaluate a stack I ask three questions: how does it handle server state, how does it handle forms, and how does it scale to a large team. For me that usually answers to TanStack Query, React Hook Form, and a typed component library with clear conventions.
The trap is over-engineering. Most apps don't need a meta-framework's every feature on day one. I start lean, measure, and add structure when the pain is real — not before.
Start with the interaction the product needs
An AV editor needs equipment identity, position, and ports. A small domain type makes it easier to compare whether a graph library supports the product, before investing in custom interactions.
Illustrative example · TypeScript · Simplified for explanation
type Equipment = {
id: string;
label: string;
ports: { id: string; direction: "in" | "out" }[];
};
type Placement = {
equipmentId: Equipment["id"];
x: number;
y: number;
};- Interaction requirements
- Domain model
- Library prototype
- Product decision
Conceptual flow for the example above.
Tradeoff to keep in mind
A library saves work on standard interactions but introduces conventions you must adapt to. Prototype the hardest interaction first.