Evaluating LLMs on Recreating Complex Web Particle Animations

1. Why this test: a deliberately hard requirement

Typical LLM coding tests—sorting algorithms or a simple form—do not reflect messy production work. To get closer to real engineering, the target was a full recreation of a well-known technical site’s hero animation: a “vortex galaxy” particle system.

The effect is an interactive visual system, not a static page:

• The first screen shows a large “6”-shaped particle cloud with mouse-driven parallax.
• On scroll, particles scatter into a starfield, then regroup into a logo.
• Transitions are smooth; particle count, density, and trajectories are tightly tuned.

The task covers requirement parsing, tech choice, source analysis, Canvas/WebGL, event handling, and animation loops. It also tests exploration: original scripts are minified and loaded in chunks, so grabbing them is not trivial.

2. Experiment design and models

Three mainstream models (labeled Model A, B, and C) were used under comparable conditions. All were connected to a local coding environment with access to the target page via an embedded browser or plugin.

Prompt (as given):

Visit https://example.com/index (original domain replaced). The homepage and mid-page have a striking particle effect. On scroll, particles gather and scatter; gathered they form a specific shape, scattered they look like stars. Mouse movement also interacts. Recreate the effect by any means (browser plugins, code analysis, screenshot recognition, etc.). Deliver a standalone demo page that matches as closely as possible.

The prompt did not prescribe an implementation, so models had to choose their own approach.

3. Findings: paths and results

3.1 Model A: orderly but conservative

Model A loaded the page, took screenshots, and identified a Canvas particle system. It did not deeply parse minified JavaScript and rebuilt from scratch.

First version:

• Shape fidelity ~60%: a “6” formed, but density and evenness lagged.
• Motion: scatter/gather on scroll was abrupt, missing original easing.
• Mouse: simple particle repulsion, not parallax follow.

After feedback that the shape was off, it mapped particle density to target-image grayscale, improving form. Physics of the motion still felt weak.

3.2 Model B: strong reverse engineering

Model B inspected network requests, found Webpack chunks, and located animation logic. It deobfuscated some names and extracted formulas (e.g. 3-axis rotation, target interpolation).

Approach:

• Copied original init parameters and the animation loop.
• Used an offscreen canvas to bake the logo into particle coordinates.
• Recreated attract–repel dual force fields for the mouse.

Result: shape fidelity ~95%; timing, particle count (5000+), and CPU use close to the original. Slight frame drops at extreme scroll speeds; code was large and uncompressed.

3.3 Model C: interaction and engineering balance

Model C rewrote after understanding rather than copying. It defined three states (scattered, transition, gathered) and a state-machine controller.

• WebGL instead of Canvas for higher particle counts.
• Positions computed dynamically; shaders for smooth blends.
• Clear knobs for count, color, and speed.

Shape fidelity ~85% (below B), but motion was smoother, especially on high-DPI and zoom. Structure was modular and easier to extend.

4. Four capabilities that decided success

4.1 Requirement understanding and modeling

All three saw a “particle system.” Interpretation of scroll-driven gather/scatter differed. Model A first treated it as opacity fades (wrong); B and C correctly used position interpolation between states. Stronger models decompose visuals into state-transition equations.

4.2 Reverse engineering vs. prior knowledge

Minified, chunked code favored Model B, which guessed particle data might come from JSON and tried to dump coordinates from the console. A and C leaned on internal knowledge and rebuilt from experience. A hybrid—extract key parameters, then regenerate the framework—worked best.

4.3 Visual perception and calibration

Screenshots tested vision. All recognized a “6”; none initially nailed density at the edges. Model A’s first “6” was blurry until prompted to study edge distribution and grayscale mapping. Explicit prompts to “learn visual rules from screenshots” help.

4.4 Performance and code quality

5000+ particles need a rendering strategy. B used Canvas and updated every particle on the CPU—fine on high-end machines, risky on low-end. C used WebGL and GPU shaders: better performance, more complex code. None of the models volunteered optimizations (spatial hashing, layered rendering) without being asked.

5. A reusable evaluation rubric

The method generalizes beyond this one effect. Suggested weights:

Dimension	What to check	Weight
Requirement parsing	All interaction states understood	20%
Tech choice	Canvas / WebGL / DOM fit	15%
Completeness	Shape, motion smoothness, interaction	25%
Code quality	Naming, comments, modularity	15%
Self-iteration	Fast, accurate fixes from feedback	25%

Use more than one task (static layout, interaction, APIs). Give the model explicit criteria (e.g. “explain how you will verify fidelity”) so it self-checks and exposes reasoning.

6. How developers can use LLMs on this kind of work

6.1 Divide and conquer

Split the job:

• Analyze layout and screenshot key regions.
• Extract stack and core algorithms.
• Generate particle system, scroll listeners, and mouse interaction separately.

Multi-turn work beats one giant script.

6.2 Prefer reverse engineering first

After a first look, ask the model to pull parameters from DevTools or network traces (coordinates, durations, easing names). Fall back to visual reconstruction only if that fails.

6.3 Version and diff

Save a snapshot before each change. Have the model compare diffs and explain which lines shifted the effect.

6.4 Human visual QA

Always check in a real browser. Automated screenshot diffs at the same viewport, with pixel-level error fed back to the model, sped up convergence in this experiment.

7. Conclusion

Current LLMs can recreate moderately complex front-end effects when a live reference page is available—roughly mid-level engineer quality. Weak spots remain: interaction timing (scroll vs. mouse priority) and visual polish (“correct but crude”).

As multimodal models improve, they may learn motion from video and even softer notions such as “softness of particle motion.” Collaboration should shift from one-shot specs to joint debugging, treating the model as a pair-programming partner.

Whatever model you pick, keep an internal pipeline: screenshot comparison, performance checks, and code quality gates, so evaluation stays consistent as models change.