A Story about Scaling Front-End Platforms at Grammarly
summary
Grammarly moved sidebar and inline cards into shared React component libraries inside a cluster monorepo using Beasel, reusing them across web and extension clients and reducing editor-specific code to about 20%, enabling the sidebar to ship in months. They also adopted a Server-Driven UI to provide stable card layouts and faster experiments; SDUI worked well for stable elements while a webview approach sped cross-platform releases but introduced a fragile native bridge and extra operational overhead.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 1:23Front-end scaling story
- 3:30Independent app challenges
- 5:55Unifying client apps
- 7:18Shared libraries
- 9:09App modularization
- 10:35Monorepo cluster
- 12:41Unification results
- 13:03Multi-platform expansion
- 15:15Multi-platform motivation
- 17:25Server Driven UI
- 21:43Server Driven UI pros/cons
- 23:07Server Driven UI challenges
- 25:22Server Driven UI limits
- 28:14Server Driven UI vs native
- 30:27WebView for faster dev
- 33:20WebView benefits/challenges
- 36:15Current platform state
- 37:19Future plans
- 39:03Client platforms retrospective
- 41:10Q&A: Monorepos & versioning
- 44:03Q&A: Versioning & orchestration
- 46:39Q&A: Mobile apps & WebView
- 49:12Q&A: Native components
- 50:57Summary
related talks
23mFront-End Platform Engineering
42mThe story of declarative React at Grammarly: two-way data binding with Focal
14mMicro-frontends: Is it a Silver Bullet?
26mFrontend At Scale - Experiences Using React In A Large Organization
37mCollaborative Real-Time Text Editing: A Front-End Case Study
30mMicro Frontends in React — a State of the Art Approach
19mLessons from adopting React Compiler
22mBreak Up With Your Frontend Monolith