Frontend Nation 2024 - Marchant Web Case Study

In June 2024 I had the opportunity to speak at Frontend Nation, the largest online frontend event in the world, alongside a bunch of talented frontend developers. My talk was to be titled "crafting completely crazy and collectively constructive creative coding concoctions".
I was the final speaker on Day 3, closing out the event by delivering a talk that provided no educational value at all, instead opting to inspire and have some fun with the participants in a highly interactive 3D experience running in the browser. Using frontend tools such as Threejs and PartyKit I crafted an immersive factory experience where participants played as rubber duckies driving forklifts in real-time - with the goal of building a new creative landing page hero section.
Who knows where the idea came from, but early on I decided one of the interactive “toys” participants would interact with would be a forklift. I set out to build a proof-of-concept using a forklift 3D model and building a few physics bounding boxes around it. Working with a segmented mesh (where the lift mesh was not attached to the main body) allowed me to add gsap animations to both the mesh and physics body to raise/lower the forklift.
An early test included using a pallet and some traffic cones/barricades that could be ran into. If I could control the forklift and successfully move some traffic cones around an empty space, then the rest would just be icing on the cake.
Once I was happy with the proof-of-concept, I moved onto to implementing this at scale. I approached development with an object-oriented mindset, building TS classes representing base physics toys, props, structures, and rooms. This allowed me to build upon base functionality, such as automatically-generated physics bounding boxes and contact materials. Structuring code this way enabled me to create scenes at scale that would have otherwise taken me significantly longer otherwise.
One of the most impactful decisions I made along the way was to treat this like a video game more than a web experience, pulling from well-known video game development techniques to optimize for performance. Each “room” was divided using a pair of rolling garage doors that acted like airlocks. Once the camera entered the “airlock”, the previous room’s resources were disposed of and the scene got reset back to {x: 0, y: 0, z: 0} . This logic provided for segmentation during development - I could swap between scenes easily, re-order them, and never worry about keeping multiple scene's resources in memory at once.
The red outlines below represents the physics bodies in the scene. Nearly everything in the scene had a physics body for collisions. This image also shows the modular approach to level development, using a grid to build up the floors, ramps and walls.
Excluding structures, over 70+ unique physics props were created for participants to engage with, ranging from the pallets of npm packages and DOM elements of various types/sizes to barricades, speaker cards, railings and more. Each one had it’s own properties and logic, running on top of a parent class with automatic lifecycle management to ensure models, textures and materials were cached and disposed of when needed. Certain props, like storage racks, hooked into this lifecycle to run additional logic, like adding cardboard boxes to the rack’s shelves as separate physics objects.
Although hard to spot during the madness, there were a ton of small details and easter eggs to discover - such as some non-standard css properties and posters with inspirational messages such as “let’s get this bread”.
One of my favorite scenes of the entire talk was the fragment shader room. It took a decent bit of manual work to build up a hex grid of colors to play with - and the result of this with 15 forklifts pushing them all over the place was crazy. This was also one of the more intensive rooms resource-wise, as it required more connections for all of the forklift interactivity and more physics bodies to support all the hex codes. This one scene actually uses more "loose" physics parameters to improve on framerate performance, at the expense of accuracy. This led to some weird things happening, but it visually made sense during the madness of this scene.
One of the core messages of the talk was to emphasize that creative coding is a process of exploration - and that making mistakes was a part of that process. I didn't want things to go perfectly, opting instead to have it crash and burn intentionally.
The original ending, shown below, would take the Frontend Nation logo and drop it into place. Doing so would disrupt the landing page below and scatter the elements, and I'd close out on the aforementioned message.
But that didn't quite feel right. Somewhere, admittedly fairly late in planning for the talk, it dawned on me that I might want to store screen-captures of the factory experience along the way. I'd already developed a process early in prototyping to save out image data for the sake of potentially streaming it to attendees, but this seemed like a better fit.
Within a couple of days, I built out a process that captured low-resolution media during the entire talk, and then compiled it in real-time at the end of the talk to build the Frontend Nation logo back in the original 3D scene. It's sort of trippy when you think about - those are screenshots of the current 3D scene, within the 3D scene itself. The result here being a single high-resolution artwork representing the talk in full, emphasizing that the process of building and giving the talk itself is what led to this artwork being generated through exploration.
Some of my random updates, articles, thoughts, tinkering and talks.
© 2025 Marchant Web, LLC
Grab your sense of humor and prepare to dive headfirst into this crazy coding adventure.
Introducing "usePartyRef" for @vuejs. It's a ref() that syncs in real-time with other clients using @partykit_io.
This was a fun one to build, with the design by n