Jakub 'Urbik' Urbanec

Web developer | DJ | Hovawart daddy

00 / ABOUT

Developer, DJ and explorer of digital things

Hello, I’m Jakub Urbanec — a Prague-based web developer and DJ performing under the name Urbik.

I have spent more than a decade working with the web, primarily on front-end applications, while continuously experimenting with graphics, games, audio, interaction and other areas where programming becomes more than just forms and buttons.

Outside software development, music is a major part of my life. I have been collecting electronic music and DJing for many years, playing mainly drum and bass, halftime, jungle and other forms of underground bass music.

Urbik performing at Dark Atmo Breaks
Urbik / Dark Atmo Breaks
Prague
Base
Czech Republic
10+
Development
years professionally
FE
Primary field
Front-end engineering
Urbik
DJ name
Alternative bass
01 / PROFILE

Three important parts of my life

01

Web development

I build modern web applications with JavaScript and TypeScript, primarily using React, Vue, Next.js and Nuxt.

I enjoy solving architecture, performance and interaction problems rather than treating front-end development purely as UI implementation.

02

Music

As Urbik, I play alternative electronic music with a strong focus on drum and bass, halftime, modern jungle and deeper experimental sounds.

I previously organized the Dark Atmo Breaks and BrainStorm club nights and currently focus primarily on DJing, mixes and musical exploration.

03

Jupiter

I am also the owner of Jupiter — Jupík — a golden hovawart and a fairly substantial part of my everyday life.

Hovawarts are large, intelligent working dogs, so living with one provides a useful counterbalance to spending too much time in front of a computer.

Offline mode

Away from the screen

When I am not programming, I am usually listening to music, preparing DJ sets, looking for new releases or spending time outside with Jupiter.

I am naturally drawn to things that involve exploration — whether that means discovering an unusual record, understanding how a browser renders graphics, experimenting with a new API or finding a new place during a long walk.

Jakub with Jupiter the hovawart
01 / DEVELOPER

Basic developer info

I am proficient in Vue as well as React, capable of working with framework ecosystems and component libraries, as well as developing new components, handling complex data transformations and integrating applications with APIs primarily through REST and WebSockets. I also have experience with build processes, deployment, debugging, performance optimization and more complex algorithms.

I have been working with TypeScript for about 4 years and Vue for around 5 years. I first used React professionally later than Vue, but I am comfortable working with both ecosystems. Altogether, I have approximately 13 years of experience with JavaScript.

Beyond conventional front-end development, I am strongly interested in computer graphics and interactive browser experiences. I have spent a significant amount of time working with Canvas 2D, animation, particles, compositing and real-time rendering, while also gradually expanding my knowledge of WebGL and GPU-based graphics.

I am also capable of working with JavaScript and TypeScript on the backend using Node.js at a solid level, although I consider front-end engineering, browser technologies and graphics to be my main areas of specialization.

Outside of work, music is probably my biggest interest. I perform as a DJ under the name Urbik, and I also have a large golden hovawart named Jupiter.

02 / PORTFOLIO

This portfolio webpage

Link to the repository: repository with extensive README.md

One of the reasons behind this portfolio is to present my work while also using the project as a place where I can experiment with web programming outside the constraints of commercial development.

From the technical side, one of my goals was to use a minimal number of libraries while keeping the application written in TypeScript and separating the front end and back end. The backend is deliberately simple and mainly provides server-side rendering using functionality shared with the front-end source.

The front end experiments with lower-level concepts normally hidden behind modern frameworks. One example is the use of JavaScript Proxy to implement a small reactive store. Rather than building another application entirely around an existing framework, I wanted to look underneath some of the abstractions I use professionally every day.

A major part of the visual identity of the portfolio comes from my separate generative graphics project Eraser. Integrating Eraser with the portfolio also created an interesting development challenge: keeping the visual system in its own project while maintaining a good development experience between both repositories and their shared environment.

03 / ERASER

Generative visual project

