React from Scratch
Re-implementation of React
React from Scratch
Re-implementation of React
React from Scratch
A complete re-implementation of React w/ custom architecture, and a blog post describing it in detail
Overview:
I implemented the core functionality of React (rendering, reconciliation, hooks) without referencing React's implementation. The goal was to understand how the abstractions were implemented, and the motivations behind them.
Linked above is a blog post going over my thought process when making this to share the intuitions I built.
React Scan
Visualize re-renders in your react app
React Scan
Visualize re-renders in your react app
React Scan
A script that hacks into react-internals to provide visualizations of re-renders, a real time component inspector tool, and an always on component render time profiler
Overview:
Built the component inspector tool. This tool allows you to select any component, view its props/state/context, and view in real time diffs of what props/state/context changed.
Implemented the runtime to efficiently draw render outlines to the screen. This ended up requiring lots of hacks to have no overhead on user application, like asynchronously reading DOM layout, interpolating outlines to give the illusion of max FPS outline updates, and aggregation techniques so memory scales O(1) w.r.t outline.
Implemented the notification system for react-scan to detect slow performance, and visualize what happened. The hardest part of this was developing a browser independent script to accurately collect data about the browser rendering pipeline, allowing react-scan to know precisely how long every frame spent on JavaScript, React renders, frame preparation, frame constructing, and frame drawing (compositing, rasterization).
Implemented React Scan for React Native.
Session Replay (for performance problems)
Visually enhanced session replays, offline app simulations, session replay to mp4 server, replay search engine
Session Replay (for performance problems)
Visually enhanced session replays, offline app simulations, session replay to mp4 server, replay search engine
Session Replay (for performance problems)
A comprehensive system for detecting performance problems, collecting session replays, analyzing performance problems, and recommending the videos to users
Overview:
This system can be split up roughly into:
The end result is a script you throw in the background of your app. This script automatically collects videos of when your app is slow, and surfaces the videos in the frontend. The video player tells you what the root problem of the performance issue was, so you do not need to reproduce the problem to know the root problem.
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
Overview:
AlgoViz implements a custom playground designed specifically for constructing graphs that you would see in an algorithms class (as the motivation was a tool for a DSA class).
Next to the graph builder is a code editor, where you can implement algorithms. These algorithms are executed on a remote sandboxed server, and visualized directly on the graph built.
You can step through each iteration of the algorithm to see how it traverses the graph.
AlgoViz also implements a heap inspector that allows you to view the real time state of all your variables at every step of your algorithm.
AlgoViz is entirely multiplayer (blog post about implementing a multiplayer infinite canvas). You can share playgrounds with other people, and the state of the whiteboard will be synced in real time with all other members.
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Overview:
Fireside is a culmination of technologies I wanted to learn deeply.
Fireside implements P2P audio broadcasting through WebRTC. This implementation allows for m->n audio broadcasting, where hosts can broadcast audio to any number of participants.
Transcription is performed on device through a WASM'd version of OpenAI Whisper. Since the transcription is collected locally, it's then broadcasted to users in realtime. This means both the audio broadcasting and transcription is near 0 overhead for the backend.
The transcription recorded and user chat messages are sent to a Mistral model, where it autonomously creates threads in the app to answer user questions. The motivation is professors can't answer all questions students have during lectures, and most of the time the question was answered by something the professor just said.
The app importantly implements a real time canvas that supports image upload, drawing, and embedding the canvas directly into chat messages. The specific motivation for the app was to allow professors to visualize drawings for students directly in the website. It also allows students to quickly send hand drawn diagrams when asking questions.
And of course, real time chat messages, threads, reactions, friend requests and DMs.
Trace Tool
An assessment platform for language agnostic memory diagrams
Trace Tool
An assessment platform for language agnostic memory diagrams
Trace Tool
An educational tool for teaching and testing understanding of memory management and data structures.
Overview:
Trace tool is an application I built (along with Zaid) for my university (University at Buffalo). It's used by multiple courses and thousands of students to assess students' understanding of the underlying memory of programs during execution.
This is one of my most proud projects I've worked on since it was the first time I owned an entire user experience end-to-end.
The most important feature of the trace tool is a general editor for representing language agnostic memory layouts. We need to represent scopes, reclaiming memory, stack frames, heap objects, the relationship between variables, objects, and IO.
The quiz platform itself is split up into 2 sections: Student (to take quizzes) and Instructor (manage quizzes).
On the student side, the trace editor is applied to a quiz taking experience. This is surprisingly hard. You need to not add stress to an already stressful experience (taking a quiz). This means having support for things like undo/redo state, drag and drop support, and reliable (and optimistic) autosaves that can never get out of sync with server.
Another large consideration is security. Students will try to cheat, try to access quizzes they shouldn't try to access, access quizzes at the wrong time, submit when they aren't finished, need to go back and edit the quiz, access other students' quizzes. There's an endless list of requirements which need to be validated on the client AND server for optimal UX. This complexity can only be contained with a composable and testable permissions system, which was implemented with tRPC middleware, SQLite (SQLite makes testing... fun), React Suspense + TanStack Suspense queries, and error boundaries. I need an entire writeup to explain the approach taken, but the correct technology choices were extremely important.
The student implementation is only half the app. Instructors also need to create assessments, grade students, manage submissions, create solutions, receive automatically generated solutions and 100 other things to meet requirements. This is a little more boring so I won't get into the details, but the same intuitions from the student side apply. A robust permission system is still crucial to avoid data leaks.
We have a paper to-be-published describing the application's motivations and solutions.
Million Lint Profiler
A real time React profiler directly in a VSCode extension
Million Lint Profiler
A real time React profiler directly in a VSCode extension
Million Lint Profiler
A React profiler and component tree that visualizes slow components directly inside a VSCode extension
Overview:
This one was hard. I'll break up the feature into distinct parts:
Babel Plugin
We have a Babel plugin that injects our profiling code into the user's React code. This allows us to get precise timings on component renders, hook calls, and render data. We can tie all this data back to source code trivially.
JavaScript Runtime
We ship a JavaScript runtime that hooks into React internals to track the life cycle of component renders. This is also what allows us to generate visualizations of the fiber tree.
All this data needs to be sent over the network to our extension. The fiber tree (React's runtime representation of components that have been rendered) can be massive, and updated extremely quickly. It's unfeasible to send the entire fiber tree every render, so I had to develop an efficient algorithm that syncs the runtime fiber tree to the fiber tree representation we had stored on the extension. This algorithm sends compressed fiber tree nodes as patches over a WebSocket connection.
This algorithm must run in the hot path of user code when rendering, so it needed to have tight runtime complexity guarantees to avoid destroying performance on large applications (scale linear w.r.t size of fiber tree).
The runtime to sync the fiber tree also needed to self heal if it got out of sync with server state.
Compiler server
Every time the user spins up a dev server, our build plugin spins up a TCP server next to the user's dev server. This makes WebSocket and HTTP connections with the JavaScript runtime. It acts as a proxy to the extension.
The compiler server must handle M runtime connections from tabs open with the user website, and then connect to N extensions - as a user may have multiple projects open.
To support real time profiling, we needed to implement synchronization primitives between the extension and the JavaScript runtime on the compiler server. There are lots of UX considerations, for example, should you accept profiling updates from a tab the user is not focused on?
VSCode webview
How are we able to render this pretty profiling view in VSCode? VSCode supports webviews, which means we can run any JavaScript that can run on the web to visualize data. One problem with webview is that we lack native APIs to access things like file system while in webview, since it's just an iframe. So we needed to implement an RPC layer between the iframe and native layer. The webview is just a normal React application, which listens to a store for updates. These updates are pushed by the native layer that receives updates from the compiler server.
TLDR
We send React internal data over a WebSocket connection to a VSCode extension, which is just a React app :)
React from Scratch
Re-implementation of React
React from Scratch
Re-implementation of React
React from Scratch
A complete re-implementation of React w/ custom architecture, and a blog post describing it in detail
Overview:
I implemented the core functionality of React (rendering, reconciliation, hooks) without referencing React's implementation. The goal was to understand how the abstractions were implemented, and the motivations behind them.
Linked above is a blog post going over my thought process when making this to share the intuitions I built.
Session Replay (for performance problems)
Visually enhanced session replays, offline app simulations, session replay to mp4 server, replay search engine
Session Replay (for performance problems)
Visually enhanced session replays, offline app simulations, session replay to mp4 server, replay search engine
Session Replay (for performance problems)
A comprehensive system for detecting performance problems, collecting session replays, analyzing performance problems, and recommending the videos to users
Overview:
This system can be split up roughly into:
The end result is a script you throw in the background of your app. This script automatically collects videos of when your app is slow, and surfaces the videos in the frontend. The video player tells you what the root problem of the performance issue was, so you do not need to reproduce the problem to know the root problem.
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Fireside
Real time question board with P2P audio, multiplayer canvas, on device audio transcription, LLM TA
Overview:
Fireside is a culmination of technologies I wanted to learn deeply.
Fireside implements P2P audio broadcasting through WebRTC. This implementation allows for m->n audio broadcasting, where hosts can broadcast audio to any number of participants.
Transcription is performed on device through a WASM'd version of OpenAI Whisper. Since the transcription is collected locally, it's then broadcasted to users in realtime. This means both the audio broadcasting and transcription is near 0 overhead for the backend.
The transcription recorded and user chat messages are sent to a Mistral model, where it autonomously creates threads in the app to answer user questions. The motivation is professors can't answer all questions students have during lectures, and most of the time the question was answered by something the professor just said.
The app importantly implements a real time canvas that supports image upload, drawing, and embedding the canvas directly into chat messages. The specific motivation for the app was to allow professors to visualize drawings for students directly in the website. It also allows students to quickly send hand drawn diagrams when asking questions.
And of course, real time chat messages, threads, reactions, friend requests and DMs.
Million Lint Profiler
A real time React profiler directly in a VSCode extension
Million Lint Profiler
A real time React profiler directly in a VSCode extension
Million Lint Profiler
A React profiler and component tree that visualizes slow components directly inside a VSCode extension
Overview:
This one was hard. I'll break up the feature into distinct parts:
Babel Plugin
We have a Babel plugin that injects our profiling code into the user's React code. This allows us to get precise timings on component renders, hook calls, and render data. We can tie all this data back to source code trivially.
JavaScript Runtime
We ship a JavaScript runtime that hooks into React internals to track the life cycle of component renders. This is also what allows us to generate visualizations of the fiber tree.
All this data needs to be sent over the network to our extension. The fiber tree (React's runtime representation of components that have been rendered) can be massive, and updated extremely quickly. It's unfeasible to send the entire fiber tree every render, so I had to develop an efficient algorithm that syncs the runtime fiber tree to the fiber tree representation we had stored on the extension. This algorithm sends compressed fiber tree nodes as patches over a WebSocket connection.
This algorithm must run in the hot path of user code when rendering, so it needed to have tight runtime complexity guarantees to avoid destroying performance on large applications (scale linear w.r.t size of fiber tree).
The runtime to sync the fiber tree also needed to self heal if it got out of sync with server state.
Compiler server
Every time the user spins up a dev server, our build plugin spins up a TCP server next to the user's dev server. This makes WebSocket and HTTP connections with the JavaScript runtime. It acts as a proxy to the extension.
The compiler server must handle M runtime connections from tabs open with the user website, and then connect to N extensions - as a user may have multiple projects open.
To support real time profiling, we needed to implement synchronization primitives between the extension and the JavaScript runtime on the compiler server. There are lots of UX considerations, for example, should you accept profiling updates from a tab the user is not focused on?
VSCode webview
How are we able to render this pretty profiling view in VSCode? VSCode supports webviews, which means we can run any JavaScript that can run on the web to visualize data. One problem with webview is that we lack native APIs to access things like file system while in webview, since it's just an iframe. So we needed to implement an RPC layer between the iframe and native layer. The webview is just a normal React application, which listens to a store for updates. These updates are pushed by the native layer that receives updates from the compiler server.
TLDR
We send React internal data over a WebSocket connection to a VSCode extension, which is just a React app :)
React Scan
Visualize re-renders in your react app
React Scan
Visualize re-renders in your react app
React Scan
A script that hacks into react-internals to provide visualizations of re-renders, a real time component inspector tool, and an always on component render time profiler
Overview:
Built the component inspector tool. This tool allows you to select any component, view its props/state/context, and view in real time diffs of what props/state/context changed.
Implemented the runtime to efficiently draw render outlines to the screen. This ended up requiring lots of hacks to have no overhead on user application, like asynchronously reading DOM layout, interpolating outlines to give the illusion of max FPS outline updates, and aggregation techniques so memory scales O(1) w.r.t outline.
Implemented the notification system for react-scan to detect slow performance, and visualize what happened. The hardest part of this was developing a browser independent script to accurately collect data about the browser rendering pipeline, allowing react-scan to know precisely how long every frame spent on JavaScript, React renders, frame preparation, frame constructing, and frame drawing (compositing, rasterization).
Implemented React Scan for React Native.
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
AlgoViz
A multiplayer graph builder, code executor, algorithm visualizer
Overview:
AlgoViz implements a custom playground designed specifically for constructing graphs that you would see in an algorithms class (as the motivation was a tool for a DSA class).
Next to the graph builder is a code editor, where you can implement algorithms. These algorithms are executed on a remote sandboxed server, and visualized directly on the graph built.
You can step through each iteration of the algorithm to see how it traverses the graph.
AlgoViz also implements a heap inspector that allows you to view the real time state of all your variables at every step of your algorithm.
AlgoViz is entirely multiplayer (blog post about implementing a multiplayer infinite canvas). You can share playgrounds with other people, and the state of the whiteboard will be synced in real time with all other members.
Trace Tool
An assessment platform for language agnostic memory diagrams
Trace Tool
An assessment platform for language agnostic memory diagrams
Trace Tool
An educational tool for teaching and testing understanding of memory management and data structures.
Overview:
Trace tool is an application I built (along with Zaid) for my university (University at Buffalo). It's used by multiple courses and thousands of students to assess students' understanding of the underlying memory of programs during execution.
This is one of my most proud projects I've worked on since it was the first time I owned an entire user experience end-to-end.
The most important feature of the trace tool is a general editor for representing language agnostic memory layouts. We need to represent scopes, reclaiming memory, stack frames, heap objects, the relationship between variables, objects, and IO.
The quiz platform itself is split up into 2 sections: Student (to take quizzes) and Instructor (manage quizzes).
On the student side, the trace editor is applied to a quiz taking experience. This is surprisingly hard. You need to not add stress to an already stressful experience (taking a quiz). This means having support for things like undo/redo state, drag and drop support, and reliable (and optimistic) autosaves that can never get out of sync with server.
Another large consideration is security. Students will try to cheat, try to access quizzes they shouldn't try to access, access quizzes at the wrong time, submit when they aren't finished, need to go back and edit the quiz, access other students' quizzes. There's an endless list of requirements which need to be validated on the client AND server for optimal UX. This complexity can only be contained with a composable and testable permissions system, which was implemented with tRPC middleware, SQLite (SQLite makes testing... fun), React Suspense + TanStack Suspense queries, and error boundaries. I need an entire writeup to explain the approach taken, but the correct technology choices were extremely important.
The student implementation is only half the app. Instructors also need to create assessments, grade students, manage submissions, create solutions, receive automatically generated solutions and 100 other things to meet requirements. This is a little more boring so I won't get into the details, but the same intuitions from the student side apply. A robust permission system is still crucial to avoid data leaks.
We have a paper to-be-published describing the application's motivations and solutions.