This year I joined Juicyway to help build their website frontend. The project demanded I built about 30+ pages with a headless cms & custom animations (marketing pages, blog, news, faq etc.), the site needed 4 locales (us,uk,ng and ca) and It had business, individual and general sections.

What i’ll be talking about:

1. component strategy
2. how i handled animations in the project
3. ssr vs ssg or both (isr)
4. dynamic hero illustrations
5. how i generally approach styling

The project was written with Nuxt, Typescript & scss. I only think this is noteworthy because I would like to use this to document my general approach to front-end projects.

Component strategy

For large projects like this, you’ll definitely see recurring components on several pages. In most cases you can easily write a component, add a few props and then you’re good to go. Some other cases “just a few” props won’t cut it —although they’re same, you’ll have to modify a good chunk (UI & functionality) of it.

So you can either maybe;

1. spam loads of props and keep it moving or
2. make a new component similar to that or
3. use template components with room to extend

I know some times you just need a lot of fine-tuning even though the core structure remains the same, it may not be prop heavy but will need a fair amount of conditionals against url-params, locales, time of day etc. But it still falls under the first approach.

For me b and c are my go to, or well that’s what I did for this project. My way of deciding which approach to go for anytime I have to write one depends on all these factors;

• implementation complexity (few lines vs significant code)
• component hierarchy (where it sits in the component tree)
• functionality requirements (what it needs to do)
• visual variance (how much its form changes in different contexts)

As much this is a personal heuristic it maps well to some established principles for software design. component hierarchy → single responsibility principle. functionality requirements → composition vs configuration. implementation complexity + visual variance → rule of three.

This isn’t specifically about this project, but yeah these were definitely factors I considered while building it. Out of all of them though, functional requirements tend to influence my decision making the most. Like if I need to handle state, deal with data, or add custom animations, I’ll usually go for making components. When these components need to work in different contexts, I’ll configure them with props as much as makes sense —if the props start to feel like a workaround, that’s usually a sign to split into a new component. For stuff that’s purely UI where only the structure changes between contexts, I lean towards template components. And if it’s just the functionality that varies, I’ll use props to handle all the different needs.

Btw when I say template components, I mean html structures with specific class patterns that maintain consistent styling patterns. This approach allowed me to write out repeatable UI patterns directly instead of spamming props and conditionals.

How i handled animations in the project

Component-specific animations

Some components needed their own special animation logic that didn’t fit into the general system. These were usually interactive animations based off scroll & click. In these cases, I’d handle the animations directly in the component, using props or conditions to configure them.

General animations

The animation system used gsap combined with the intersection observer for scroll-triggered animations. It was split into three files each handling different aspects of the animation system (text animations, text splitting, generic animations). The animations in this project relied on data attributes to mark elements for specific animation effects, then setup/system observed these elements and triggered their animations when they entered the viewport.

The most consistent animations across all the pages were the text animations, image mask animations and fade-in animations. Which were to kick in on every page visit. The animate() handled the mask animations and fade in animations (single & grouped) while the textAnimate() handled the text animations

