Marketing Platform

Challenges

1. Secure Lead Collection Pipeline

The lead generation form required a production-grade validation and abuse prevention strategy.

The challenge was ensuring that the submission flow remained frictionless for legitimate users while preventing automated spam and repeated abusive requests.

Rate limiting was implemented as a distributed edge-friendly layer capable of throttling excessive submissions without introducing server-side bottlenecks.

2. Scroll-Based Card Stack Orchestration

The project includes a stacked-card scroll interaction where sections progressively overlap and transform during scroll progression.

Animations were implemented using transform-based compositing (translate3d, scale) and centralized GSAP timelines to ensure GPU-friendly rendering.

3. Multilingual Rendering Architecture

The interface supports multiple locales through useI18n() with SSR-compatible translations.

The architecture ensures consistent locale-aware rendering while minimizing duplicated translation logic across components.

4. Progressive Loading Strategy

To reduce initial payload size, non-critical sections were lazy-loaded and initialized only when approaching the viewport.

The result was a progressive rendering pipeline that prioritizes above-the-fold performance while preserving smooth transitions into deferred content.

Architecture & Technical Decisions

1. Why Nuxt.js

Nuxt was chosen to combine SSR rendering with modern client-side interactivity.

This made it particularly suitable for a marketing-oriented platform where discoverability, performance, and perceived loading speed are critical.

The result is a hybrid architecture optimized for content-heavy, motion-driven landing experiences where full SPA hydration would be unnecessary overhead.

2. nanostores — Reactive Atomic State Model

For cross-component state management, nanostores was chosen as a lightweight reactive primitive system based on atomic stores.

Instead of a centralized global store or prop drilling, the application state is split into small reactive units (atoms), each representing a specific domain (e.g. scroll progress, active section, animation state).

This model allows independent UI parts to react only to the state slices they depend on, reducing unnecessary re-renders and improving predictability in animation-heavy contexts.

It also works naturally with scroll-driven interactions, where multiple subsystems need to react to the same underlying signal (e.g. scroll progress) without tight coupling.

3. Anime.js — Lightweight Animation Engine for Fine-Grained Control

Anime.js was used as the primary animation engine due to its lightweight footprint and flexible API for timeline-based and property-based animations.

Compared to heavier alternatives, it provides sufficient control for complex motion sequences while keeping implementation overhead low.

This made it suitable for a system where animations are not isolated effects, but part of a continuous narrative flow.

4. Tailwind CSS + Custom Styles — Hybrid Design System Approach

Tailwind CSS was used as the base styling system to accelerate UI development and enforce consistency across layout primitives.

However, for motion-heavy and highly visual sections, custom CSS was introduced where utility classes were insufficient (e.g. complex layering, scroll-driven transforms, SVG interactions).

5. Locomotive Scroll — Centralized Scroll Orchestration Layer

Locomotive Scroll was used as the foundation for scroll handling, providing smooth scrolling behavior and a centralized scroll abstraction layer. On top of it, a custom extension layer was built to expose normalized scroll progress to the application.

A key enhancement was a progress-dispatching mechanism that broadcasts scroll state changes globally, enabling components to subscribe via data-* attributes and react declaratively.

Under the hood, scroll updates are mapped into a normalized progress value and propagated through the system as a shared reactive signal.

Trade-offs

Why Not React (or Full SPA Architecture)

A full React SPA was intentionally avoided to prevent unnecessary runtime overhead and hydration cost for a primarily content-driven, scroll-heavy experience.

In this type of product, the UI is not application-centric but narrative-centric, meaning most of the interface is static or progressively enhanced rather than constantly state-driven.

React was still implicitly replaced where state-driven complexity was required (via Nanostores + Web Components), but without introducing a global rendering runtime.

Why Not GSAP

GSAP is a powerful industry-standard animation library, but it was intentionally not used as the primary animation engine to reduce abstraction overhead and keep animation control closer to the application logic.

GSAP excels in complex timeline orchestration and plugin ecosystem, but in this case most animations were tightly coupled with scroll progress rather than independent timelines. Animation logic needed to be declarative and data-driven through attributes and scroll signals.

Conclusion

This project demonstrates how a visually rich, scroll-driven landing page can be built without relying on a heavy SPA runtime or oversized animation framework. By combining Astro, Web Components, Locomotive Scroll, Nanostores, and Anime.js, the implementation keeps the experience modular, performant, and maintainable.

The result is a motion-focused frontend architecture that balances cinematic interaction design with practical engineering concerns: small client-side overhead, reusable animation primitives, centralized scroll orchestration, and predictable behavior across responsive layouts.