Forem: Atharva Deosthale

Shiny Object Syndrome: Code Edition

Atharva Deosthale — Sat, 13 Jul 2024 20:52:27 +0000

Imagine a little kid going to a toy store. This kid has a ton of options to choose from, and let's forget about the budget for the desired toy. He will roam around the store to find the most exciting thing to play with. He will find one cool Superman toy and quickly grab it. While going back to the counter to finalise the purchase, he would see an RC car. Now, this would be a more exciting choice for him as this is something he has probably never tried before. So, he picks the RC car instead. While moving towards the counter, he finds an RC drone, picks it up and drops the car. Similarly, he gets attracted to many things along the way. The store closes, and the kid turns out not to have made a choice and has nothing in hand while leaving the store.

Do you see the problem here? I see it clearly. The kid had no budget constraint, so he decided to use this opportunity ideally and get the best toy he could enjoy. But he ran out of time and had to go back home empty-handed. He was attracted to every other toy and couldn't make a conclusive decision.

This is called the shiny object syndrome, and it's not just limited to kids or general topics. It also happens in code and a lot more often than you think. This article will examine how a passionate developer gets caught in the shiny object syndrome, how it keeps getting worse and the steps they can take to overcome and escape it.

In code? How exactly?

Developers in this modern era (including myself) often get caught in this. Shiny object syndrome might not necessarily be bad, but for a particular group of developers, it absolutely is, and we will talk about it in this section.

In this modern era, where information is abundant and accessible to developers, we have many choices around us. While scrolling through Tech Twitter (or Tech X), we are bombarded with the latest and greatest news in your favourite field of programming. Especially, if you are a JavaScript developer, you know what I mean.

Everyday, you might find a new framework launching, different people talking about how the framework of their choice is better than the other framework, how is going scratch much better than a framework & vice versa. Then there are feature releases in the newest frameworks that seem like "the thing" which attracts you towards it.

Not targetting anyone, but for example, the Next.js app router is one such case. It's something exciting, somewhat new, so developers naturally get attracted towards all these new things and start to get their hands dirty. Then there are other features that the team keeps putting out that keep attracting you towards them. Then there are other frameworks doing their own innovation and again, you get attracted to them. For someone who is well-versed with programming and knows what he/she is doing, this could be beneficial for them as they get to learn new things regularly, and it's often said that in tech, staying up to date is the key.

But then, there are beginners who also get inside this loop and keep changing their mind about what they want to learn. For beginners, the loop could also be the question of "which programming language to learn?", which they will never figure out as they would keep comparing between the language instead of picking one and learning it. At the end, it's just a waste of time and there's nothing productive the beginner does.

I believe that for a beginner (who is currently not familiar with ANY technology), the priority should be to learn a technology, understand the fundamentals, and then move on to the newest stuff and reason themselves whether the new features are for them or not.

Most of the time, the beginner undergoing this process doesn't even know he/she is trapped under this syndrome, and that's the worst part.

Root cause and why is it unavoidable?

Believe it or not, the root cause of this "shiny object syndrome" is innovation. Now, don't get me wrong, I'm not one of those people who believe that innovation is the root of all evil. In fact, I'm pro-innovation. I think that this syndrome is some kind of side effect of innovation which we cannot escape unconsciously.

If innovation stops, the world stops developing, and it's definitely not the best state to be in. Innovation improves things. That leaves us in a very tough spot because we cannot eliminate the things that cause the shiny object syndrome.

However, there are measures to delay the syndrome (if you are a beginner) and get your fundamentals cleared before jumping onto the next big thing.

The solution

Here are a few things you could do if you are a beginner (or someone who feels distracted while learning to code) to avoid the shiny object syndrome somewhat:

