What fixing front-end bugs has taught me.

2026 Day 125. #TechDays.

The majority of the front-developers are also designers. Life has brought them at the intersection of technology which they use to build UI and streamline the UX. Before getting into this development I believed it was much ‘easier’ than backend. All the data you need is given to you via APIs and hooks, presentations are pretty standard, and to send data back you must put it in a pre-defined structure and you are good to go.

Now I have begun to realise that front-end developers are not simply developing a UI. That is a part of their job but the real engineering work relies behind all this.

A front-end developer must develop a UI that is readable, responsive, and attractive. To stand out they must add animations and transitions. To provide a better UX, they employ more 3rd party operations. To manage SEO they build plugins or use frameworks. They need to optimise the website so it runs on most browsers and devices. Then they need to keep in mind that the website can be accessed by people with a visual or physical disability. They need to manage the states of data and make sure it is consistent across various pages. They need to minimise the load of API calls to the server. They need to clean the data before passing it to a database to prevent attacks. They need to manage authentication, rate-limiting to prevent malicious attackers. In the age of globalisation, they need to look into i18n and work their way through various language based challenges.

The above still does not completely cover the full work of a front-end engineer.

Photo by Sebastian Herrmann on Unsplash

Recently I found a rather interesting but on my website that was caused by my choices. I was building a Next.js project with Lenis Scroll for smooth scrolling, GSAP for animations, and Link from next/Link, which is the native way to do anchor tags in Next.js.

The error was caused by this expected combination. If only I had different syntax choices while writing the same code I would never have seen the issue. It was in the cards that this issue was to fall in my hands.

Here is what I was trying to achieve.

The user is on page1.

They see an image with a link on it that will take them to the relevant section on a different page.

I achieved this via something like

<Link href=“/page2#section3”>…image content…</Link>

This means that the if the user clicked the link, they would be routed to a defined section (section3) on a different page (/page2). Fairly straightforward.

There are multiple sections on page2 each being dynamically generated by passing different data to the same component like so.

{array.map((el: arrayElement,idx: number)=>(
<ReusableComponent prop=el.data/>
))};

The ReusableComponent had a GSAP animation attached to it via the timeline syntax. Here is a simplified version.

 const tl = gsap.timeline({
          scrollTrigger: {
            trigger: section,
            start: "top 80%",
            end: "top 20%",
            scrub: 1.1,
          },
        });

        tl.to(
          {
            y: 96,
          },
          0,
        )… more timeline related code

Here is the initialisation the Lenis

    const lenis = new Lenis({
      smoothWheel: true,
      wheelMultiplier: 1.1,
      touchMultiplier: 1,
      lerp: 0.08,
      anchors: true,
      stopInertiaOnNavigate: true,
    });

The unexpected problem.

Ideally I should have not run into any problems but the bug I faced was inconsistent, broke the linking but slightly differently enough to confuse me.

To describe the issue

The user would click on the link to navigate to the relevant section.

Sometimes it would place the view correctly but the animation would not play.

Other times it would bring the wrong section into view.

In rare cases it would throw an error in the console.

So many different things kept happening. I decided to fix things one by one until it eventually fixed itself.

The fixes.

First I looked into the issue of using Link. Apparently Next.js has often struggled with linking to a separate section on a different page. Navigating to a different section on the same page or to an entirely different works, but navigating to a different section on a different page would cause some issues. I read through multiple GitHub incident reports.

I also looked into the issue with Lenis and anchor tags. Whenever I would scroll to the page I could see in the console that Lenis could not find the relevant section ID on the page and thus failed to scroll to it. The problem seemed evident. I just had to make sure the page was loaded before letting Lenis scroll to the right element.

I added a small handler function that would fetch the page and wait for it to load. Once it was loaded it would push #section3 so that Lenis could bring it into view. This worked better but Lenis would place a completely different section on the view.

Next on carefully reading the Lenis documentation I learned that scroll-behaviour: smooth does not work well with Lenis. I got rid of it and now at least the correct section was being displayed, consistently.

Still the animation would not play.

The error indicated that ScrollTrigger which played/paused the animation could not find the trigger. The page was already being pre-loaded so there was not much I could do here. I was really at a loss.

I kept at it to finally discover the problem.

Using GSAP timeline to animate meant that there were initial offsets to when the animation would start. If I simply removed the timeline syntax and use gsap.fromTo instead, my problem would be solved, and so it was. I theorise that while the layout was loaded when my handler worked it could not confirm if the animation had been setup as well which caused the issue of ScrollTrigger errors and the animation not playing.

Finally I had fixed all the three problems. There was an epic race condition between three errors. All of them caused different problems depending on what executed correctly when.

These are the kind of problems I was taught to solve when using APIs or working with OS schedulers. I never thought I would face a race condition in front-end environments. I never thought innocent looking CSS could cause massive issues with placement. The three third party add ons caused a lot of problems.

I wanted to take this blog as an opportunity to do three things.

1. Help people realise that front-end engineering is more than just design.
2. Help people who might face such issue(s) in the future.
3. Help people know that developers are still and will be relevant.

See you tomorrow.