Eraser is my long-term generative visual project and probably the clearest connection between my interests in programming, computer graphics and music. It originally developed alongside my DJ work and takes its name from my original mix Eraser, which won a competition organized by Decoded Magazine.

The visual explores transformation, distortion and the boundary between recognizable shapes and abstraction. Elements can appear structured or almost organic for a moment and then dissolve, collide or become unstable. I am interested in creating something that feels generated by a system while still having a strong visual character rather than looking like a conventional screensaver or visualization.

Technically, Eraser is a real-time browser graphics experiment built from multiple rendering layers. The current visual combines WebGL with two Canvas 2D layers. Much of the visual complexity comes from large numbers of particles, transparency, blending and different compositing operations.

Keeping a substantial part of the project in Canvas 2D is intentional. I like the API and the flexibility of its compositing model, even though this also makes performance one of the most challenging parts of the project. Large transparent areas, particle rendering and multiple stacked canvases can become expensive, especially at high resolutions.

Because of that, Eraser has also become a practical playground for investigating how browsers actually render graphics. I have spent a lot of time profiling frame rendering, reducing unnecessary drawing, experimenting with batching and state changes, studying alpha and composite-operation costs and looking at the interaction between CPU rasterization, GPU acceleration and the browser compositor.

  • Multi-layer real-time rendering using WebGL and Canvas 2D
  • Particle systems, transparency and compositing
  • Procedural and generative visual behaviour
  • Browser rendering and frame-rate optimization
  • Experimentation with the boundary between 2D raster graphics and GPU rendering
  • Integration as the main generative visual layer of this portfolio

The project continues to evolve as I learn more about browser graphics. My current direction is to keep exploring what can be achieved with Canvas 2D while gradually introducing more GPU-driven techniques through WebGL and, eventually, WebGPU where they make sense.

04 / GAMES

Game development

I have loved games since childhood, and they were one of the reasons I became interested in programming in the first place. When I started learning web development around 15 years ago, one of my first larger projects was a D&D-inspired browser game built using PHP 5, JavaScript, jQuery and XHR.

I originally imagined that game development might eventually become a career. As the industry and the complexity of modern games grew, however, I followed web development professionally instead. Game development nevertheless remained one of my hobbies and an important reason for my continuing interest in graphics, animation and interactive systems.

I experimented with several smaller games, with two projects becoming presentable enough to mention here. The first is a simple Asteroids-like browser game built with JavaScript, Canvas and EaselJS. The second is Quarantine Zone: Warfare, a mobile top-down shooter developed with Solar2D.

Quarantine Zone: Warfare eventually grew into a considerably more ambitious project. It has never been publicly released and remains a work in progress, but developing it taught me a lot about game loops, object management, animation, interaction and designing systems that have to operate continuously in real time.

01 / BIO

Music Bio

Beyond programming, music has always been one of the most important parts of my life. I perform under the name Urbik and have been collecting electronic music and DJing for well over a decade.

What started as an obsession with discovering new records gradually developed into regular club performances, radio appearances, DJ competitions, guest mixes and eventually my own event series.

My musical roots are primarily in drum and bass. I discovered the genre during the period when drum and bass was becoming increasingly visible in Prague, and over time I became much more interested in its less conventional edges than in its mainstream forms. That gradually led me towards deeper drum and bass, autonomic, halftime, modern jungle, experimental bass music and other sounds built around broken rhythms.

Urbik performing at Let It Roll
Urbik / Let It Roll Winter Warm Up

I am especially interested in music that has a strong individual character: unusual rhythm, atmosphere, sound design or structure. I do not approach DJing as simply playing a sequence of recognizable tracks. For me, selection is the most important part of the process. I enjoy finding music that is overlooked, connecting records from different scenes and periods, and building sets that have their own identity.

A major turning point came around 2022, when I started performing regularly in Prague clubs and became much more involved in the local scene. During that period I won several DJ contests, started receiving more bookings and eventually founded my own club nights, Dark Atmo Breaks and BrainStorm.

