Fluid UI: Making Web Apps Feel Native

Frame.io's users are video professionals who notice the slightest hitch in playback or interface response. The company’s product engineering team describes this as "seeing in milliseconds"—a perceptual standard that forces them to treat application feel as a first-class requirement, not an afterthought. For an Adobe company whose users juggle high-resolution content, a web app that stutters or lags is functionally broken, even if every feature works.

That realization pushed Frame.io away from the common "make it work, make it right, make it fast" sequence. Instead, the team adopted a principle that inverts the usual priority order: How it feels equals how it works. Charlton Roberts, Senior Manager of Product Engineering at Frame.io, frames performance as a feature in itself: if the interface doesn’t feel good to interact with, it isn’t working, regardless of underlying correctness.

Three Pillars of Fluid UI

Frame.io calls its framework for building responsive interfaces Fluid UI, a concept inspired by Apple’s "Designing Fluid Interfaces" session from WWDC 2018. The approach rests on three pillars that guide every UI decision:

  • Instant: The interface must acknowledge user input within 100ms. To hit this threshold, Frame.io relies on React hooks like useState and useOptimistic for immediate state feedback, alongside the Next.js Router Cache. Developers trim unnecessary component re-renders using useMemo and useCallback.
  • Smooth: Animation must hold a steady 60 fps, matching the fluidity of natural motion. The team leverages React’s useTransition Hook, prefers CSS-only animation solutions wherever feasible, and builds UI components with stable structure to limit DOM churn.
  • Coordinated: Related UI elements should move as one unit, so transitions feel like extensions of the user’s gesture rather than disconnected effects. This requires deliberate orchestration of timing and easing across linked components to preserve a coherent visual narrative.

To apply these principles consistently, Frame.io standardized on the Next.js App Router and uses Vercel’s platform for hosting and performance oversight.

Catching Regressions Before Users Do

Shipping under Fluid UI standards demands early detection of performance decay. Frame.io uses Vercel’s automatic Preview Deployments to test each code change in a production-like environment before merge. This workflow previously cost them up to 40 minutes per preview cycle; Vercel cut that latency by over 6x, bringing previews live in roughly 6 minutes. Faster previews mean performance analysis happens early, when regressions are still cheap to address.

“A lot of the value we get from Vercel is things we don't have to think about. Initial load performance is just as important as interaction performance, but we spend so much less time thinking about load performance because of the optimizations Vercel offers us.”

Charlton Roberts, Senior Manager of Product Engineering at Frame.io

The team also dogfoods its own product: they record screen sessions and analyze them frame-by-frame inside Frame.io to isolate performance bottlenecks. This self-referential feedback loop turns subjective "feel" complaints into concrete, addressable engineering problems.

Architecting for Scale Without the SRE Tax

Fluid UI dictates more than animation curves. Frame.io’s engineering approach is guided by an "instant and infinity" philosophy—designing for massive future datasets from day one so the application can scale to millions of items without compromising interaction speed. This forward-looking stance is paired with a pragmatic division of labor: infrastructure concerns that formerly consumed weeks of SRE collaboration are now handled out of the box by Vercel.

Vercel’s global Edge Network, static asset revalidation, and straightforward cache header configuration offload the burden of load-time optimization. Roberts notes that this lets product engineers concentrate on features without neglecting initial load performance, a trade-off that would otherwise require significant platform-level investment.

Ruthless prioritization also plays a role. Because every feature addition has a performance cost, the engineering team defers noncritical tasks to preserve the application’s responsiveness under load. They also preload data and resources ahead of user interaction, and offload heavy computation from the main thread to avoid jank and protect core web vitals like Cumulative Layout Shift.

Deploying Without Disruption

Continuous improvement only works if updates don't disrupt the user base. Frame.io ships thousands of concurrent users through a deployment pipeline that cannot afford downtime. They gate releases behind feature flags, rolling out new functionality only after it clears performance standards. Routine audits using Vercel Speed Insights or Conformance catch regressions before they compound.

For larger rollouts, Vercel’s Skew Protection mitigates version mismatch risks during deployment, allowing Frame.io to transition seamlessly between API versions without shedding active sessions. This safety net lets the team release frequently and with confidence, knowing users will experience minimal interruption.

The underlying lesson extends beyond Frame.io’s specific stack: for interface-heavy applications, performance engineering is not a separate track from product development. By tying every architectural decision to a measurable feel threshold—instant, smooth, coordinated—and investing in tooling that automates performance scrutiny, teams can build web applications that rival the responsiveness of their desktop counterparts.