You are browsing as a guest. Sign up (or log in) to start making projects!

lionel

@lionel

Joined June 2nd, 2026

  • 7Devlogs
  • 3Projects
  • 2Ships
  • 15Votes
Radically prospective, probably pretentious. (i just wanted something that sounded cool)
Ship

I built a minimal "web-os" project using HTMX, Tailwind, DaisyUI, and GitHub Pages! Loosely based on the guide - I look some license to build the app in the way that I'm used to. My incredible, unseen new feature: wobbly windows! The windows wobble around and move super smoothly :p

Try project → See source code →
Open comments for this post
Reposted by @lionel

2h 32m 57s logged

I started building wobblyOS!, a jellified web-os with some fancy animations that you will all be delighted to see. (using HTMX and github pages)

0
1
14
Open comments for this post
Reposted by @lionel

31m 20s logged

How wobblyOS windows feel alive
The goal of this system is not to “animate” windows with CSS transitions. It treats every window as a physical object with mass, velocity and momentum, then simulates that every frame.
This makes movement feel weighted, reactive, and surprisingly satisfying.

The spring
Every window tracks two positions- where it is, and where it’s going:

currentX += (targetX - currentX) * 0.18

That 0.18 is the spring stiffness.

Velocity
After each position update, velocity is derived from the gap that remains:

velocityX = targetX - currentX

This is reused for every visual effect.

Rotation
The window tilts based on how fast it’s moving horizontally:

rotate = velocityX * 0.08

Drag it left and it leans left. Etc etc.

Squash & stretch
Animation principle, applied physically:

stretchX = 1 + abs(velocityX) * 0.0015
stretchY = 1 - abs(velocityX) * 0.0008

Fast horizontal movement makes it wider and slightly shorter.

Bounce
A sine wave modulated by current velocity adds a subtle wobble while moving:

bounce = sin(time * 0.015) * min(speed, 25) * 0.15

When still, it does nothing- moving, it oscillates.

Open & close
A second spring drives the scale when windows appear or disappear:

velocity += (target - value) * stiffness
value    += velocity

Open: spring launches from 0 with an initial velocity kick, overshoots 1, bounces back.
Close: target flips to 0, the window squashes down toward the taskbar and vanishes.

Taskbar
Waits 500ms after the window is gone, then pops in on its own spring. Restore reverses it- button springs out first, then the window pops back.

Summary
Every effect shares one velocity value derived from one spring equation. No CSS transitions, no keyframes, just position, momentum, and a multiply.

0
1
5
Open comments for this post

31m 20s logged

How wobblyOS windows feel alive
The goal of this system is not to “animate” windows with CSS transitions. It treats every window as a physical object with mass, velocity and momentum, then simulates that every frame.
This makes movement feel weighted, reactive, and surprisingly satisfying.

The spring
Every window tracks two positions- where it is, and where it’s going:

currentX += (targetX - currentX) * 0.18

That 0.18 is the spring stiffness.

Velocity
After each position update, velocity is derived from the gap that remains:

velocityX = targetX - currentX

This is reused for every visual effect.

Rotation
The window tilts based on how fast it’s moving horizontally:

rotate = velocityX * 0.08

Drag it left and it leans left. Etc etc.

Squash & stretch
Animation principle, applied physically:

stretchX = 1 + abs(velocityX) * 0.0015
stretchY = 1 - abs(velocityX) * 0.0008

Fast horizontal movement makes it wider and slightly shorter.

Bounce
A sine wave modulated by current velocity adds a subtle wobble while moving:

bounce = sin(time * 0.015) * min(speed, 25) * 0.15

When still, it does nothing- moving, it oscillates.

Open & close
A second spring drives the scale when windows appear or disappear:

velocity += (target - value) * stiffness
value    += velocity

Open: spring launches from 0 with an initial velocity kick, overshoots 1, bounces back.
Close: target flips to 0, the window squashes down toward the taskbar and vanishes.

Taskbar
Waits 500ms after the window is gone, then pops in on its own spring. Restore reverses it- button springs out first, then the window pops back.

Summary
Every effect shares one velocity value derived from one spring equation. No CSS transitions, no keyframes, just position, momentum, and a multiply.

0
1
5
Open comments for this post