Although drum and bass remains the center of my musical identity, I do not want my sets to be limited by genre labels. Depending on the context, I can move through 170 BPM jungle, halftime, autonomic, broken beat, bass music, techno-influenced material and slower experimental electronics. The common element is usually rhythm, atmosphere and music that does not immediately reveal everything about itself.

02 / SOUND

My Sound

My sets are usually rooted in bass and breaks, but I am more interested in a particular feeling than in maintaining a strict genre definition. I tend to look for music that sits somewhere between functional club music and more detailed listening music.

Within drum and bass, I am particularly drawn to the space around halftime, autonomic and modern jungle: music where rhythm can breathe, where silence and space matter, and where the relationship between percussion, sub-bass and atmosphere is often more important than constant intensity.

At 170 BPM, I like sets that can move between stripped-down rhythmic tracks, abstract sound design, deeper rollers, modern jungle and atmospheric material without becoming either relentlessly dark or overly smooth. Contrast is important to me. A set can be heavy without being aggressive all the time, and experimental without losing its physical impact.

  • Drum and bass
  • Halftime
  • Autonomic
  • Modern jungle
  • Experimental bass music
  • Breaks and broken rhythms
  • Occasional excursions into techno and slower electronic music
03 / PROMOTER

Dark Atmo Breaks & BrainStorm

My involvement in music eventually moved beyond DJing. I founded Dark Atmo Breaks and later BrainStorm as event concepts focused on music that I felt was underrepresented in the regular Prague club program.

DAB

Dark Atmo Breaks

Built around deeper, darker and more experimental approaches to drum and bass, halftime and related bass music.

BS

BrainStorm

Broadened that idea further, creating room for alternative forms of electronic music and for artists whose sets did not always fit easily into conventional genre-focused club nights.

Through these events I had the opportunity to perform together with friends, local DJs and artists such as Last Life, Heatwave and Fuj. The nights also gave me experience on the other side of club culture: programming lineups, communicating with artists and venues, promoting events and trying to create a coherent identity around a particular musical idea.

Organizing events significantly influenced how I think about DJing. A successful night is not simply a collection of individual sets. The sequence of artists, changes in energy and the relationship between different sounds can create a much larger musical narrative. That way of thinking also carries over into how I construct my own recorded and live sets.

At present, I am focusing primarily on DJing, recording mixes and developing my own musical direction rather than actively promoting regular club nights.

04 / GIGS

Selected Performances

Most of my performances have taken place in Prague and the Czech underground electronic scene, although I have also played outside Prague and been selected for international opportunities.

Shadowbox on Radio 1guest DJ appearance
Let It Roll Winter Warm Up, Pilsenwinner of the DJ contest
Dark Atmo Breaks eventspromoter and resident DJ
BrainStorm eventspromoter and resident DJ
Vzorkovnaregular performances and residency
Cross ClubPrague
Chapeau RougePrague
KlubovnaPrague
FAMUPrague
K7 and rest.artPrague
Festival VIDINY 2025Třeboň 105
Ravekjavik Festival, Polandselected through the YEAH initiative alongside artists including Bambi Uzi — eventually missed because of appendix surgery

I have also performed at smaller club nights, independent events and underground venues that are difficult to summarize in a single list. These smaller events have often been equally important to me because they provide more freedom for unusual selections and longer musical journeys.

05 / SETS

Recorded Sets & Guest Mixes

Recorded mixes are an important part of my DJ work. A club set is influenced by the room, the time of night and the audience, while a recorded mix offers much more freedom to construct a specific musical idea from beginning to end.

I enjoy preparing mixes that can function almost like self-contained pieces. Selection, sequencing and transitions are used to create a progression rather than simply demonstrating a collection of tracks. Some mixes stay tightly focused on one sound, while others deliberately connect several related styles.

Over the years I have recorded guest mixes for a number of collectives, radio projects and platforms:

Syhda Music
Dub Logic
Vykhod Sily
Rádio Punctum
Dark Atmo Breaks mix seriesown series