If you are a complete beginner, make sure you create a curriculum in place before jumping to learn. I usually oppose the idea of picking a set curriculum. I could be called a hypocrite here for that. However, I think you should "create" your own curriculum and stick to it if you have issues with committing to some technology during your learning process. Make sure you build projects, too, as these bring you to test your skills.
Social media cannot be ignored if you're a developer. You will keep seeing new stuff, especially on X. The chances of you giving in to the latest & exciting things you see are very high. You can't really blame yourself for trying to learn something new, can you? I think there's one way- giving yourself a set time to learn all the newest innovations. I think I'd go with 2:1 when dividing time between learning something that would clear your fundamentals (something you'd want to learn long term) and something new you want to learn.
Don't be too optimistic about new tech: as much as I understand your urge to get on the ship of learning and using the latest, it's not the best decision because a lot of the times the technology ends up being redundant or not-that-useful. I look at three things before picking up a new thing- the community backing up the technology, any future use-cases specific to the technology and the current age of the technology. If something just launched, I might wait for a few people to get on if the previous two factors turn out to be a negative outcome.

I think these three points could help you avoid shiny object syndrome. Again, it's almost impossible to escape the loop caused by this syndrome if you are a particularly passionate developer.

Conclusion

In this article we saw how the shiny object syndrome plays out for developers passionate about code and the steps they could potentially take to avoid getting trapped in a loop where they learn nothing.

If you would like to add two cents to this article, feel free to comment below. By the way, I also run my own YouTube channel, so if you want coding tutorials mainly in the web development space, make sure you subscribe me there!

Have a nice day, everyone!

Better hydration errors are coming to Next.js!

Atharva Deosthale — Sun, 03 Mar 2024 12:08:49 +0000

Hydration errors have been a complete meme in the web development space. Developers usually criticize the lack of good developer experience when it comes to hydration errors as they didn't use to provide useful errors.... until now.

If you prefer video content, I have uploaded a YouTube video on my channel on the same topic.

Before we move forward if you don't already know what hydration errors are, they are the errors that are displayed when the server renders the React tree, and the initial render by the client is different. However, there are more reasons, and I'd love to link the hydration errors section in the Next.js documentation.

So Guillermo Rauch (CEO of Vercel) recently tweeted the following.

// Detect dark theme var iframe = document.getElementById('tweet-1763597428513804301-737'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1763597428513804301&theme=dark" }

The hydration error diffs displayed in the tweet do really seem pretty cool. They would help many developers spot where the hydration error is coming from, which is a positive step towards the developer experience.

These changes are in the canary version of Next.js that is not recommended for production as it could have bugs.

So I decided to make a sample app with hydration errors and comparing the hydration errors received in the latest stable version vs the canary version.

Reproducing a hydration error

I have reproduced hydration errors using Date. I have made a server component where I'm computing the current Date and passing it to a nested client component.

Following is the code for app/page.tsx.



import ClientComponent from "@/components/client-component";

export default function Home() {
  const date = new Date();

  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <ClientComponent date={date.toString()} />
    </main>
  );
}

Following is the code for client-component.tsx.



"use client";

export default function ClientComponent({ date }: { date: string }) {
  return <div>{Date().toString() || date}</div>;
}

As you can see, ClientComponent is a client component nested inside a server component and being provided a date as prop. The client tries to render Date().toString() and if it fails, it renders the date sent by the server. Now, if we had a real server, the time zones would be different, and it would be an instant hydration error. However, in the dev server, the time zones are same and you need to reload the page a couple of times to see the hydration errors (to get seconds different on the client and server).

Of course, there might be better ways of doing this, but this is just what came to my mind first, so here we go.

Hydration error in the current stable version

Here's the hydration error displayed when I ran the above code using the current stable version of Next.js (14.1.1).

It's not the best error, especially when looking at the new one. However, it's way better than before when we absolutely had no idea what was causing the hydration errors.

Hydration error in the canary version

Please do not use the canary version of Next.js in the production environment. It could result in bugs. This article is using canary version for educational purposes. The new hydration errors will eventually be coming to the stable version.

So, the warnings aside, the command to install the canary version of Next.js is the following.



npm install next@canary

Now, when we run the code, we see the following hydration error.

This is a much cleaner error! We see the exact diff, locate where the error is happening, see what the client and the server are rendering, and fix the error! Well, if you're stuck on some annoying hydration error, I'd recommend checking out Next.js documentation on fixing hydration errors.

Conclusion

Who am I kidding? People will still create memes on hydration errors, and I'm all in for that. Sometimes, they're funny.

On a serious note, I think this is definitely a step towards a better developer experience. Developers have been complaining about the terrible developer experience offered by Next.js ever since the app router and RSC came around. I think with time, things should be fixed.