-
-
plant
-
grow
The theme is a contradiction worth pulling on: "hyper" suggests excess and speed, "bloom" suggests patience. Every botanical site we could picture resolves that by decorating a page with flowers. We wanted the flowers to be earned, which meant the page had to compute them.
The second thread was the herbarium. A herbarium turns living things into records: pressed, labelled, filed, frozen. We wanted to run that backwards, and let a record produce something that looks alive.
That inversion became the whole project. The label comes first, and the plant grows out of it.
What it does
HyperBloom is a garden that reads words. Type a word and it grows exactly one flower: hue, petal count, ring depth, a Latin binomial, a taxonomic family and a two-line botanical description, all computed from the text.
The rule is strict. The same word always returns the identical specimen, petal for petal. Change one letter and you get a different plant. Every flower you keep is pressed into a herbarium that fills as you go, and any specimen exports as a downloadable herbarium sheet: an 1100x1400 plate with the name, the family and the description set on it. It opens with five specimens so the shelf is never empty. There is no account, no server and no upload. The garden lives in the browser
How we built it
It is one HTML file of about 35 KB: no framework, no build step, no bundler. Open it and it runs. The only network request the page makes is an optional web font, and the site is fully usable without it.
The geometry is generated, so the SVG is assembled as strings rather than drawn by hand. The unfurl uses the Web Animations API, staggered per petal, so a flower opens outward from its base instead of fading in. The export draws the sheet to a canvas and hands it back as a PNG. Saved state is a list of words and nothing else: every specimen is recomputed on load, which is what makes determinism structural rather than a cached result.
The interesting part is the pipeline from text to flower:
H
0
2166136261 , H i +
1
( ( H i ⊕ c i ) ⋅ 16777619 ) m o d 2 32 H 0 =2166136261,H i+1 =((H i ⊕c i )⋅16777619)mod2 32
u
m u l b e r r y 32 ( H n ) ,
θ
⌊ 360 u 1 ⌋ ,
N
5 + ⌊ 8 u 2 ⌋ ,
K
2 + ⌊ 2 u 3 ⌋ u=mulberry32(H n ),θ=⌊360u 1 ⌋,N=5+⌊8u 2 ⌋,K=2+⌊2u 3 ⌋ Here θ θ is hue in degrees, N N is petal count and K K is ring depth. Each petal is the same cubic curve Γ ( ω ) Γ(ω), rotated to its share of the circle by α i α i and scaled to its length ℓ i ℓ i , so the whole bloom is one path definition repeated.
Naming and description draw from separate streams seeded off the same hash, so the naming grammar can be rewritten without disturbing a single existing flower.
We tested it in headless Chrome over the DevTools Protocol: rendered at 390, 768 and 1440 px, checked for horizontal overflow, measured every text colour pair against WCAG AA in both light and dark, then planted the same word twice and compared the generated SVG markup byte for byte. The determinism claim is measured, not asserted.
Challenges we ran into
Randomness is a promise, and it is fragile. Because the PRNG is consumed in a fixed order, adding one extra draw anywhere reshuffles every flower in the garden. Through the whole tuning phase, every small change to the shape silently redrew all existing specimens. The fix was to split the streams: geometry, naming and description each get their own seed derived from the same hash, so one can be rewritten without disturbing the others.
Animating a petal from its base. Each petal is drawn at the origin and positioned by a transform, so a naive CSS rotate swings it around the wrong point and the flower scatters. It needed transform-box: fill-box with transform-origin: 50% 100% to make the base of the path the pivot, which is the kind of detail that looks trivial in a spec and takes an evening in practice.
The first impression was an error colour. Our starter word hashed to exactly hue 0, a saturated red that made the hero read as a broken state rather than a flower. We also spent far longer on the centre of the bloom than we expected: it looked like a dark hole at one point, then like a raspberry, before it settled into a deep petal-tone disc with cream stamens.
Fitting the idea into a small file. We cut an ambient particle field we had planned for the background. It looked good, and removing it was right: drifting petals competed with the one thing that should move, which is the flower you just grew.
Accomplishments that we're proud of
We can prove the promise. Planting the same word twice produces byte-identical SVG. Most generative projects ask you to take that on trust, and we can show the diff instead.
35 KB, one file, no build step. No framework, no bundler, no dependency graph. It opens by double-clicking and paints immediately. We also tested it with the font host blocked outright, and the page still works and still looks deliberate on the system face.
The export is a real artifact. The download button produces an actual herbarium plate, name, family and description set in type, at 1100x1400. Not a screenshot of the page.
The rule is legible in about four seconds. Type two words, see two different plants, and the system explains itself. No instructions paragraph, no onboarding.
It holds together at 390 px. No horizontal overflow at any width we tested, keyboard navigable, respects reduced motion, and every text pair we measured clears WCAG AA in both light and dark, the lowest at 5.37:1.
What we learned
A generative system is only as interesting as its rule is legible. Once a visitor types two words and sees two different plants, the rule explains itself, and the page does not need to explain anything.
Constraints are authorship. The 64 KB ceiling and the ban on a build step forced decisions we would otherwise have deferred, and the page is faster and stranger for it.
The hardest part was subtraction. What made the project feel finished was removing the second most interesting idea.
What's next for hyperbloom
Links that carry a specimen. A flower is only a word plus a rule, so a link can be the specimen: #willow reproduces it exactly, with nothing stored and nothing to sync. That turns every bloom into something you can send to someone.
More than one silhouette. Today every bloom is a ring of petals. The next step is real inflorescence types chosen by the same hash: bells, umbels, spikes, composites. Two words would then differ in shape as well as colour and count.
A printable flora. The export gives you one specimen. We want the whole herbarium as a multi-page booklet with an index, so a garden built over months can exist off the screen.
A naming grammar that listens to the word. Latinisation currently works from the hash, which is fair to any input but deaf to the sound of it. Reading the word's own syllables, including non-Latin scripts, would make the names feel grown from the text instead of assigned to it.
Log in or sign up for Devpost to join the conversation.