The Dark Atmo Breaks mix series extends the philosophy of the club night into recorded form. It gives me a place to present music I particularly value without having to adapt the selection to a specific dancefloor or event.

My mixes often contain music from producers and labels occupying the more experimental sides of drum and bass and jungle. Depending on the particular recording, this can include sparse halftime, modern jungle, atmospheric 170 BPM material, autonomic-influenced tracks and more abstract forms of bass music.

06 / SELECTION

How I Approach DJing

I see DJing primarily as curation. Technical mixing matters, but technique alone cannot make a set interesting. The most important decisions happen before and during the selection of the music itself: what to include, what to leave out, what should follow what, and how long a particular mood should be allowed to develop.

I spend a lot of time searching for music and following artists, labels and smaller scenes. Digging is therefore almost inseparable from DJing for me. I enjoy finding tracks before they become familiar, discovering older music that still sounds unusual today, and hearing relationships between records that were never necessarily intended to belong together.

I generally prefer long transitions and gradual changes when the material allows it, but I do not try to force every record into the same mixing style. Some tracks benefit from blending, others from contrast or an abrupt shift. The musical idea should determine the technique, not the other way around.

I am also interested in working outside the limitations of a traditional two-deck setup. For some recorded sets I have used VirtualDJ with four virtual decks, allowing additional layers, extended transitions and more control over how individual pieces of music interact.

Ultimately, I want a set to feel deliberate without sounding over-planned. The goal is to create a coherent world for an hour or two while still leaving enough room for surprise.
07 / INFLUENCES

Labels, Artists & Musical Direction

A large part of my taste developed around producers and labels that expanded the vocabulary of drum and bass rather than simply refining an established formula. I have always been attracted to scenes where drum and bass meets sound design, techno, ambient music, dub and experimental electronics.

Samurai Music and the wider musical world around it have been an especially important reference point for me, together with the autonomic movement and the later development of halftime drum and bass. I am interested in the line that connects those earlier experiments with contemporary producers pushing 170 BPM music in new directions.

Producers such as Last Life, gyrofield, Quartz, Overlook, Mako and Rainforest represent different parts of that spectrum and have all appeared in or influenced selections I have worked with. What connects them for me is not one specific sound, but the willingness to treat drum and bass as an open format rather than a fixed genre template.

LAST LIFE · GYROFIELD · QUARTZ · OVERLOOK · MAKO · RAINFOREST
08 / NOW

Current Direction

At the moment I am concentrating more on DJing and recorded mixes than on organizing events. This gives me more time to dig for music, develop new sets and explore the part of drum and bass that interests me most.

Modern jungle and experimental 170 BPM music are currently especially important to me. I am interested in sets that combine the physical energy of drum and bass with the detail and freedom usually associated with more experimental electronic music.

I do not want Urbik to become associated with one narrowly defined subgenre. The project is ultimately about selection: finding original music, placing it in the right context and creating sets that offer something different from what can be heard on an average night out.

A technical review of this website

A portfolio that renders twice
and listens to the music

I am Jakub “Urbik” Urbanec — a Prague-based front-end developer, a drum & bass and halftime DJ, and the daily staff of a golden hovawart named Jupiter. This site is where those three things share one codebase: a server-rendered portfolio with no UI framework, a typed design system, and canvas visuals that react to my own mixes.

TypeScript · Express · JSDOM SSR · Canvas · Vite · esbuild · pnpm
01 / OVERVIEW

What this site actually is

Most portfolios are either a static page or a single-page application that ships an empty div and hopes the JavaScript arrives. This one is a small production web platform: it serves meaningful HTML on the first response, then upgrades itself in the browser into something interactive, audio-reactive and animated.

It is intentionally built without React, Vue, Svelte or Lit. Not because frameworks are bad — I use them professionally every day — but because a personal site is the right place to show that I can design the architecture underneath them instead of only assembling components on top.