2h 32m 57s logged

I started building wobblyOS!, a jellified web-os with some fancy animations that you will all be delighted to see. (using HTMX and github pages)

0
1
14
Ship

I built a minigame web app where your goal is to draw a perfect star! It's inspired by Neal.fun's "Draw a Perfect Circle" challenge (which went viral on YouTube last year) and I wanted to recreate that same simple-but-addictive feeling with a slightly different twist- perfectly fitting for Stardance.

The idea is straightforward: you draw a star on screen, and the game scores how close you are to a mathematically perfect star shape. It sounds simple, but it quickly turns into one of those "just one more try" kind of challenges.

I built the site using Astro for structure and performance, and styled it with Tailwind CSS to keep the UI design process simple. The drawing system is handled with basic pointer events and canvas logic, where I track the user’s input path and compare it against an ideal star shape using a scoring algorithm- you can check out my devlog for more info!

For deployment, I used GitHub Pages, which also forced me to properly understand static builds, routing, and how Astro compiles static projects down for production. That part alone helped me get a lot more comfortable with real-world deployment workflows.

This was mostly a fan project, but it ended up being a really useful way to get back into web development after a short break. I brushed up on Git workflows, got more comfortable with CSS animations, and learned a lot about handling user input smoothly in the browser without external libraries.

Overall, it’s a small project, but it taught me a surprising amount about building something end-to-end- from idea to deployment. If you enjoyed it or want to see improvements, feel free to star the repo or check it out.

  • 3 devlogs
  • 2h
  • 10.69x multiplier
  • 19 Stardust
Try project → See source code →
Open comments for this post
Reposted by @lionel

34m 6s logged

How “Draw a Perfect Star” actually calculates accuracy

The goal of this system is not to “recognise” a star visually. It turns both your drawing and a perfect star into comparable point data, then measures how far apart they are.

This makes scoring fast, deterministic, and surprisingly stable.

Input capture

While you draw, the app records raw mouse positions:

path = [(x1, y1), (x2, y2), etc etc]

This data is noisy and depends heavily on speed and polling/sampling rate.

Resampling

The stroke is converted into a fixed number of evenly spaced points (120).

This removes:

  • drawing speed differences

  • uneven mouse sampling

Now every drawing has a consistent structure.

Normalisation

The shape is transformed so comparison is fair:

  • centred around (0, 0)

  • scaled so max radius = 1

This removes position/size- only shape remains.

Reference star

A perfect 5-pointed star is generated mathematically using polar coordinates and sine-based radius switching.

It is also sampled into 120 points so it matches the user format.

Comparison

Each user point is compared directly to the corresponding star point-

error += distance(user[i], star[i])

This produces an average geometric deviation across the full shape.

Scoring

Final score is computed as:

score = 100 - error * 120

Then clamped between 0 and 100.

Summary

The system works by converting both shapes into normalized point sequences and measuring their geometric distance.

4
4
1933
Open comments for this post

34m 6s logged

How “Draw a Perfect Star” actually calculates accuracy

The goal of this system is not to “recognise” a star visually. It turns both your drawing and a perfect star into comparable point data, then measures how far apart they are.

This makes scoring fast, deterministic, and surprisingly stable.

Input capture

While you draw, the app records raw mouse positions:

path = [(x1, y1), (x2, y2), etc etc]

This data is noisy and depends heavily on speed and polling/sampling rate.

Resampling

The stroke is converted into a fixed number of evenly spaced points (120).

This removes:

  • drawing speed differences

  • uneven mouse sampling

Now every drawing has a consistent structure.

Normalisation

The shape is transformed so comparison is fair:

  • centred around (0, 0)

  • scaled so max radius = 1

This removes position/size- only shape remains.

Reference star

A perfect 5-pointed star is generated mathematically using polar coordinates and sine-based radius switching.

It is also sampled into 120 points so it matches the user format.

Comparison

Each user point is compared directly to the corresponding star point-

error += distance(user[i], star[i])

This produces an average geometric deviation across the full shape.

Scoring

Final score is computed as:

score = 100 - error * 120

Then clamped between 0 and 100.

Summary

The system works by converting both shapes into normalized point sequences and measuring their geometric distance.

4
4
1933

Followers

Loading…