Dear Beneathatree crew, and any curious soul who got tripped into this report:

This was my first React Nexus. And like most conferences, this one too felt more about the people than the talks. I was left with mixed feelings. Maybe expecting originality in conferences with this scale and depth is unrealistic. Maybe they're not here to hand you bespoke polished gems — they dump a lot of unprocessed mud at your feet. The diamonds — the signals that matter to you — are there, but you have to be very intentional about finding, picking and bringing them home. Otherwise, you walk away with nothing but noise. Maybe a few connections, if you're lucky a social butterfly.

Some felt like a personal report on things and problems we were trying to solve. Some only summarized a relatively new trend, rehearsing what's fresh without adding anything fresh to it. The topics were wide and well covered on the surface: Accessibility, Design Systems, Observability. But most came wrapped in the agentic approach first, engineering depth second. But thats not surprising for new age of conference talks too. Also, they weren't workshops either. A wiki paragraph, presented aloud, often without digging much in the limited time windows. That also did give a pulse: what's happening in the landscape, who's building what. But overall? Good signals, definitely there, yet scattered thin. And React Dev Tools? A complete miss, unfortunately.

I took messy live notes across both days. Here are my Notes from React Nexus 2026 - Day 1 and here are my Notes from React Nexus 2026 - Day 2. Surface reason: for a couple of you at Beneathatree who might care. Real reason: keep the old journalism muscle alive — crude as it is, this muscle knows only one way to stay sharp: stay locked in every session, every minute. Take notes raw, don't polish in the moment. Let the signal and noise bleed onto the same page. Probably why the conference kept me overwhelmed, yet left me underwhelmed with what to carry home.