SSR
Rendering
JSDOM + hydration
0
UI frameworks
plain DOM APIs
2
Packages
frontend + backend
TS
Source of truth
routes and tokens
  • The server prepares the page, so the first response contains real content — good for readers, crawlers and slow connections alike.
  • The browser then adds navigation, transitions, audio analysis, canvas effects and media controls.
  • Routes, design tokens and content are typed data shared by both sides of the application.
02 / FRONTEND

No framework, but plenty of structure

The document is an argument, not a container.

Every builder receives a Document instead of reaching for the global one. That single constraint is what lets the same functions run inside JSDOM on the server, inside Vitest during unit tests and inside a real browser after hydration.

Typical SPA
EMPTY DIV — JS — CONTENT
This portfolio
CONTENT — JS — MOTION
01

Factory functions

createHeader(), initContent(), createVideoPlayer() — plain TypeScript functions that build or mutate DOM. No JSX, no virtual DOM, no scheduler.

02

Sections compose pages

Page-level modules own the header, the content panel, the menu overlay and the media player; the design system owns everything smaller.

03

Explicit lifecycles

Without a framework nobody cleans up for you. Effects expose init() and stop() pairs, and state transitions await each other through a loading queue.

04

Small runtime

The browser bundle carries the app, the design system and the visuals — not a component runtime that also has to boot before anything is visible.

03 / REQUEST

One request, step by step

The most interesting part of the architecture is that the server and the browser run the same composition code. Here is what happens between typing the address and the first canvas frame.

Step 01
HTTP boundary

Express receives the request

Helmet security headers, a restrictive permissions policy and an origin-locked CORS setup run before anything else. The server is deliberately thin: it owns transport, policy and static assets, never page composition.

EXPRESS · HELMET · CORS · DOTENV
Step 02
Shared contract

One route table decides what this URL is

Routes live in a single typed module that both the server and the browser import. A route is data — page, showcase, blog, article or effect — so server registration, client matching, menu state and tests can never drift apart.

ROUTES.TS · PATH-TO-REGEXP · TYPED ROUTE KINDS
Step 03
Document shell

SSR() writes the head

Metadata, fonts, Open Graph tags and the inlined stylesheets are produced by the frontend package, not by a server template. Design-system CSS is embedded as a string so the first paint already knows the tokens.

META · OG TAGS · ?INLINE CSS · DESIGN TOKENS
Step 04
Server rendering

JSDOM runs the real mountApp()

The backend opens a JSDOM document and calls exactly the same mounting function the browser will call. There is no parallel server-only rendering path to keep in sync — and the window is closed immediately after serialization.

JSDOM · MOUNTAPP() · SERIALIZE · CLOSE
Step 05
Caching

Render once, serve many

A small page cache renders each route a single time per process and serves the stored HTML afterwards, advertising s-maxage to shared caches while keeping browser freshness at zero.

PAGECACHE · S-MAXAGE=300 · MAX-AGE=0
Step 06
Hydration

The browser reruns the same composition

On DOMContentLoaded the bundle matches the pathname against the shared routes, initializes the store without replaying transitions, and only then connects browser-only concerns: history, media, audio analysis and canvas effects.

DOMCONTENTLOADED · INITSTATE · POPSTATE · EFFECTS
04 / DESIGN SYSTEM

Tokens that cannot be ignored

SOURCE

TypeScript first

Colors, spacing, typography and motion live in typed token modules. tokensToCss() turns them into --ds-* custom properties, and cssVar(‘color.accent’) is checked by the compiler.

GUARD

A parity test

A unit test renders the whole showcase and fails the build if a ds- class has no CSS rule, if a --ds-* variable is undefined, or if any component CSS smuggles in a raw hex color.

Components are factories that return elements with BEM-style ds- classes, and their stylesheets are imported as strings so the server can inline exactly the CSS a page needs. The /ui showcase exercises every primitive in a real document — and it is filtered out of the production route set at build time.

05 / STATE

A Proxy instead of a state library

The only meaningful application state is which section is open. Instead of reaching for a store library, assigning to store.state goes through a Proxy setter that validates the value, pushes history, awaits the outgoing transition, swaps the state, then awaits the incoming one.

