Open to offers Middle+ Frontend / Fullstack · Moscow or remote
Qwern_9876r
I make complex systems stable and fast and scalable
I started programming at 14, and at 15 graduated from Yandex School of Interface Development — its youngest student in 12 years — before starting my career at Yandex as a frontend developer at 16. I handled complex technical challenges — from optimizing interface performance to designing large-scale projects. I write high-performance, maintainable code and always look beyond the immediate task: I think about how a solution affects the product and the business as a whole. I take initiative, see work through to completion, and do not wait to be told what to do. In my spare time I build Rook, my own programming language that compiles to JavaScript and runs it on every CPU core.
Yandex
MTSI write code that does not just work — it works fast. I optimize rendering, bundle size, network requests, and response time. Lighthouse metrics, Core Web Vitals, and profiling are a required part of the work, not an option.
I do not wait for tasks to be assigned — I find problems and propose solutions myself. I take on complex, uncertain tasks and see them through without constant supervision. I work autonomously and take responsibility for the result.
+53% DAU
I look at tasks through a business lens: I assess the long-term impact of technical decisions, avoid overengineering, and focus on what creates real value for the product and its users.
+32.5% Profit
+31% E-REACH
TypeScript · HTML5 · CSS3 · SCSS
Strict typing, generics, utility types, decorators
Semantic markup, accessibility, SEO
Animations, grid, custom properties, optimization
Mixins, variables, style architecture
React 19 · Next.js 16 · MUI · TanStack Query
Hooks, Suspense, Server Components, render optimization
App Router, SSR, SSG, ISR, middleware
Material UI, styled components
Query, Mutation, Infinite Query, Optimistic Updates
Pixi · Three.js · Rive · Lottie
WebGL, WebGPU, complex graphical interfaces
WebGL, complex graphical interfaces
Interactive animations, wasm
Graphics, complex animations
Lit · Custom Elements
Reusable web component development
Storybook · Jest · Playwright
UI documentation, isolated component development
Unit and integration testing
E2E testing, cross-browser compatibility
Go · Node.js · Echo 4 · Fastify
Concurrency, performance, REST API
Node.js, REST API
Routing, middleware, validation, error handling
Fastify, REST API
MongoDB · PostgreSQL
Document-oriented data, aggregations
Relational data, indexes, complex queries
Docker · Kubernetes · Nginx · Kafka
Application containers, dependency isolation
Container orchestration, automatic scaling
Reverse proxy, load balancing, caching
Stream processing, message queues
Click an icon to visit the technology website
Yandex and MTS
Moscow
Promoted in 3 months
Summer 2024 campaign · a product with millions of users
The task was to add a small animation to the home page without any designs.
Turned the animation into a mini-game
Significantly improved the animation and added interaction
Optimized it
Lazy loading and animation-level performance work: it ran smoothly even on older phones
Came up with a reward mechanic
Interacting with the animation earned a symbolic reward
Marketing picked it up
The mini-game attracted many daily users, and a summer campaign with bloggers was built around it
I significantly improved the animation, added interaction, and optimized it with lazy loading and animation-level performance work. It ran smoothly even on older phones. I also introduced a symbolic reward for interacting with it. Although the product was not related to entertainment, the mini-game attracted many daily users and increased product engagement. Management and marketing built a summer campaign around this unexpected success, with many bloggers taking part. I turned a small animation into the summer's killer feature with millions of engaged users.
A new game page built solo by the deadline
One of three frontend developers moved to another team and another went on extended leave. The managers brought in a large project with a very tight deadline.
A new page with game mechanics
Game mechanics and rewards
A new stack for the project
Server Components and REST API instead of GraphQL
Learned Rive from scratch
An interactive layer on Rive, never used in the project before
Delivered solo on time
My Rive component became the foundation for the team and Yandex Plus
I built a new page with game mechanics and rewards, introduced Server Components and REST API, and used Rive for the interactive layer. I learned the unfamiliar tools while working part-time and delivered the project alone by the deadline. The resulting Rive example and reusable component became the foundation for future Rive integrations across the team and Yandex Plus.
May 2026, my first month at MTS. Model weight after compression in October 2026, gzip
For new projects at MTS we had to decide whether Svelte + Threlte + Pixi.js was the right stack: could it handle 3D, 2D effects and UI in one app, and how fast could we build with it.
The task: choose a stack
Would Svelte + Threlte + Pixi.js work for new MTS projects: 3D, 2D effects and UI in one app
A game instead of a demo
A browser 3D game in 4 days: a forest with mushrooms, a greenhouse with a cauldron, potions
Three layers in one frame
3D scenes on Threlte, Pixi.js particles on top, UI and state on Svelte 5
The stack was adopted
After the test, the stack was chosen for new projects
Models 8× lighter
gltf-transform and meshopt: 9.7 MB on start instead of 76.4
To test the stack on a real task rather than a demo, I built Alchemy Terrarium in 4 days: a browser 3D game where you gather mushrooms in a forest and brew potions from them in a cauldron in a greenhouse. The 3D scenes run on Threlte (three.js), particle effects on Pixi.js on top of the 3D, the UI and game state on Svelte 5 — all in TypeScript and SvelteKit with a static build. The stack proved itself and was adopted for new projects. Later I compressed the game's 3D models with gltf-transform and meshopt: it now loads 9.7 MB on start instead of 76.4 MB.
Build measurements, gzip
A portfolio of a developer whose main argument is performance. The site itself has to be the proof: 3D, animations, and interactivity — while still flying on any phone.
SvelteKit with prerendering
Every page is ready-made HTML; the first screen ships only the JS it needs
3D with no weight at start
The Threlte prism and Pixi scenes load after the page and render frames only while animating
The site measures itself
Live metrics in the visitor's browser via the Performance API, no libraries
A PWA with no extra traffic
The service worker caches only what the visitor has already downloaded
The site was rewritten from React to SvelteKit with prerendering: every page is ready-made HTML, and the first screen ships only the JS it needs. The Threlte prism and Pixi scenes load after the page and render frames only while animating, then fall asleep at rest. The metrics in “Why me” are live measurements in the visitor's browser via the Performance API. A service worker makes the site a PWA and caches only what the visitor has already downloaded.
Numbers from the repository: go for as measured on the docs home page, goroutines from the docs example in Node; both on a 14-core Apple M4 Pro
func isPrime(n number) bool {
for let d = 2; d * d <= n; d++ {
if n % d == 0 {
return false
}
}
return n > 1
}
const primes = make([]uint8, 10_000_000)
go for i, _ in primes {
primes[i] = isPrime(i) ? 1 : 0
}func isPrime(n number) bool {
if n < 2 {
return false
}
for let d = 2; d * d <= n; d++ {
if n % d == 0 {
return false
}
}
return true
}
func countPrimes(from, to number) number {
let count = 0
for let n = from; n < to; n++ {
if isPrime(n) {
count++
}
}
return count
}
const PART = 1_000_000
const parts = Array(10).fill(0).map((_, i) => go countPrimes(i * PART, (i + 1) * PART))
console.log((await Promise.all(parts)).reduce((a, b) => a + b, 0))comp Counter(start number) {
state count = start
return <button onClick={count++}>Clicked {count} times</button>
}
document.body.append(<Counter start={0} />)The same loop, one word longer: go for splits the array into parts, several per core, and runs them as goroutines on whichever cores are free. On the 14 cores of an Apple M4 Pro it is 8.1 times faster than one thread.
go runs countPrimes in a worker, a thread on a core of its own, and gives a Promise of the result; the compiler sends isPrime along by itself. Ten goroutines count the primes below 10 million 5.4 times faster than one thread.
The whole component: after count++ the compiler updates the button text by itself — no virtual DOM, no library.
JavaScript runs on one thread: a heavy computation takes one core and blocks everything else, while Web Workers need separate files, postMessage and copying data by hand. I wanted to write parallel code as simply as in Go — with strict types and without paying for the convenience in the bundle.
Goroutines on real threads
go f(x) runs a function in a pool of workers, one per core, and gives a Promise of the result
go for: a loop on every core
The array is split into parts, several per core, and each runs on the first free one: ×8.1 on 14 cores
Channels and select
Goroutines on different threads pass values through channels, wait on several at once and time out, as in Go
Types that know about threads
The compiler moves the functions a worker needs by itself and checks before the run that the data can be copied to another thread
TypeScript and npm interop
Types of packages and the DOM come from .d.ts files, and the compiler writes .d.ts for its own modules
Tooling around the language
An npm package, a CLI, a Vite plugin, a VS Code extension and docs with a playground, written in Rook itself
I built Rook, a language with JavaScript semantics, Go syntax and static types, focused on speed and concurrency. go f(x) runs a function as a goroutine in a pool of Web Workers or worker threads, one thread per core, and gives a Promise of the result; channels, select, after and tick work as in Go. go for is the same loop over an array, one word longer: the array is split into parts, several per core, and each runs on the first free core. On the 14 cores of an Apple M4 Pro such a loop is 8.1 times faster than one thread. The compiler moves the function and everything it uses into the worker by itself and checks before the program runs that what goes to another thread can be copied there: a function, a class instance or a DOM element cannot be sent. The compiler is written in TypeScript: a lexer, a parser and a type checker with generics, union types, null safety and narrowing. It reads the types of npm packages and the DOM from .d.ts files and writes .d.ts files for Rook modules, so the language works with any npm library in both directions. Code compiles to readable JavaScript with a small runtime for channels and goroutines, imported by name; components compile to direct DOM calls, with no virtual DOM. Around the language there is the rooklang npm package, a CLI, a Vite plugin, a VS Code extension and documentation written in Rook itself, with a playground right in the browser.