Bijoy, our younger colleague, hovered around. Less appealed, so less engaged, more tired and fractured (literally) than I was. No way he would find it memorable either. But it's unfair to turn this report into an opinion fest. Plenty of glowing LinkedIn posts from the same auditorim. Reading Why I Stopped Attending and Started Contributing after React Nexus felt timely. Its central argument—that communities shouldn't only critique conferences but actively contribute to making them better. Organizers can curate only so much. The rest is on us: asking better questions, writing thoughtful follow-ups, sharing what worked (and what didn't), and contributing talks that push beyond introducing trends into explaining their trade-offs. If we want better conferences, we have to help build them.

Here's what I set out to do: surface the signals, as many as I can find, without sweetening the page. Filter the noise, as much as I can, without erasing what was real. And then go beyond the talks themselves. Pull in references that matter but weren't mentioned. That last bit is personal. Me, thinking out loud, leaving something behind for a future self.

So: a curated dump of topics and resources from both days. Practice, mostly — learning to walk out of a conference with something more than a few handshakes.

# Day 1:

The conference started right on time. The emcees opened with well-rehearsed banter while the auditorium was still filling. Effortfully candid, effortlessly generated. The introductions were engaging. Often sloppy, too. But this was only rehearsed openings, things felt a lot more humane as the day went on.

I hadn't heard of most of the sponsors. CodeWalnut, ImageKit, WSO2—all new to me. Except Zoho. The emcees slipped pushed in a product plug for Zoho's serverless offerings. They claimed the schedule was drowning in AI talks. In hindsight, it was thankfully not entirely true. Then they very brazenly tried to make a case for why engineers remain irreplaceable. The jokes and stage drama were okay. The auditorium was nearly full by then. I just wish they'd spread the humour across the day instead of front-loading it all at the opening. And yes, things felt a lot more humane as the day went on. But we are here for the talks, not for the opening.

# 1.1 React Is Becoming a Platform, And Most Developers Haven't Noticed Yet | Tapas Adhikary, CEO, CreoWis

Tapas opens by sharing—almost as an aside—that this was the first year his full-length talk got accepted. He later shared The slides from this talk on LinkedIn. He'd applied every single time. This year, not only accepted, but as the keynote. He saves the personal introduction for later instead of leading with it. I like such talk templates. Doesn't make you sit through a bio before earning your attention. He's a serial React community builder and YouTuber, but that comes after the intro the substance.

React is always evolving, he says. There's always something new to learn. It stopped being just a UI library a long time ago. Streaming, SSR, Server Actions—these have fundamentally expanded what React is. He walks through the history since 2013, and it's striking how simple the original bargain was: manage state, render UI to the DOM. Nothing more. That's it. A "V" in MVC.

Around 2018, something shifted. Applications were shipping JavaScript bundles north of a megabyte with long, sequential network waterfalls, and the ecosystem started reaching for better ways to orchestrate data. The talk feels humane and informative—not the usual sloppiness you brace for at these things.

React never really cared about the backend in the beginning. But routing, data fetching, all the concerns that live on the other side of the network—they kept surfacing. React kept pushing against the limits of what a client-only library could do, and the cracks started showing.

Tapas continues to talk about the complexity crisis of SPAs—the tension between SEO, zero-loading expectations, and applications that keep growing past what the client can reasonably handle.

He asks the room: how many people started using React in 2013? A handful of hands go up. Then he traces the arc: a client-heavy library in 2015, the Hooks era around 2020, and today—a platform that increasingly embraces the server as a first-class concern, not an afterthought.

Moving computation closer to the edge shrinks the traditional server roundtrip. Hooks like useOptimistic represent a deeper shift in mental model. You're no longer thinking "fetch, wait, render." You're thinking about what the user should see now while the network catches up behind them.

The "framework bloodbath," as Tapas puts it, now consists of Next.js, React Router v7, and TanStack Start. They largely solve the same category of problems. Forget the competition. What's striking is the convergence. These tools are all reaching for the same shape.

Tapas gives Next.js credit for something specific: pioneering the App Router mental model and, more importantly, helping establish the vocabulary and architectural parity the ecosystem now shares. While now TanStack Start doing it very beautifully. Across all three frameworks, you'll find router-level loaders, server-first mutations, streaming SSR, hydration optimization—just under different names. All of them arguing about the implementation while agreeing on architecture. React increasingly acts as the common platform that makes these backend capabilities possible.

For those of us at Beneathatree wrestling with framework choices: his take is that whichever of the three you pick, you're generally in good shape. He recommends TanStack Start for founding teams with experience—lean, composable, you own more of the stack. Next.js remains a strong recommendation for new teams because so much comes out of the box. But the real takeaway isn't which framework to choose. It's the paradigm shift underneath: React is moving from client-first thinking toward server-first applications.

He illustrates this with an ebook-selling application—client UI coordinated with the Next.js App Router, Razorpay, Supabase, Vercel Blob storage, all within the React ecosystem. It's a lot of pieces. But the point is they all fit.

Here's the line I wrote down:: today there's hardly anything called "global state" in the traditional sense. The conversation has shifted toward server state. Complex lifecycle discussions matter far less than they used to. Suspense is widely adopted, because it brings sanity to the developer experience while debugging. Edge-based architectures increasingly shape how we design applications. If you've been building React apps for a while, that's a quiet earthquake.

The biggest transformation in React, Tapas argues, isn't any single feature. It's where applications execute. React applications are steadily moving from the browser toward the server—not because of some ideological swing, but because user expectations demanded it. The browser alone couldn't keep up.

He closes by mentioning his book, The React Clean Code Rule Book. If the talk resonated, it's probably worth a look.

# 1.2 React with the server, without compromise: TanStack Start | Sreetam Das, Senior Frontend Engineer II, Remote

Sreetam has a personal dev site — started in 2021, as a second repo 2016, if you consider the first commit on the first repo, as plain HTML and CSS, then a React SPA, then Next.js Pages Router, and eventually, Cloudflare Workers with TanStack Start. His site is his scratch file. Too personal to abandon. The one that outlasts everything else. Yet, nothing's sacred with 0 users (his claim, not mine) and 1M visitors (his omission, not mine). So Drizzle goes in. Zustand goes in. TanStack goes in. That story is his talk.

His biggest motivation to leave Next.js? Staying free. Not escaping a bill he already had, but avoiding one altogether. Cloudflare's generous free tier made that viable. TanStack Start made the architecture feel clean.

He didn't land on TanStack immediately. He also tried SvelteKit, Vite, Remix. Next.js introducted the React Server Components, but most people struggled with moving the mental model from client-first to server-first full-stack development. Next.js eventually fixed Turbopack, but by then he'd already experienced Vite's speed, data-loading and nested routes and didn't want to go back. TanStack Start, which was a full-stack on top of TanStack Router. Was fully open and framework-agnostic. Client-first by default, but server-capable when you need it with SSR, streaming, server-routes, server functions, middleware and route-level caching.

Technically, what he demonstrates is genuinely interesting. Routes own the entire data contract — the loader data is cached, types flow end-to-end without you needing to intervene. Server functions go beyond regular HTTP endpoints: a static JSON function file is sent from the server when called. There's middleware across boundaries with client() and server() contexts. Really comes handly for user timezones and cookies. Rendering is a dial you can tune per route: full SSR, data-only SSR, client-only. Inspired by SvelteKit actually. Streaming SSR with a shell. Build-time server functions for static data and store them as a static JSON file. One route, many choices. His slides walk through each of these — the loader contracts, the server functions, the rendering dial — with code snippets and diagram.

He also plugs type-fest, TypeScript taking care of route types, and TanStack CLI for guidance. The TanStack library ecosystem keeps the experience consistent. There's talk of composite components and deferred hydration. And, buried in the middle: this is the first actual mention of agentic engineering all day. TanStack Start is apparently "agent ready."

The talk is packed, maybe even too packed. Like Tapas before him, Sreetam's session feels rooted in engineering philosophy and genuine DX concerns. It's the kind of talk that makes you want to over-engineer your personal site. Bijoy, watching alongside, was more curious about why Sreetam left SvelteKit. Sreetam also makes a plug for his 25k downloaded VS Code Theme: Karma

# 1.3 Rendering Only What Matters: Performance Wins with Partial Prerendering | Archana Agivale, Tech Lead, QED42

Archana delivers a short, straight-line talk. Archana is stellar contributor actually. Next.js, Strapi, Shadcn. No anecdotes, no warm-up, just a freight train of performance reasoning. I wish there had been a break before this one.

Her core argument: performance is not just about how much data you send to the client, but about when you render it. Nobody stays on slow sites for more than two seconds. Google rankings depend on LCP. These are the stakes she opens with. The talk then primarily evolves to be about Partial Prerendering (PPR), introduced in Next.js 15.

For the context, Archana walks us through Next.js's rendering evolution. SSR: always fresh, but slow and expensive. SSG: super fast, but stale whenever data changes. ISR: a balance, but still rebuilds everything. Then comes partial prerendering, introduced in Next.js 15, which takes the best of both worlds: static shell with dynamic islands. The browser can paint the static shell — header, hero, layout — immediately, improving LCP, while the dynamic content (inventory, reviews, ratings) streams in progressively at runtime also helping with CLS.

Her implementation tips are practical: use Suspense boundaries, separate dynamic and static zones, prioritize what's above the fold, use server components, cache expensive CMS calls. Static layout shells can have component-specific cache lifetimes.

She's upfront about limitations. Partial prerendering isn't for everything. When every byte of information needs to be fresh, you're back to SSR. She touches briefly on cache components, noting that Next.js 16 will take the PPR model further with them.

# 1.4 The Third State: How React's Activity API Fixes the Hidden Problem in Every App You've Ever Built | Piyush Assudani, SSE, RBJ Technologies

Piyush is a designer-engineer and brings energy the room needed. The personalities of the speakers, I scribbled, were curated like a salad. He's dramatic. He's candid.

The problem he diagnoses is one you've felt but maybe never named: mounting and unmounting are the only two states in React's component lifecycle. There is nothing in between. Unmounting destroys everything — state, focus, scroll position. The hack has always been display: none, which keeps the component alive but still fires functions without a visible UI. React historically coupled visibility with existence. That coupling is the bug.

The fix is a third, middle state: background. React's Activity API introduces a mode prop that deprioritises re-rendering when the component moves to the background, selectively preserving the states that matter while releasing what doesn't. It saves the struggle of recreating user state, preserving UI memory that nobody was preserving before.

When to use it? Search interfaces, shopping carts, chat sidebars — anything a user leaves and returns to. When not to? Toast notifications, tooltips (too cheap to matter), login modals (used once anyway). The judgment call is part of the API.

Piyush made what could have been a dry spec walkthrough into something theatrical. I did later write that the "third middle state" talk could have been a small email. But I'm not sure that's fair. Sometimes the small email contains exactly the right idea.

The morning session closes with a 15-minute break. The energy has been dense. I sit with Bijoy and we both feel the cognitive load — too many ideas packed too tightly. But there's coffee, and the second half re-renders with a new paint.

# 1.5 React Upgrade at Scale: The Good, The Bad, and The Unexpected | Akshay Ashok, SDE II, Rippling

His slides are a React app. Of course they are. The talk is the same. Some very sharp sloppy copywriting in mostly well curated story from the trenches. This is a war story. Upgrading React across a large codebase with real users. He starts with the obvious: even with an agentic approach, a lot of unit tests will break. Runtime errors will surface in places you didn't expect. Concurrent rendering was the most challenging chapter in his team's migrations.

The technical insights are direct. Updating types first, then moving to the actual code changes — a process that would takes months in pre-agentic times. Asserting intermediate states may not work in tests migrating from React 17 to 18 because React 18 batches state updates differently. Nuances around synchronous and concurrent modes: concurrent rendering breaks during user interactions like clicks, observable in DevTools. There's no escaping directly to React 19 by bypassing 18 — the concurrency model shift is a prerequisite. React 19 is mostly removals and semantic changes; agents can handle large chunks of that work.

One underappreciated detail: there's no single entry point during the runtime for a gradual migration from 18 to 19. His team's solution was to create a separate build at the infrastructure level and serve them with instant rollback capability. For rollout and rollback, he literally recommends an if/else in createRoot(el). Sometimes the simplest thing that could possibly work is the right answer.

Why go through all this? The React compiler, less legacy debt, async in render, Actions, useOptimistic — the features that make the migration worth it. But the talk is honest: this is painful, expensive work. And at enterprise scale, the agentic approach doesn't eliminate the pain. It possibly only shifts where you feel it.

Bijoy stayed curious about something I'd glossed over: locator.js. Click a component in the browser, and it opens the corresponding code in your IDE. It started breaking after Akshay's migrations, they had to fix it with some That's a tool worth knowing about, even if it's fragile. This talk had more detail than I could condense.

# 1.6 AI Solved* Coding. Shipping Is the New Bottleneck | Vignesh Krishnan, Developer Relations Engineer, Zoho

Vignesh is a Zoho veteran of ten years, and this is a full-length sponsor showcase. His opening claim: AI has dramatically shrunk the time to build, but the time to ship hasn't changed much. AI doesn't decide where the app runs, where the data lives, how to autoscale, or how auth works. These are the real bottlenecks, and they're not going away.

Then the Catalyst tour begins. Zoho makes SaaS — 55+ apps, 150 million users, 16 data centres. Catalyst is their full-stack hosting platform: frontend hosting and deployment, object storage, an event bus. Then authentication components, third-party service integrations, S3-compatible bucket migration paths, push notifications, mail services. Then QuickML, which imports datasets and returns models with API endpoints. Then serverless backend, Docker image support, cloud-scale databases.

The talk loops through a live demo where Vignesh one-shot deploys an application using Catalyst with Sonet, walks through the platform's UI, syncs GitHub repos, auto-detects the framework, and deploys with preconfigured build paths. It's competent, but the relevance to the talk's title is increasingly thin. As Bijoy muttered, everyone now has their own AWS.

The talk ends with a plug for Datathon 2026 with Zoho and Karnataka Police. Thank you Zoho, for sponsoring this conference.

# 1.7 What I Learned Building Payments | Smile Gupta, Software Engineer II, Wayfair

Smile's charmingly illustrated slides are almost storybook-like — and while that feels surprising for a payments talk, the warmth of the presentation lowers your guard just enough for the technical depth to cut through.

She started with the disclaimer that this wasn't about payments architecture. Something I wasn't expecting. But of course, this is a React conference; it is, in her defence, entirely about the high-stakes frontend user experience during payment navigation.

Different payment service providers have different authentication models: some use an API key + URL, some redirect with a return URL, some use multi-use tokens, and some use single-use tokens. The flow is standard enough: frontend starts, backend creates a session, the Payment Service Provider returns a token or session ID, the token goes to the frontend, the frontend opens the payment page or SDK, the user completes the payment, the result is shown with a reference, and the backend verifies it too. But the edge cases are where the real complexity lives.

Take the auth token lifecycle, for example. A user starts a payment, leaves the page, comes back ten minutes later, and the flow is broken. The token has expired, or the session state doesn't match. UI and payment readiness need to always stay in sync. These are the kinds of bugs your users discover first. Refetching the cached token is not a bad idea here. But there are also different token models depending on the provider. Some have API key + URL. Some use redirect + return URL. Some use multi-use tokens. Stripe's 3DS gets a plug here. Others rely on single-use tokens. The problem above is specific to that last case.

The error UX is where Smile shines. "Something went wrong" is not a good error message when money is involved. Trust is at stake. She advocates for well-designed and actionable error systems: tell the user upfront whether they were charged or not. Can I retry safely? What's the next step? If a specific payment provider is down, clearly tell the user it's unavailable while nudging them toward an alternative payment method. There's also the problem of the "ghost order". Payment succeeds, but the order fails on the checkout side. The user sees the debit but gets no confirmation. This mostly happens when the return URL is broken or the backend update fails, possibly due to network issues. These gaps erode trust silently. Clear user feedback telling them that the payment has been processed but the order creation failed would be a much better UX.

Someone from the audience points out that Safari blocks pop-ups, AJAX requests must always originate from a user click, and redirect-based payment flows break on certain browsers and WebViews. Smile's answer: check capabilities across payment SDKs and browsers first, then conditionally offer the available options.

Good observability and good logs have a strong case here, along with being mindful about what we log and what we must never log. Never log personal information. "Payment UI is a lot more than just UI. Design for clarity. Engineer for trust.", said Smile Gupta.

# 1.8 AI-Generated React UI that ACTUALLY follows your Design System | Apurv Khare, Staff Software Engineer, Procore

Apurv is returning to React Nexus for the third time. You can find his Vue slides here on vercel.

He opens with a demonstration: give an LLM a GitHub Issues UI screenshot, ask it to generate the UI using GitHub's Primer Design System. The code renders a design that looks remarkably close to the original. But it's not good code. It's not maintainable. It doesn't follow any system. It's a one-shot visual replica with hard-coded values that would collapse under the weight of real iteration.

The problem, Apurv argues, is that LLMs are generic, stale, and blind to your specific design system. Guidelines — the dos and don'ts, the spacing rules, the typography hierarchy — exist in your team's heads and possibly in a Figma file, not in the model's training data. His solution has three layers: Design Tokens (central variables, colours, spacing), Component API (how components compose, what props they accept), and Guidelines (the patterns and anti-patterns specific to your system).

He references popular examples: Amazon's Cloudscape, GitHub Primer, Adobe Spectrum — all have mature design systems and foundations. His approach is to encode your own system into an Agent Skill. His skill has following skeleton: a SKILL.md file (the instruction set), a references/ directory (documentation the model can consult), scripts/ (deterministic tooling to feed context), and assets/ (images, screenshots). The reference docs don't just inform the model — they also generate, verify, and audit the workflow outputs. Deterministic scripts are critical because they create a ground truth the model can't hallucinate its way around.

A few practical details: such a skill is currently limited to Vision Language Models — the model must be able to see your reference screenshots. There's a disable-model-invocation flag that prevents the model from auto-invoking the skill, only triggering it on explicit /slash commands. An important nuance for anyone building these: the skill needs to stay living. It should update automatically, either through agents or routines, as your design system evolves.

I don't have the exact skill that Apurv used during his demo, and I didn't see a link to it in his slides. But that's not the point of such a bespoke approach. He rightly gives us the recipe to create one. First, inventory your sources: tokens, component types/catalog, guidelines/docs, Storybook. Second, write an ingest script to emit knowledge/, tokens.json, components.json, usage/. Third, write SKILL.md — a sharp description, the tree workflows, and the rubric. Fourth, add scripts for audit (rubric), screenshot, and compare to verify. Fifth, install the skill in the repo. Finally, add a GitHub Action to re-ingest on every release to keep it current forever. Although Apurv doesn't share the exact skill, he instead shares a meta-skill that interrogates you to create the above skill (github.com/apurvkhare/design-system-skill).

The concept of encoding institutional design knowledge into something an agent can consult, rather than crossing your fingers that the model already knows, is a pattern that extends well beyond UI.

# 1.9 The Agentic React Engineer: How to Win in 2026 and Beyond | Nattu Alagappan, CEO, CodeWalnut

Nattu Alagappan, CEO of CodeWalnut, brings this unmistakable CEO energy to the stage. This is a big-picture talk about the agentic era. Wants to lean on stories more than implementation details.

He begins with a tour through history. The Industrial Revolution becomes a way to talk about scale, pace, and how software engineering is changing again. The visuals are wide. The delivery is theatrical. One story flows into the next.

He then refers Radhika Menon, the pioneering merchant navy captain and bravery award recipient, as a metaphor for navigating unfamiliar waters. From there, the talk shifts plugging in Graphify, Agent Memory, multi-agent workflows, and knowledge graphs. These, he argues, are the building blocks of the new playbook.

Nattu puts up a slide listing twelve agentic engineering competencies his team at CodeWalnut has identified: Toolchain Setup, Context Engineering, Test Automation, Skill Packaging, Code Review, Token Economics, Agentic Retrospective, and six others that flash by too fast to note. He strikes a playful pose next to the slide.

The session ends with a CodeWalnut plug. Nattu talks about how the company spent the start of this year rethinking the way it builds software, experimenting internally before turning those lessons into a free AI coding masterclass.

It's a classic CEO keynote. Big on vision. The talk is engaging enough that I didn't mind sitting through it. Bijoy, meanwhile, was doing his best to stay awake through the afternoon slump.

# 1.10 Performing large scale migrations with AI | Rishab Bhattacharyya, Senior Software Engineer, Ford Pro

Rishab opens with a story about spotting a black panther while trekking on foot — he hid in time, just barely. The metaphor, it turns out, is about confronting something that could eat you alive: large-scale migrations. The legacy codebase is the panther.

Here are his slides with a framework that breaks migration into three parts. Analysis takes 50% of the time. Code generation and migration is about 80% correct on the first pass. Verification is what closes the gap from 80% to 95-100%. The numbers feel honest, and the implication is clear: AI helps most in the middle phase, but the edges — understanding the code and proving it still works — remain fundamentally human work.

For analysis, he goes deep on context. You need more than the code. You need the dependency graph: what depends on what, not just at the package level but folder by folder, function by function, what does this code mean and what does it do. He plugs Graphify (second plug of the day, after Nattu) as a tool for building that understanding. Migrating to a new framework requires a tree-like structure of context files — distributed agent.md files, not one monolithic document. Putting everything in a single agent.md is a mistake for the effective context size.

For the prompt engineering, he has a specific five-component model: Persona (who the agent is), Context Injection (the map of the codebase), Constraints (the guardrails), Few-Shot Examples (the patterns to follow), Chain of Thought (the logic check). He categorises skills into Discovery (understanding), Manipulation (making changes), and Validation (verifying correctness). (His public skill for this is on GitHub — deeper link pending, couldn't fetch it yet.) Tests are the bedrock. Create tests before migration — legacy TDD, kept alive for the modernised codebase.

Then he shows his workflow orchestrator: a set of .md files that define the migration pipeline — orchestrator, analyser, committer, executor, gap reporter, reviser, validator. Each step is a discrete agentic sub-workflow. The approach is: analyse, verify, use analysis to generate code, confirm, revise, commit. He plugs Opencode (the desktop app in light mode) as his tool of choice, noting its permission-setting capabilities.

The talk feels high-level and a little slow, but the relevance is hard to deny. Migration work is the kind of grunt labour nobody wants to do — and the kind where AI assistance, properly scaffolded, could actually move the needle. This wasn't the flashiest talk, but it was one of the more practically structured ones.

# 1.11 You Logged Into Your React App. Now What? | Omal Wijegunawardana, Associate Technical Lead, WSO2

Omal Wijegunawardana from WSO2 starts with a simple yet fundamental question: How confident are you in the role-based access control of your React application? I know that feeling. RBAC is one of those things where you would always want to say I'm fully confident, but wish to rush tests across one last time.

He says the talk is about authorization, which is genuinely a hard problem. And I wish I came across enough codebases that roll their own auth from scratch where the same application can expose completely different capabilities depending on the user's role or subscription tier. Role based Access Control. Our applications do have a fully hand rolled, and very intricate role based access control with Cognito's authentication.

And as expected one of the first things he points out is that hiding a component behind an if condition in the UI isn't really security. The headless endpoints behind it could still be open. Instead, permissions need to be enforced in three places: routes, components, and data.

Initially, I expected him to frame it as frontend, backend, and database. But thinking about it, these are really application-level enforcement points. Routes control what users can navigate to, components determine what they see, and data is what ultimately needs protecting. That doesn't necessarily mean the database itself enforces authorization. In practice, especially with many popular NoSQL databases that lack PostgreSQL-style Row-Level Security, these checks often live in the application or API layer instead.

That naturally leads to his main point: the real gate is on the server, where the data lives. The same application may serve different classes of users, but the authorization token should be the single source of truth. It should consistently gate routes, components, and data. The UI is really just a courtesy.

Then comes the inevitable WSO2 product plug. They position their identity platform as enterprise-ready, flexing RBI as one of their customers. The pitch: a drop-in React SDK with built-in role management, enterprise features, and a free tier.

I also learn that Asgardeo was the previous branding before being folded under WSO2. It ships with React hooks and support for user tiers, and from the demo it looks like it makes RBAC integration surprisingly seamless for React applications.

Towards the end, Omal briefly mentions ThunderID, an upcoming fully open-source RBAC solution where you own the authorization code yourself. Later, outside the sponsor area, I ask him about our custom RBAC setup and that leads him to elaborate further on ThunderID. Apparently someone from WSO2 will be demoing it later on Day 2.

# 1.12 Shipping React with AI Coding Agents: What Works, What Breaks, What Scales | Kumar Prince, Software Engineer 3, Walmart

Kumar takes the stage for his first-ever React Nexus talk. He's sincere, maybe a touch nervous, and his slides are full of memes and screenshots from his editor. The framing is practical: what actually works when you ship React with AI coding agents?

What works: refactoring, test generation, boilerplate, code review. Mocking becomes easy. AI can find potential memory leaks and file extension issues. It can prioritise issues it finds.

What breaks: architecture, edge cases, business context. The AI's blind spot is business logic — it can generate code that passes tests but misses why the code exists in the first place. It struggles with ownership boundaries and the judgement calls that experienced developers make without thinking.

What scales: bounded tasks with clear context, existing patterns to follow, human review of all outputs.

The talk is practical but stays at a high level. He did give quick examples, though I would have liked more depth on the code smells and frequent failure patterns. Kumar closes by wishing everyone a very long career and hopes they can change their jobs. A warm ending, if not a technically satisfying one.

# 1.13 From Copilot to Collaborator: Architecting an Autonomous Workflow for Frontend Teams | Amit Panigrahi, Computer Scientist II, Adobe

Amit opens with an anecdote that lands: a two-hour coding task that turns into a three-day affair because of everything around the code. The PRD takes a day. Design takes two hours. Implementation is another two hours. Unit tests and integration tests — painful, boring — eat up three more hours. Build and test: another hour. Reviews and deploys with their latency: another day. Amit calls this the developer tax.

He traces the evolution of AI integration: from autocomplete to chat LLMs to agentic loops. Low agency to medium to full. His autonomous dev pipeline consists of a product agent, coding agents, a QA agent, and a reviewer agent. A process that takes 3-4 days manually now takes 45 minutes in the agentic pipeline. The Agent Composer handles reasoning, planning, reflection, retries with plan, execute, observe — MCPs providing the reality checks at each stage. "Agent + MCP: brain and hands," he says.

Then, the reality check. His own agentic pipeline to generate the missing unit tests, spiked the Infrastructure costs. Build time went from 2 minutes to 47 minutes. Because unoptimized process with 3 retries on each failure. Trust collapsed. Fifty percent token wastage was traced to harness overload. But liner harness, to struggles with quality of the unit tests.

The breakthrough came with a custom Agent Composer operating in distinct phases: planning, execution, observation, and correction. MCP servers give it direct access to GitHub, terminal, Jira, and Postgres. The fully autonomous dev pipeline parses the PRD to identify affected files and creates a scoped task graph. The coding agent then implements everything with unit and integration tests — no lint errors. The QA agent — which Amit calls crucial — uses Cypress/Playwright to run regression tests and generate coverage reports. On top of this sits a reviewer agent that runs security scans with cross-model gap tests, though a human remains in the loop.

The dark side gets a section. Prompt injection, goal hijacking, autonomous flows going rogue. I note that I don't see enough discourse around orchestration and multi-agent flow unreliability — these are the failure modes most worth talking about, and they're barely mentioned.

Amit still flags the need for code review and security, though he's hopeful about newer models. Amit's custom dashboard shows how the new generation of tools has multiplied his productivity and complements his working hours with AFK modes.

# 1.14 How Atlassian Refused to Let CI Become the Bottleneck of Agentic Development | Chaitanya Deorukhkar, Principal Engineer, Atlassian

This is the talk that makes Day 1 worth it.

Chaitanya works on Jira at Atlassian, which is a very large extremely massive monorepo. 500k files. Everything is a package in organized in specific domain folders. Two hundred PRs every day just for Jira. The expectation, in the agentic era, is 2,000. AI increases code throughput, sure, but does it increase shipping speed? Not really. Because the bottleneck just moved.

CI check is the recurring choke point. At every stage — review, merge queue, deployment — there are way too many tests. Even more in the agentic era, where every agent generates its own test suite. The dependency graph is a mess: highly coupled, deeply convoluted, a dense forest of code where every change risks a wildfire. The common dumping grounds—/utils, /types, /common—are a root cause: whatever doesn't belong anywhere goes here, and there are so many of them. They pull in large packages for singular constants, types, and functions. Unrelated code gets packaged together, entangling everything. Hearing this, it hit me: SOLID principles are not really followed in enterprise codebases — and now they're paying for it. The result is not aesthetics: more tests to run, slower static validation, long-running CI checks, and higher TTRP. The CI cost is very, very high.

Atlassian's response is Project Thunderstone. The core insight: you don't need to run every test for every change. You only need to run the tests affected by the change. The tool that makes this possible is FactsMap — a Rust-based, in-house dependency graph engine. But FactsMap was helpful largely because it surfaced just how bad the coupling was: everything depended upon everything. It produces actual JSON (not Markdown), mapping exactly what each file touches. FactsMap identifies what's changed, traces the dependency graph, and flags only what needs selective validation.

The principles: Tools, Rules, Guardrails. Rules create package levels based on impact — directional boundaries that keep dependencies under control. Tools give visibility: a CLI package that shows the tax for every change. "With these tools, developers are paying a lot less tax." But developers wouldn't care at this scale. What matters is CI complexity. The result: 90% fewer tests using FactsMap. Less than 50% of integration tests running on each change.

Guardrails prevent regression, but they come at a cost: friction. So Atlassian built a toolkit to make living with them bearable. Thunderstone Package Complexity surfaces the hidden CI tax of each package — how much it costs to touch — using FactsMap under the hood. Thunderstone Migrate does the heavy lifting: through codemod actually, given a target folder, inlines rarely-used constants, types, and functions right into their call sites; promotes heavily shared ones into dedicated packages of their own; and unknots tangled packages by pulling out discrete subgraphs of files. Over time, this sorts packages into usage-frequency tiers, each mapped to a tax bracket with directional rules — a package can only depend on tiers at or above its own, with explicit thresholds. And when a violation slips through? Thunderstone Doctor inspects the offending commit, traces the root cause, and prescribes a fix. No AI. Deterministic, reliable, boring.

The metrics Chaitanya shows are genuinely impressive. Worst case, all percentiles (P90, P70, P50) touched 139,000 files. Dumping grounds like utils, types, and common directories were pulling in large packages unnecessarily. The codebase was, in his words, "really shit." Making the CI cost astronomical. Thunderstone helped them drop by more than half. 90%-50% fewer tests.

"Codebase health is everyone's responsibility," he says. "You need owners, drivers, and torchbearers. Quantification is super helpful — to know the problem from what to why. Preventing regression is just as important as shipping features."

This was a good talk. Still high-level in places, but rooted in low-level impact. Good storytelling that moves developers. But stepping back: the talk is not about dependency analysis algorithms. It's about organizational engineering. Chaitanya spends most of the time convincing the audience why this problem matters and how Atlassian got people to change their behavior. The actual implementation and codemod internals are largely absent. That's a perfectly valid conference talk, but it means the audience walks away inspired rather than equipped.

The last talk of the day.

# Day 2

Day 2's schedule leans more toward production engineering — crash resistance, load testing, observability, image perf. A different register from yesterday, and one I'm looking forward to. The auditorium is 25% filled at 9:30. Bijoy said he'd bring his laptop. Firmer handshakes from yesterday's people.

The emcees are candid and engaging — I should give them more credit. They're trying well. The first session is on React Native crash resistance. Only one React Native talk in the whole schedule. Then load testing, observability, image performance with MCPs. The morning is stacked with infra and reliability before the agentic talks pick up later.

# 2.1 Building crash resistent React Native apps | Nikhil Soni, Engineering Manager, Quince

Nikhil's talk is the only React Native session of the conference, and it starts the day on a technical, grounded note.

Crashes, he explains, grow with user adoption. The curve rises exponentially until about week ten before it starts to flatten. His team went into a "Code Red" — no features, only fixes — and ran crash rate benchmarking. Best in industry: Hotels and Booking at 0.4% crash rate. The worst are much higher.

His toolkit: Datadog and Bugsnag for crash identification, user journey investigation. Traces with dSYM files (debugging symbols) for full stack visibility. Hermes dSYM, specifically, is what he calls a life-saver for getting proper trace data. These tools helped diagnose the hardest category: launch crashes. A launch crash is particularly brutal because the first attempt that fails leaves almost no trace to debug.

The real villain throughout is memory. Image-heavy e-commerce applications on mobile face a specific set of challenges: size, resolution, image buffering. His team's biggest intervention was a partial unmounting strategy: instead of keeping the entire navigation stack alive, inactive screens were torn down, keeping memory usage roughly constant. Images were only one part of the problem; long-lived screens and decoded image buffers were steadily accumulating RAM. This alone dropped memory warnings by 85%. But then came the image buffer explosion. Scheduled cache cleaning — an useEffect with an interval calling clearMemory() — was needed. Beyond that: thresholding the number of images via cache limits with SDImage, using dynamic cache units to find optimal values per device, and querying device memory variables to adjust caching strategies.

Module Registration Architecture introduced another class of crashes: modules failing from the main thread. The fix was forcing those modules to run only on the JS thread, since the UI thread would crash them.

Nikhil mentions the solace and joy of watching the crash report graph go down — it became his wallpaper. Their stability rate is now 99.99%. A talk that was technical, low-level, and satisfying.

# 2.2 Load Testing Real React Applications for Production Performance | Mohammed Zubair Ahmed, Senior Software Design Engineer, Mattermost

# 2.3 Frontend Observability is the Missing Piece of Your Stack | Gaurav Tewari, Software Engineer, signoz.io

# 2.4 Debugging image and video performance issues with MCPs | Harshit Budhraja, Senior Software Engineer, ImageKit.io

# 2.5 Real-Time React: Building WebSocket Apps That Hold Up in Production | Prakhar Goel, Founding Engineer, Adalat AI

# 2.6 From Click to Agent: Orchestrating AI Workflows with Temporal and React | Aqsa Aqeel, Software Engineer, DigitalOcean

# 2.7 The Browser Is the Backend: Running LLMs in React with WebGPU | Harsh Pathak, SDE, Groww

# 2.8 We Want Security, but Not Complexity | Jerad Rutnam, Senior Technical Lead, WSO2

# 2.9 From Memory Cards to Real-Time: Building a Live Event Photography Platform with FTP Server! | Sumanth B A, Senior Software Engineer, smallcase

# 2.10 Agentic Development: Hype, Reality, and What's Next | Panel Discussion

# 2.11 From Prompt to XR: Building Immersive Experiences in the Browser with AI | Mohit Kumar Toshniwal, Senior Software Engineer, Ethos

# 2.12 Beyond the API Call: Architecting Local AI Workflows in the Browser | Megha Pathak, UI 2, Flipkart

# 2.13 Structured Data and Schema Markup for Frontend Developers: SSR, CSR, and the AI Search Era | G Sriram, SDE - III, HighLevel

# 2.14 Making Your UI Agent-Ready: How AI Agents Use Websites and What's Coming Next | Adnan Arif Sait, Lead UI Engineer, MiQ Digital

# 2.15 Fixing AI's Blind Spot, Give Your AI Eyes in the browser | Janardhan, Principal Engineer, Oracle

# 2.16 Playwright + MCP for E2E | Santosh Selvasundar, Software Engineer, Brackett AI

# 2.17 Agentic Voice AI powered Career counselor | Mohith Kumar, Software Engineer, Edstruments

# 2.18 From UX to AX: Building agentic experiences in React | Ashita Prasad, SDE / Developer Advocate, AWS

# 2.19 From Predefined Screens to Realtime UI Generation | Zahle Khan, Founding Engineer, Thesys

# 2.20 Agentic UX: Designing Experiences for the AI Age | Panel Discussion

Looking back, I think I walked into React Nexus with the wrong expectation. I expected the talks themselves to be the value. What I ended up valuing was everything they pointed towards.

There are a few ideas from learning science and cognitive psychology that helped me make sense of this. One is Information Foraging Theory, which suggests that good information sources don't always contain the answers—they emit information scent: just enough cues to help you discover where richer knowledge lives. A passing mention of FactsMap, DESIGN.md, Activity API, or codemods at scale became trails leading to papers, engineering blogs, conference talks, GitHub repositories, and debates that were far more rewarding than the original thirty-minute session.

Another is the idea of scaffolding, or what education researchers call Preparation for Future Learning. Some experiences don't maximize what you learn in the room; they maximize what you're able to learn afterwards. They give you vocabulary, mental models, and just enough context to ask better questions. Andy Matuschak makes a related argument in his essay, Why Books Don't Work — a reference I first came across in Geoffrey Litt's talk, Understanding is the new bottleneck. Reading—or listening—often creates the comforting illusion that learning has happened. Real learning begins when you retrieve, compare, apply, question, and connect ideas for yourself.

In hindsight, that's exactly what these notes became. The conference was only the beginning. The real work happened later: revisiting talks, finding missing references, comparing competing approaches, tracing ideas back to their original papers, and trying to understand not just what people were building, but why. The summaries you just read are only one layer of that process. The references beneath them are where I hope the more interesting journey starts.

So perhaps I judged the conference using the wrong yardstick. A conference isn't always a place to come home with polished answers. At its best, it's a map of the landscape—a dense collection of signals that helps you discover where the worthwhile questions lie. Some signals fade immediately. Others stay with you for weeks. The challenge isn't simply attending. It's learning how to separate signal from noise, and then following those signals long after the lights in the auditorium go out.

If these notes are useful to anyone beyond my future self, I hope it isn't because they save you from watching twenty-minute talks. I hope they help you start where the talks ended.

[TBC] [███████████████████░░░░░░░░░░░░░░░░░░░░░] 19/40