router.state = "devel"intent
Proxy set trapvalidate · pushState · queue
Transitionsend(previous) → start(next)
Content panel + visualsclasses, scroll, effects
initState()

Used by SSR and hydration: sets the state without touching history or replaying animations, so the server output and the first client frame agree.

restoreState()

Used by popstate: navigates without pushing a duplicate entry, which keeps the browser back button honest across sections and blog articles.

06 / BACKEND

Small server, explicit policy

  • Security headers first: CSP limited to same-origin scripts, inline styles for the SSR payload and Google Fonts; framing, plugins and inline script attributes disabled.
  • A permissions policy that switches off camera, microphone, geolocation, payment, USB and MIDI — a portfolio has no business asking for them.
  • Static assets, then generated routes, then an HTML fallback that redirects unknown documents to the root instead of leaking stack traces.
  • A central error handler and a process-local page cache, so each PM2 worker renders a route once and then just writes bytes.

Long-form HTML articles that already have their own document structure are still served as files. Not everything has to be forced through the DOM-builder architecture — matching the tool to the content is part of the design.

07 / PIPELINE

From source to two bundles

Vite library buildfrontend → backend/dist-fe + .d.ts
tscbackend compiled against those declarations
esbuilddist/app.cjs (server) + dist/fe.js (browser IIFE)
PM2 reloaddeploy

The stages are sequential on purpose: the backend type-checks against the generated frontend declarations, which is exactly how a type error in a shared route or a blog article is caught before deployment rather than after it.

Vitest
Unit
jsdom + CSS parity
Playwright
E2E
dev and prod route sets
ESLint
Lint
one flat config
Husky
Pre-commit
lint-staged + tests
08 / MUSIC

The part that plays records

I have been collecting and playing drum & bass, jungle and halftime for years as Urbik, and I used to run the Dark Atmo Breaks and BrainStorm nights in Prague. That half of my life is not a separate page on this site — it is wired into the runtime.

AUDIO

An analyser on my own mixes

The player streams my archived sets. A Web Audio analyser is created after hydration and resumed only on playback, because autoplay policies are a feature, not an obstacle.

VISUALS

Canvas that reacts to the low end

The visual layer taps into the Web Audio analyser and maps frequency bins to parametric effects: particle patterns shift and bloom intensifies with the bass energy. Multiple visual modes —atom, bloom, eraser, sweeper and more — are available depending on the section. Each effect maintains its own animation state and frame-rate budget, throttling to 30fps on mobile while desktop maintains 60fps.

Routes decide which section is open; the visual layer owns its own lifecycle independent of page navigation. Effect initialization happens after hydration completes, and shutdown hooks ensure audio resources are properly released when switching routes. Canvas is cleared and reinitialize on demand rather than running a global tick loop.

Writing the halftime history article on this same site closed the loop nicely: the design system I built for a developer profile turned out to be a decent typesetting engine for music writing.

09 / OFFLINE

Jupiter, walks and perspective

A hovawart is an excellent code reviewer.

Jupiter — Jupík — is a golden hovawart, which means a large working dog with strong opinions about how long I am allowed to stare at a screen. Most of the refactors on this site were designed during long walks rather than in front of the editor.

That is roughly the same instinct that drives the rest of the project: look for the interesting thing, whether it is an unusual record, a browser API, a rendering trick or a new route through the forest.

10 / NEXT

What I would build next

The architecture is finished enough to be honest about its edges.

Soon

Real cache invalidation

The page cache currently lives and dies with the process. Content-hash based invalidation would let me publish a blog article without a restart.

Next

Per-article metadata

Blog entries already expose a typed title and path; the natural extension is generating per-route titles, descriptions and Open Graph images from that same data.

Later

Performance budgets for the visuals

Canvas effects are the least predictable part of the runtime. Explicit budgets and accessibility regression checks would make them safe on low-powered devices.

ROADMAP — intentions, not shipped features.
A personal site is the only project where the architecture is allowed to be the portfolio piece.