animations.client.ts

 if (import.meta.client) {
        const runPageAnimations = () => {
                splitText(); // split animation
                nextTick(() => {
                    animate(); // general animations
                    textAnimate(); // text animations
                });
        };

        // this is for every page visit, resets the animations &
        // the scrolltrigger to avoid bugs
        nuxtApp.hook("page:start", () => {
            resetAnimations()
            const { $ScrollTrigger: ScrollTrigger } = useNuxtApp()
            ScrollTrigger?.refresh()
        })

        // runs when the page has been rendered and the dom is accessible
        nuxtApp.hook("page:finish", () => {
            runPageAnimations();
        });

So the design for the animations was to write the selectors (based off the attributes) for each type and then map through and apply the animations when they were observed at a set threshold.

For example:

export const animate = () => {
    const { $gsap: gsap } = useNuxtApp();
    const maskLeft: NodeListOf<HTMLElement> = document.querySelectorAll("[data-mask='left']");

    maskLeft.forEach((item: Element) => {
        const image = item.querySelector("img") as HTMLImageElement;
        gsap.set(image, { xPercent: -150 });
        IO(item, { threshold: 0 }).then(() => {
            gsap.to(image, {
                xPercent: 0,
                transformStyle: "preserve-3d",
                ease: "power1.inOut",
                duration: 1.3,
                delay: 0.1,
            });
        });
    });

    export const textAnimate = () => {
    const { $gsap: gsap } = useNuxtApp();
    const blurTextIn = document.querySelectorAll("[data-animation='blurIn']");

    blurTextIn.forEach((item) => {
        gsap.set(item.querySelectorAll(".word"), {
            yPercent: 50,
            opacity: 0,
            filter: "blur(2px) contrast(0%)",
            rotateX: 50,
            transformStyle: "preserve-3d",
        });
        IO(item, { threshold: 0.8 }).then(() => {
            const elem = item.querySelectorAll(".word");
            gsap.to(elem, {
                yPercent: 0,
                opacity: 1,
                filter: "blur(0px) contrast(100%)",
                rotateX: 0,
                stagger: elem.length > 30 ? 0.02 : 0.03,
                duration: elem.length > 30 ? 0.6 : 0.8,
                ease: "power1.inOut",
                delay: 0.1,
            });
        });
    });

Then in the template

<!-- Word-by-word text animation -->
<p data-animation="blurIn">This text will animate blurred in word by word</p>

<h2 data-animation="bounce">This text will animate in bouncing word by word</h2>

<!-- Character text animation -->
<h2 data-animation="h">This animates character by character</h2>

<!-- Image mask reveal (top, left, right). The styles for the mask are already applied -->
<div data-mask="top">
	<img src="image.jpg" alt="Animated image" />
</div>

Spliting text

I used splitting.js for the splitting the text, preparing it for the animations. To prevent double splitting which messes up the animation, I had to seperate the splitting logic from the text animation, call it before the other animations so the dom is updated and then use a data-split attribute to mark elements so they are not selected for animation on every page visit. For example:

const arrayOfText = document.querySelectorAll("[data-animation='bounce']:not([data-split='true'])");

arrayOfText.forEach((item) => {
	$splitting({
		target: item,
		by: "lines",
	});
	markAsSplit(item);
});

const markAsSplit = (item: Element) => {
	item.setAttribute("data-split", "true");
};

SSR vs SSG or Both (ISR)

For projects like this with both marketing pages and dynamic content (blog, news, etc.), you often end up thinking about both. Marketing pages rarely change and need to be fast, while content pages need to be fresh. The way I approached it was pretty straightforward - used SSG for the marketing/product pages since they change maybe once in a while, and SSR for content-heavy routes like /blog, /press, and /faq where content updates frequently. Now, ISR (Incremental Static Regeneration) could’ve been interesting here - it’s like SSG but pages can revalidate and rebuild in the background after a set time. Could’ve helped with the blog and news sections while keeping the performance benefits of static pages. But the hybrid SSG/SSR approach worked well enough for our needs.

Dynamic hero illustrations

If you notice, the hero illustrations switch backgrounds depending on the time of day, cycling through four states: morning, day, evening, and night. I wrote a composable that checks the current hour and reactively returns the right time cycle, which then updates the background. I just find it cool

How I generally approach styling

I style projects with vanilla CSS, using SCSS as a preprocessor. The styling is organized using a modified 7-1 pattern, with all styles primarily contained in a styles directory at the project root. For this project, while I used custom styles exclusively, the setup allows future devs easily build on top with either more custom styles, SCSS (preferred), or component libraries like Tailwind.

The structure breaks down into key areas:

• abstracts: contains mixins, variables, and breakpoint definitions
• base: Houses fundamental styles and utilities (reusable atomic classes. such as flexbox utilities, spacing helpers, gap utilities, common layout patterns.)
• components: component-specific styles, plus template-based component patterns

all core styles are automatically available throughout the app through Nuxt’s config setup, making them easy to use without explicit imports.

you can check out my: github, i’ve got some public frontend projects on there.