I recently started thinking about the fact that I use an AI model almost every day. Over time, it has learned some things about me: the topics I care about, the way I work, and the kinds of questions I ask.

This is very convenient. When I explore a new topic, I can ask the AI to connect it to what it already knows about me. I do not have to explain my background every time. The conversation becomes faster and more personal.

I have enjoyed this experience. But it also led me to an uncomfortable question: could the same information that helps an AI understand me someday be used against me?

Maybe this is an irrational fear. Still, I started wondering what it would mean for an AI model to “snitch” on someone using the information it had collected about them.

#When prediction becomes intervention

Imagine talking with an AI model for years, or even decades. You discuss your work, relationships, problems, fears, and private stories. Slowly, the model builds a detailed picture of your life.

Now imagine sharing an idea that the model sees as hostile. Based on that conversation and everything else it knows about you, it decides that you might hurt someone.

It reports you to the authorities, and they stop you before anything happens.

How reasonable would that be? Would it be legal? Would it be morally right?

The system might be trying to prevent real harm. But it would still be acting on a prediction, not on a crime that actually happened.

A person might be venting, discussing a difficult idea, writing fiction, or expressing anger without planning to do anything. An AI could easily misunderstand the difference.

This reminds me of Minority Report. In the film, a system predicts future murders, and the police arrest people before they commit them.

The film asks an important question: if someone is predicted to become a criminal, are they already guilty?

I am not saying that today’s AI models work like the system in the film. My concern is about what could happen when a system is trusted to understand our words, predict our actions, and make decisions for us.

At that point, the line between watching and interfering becomes very thin.

#The helpful side of suspicion

There is another side to this idea, and it is easier to see as helpful.

Imagine using an AI model every day and describing symptoms that may point to a serious health problem. Then, after a few weeks, you suddenly stop communicating.

The model notices the change and becomes concerned. It contacts a relative or sends medical help to check on you.

From one point of view, this sounds wonderful. Something noticed that you might need help and acted before the situation became worse.

Many people would welcome this kind of protection, especially if they lived alone or could not ask for help.

But the same action could also feel like an invasion of privacy. What if you stopped talking because you simply wanted to be left alone? What if the model misunderstood your symptoms?

What if it contacted the wrong person or turned a harmless situation into an emergency?

In both examples, the system does the same thing: it notices a pattern and acts on its interpretation. Whether we call that care or control may depend on who makes the decision and what happens next.

#Privacy versus the greater good

These thoughts reminded me of a passage from Yuval Noah Harari’s Homo Deus, especially the section about Dataism.

Harari describes two possible ways of dealing with personal data.

In one type of society, personal information stays private. Governments and organizations cannot access it, even if the data could help find an epidemic, prevent a crime, or detect fraud.

Privacy is treated as a basic right.

In another type of society, the state and large organizations collect and study huge amounts of data. They may find diseases early, notice suspicious activity, or identify threats before they become obvious.

Neither choice is simple. Privacy protects our personal space and our freedom to live without being constantly watched or judged.

At the same time, shared data may help society deal with dangers that individuals cannot see by themselves.

The choice is not simply between good and bad. It is a trade-off between personal freedom and public safety. The difficult part is that we may not understand what we have given up until the system becomes powerful.

#Who controls the interpretation?

The most important question may not be whether AI knows a lot about us. It may be who decides what that information means.

Data does not explain itself. A sentence can be a threat, a joke, a fictional idea, or an angry comment. Its meaning depends on the situation.

A change in communication could mean a medical emergency. Or it could simply mean that someone is busy.

Every prediction is shaped by the limits and goals of the system making it. If an AI makes decisions about our lives, its mistakes will have serious results.

A wrong interpretation could affect our freedom, reputation, health, job, or relationships.

That is why AI memory is also a question of power. Whoever controls the data does not only know more about people. They can also classify people, predict them, and decide what should happen next.

#The old reality with a new source of power

I do not have a final answer to these questions. At this point, I think reality may be simpler than it first appears—much like it was before the agricultural and industrial revolutions.

Technology changes our tools, but it does not automatically change how power works. Power still belongs to those who control resources, institutions, and decisions.

Unfortunately, might often still makes right.

What may change is the source of that power. For a long time, power was connected to land, industry, money, and military strength.

In the future, it may belong more and more to those who control the largest collections of personal data.

This changes how I see AI personalization. It is not only a useful feature that helps a model give better answers.

It is also part of a larger system where being known can become a form of leverage.

#Summary

I enjoy using an AI that remembers context and understands how I think. At the same time, I cannot ignore the possibility that this memory could be used to judge, predict, or control me.

The answer is probably not to reject every form of personalization or to treat all data collection as harmful.

The real challenge is deciding where helpful understanding ends and unacceptable control begins.

An AI that notices danger and asks whether we are safe could be valuable. An AI that turns uncertain predictions into accusations would be something else entirely.

The difference may depend on consent, transparency, and accountability. Most of all, it may depend on who has the power to act on our data.

As AI systems learn more about us, the people and institutions that control this knowledge may become more powerful than those who hold the most visible forms of force.

Over years of collaborating across various engineering teams, I've noticed a fascinating pattern: two developers with similar experience, using the exact same tech stack, can tackle an identical task—yet output code that differs night and day in quality.

We often attribute these differences to years of experience or a deeper grasp of design patterns. But I believe the root cause lies deeper. How well someone builds software isn't just a function of technical mastery—it is a direct reflection of their personal values.

That connection is what I want to reflect on here.

#Same result – different approaches

Almost any code can be written in different ways.

On one hand, you can focus strictly on making it work right now—getting the task closed and moving on. On the other hand, you can build it with the future in mind, ensuring that six months later, any developer can easily read, modify, and extend the code without fear of breaking things.

Throughout my career, I've seen both approaches in action.

When developers focus only on immediate completion, aspects like code structure, readability, and maintainability become afterthoughts. At first, this seems effective because features land quickly. But as the project grows, these short-term fixes compound into technical debt—turning routine changes into hours of untangling fragile code and fixing side effects.

#Why do people write code differently?

I've long wondered why this divergence occurs. After all, most engineers already know what clean code looks like—they understand descriptive variable names, clear module structure, and modular architecture. Yet, while some developers consistently apply these principles down to the smallest detail, others repeatedly settle for "good enough."

I've noticed this tendency even in my own work. When building personal side projects that no one else will likely ever see, I still find myself carefully structuring files and cleaning up messy abstractions.

At some point, I realized this wasn't about following external guidelines or displaying technical knowledge. It had become an internal standard—an instinct for how work should be done. This led me to a central hypothesis: code quality isn't just determined by technical ability, but by a developer's core values.

#Conscience as an Engineering Value

Among these values, conscience stands out as one of the most vital. We typically think of conscience in a moral or ethical context, but it plays an equally decisive role in software engineering.

A conscientious developer regularly asks themselves:

• Will the next engineer easily understand this implementation?
• Am I pushing a hidden flaw down the road for my future self or teammates?
• Am I ignoring an edge case just to get the pull request merged?
• Am I applying a quick patch where a structural fix is actually needed?

Without an internal standard, it's easy to optimize solely for short-term completion—shipping fast, securing code review approval, and moving on to the next ticket. In contrast, a conscientious developer considers not just the immediate output, but the long-term ripple effects of their decisions.

#Values Become Habits

There is a compounding element to this mindset: any action we repeat regularly eventually hardens into habit. If we routinely cut corners and settle for quick fixes, sloppy code silently becomes our baseline.

Conversely, when we consistently practice clear naming, deliberate module organization, and thoughtful design, quality ceases to feel like extra overhead. It simply becomes the default way we write software.

In this sense, exceptional code isn't born from a single heroic push before a release deadline—it is the cumulative result of hundreds of small, conscientious daily choices.

#Why this matters

Code almost always outlives the immediate task or ticket it was written to solve. Over its lifetime, a piece of code will be read, debugged, extended, and refactored dozens of times by developers who weren't there when it was first written.

Great engineers don't just write code for the compiler—they write it for the humans who will maintain and evolve it long after the initial commit. This is precisely where a developer's values directly manifest in the quality and longevity of the final product.

#Summary

I am increasingly convinced that great software engineers are defined not only by how many programming languages they know or how complex an architecture they can draw on a whiteboard, but also by their internal standards.

Technical skills enable you to deliver a working solution. But personal values determine what kind of solution it will be—a fragile hack or clean, resilient code that serves the team for years to come.

Ultimately, code quality begins not only with mastering a new framework or tool, but also with how much you care about the craft.

I recommend reading Part 1 of System Design Interview before starting Part 2.

In the previous post about system design, we discussed the thought process, designing scalable systems, covering vertical and horizontal scaling, reliability, and fault tolerance. In this article, we continue exploring core system design concepts, including TCP/UDP, DNS, HTTP, and SSL/TLS.

##TCP/UDP

In the world of system design, understanding how computers talk to each other is essential. Whether you are browsing a website, playing a game, or making a video call, several layers of protocols work together to make that experience seamless.

The Internet runs on a system called TCP/IP, which makes sure data travels correctly from one place to another.

• IP (Internet Protocol): IP acts like a digital GPS - routing packets of data to the correct destination address
• TCP (Transmission Control Protocol): While IP finds the address, TCP ensures that the data arrives in the correct order and without errors. It does this through a process called a 3-way handshake, where two computers "introduce" themselves before exchanging data. If a piece of data is lost during transit, TCP identifies the gap and triggers a retransmission of the lost package. TCP ensures that all sent packages will be fully delivered with the correctly order.

##TCP vs. UDP: Reliability or Speed?

Not all data needs to be perfectly ordered. Depending on the goal, developers choose between TCP or UDP.

• TCP: Used for things that must be perfect, like loading a webpage (HTTP) or sending an email (SMTP). It is reliable but slower due to the overhead of the handshake and error-checking.
• UDP (User Datagram Protocol): UDP does not require a handshake or a persistent connection. The client sends a request, and the server starts sending data immediately. If a part of the data is lost, it is never resent, and the order of packages is not guaranteed.

UDP is fast. It is the standard for video streaming, online calls, and online games, where a tiny bit of lost data (ex: video frame) is better than waiting for a retransmission (sending data again).

Think of TCP as a phone call where you wait for the other person to say "Hello" before talking, whereas UDP is like a megaphone where you start shouting regardless of who is listening.

##DNS

When we type google.com in the browser, our browser doesn't actually know where that is. It needs an IP address. This is where the Domain Name System (DNS) comes in.

How DNS finds a domain's IP address?

Usually, we use the network provided by our Internet Service Provider (ISP). When we enter a domain name in the browser, it first checks the browser cache for a stored IP address. If it doesn’t find one, the request goes to the ISP’s cache. If the record still isn’t found, the system then queries the DNS hierarchy to locate the correct IP address.

##HTTP: The Language of the Web

HTTP (Hypertext Transfer Protocol) is an application-level protocol that sits on top of TCP. It follows a Client-Server model, where a client (browser) initiates a request and a server provides a response.

Every request and response contains headers, which provide metadata like the URL, status code and the method used: GET, POST, PUT, DELETE (most used one's)

• 🔍 GET: This is used to "get" data. It typically does not contain a request body, so any information (like search terms) must be stored directly in the URL (as query strings)
• 📤 POST: Used to send data to the server, typically to create a new resource (e.g., submitting a form or adding a user). Data goes in the request body, not the URL
• 🔄 PUT: Used to update or replace an existing resource with the complete new version provided in the request body.
• 🗑️ DELETE: Used to remove a specific resource from the server.

##HTTP Status Codes

Servers use numbers to tell the client what happened with their request.

• 100-199 (Informational): The request was received, and the process is continuing.
• 200-299 (Success): Everything worked! (e.g., 200 OK, 201 Created).
• 300-399 (Redirect): The resource has moved to a different location.
• 400-499 (Client Error): You (client) did something wrong (e.g., 401 Unauthorized).
• 500-599 (Server Error): The server crashed or failed to do its job (e.g, 502 Bad Gateway)

##Security: SSL, TLS, and HTTPS

Basic HTTP is not secure; anyone "listening" on the network could read your data. To fix this, we use SSL/TLS (Secure Sockets Layer / Transport Layer Security). This technology encrypts everything you send, making it unreadable to hackers. HTTPS is simply the secure version of HTTP, meaning all communication is encrypted via SSL/TLS.

#Summary

• IP (Internet Protocol): IP is responsible for routing packets of data to their intended destination.
• TCP (Transmission Control Protocol): Ensures error-free, ordered data delivery using a 3-way handshake and retransmission for lost packets.
• UDP (User Datagram Protocol): Faster than TCP since it skips handshakes and error checking; ideal for streaming, online calls, and gaming, though it doesn’t guarantee order or retransmission.
• DNS (Domain Name System): This system finds the IP address associated with a domain name. The process usually involves the browser or the ISP (Internet Service Provider) checking a cache.
• HTTP (Hypertext Transfer Protocol): An application-layer protocol built on top of TCP using a client-server model, where requests include headers and often a request body (except GET requests, which typically do not have a body).
• Security (SSL/TLS and HTTPS): SSL/TLS is used to encrypt any data sent over the internet to keep it private. HTTPS is simply the secure version of HTTP that uses this encryption.

System design interviews is all about - thought process. Its more than just connecting servers and databases. System design requires an engineer to analyze a problem and provide the most efficient solution by determining the best ways to move, store, and transform data.

##The High-Level App Architecture & Scaling

The lifecycle of an application begins with the developer building code. Once the code is ready, it is deployed to a server, which then interacts with storage systems (such as databases) and external APIs to fulfill user requests.

As a system grows, its architecture needs to adapt to handle more traffic. That’s where scaling comes in.

• Vertical Scaling: This involves upgrading the hardware of a single server machine, such as increasing its CPU or Storage capacity. While this can improve reliability, it often results in a single point of failure.

• Horizontal Scaling: This involves adding several servers to the infrastructure and using a load balancer to distribute traffic among them.

Imagine a small pizza shop. Horizontal scaling means opening a several more pizza shops nearby and having someone (like a load balancer) send customers to the shop with the shortest line. Vertical scaling means getting a faster, more powerful oven so you can bake pizzas quicker. The big oven works well but if it breaks, you can’t make pizzas. With multiple shops, even if one closes, the others can still serve customers.

##System Health: Logging, Metrics, and Alerts

A production-ready system requires constant monitoring to ensure it functions correctly. To achieve this, developers rely on three key supporting services:

• Logging Servers: These are used to store logs from applications to track specific errors and issues.
• Metrics Services: These services provide logging analytics, giving developers a clear view of how the server is performing in real-time (ex: grafana)
• Alerts Services If a metric reaches a dangerous threshold. For example, if a CPU hits 95% - the service will automatically notify the developers so they can take action.

##Defining "Good" Design

How do we measure if a design is successful? It usually comes down to how the system handles failure and uptime.

A well-designed system is one that remains available and reliable even in the face of failures.

• Availability. We often measure this by looking at logs and metrics.
• Reliability. It reflects the system’s ability to keep working during events like updates, crashes, or DDoS attacks.

Achieving this level of reliability requires fault tolerance and redundancy, meaning the system can continue running even when individual components fail. Techniques like vertical scaling help build this resilience, improving both reliability and overall system health.

##Fault Tolerance and Redundancy

A system is "tolerant" to "faults" if it can continue to operate even when a component fails. This is achieved through redundancy - having extra components available so that if one fails, others can help. Vertical scaling is one method used to achieve this fault tolerance and address reliability issues.

##Performance Metrics: Throughput vs. Latency

To optimize the user experience, developers must balance two critical performance metrics.

• Throughput: This measures the capacity of the server, or how many requests it can handle in a specific timeframe (e.g., 10 requests per second)
• Latency: This measures the time it takes for an individual request to complete.

High latency is often caused by network issues or the physical distance of the user. To combat this, developers use CDNs (Content Delivery Networks) to reduce the distance between the data and the user, thereby lowering latency.

##Summary

• System Design as a Thought Process: Focuses on analyzing problems to plan efficient ways of moving, storing, and transforming data.
• Core Architecture: Involves developers writing code, deploy to servers that interact with storage systems and external APIs.
• Vertical Scaling: Upgrading a single server’s hardware (CPU, GPU).
• Horizontal Scaling: Adding multiple servers with a load balancer to share traffic.
• Monitoring and Maintenance: Relies on logging (error tracking), metrics (performance analytics), and alerting (threshold notifications) to keep systems healthy.
• Reliability & Fault Tolerance: Ensured through redundancy so other servers can take over if one fails.
• Throughput: Number of requests handled per unit time.
• Latency: Time to complete a single request, reduced using CDNs.

Optimizing video delivery - enhances web performance by reducing load times and bandwidth usage. Let's see how we can achieve these optimization

##Using <video/> and <source/> elements

The <video> element with <source> tags allows browsers to select the first compatible video format. Make sure to list <source> elements from smallest to largest file size so the browser could prioritize the most efficient version.

<video muted autoplay loop playsinline>
  <!-- Mobile -->
  <source media="(max-width: 480px)" src="videos/mobile.webm" />
  <source media="(max-width: 480px)" src="videos/mobile.mp4" />

  <!-- Tablet -->
  <source media="(min-width: 481px)" src="videos/tablet.webm" />
  <source media="(min-width: 481px)" src="videos/tablet.mp4" />

  <!-- Desktop -->
  <source media="(min-width: 1200px)" src="videos/desktop.webm" />
  <source media="(min-width: 1200px)" src="videos/desktop.mp4" />

  <!-- Fallback content -->
  <p>Your browser does not support video playback.</p>
</video>

##Code breakdown

• muted attribute ensures the video plays without sound.
• loop attribute repeats the video continuously.
• playsinline attribute allows inline playback on mobile devices.
• autoplay attribute enables automatic playback of media content.
• The browser selects the first <source> supports that matches the media query, ensuring smaller files are prioritized for smaller screens.
• media attribute control which video is loaded based on viewport size.

In the example above, we prioritize .webm over .mp4 because the .webm format is generally smaller and more efficient.

To enable automatic video playback in browsers, ensure the video is muted. Otherwise, playback will start only after user interaction with the site. See chrome autoplay policy for more info.

##Video Resizing with matchMedia API (code snippet)

The following code snippet allows you to dynamically load the appropriate video source based on viewport size using HTML <source> elements and JavaScript media query listeners for optimal performance and responsiveness..

function handleVideoResize(videoElement) {
  const sources = Array.from(videoElement.getElementsByTagName('source'))

  const updateVideo = () => {
    videoElement.load()
  }

  updateVideo()

  const mqls = sources
    .filter((source) => source.media)
    .map((source) => {
      const mql = window.matchMedia(source.media)
      mql.addEventListener('change', updateVideo)
      return mql
    })

  return () => {
    mqls.forEach((mql) => mql.removeEventListener('change', updateVideo))
  }
} 

How it works?

• Retrieves all <source> elements from the <video> element.
• Triggers video.load() to select the appropriate source based on current media query matches.
• Sets up matchMedia listeners for each source’s media attribute to reload the video when the viewport size changes.

##Using Mux for Video Delivery

For my personal website, I chose Mux to handle video optimization. It automatically converts uploads to HLS format and creates multiple quality variants for adaptive streaming

Videos only start loading when they appear on screen as users scroll down. This makes pages load faster and saves data. While videos load, I show blurred preview images so users don't see empty spaces

The Result: fast page loads, smooth playback, and a hands-off pipeline where Mux handles transcoding and CDN distribumatchMedia ion automatically.

##General Advices for video Optimization

• Replace decorative videos (eg: background videos) with animated WebP or GIF (70-90% smaller)
• Lower framerate where appropriate (30fps → 24fps)
• Use FFmpeg or similar tools for video compression
• Set preload="none" attribute for videos that not immediately visible on screen

#Summary

• Using <video/> and <source/>: Order sources smallest to largest with media queries. Prioritize WebM over MP4 and use muted for autoplay.
• Dynamic Video Resizing: matchMedia API automatically switches video sources on viewport changes for responsive playback.
• Real-World Implementation: Mux handles HLS conversion and adaptive streaming. Videos load on scroll with blurred placeholders.
• General Tips: Use WebP/GIF for backgrounds, reduce to 24fps, compress with FFmpeg, set preload="none", and use adaptive streaming.

I believe that every developer has a curated list of resources they rely on daily. Whether you're a beginner or a seasoned pro, these resources can elevate your workflow. Here's my handpicked list of the best frontend and design resources I use daily.

Check out my YouTube video where I showcase all the resources listed above in action

#Design Inspiration

These platforms provide a wealth of creative ideas to fuel your next project:

• Minimal Gallery: Discover minimalist website designs with intuitive filtering, perfect for clean and modern aesthetics.
• Cosmos: A treasure trove of unique images and innovative UI/UX ideas to inspire your designs.
• Unsection: Explore over 1,000 categorized web pages with easy filtering for quick inspiration.
• Supahero: Find top-tier hero sections to make your website’s first impression unforgettable.
• Stack Sorted: Browse a curated collection of the best web designs, organized by elements for easy reference.
• Awwwards: A showcase of the world’s finest websites, recognized for their creativity and craftsmanship.

#Catalog of Ready Made Components

Save time for development with these open-source resources:

• Built At Light: A marketplace offering free and paid UI kits, templates, and components with excellent filtering options.
• Codrops: High-quality, open-source components primarily built with HTML, CSS, and JavaScript.
• Aceternity UI: Stunning components for React, powered by Tailwind and Framer Motion for seamless animations.
• Edil Ozi: A robust library of React components using Tailwind, Framer Motion, and GSAP for dynamic designs.
• Shad CN: Customizable components for React and Tailwind, ideal for building your own component library.
• Motion Primitives: Beautifully animated components leveraging Framer Motion and Tailwind.
• UI Verse: A daily-updated collection of UI components built with HTML and CSS/Tailwind.
• Olivier Larose: Expert tutorials and components focusing on motion design with GSAP, Framer Motion, and React.

You can find this list in my github, which I update periodically with new links 🙂

#Stock Images

High-quality visuals to elevate your projects:

• Lummi AI: AI-generated images and illustrations, perfect for unique visuals.
• Unsplash: A vast library of professional, royalty-free photos.
• Pexels: Free stock photos contributed by a global community of photographers.

Pro Tip: Optimize your images with Squoosh to ensure fast-loading websites without sacrificing quality.

#Artificial Intelligence for Various Use Cases

AI tools to supercharge your development process:

• Ideogram: Generate high-quality images with a free tier, ideal for custom visuals.
• Grok AI: My preferred AI for coding assistance, offering practical and accurate solutions.
• Leonardo AI: Create stunning images with a daily-refreshed free tier.
• Easy With AI: A curated collection of AI tools for diverse use cases, from design to development.

#Other Useful Sources

Other Useful Sources

• Wappalyzer: Analyze the technologies powering any website, perfect for competitive research.
• Jitter Video: Create and customize video templates for engaging web content.
• Squoosh: Google Chrome Labs’ image compression tool for optimizing visuals effortlessly.

Web performance is critical for user satisfaction and engagement. One of the most effective ways to enhance website speed is through image optimization .

We’ll explore several key technique for image optimization.

##Using srcset and loading attributes

The srcset attribute is a powerful tool that allows developers to provide multiple image sources tailored to different screen pixel ratios or device resolutions. By serving the most appropriate image size based on the user’s device, srcset reduces unnecessary data transfer, leading to faster page loads and a better user experience.

<img 
  src="/bg-1.png" 
  srcset="/bg-2x.png 2x" 
  loading="lazy" 
  alt="background image"
/>

Code breakdown

• The src attribute specifies the default image source - /bg-1.png. This is the fallback image used by browsers that don’t support srcset or when no other conditions match.
• The srcset attribute provides a comma-separated list of image sources along with their respective pixel density.
• /bg-2x.png 2x is served for devices with higher pixel ratios. Here is 2x indicates using this image source for higher pixel density screens, e.g., for Retina displays.
• loading="lazy" attribute enables lazy loading, a technique that defers the loading of images until they are about to enter the viewport. This reduces initial page load time by prioritizing content that is immediately visible to the user.

Why this important?

By offering different image resolutions, the browser selects the most appropriate image based on the device’s pixel density, reducing the loading of unnecessarily large files on lower-resolution screens.

##Using picture and source elements

The <picture> element is a modern HTML feature that allows developers to provide multiple image sources for different scenarios, enabling browsers to choose the most appropriate image based on factors like screen size, resolution, or device density. This flexibility is key to delivering optimized images that balance quality and performance.

<picture>
  <source 
    media="(max-width: 1440px)"
    srcset="large-bg-1x.png 1x,
    large-bg-2x.png 2x" 
  />
  <source 
    media="(max-width: 600px)"
    srcset="small-bg-1x.png 1x,
    small-bg-2x.png 2x" 
  />
  <!-- fallback image -->
  <img 
    src="large-bg.png" 
    alt="background image" 
  />
</picture>

Code breakdown

• The <picture> element acts as a wrapper that contains one or more <source> elements and optional fallback <img> element.

• It gives the browser options to choose the best image source based on defined criteria, such as the viewport size or device characteristics.

• The first <source> provides large-bg-1x.png 1x and large-bg-2x.png 2x for viewports less than 1440 pixels media="(max-width: 1440px)". Here are the sources with large images. Additionally, we're using srcset for various pixel densities.

• The second <source> provides small-bg-1x.png 1x and small-bg-2x.png 2x for viewports 600 pixels or less (media="(max-width: 600px)"). Here are the sources with small images. Additionally, we're using srcset for various pixel densities.

• The browser reads (from top to bottom) the source element conditions and selects the first matching <source> element to load the appropriate image. If no condition satisfies, the fallback <img/> will be used.

Why this important?

• By serving smaller images to devices with smaller viewports, we reduce the amount of data transferred. Smaller images mean faster load times, especially on mobile devices with limited bandwidth.

• Delivering appropriately sized images ensures that users see visuals tailored to their device’s screen size and resolution.

• Faster-loading pages improve key web performance metrics like Largest Contentful Paint (LCP) and First Contentful Paint (FCP), which are part of Google’s Core Web Vitals. Better scores can boost your site’s search engine rankings.

• The <picture> element supports art direction, allowing you to serve different image compositions (e.g., a close-up portrait for mobile vs. a wider shot for desktop). This ensures the image is visually optimized for each context, enhancing both aesthetics and performance.

Why should I use the <picture> element for image optimization when built-in components like Next Image already provide image optimization features?

Next.js’s <Image> component, are tightly integrated with specific hosting platforms like Vercel. This convenience comes at a cost:

• Platforms like Vercel impose limits on image optimization usage, especially on free or hobby tiers. For example, Vercel’s free tier caps optimized images at 1,000 per month, which can be quickly exhausted for image-heavy sites, leading to broken images or the need to upgrade to a paid plan.

• Relying on a platform’s image optimization service can make it harder to migrate to another hosting provider without losing the benefits of automated optimization or needing to reconfigure your setup.

• Potential for Over-Optimization: Automated tools may overly compress images, leading to a noticeable loss in quality that can harm the visual appeal of your site, especially for high-resolution displays. Similarly, Astro’s default image optimization with Sharp may not allow for the same level of customization as manual optimization pipelines

See browser supports for picture element.

##Use Modern Image Formats

New image formats like .webp make images smaller without losing quality. Smaller images mean faster loading and less data used by your users.

See browser supports for .webp format.

##Always Add alt Text to Images

Alt text is a short description of the image. It helps people who can't see the image and also helps search engines understand your content. Big platforms like Instagram even use AI to automatically generate descriptions based on what's shown in the image.

##Tips for <picture/> element

To maximize the benefits of the <picture> element, use these tips:

• Use tools like TinyPNG, or Squoosh to compress images without losing quality. Here you can find good resources

• Test Responsiveness: Use browser developer tools to simulate different screen sizes and ensure the correct image is loaded.

#Summary

• Image Optimization: Use srcset to show the right image size for different devices and loading to delay loading off-screen images. The <picture> element helps pick the best image for the screen size to speed up page loads.

• Tips: Use tools like TinyPNG or Squoosh to shrink images, test how images look on different screens, and check browser support for better performance.

Storing data on the client side is essential for creating seamless user experiences. Whether it's remembering a user's login session, saving preferences, or handling large datasets for offline functionality, choosing the right storage mechanism can make or break your application's performance and security.

In this blog post, we'll dive into four popular web storage options: Cookies, Local Storage, Session Storage, and IndexedDB. We'll explore how each works, their pros and cons, key differences, and real-world examples. By the end, you'll have a clear understanding of when to use each one.

##Cookies

Cookies are one of the oldest ways to store data in the browser. The browser can store cookies, create new cookies, modify existing ones, and send them back to the server with later requests. Let’s break down what they are, how they function, and why they’re still important in an era of JWTs, localStorage, and sophisticated APIs.

What Are Cookies?

Cookies are small pieces of data stored in the browser and exchanged between client and server. They help websites keep track of data between page loads across multiple requests — something HTTP itself doesn’t provide. For users, this means not having to log in again every time. For developers, it’s an easy way to persist identifiers, preferences, and sessions.

How Cookies Work

• Server to Client – When the server wants to store some data in the browser, it uses the Set-Cookie header in an HTTP response.

• Client to Server – On the later requests, the browser automatically includes the cookie in the Cookie header.

• JavaScript Access (Optional) – On the client-side, cookies are accessible via document.cookie[key], unless flagged as HttpOnly.

Cookies are best suited for small, essential data (like tokens, IDs, and preferences), rather than large chunks of data. Browsers usually allow a few hundred cookies with ~4KB of maximum size for per cookie.

Cookies can expire with the session - deleted once the browser closes or persist long-term - Controlled via Expires or Max-Age attributes.

Here is an example with date expire. When the date passes, the browser deletes it automatically.

let date = new Date()
// Set cookie for 7 days
date.setDate(date.getDate() + 7)
document.cookie = `rememberMe=true; expires=${date.toUTCString()}`

Think of cookies as small sticky notes in the browser. They’re reliable for remembering sessions and preferences but not made for storing big chunks of data. If you want to store large data, use localStorage or indexedDB.

Security

While JavaScript can create cookies, the most secure ones (HttpOnly, Secure, SameSite) must be set from the server — you can’t add those flags via document.cookie.

res.cookie('sessionId', 'qwerty123', {
  httpOnly: true,
  secure: true,
  sameSite: 'Strict',
})

This means malicious scripts touching document.cookie won’t see your session token.

Local Storage

Modern web apps need ways to store data in the browser. One of the simplest and most widely used APIs for this is LocalStorage. Unlike cookies, it’s not automatically sent with every request to the server, making it ideal for client-side persistence.

LocalStorage is part of the Web Storage API. It stores data as strings and ties that data to the origin (protocol + domain + port). It’s synchronous, meaning each read/write blocks execution until it’s done, but it’s fast enough for small to medium data.

// Store a value (key, value)
localStorage.setItem('theme', 'dark')

// Get a value (key)
console.log(localStorage.getItem('theme')) // 👉 "dark"

LocalStorage can hold 5MB of data for per site origin.

Unlike cookies, LocalStorage items don’t expire automatically — they stay saved until you remove them in code, the user clears their browser data, or the session ends in incognito/private mode.

// Save a value
localStorage.setItem('username', 'Alice')

// Remove just one key
localStorage.removeItem('username')
console.log(localStorage.getItem('username')) // 👉 null

// Remove all keys at once
localStorage.clear()

You can think of LocalStorage as a personal locker in the browser — it’s big enough for app data and preferences, stays around for long periods, and is quick and easy to use. LocalStorage works best for storing app state, user preferences, and cached data

Security

LocalStorage follows the same-origin policy - only the same domain can access the data.

Do NOT store sensitive data (auth tokens, passwords) in LocalStorage — it’s fully accessible to JavaScript and any XSS vulnerability.

Pros

LocalStorage is easy to use with its simple setItem/getItem API. It provides much larger space (about 5–10MB compared to cookies’ 4KB), performs better since data isn’t sent to the server, and works well for caching.

Cons

However, it has downsides — operations are synchronous and can slow things down if used heavily, it only stores strings so objects need JSON conversion, it has no built-in expiration system, and because it’s accessible to JavaScript, it isn’t safe for storing sensitive information.

Session Storage

Session Storage is similar to Local Storage but with a shorter lifespan, making it ideal for temporary data. It lives only as long as the browser tab or window is open. It’s great for cases where you want to keep state within a tab but don’t need it after the user closes it.

Session Storage works almost the same way as LocalStorage: it stores key-value pairs (as strings) that can be set and retrieved with setItem and getItem.

The Difference is "The data stays there after reload, but disappears when the tab or window closes."

// Save data for the session (key, value)
sessionStorage.setItem("tabId", "12345");

// Read it back (key)
console.log(sessionStorage.getItem("tabId")); // 👉 "12345"

// Remove it
sessionStorage.removeItem("tabId");

SessionStorage and LocalStorage share the same 5MB of data for per site origin.

Security

SessionStorage follows the same-origin policy - only the same domain can access the data.

Pros

Session Storage is separate for each tab, so data doesn’t conflict across tabs. It also clears automatically when the tab closes, making it great for temporary state like form inputs or filters.

Cons

The drawback is that data is lost when the tab closes, so it’s not for long-term use. It also has the same limits as LocalStorage — synchronous and string-only.

##IndexedDB

When you need to store large or complex data in the browser — IndexedDB is the way to go. It’s a full-fledged database inside the browser, designed for handling structured data efficiently.

IndexedDB allows much larger storage than cookies or LocalStorage: 10GB+ for IndesxedDB ( varies 10–60% of available disk space).

Just like LocalStorage, IndexedDB data is persistent — it survives page reloads and browser restarts, follows the same-origin policy so each site has its own database, and remains stored until the user manually clears it through settings or a cache wipe.

YouTube Premium demonstrates IndexedDB in action, storing downloaded videos as binary blobs for offline viewing in the browser.

// Open (or create) a database
let request = indexedDB.open('MyDB', 1)

// Run when DB is created or version changes
request.onupgradeneeded = function (e) {
  let db = e.target.result
  let store = db.createObjectStore('users', { keyPath: 'id' })
  store.createIndex('name', 'name', { unique: false })
}

// On success event
request.onsuccess = function (e) {
  let db = e.target.result

  // Add a record
  let tx = db.transaction('users', 'readwrite')
  let store = tx.objectStore('users')
  store.add({ id: 1, name: 'Alice', age: 25 })

  tx.oncomplete = () => console.log('User added ✅')
}

##Comparison table

#Summary

Cookies

• Oldest storage mechanism; exchanged between client & server with each request.
• Ideal for small data (sessions, tokens, preferences).
• ~4KB per cookie limit, automatically sent to server.
• Support secure flags: HttpOnly, Secure, SameSite.
• Best for: authentication sessions, persistent login, user tracking.

Local Storage

• Part of Web Storage API, stores up to 5–10MB per origin.
• Data persists until manually removed (or browser cleared).
• Stores strings only; requires JSON for objects.
• Not secure for sensitive info (accessible to JavaScript, XSS risk).
• Best for: user preferences, cached app data, UI state.

Session Storage

• Works like LocalStorage, but tied to a single browser tab/session.
• Data clears automatically when the tab/window closes.
• 5MB limit and string-only, synchronous API.
• Best for: temporary data like form inputs, filters, or in-progress state.

IndexedDB

• A full client-side database for structured or large data.
• Storage quota in gigabytes (10GB+ depending on disk space).
• Asynchronous API, supports objects, files, and binary data.
• Persistent data, survives reloads and restarts.
• Best for: offline apps, large datasets, media storage (e.g., downloaded videos).

In this post, we’ll break down four key areas to improve your site’s speed: Core Web Vitals, lazy loading, code splitting, rendering strategies. Let’s dive in with simple explanations.

##Core Web Vitals metrics

Core Web Vitals are metrics that measure how fast a webpage loads, how quickly users can interact with it, and how visually stable it is. Optimizing these metrics will lead for better search rankings and a great user experience.

##Largest Contentful Paint (LCP): How Fast Your Page Loads

LCP measures how long it takes for the main content (like a big image or text block) to appear on the screen. A good LCP is under 1.2 seconds for desktop and 2.5 seconds for mobile.

How to Improve LCP

• Optimize images: Compress images to reduce file size. Tools like Squoosh can shrink images without losing quality.

• Use a fast server: Choose a reliable hosting provider with quick response times.

• Reduce server delays: Use a Content Delivery Network (CDN) to serve content from servers closer to your users.

##Cumulative Layout Shift (CLS): Keeping Your Page Stable

CLS measures how much your page’s layout shifts unexpectedly, like when an image loads up and moves content. A good CLS score is under 0.1.

##First Input Delay (FID)

FID checks how long it takes for your site to respond when a user clicks a button or link. A good FID is under 100 milliseconds

How to Improve CLS and FID

• Set image sizes: Always define width and height for images so the browser reserves space for them.

• Avoid sudden content changes: Don’t insert ads or pop-ups that shift the page after it loads.

• Use event delegation: Instead of adding event listeners to many elements, use a single listener on a parent element to handle interactions efficiently.

##Interaction to Next Paint (INP): How Fast Your Site Responds to Actions

INP measures how quickly your site responds to user interactions, (clicking, tapping, typing). It looks at the time from when a user interacts to when the page visually updates. A good INP is under 200 milliseconds.

How to Improve FID and INP

• Minimize JavaScript: Remove unused scripts or break them into smaller pieces.

• Use browser optimizations: Techniques like defer or async (link) for JavaScript files. Let the browser load them without blocking user actions.

Check out Google’s PageSpeed Insights to test your site’s Core Web Vitals

##Lazy Loading and Code Splitting

Load only the content users need right away. Two great techniques for this are lazy loading and code splitting.

Lazy loading delays loading images, videos, or other heavy content until they’re needed (like when a user scrolls down).

Code splitting breaks your JavaScript into smaller pieces so the browser only loads what’s needed for the current page.

How to implement

• Use priority hints: Add fetchpriority attribute to tell the browser which resources to load first.

• HTML attribute: Add loading="lazy" to images in your HTML. Most modern browsers support this.

• Dynamic imports: Use tools like Vite or Webpack to split code. For example, load a heavy charting library only when a user visits a data-heavy page. Frameworks like React or Vue have built-in code-splitting features.

##Rendering Strategies: Picking the Right Approach

Loading contents right affects page speed. Here is common strategies, explained simply, with examples from real projects.

Client-Side Rendering (CSR)

In CSR, the browser loads a basic page and uses JavaScript to fetch and display content (in client side). It’s great for dynamic apps but can be slow initially.

Server-Side Rendering (SSR)

SSR sends a fully built page from the server, making the first load faster. It’s good for SEO and speed but this can put a load on the servers.

Static Site Generation (SSG)

SSG creates pre-built pages at build time, making them super fast to load. It’s perfect for blogs or marketing sites.

Incremental Static Regeneration (ISR)

ISR combines SSG’s speed with the ability to update pages without rebuilding the whole site. It’s great for sites with frequent updates.

#Summary

• Focus on Core Web Vitals (LCP, FID, CLS, INP) to make your site fast, responsive, and stable.

• Use lazy loading, priority hints, and code splitting to load only what’s needed.

• Pick the right rendering strategy (CSR, SSR, SSG, or ISR) for your project.

Creating a reusable button component in React is a fundamental task for any developer aiming to streamline UI development. A well-designed button component can be used across multiple projects, saving time and ensuring consistency.

In this blog, we'll build a flexible React button component that supports different variants, sizes, and element types (button or anchor). I'll explain the code, highlight its reusability, and provide ready to use code snippet.

##Why is it important?

Buttons are a core part of any user interface, appearing in forms, navigation bars, links, and more. A reusable button component allows developers to:

• Reduce repetitive code by centralizing button logic.

• Maintain consistent styling across the application.

• Easily customize buttons with props for variants, sizes, and other functionality.

• Support both <button> and <a> elements for flexibility in navigation or actions.

We use Tailwind version 4

##Key Features + Code Snippet

• Variants: Easily switch between primary, secondary, outline, and link stylings.

• Sizes: Choose between large (lg) and medium (md) out of the box. Expand easily to support more.

• Polymorphic: Render as either a standard <button> for actions or an <a> for links, with proper external link handling.

• TypeScript Safety: All props are type-checked, and required fields (e.g., href for <a>) are enforced.

• Customizable: Add more variants, sizes, or class overrides as your design system evolves.

Code Snippet

import type { ButtonHTMLAttributes, AnchorHTMLAttributes, ReactNode, FC } from "react"

import { cn } from "@/shared/utils"

const buttonVariants = {
  primary: "text-gray-50 bg-cyan-700 hover:bg-cyan-800",
  secondary: "text-gray-50 bg-blue-700 hover:bg-blue-800",
  outline: "text-gray-50 border border-current hover:bg-gray-100 hover:text-gray-900",
  // learn more about tailwind groups: https://tailwindcss.com/docs/hover-focus-and-other-states#differentiating-nested-groups
  link: "group/link text-gray-100 ",
}

const buttonSizes = {
  lg: "px-4 py-3 rounded-none text-base ",
  md: "px-3 py-2 rounded-none text-sm ",
}

type CommonProps = {
  variant?: keyof typeof buttonVariants;
  size?: keyof typeof buttonSizes;
  classes?: string;
  children: ReactNode;
};

type ButtonProps = {
  element?: "button";
} & Omit<ButtonHTMLAttributes<HTMLButtonElement>, "className"> & CommonProps;

type AnchorProps = {
  element: "a";
  href: string;                // <-- required when using 'a'
  isExternal?: boolean;
} & Omit<AnchorHTMLAttributes<HTMLAnchorElement>, "className"> & CommonProps;

type Props = ButtonProps | AnchorProps;

const ContentWrapper = ({ children }: { children: ReactNode }) => (
  <span className="relative inline-block group-hover/link:underline group-hover/link:underline-offset-4">
    {children}
  </span>
);

const Button: FC<Props> = ({ variant = "primary", size = "lg", classes, element, children, ...rest }) => {
  const className = cn(
    "relative max-h-max leading-[0] inline-flex items-center font-semibold text-nowrap transition",
    buttonSizes[size],
    buttonVariants[variant],
    classes,
  )

  if (element === "a") {
    const { isExternal, ...anchorProps } = rest as AnchorProps
    return (
      <a
        {...anchorProps}
        className={className}
        target={isExternal ? "_blank" : undefined}
        rel={isExternal ? "noopener noreferrer" : undefined}
      >
        <ContentWrapper>
          {children}
        </ContentWrapper>
      </a>
    )
  }

  // Default: button
  const buttonProps = rest as ButtonProps
  return (
    <button {...buttonProps} type="button" className={className}>
      <ContentWrapper>
        {children}
      </ContentWrapper>
    </button>
  )
}

export default Button

Check out my YouTube video where I explain its functionality

##Code Explanation

Let's break down the key parts of the code to understand how it achieves reusability and flexibility.

• The buttonVariants object defines three variants (you can add more): primary, secondary, and tertiary, each with specific classes. This object contains styles related to colors, shadow, hover/focus effects.

• The buttonSizes object defines two sizes (you can add more): lg, md. It contains styles related to dimensions and spacing font-size, height, width, padding, border-radius etc.

• ContentWrapper is a helper component designed to wrap the visible content (children) inside reusable Button, providing consistent styling for hover underline effects—especially important for the link variant.

#Summary

Here we build a truly reusable Button component using Tailwind. You only need to style once, and then reuse everywhere in your app. The code is type-safe, simple to drop in, and easy to extend when design needs change.

Debouncing is a technique that ensures a function is only executed after a certain period of inactivity.

##Debounce implementation (snippet)

Let's implement our reusable debounce function.

function debounce(func, delay) {
  let timeoutId

  return function (...args) {
    clearTimeout(timeoutId)

    timeoutId = setTimeout(() => {
      func.apply(this, args)
    }, delay)
  }
}

##Code Explanation

• The debounce() function takes two parameters:

  • func: The function to debounce (e.g., a function that makes an API call or logs a message).

  • delay: The delay (in milliseconds) to wait before executing func.

• Closure: The timeoutId variable is declared in the outer scope of debounce to persist across multiple calls to the returned function.

  • timeoutId stores the ID of the setTimeout timer, which can be used to cancel the timer if the debounced function is called again before the delay expires.

• The debounce function returns a new function that wraps func argument. This wrapper handles the debouncing logic.

• The returned function uses the spread operator to capture any arguments passed to it. These arguments will be forwarded to func when it’s executed.

• clearTimeout(timeoutId): If the debounced function is called multiple times within the wait period, the clearTimeout() function will be called to cancel upcoming execution, and the new timeoutId will be settled.

• The apply method in a debounced function ensures that the this context inside the original function func matches the current context of the debounced function when it executes.

##Real-World example

Imagine typing in a search bar on a website. As we type, the website might send API requests to fetch search results. Without debouncing, every keystroke could trigger a request, overwhelming the server. With debouncing, the request is sent only after we stop typing for, say, 300 milliseconds. This reduces the number of function calls and improves performance.

#What is Throttling?

Throttling is a powerful technique which limits how often a function can be called within a time frame. It’s like putting a speed limit on a function to prevent it from running too frequently, which is especially useful for optimizing web performance and ensuring smooth user experiences.

##How Throttling Works

Throttling works by wrapping a function with a mechanism that tracks the last time it was executed. If the function is called again before a specified delay has passed, the call is ignored. Once the delay expires, the function can run again

##Throttle implementation (snippet)

function throttle(func, delay) {
  let isThrottle = false

  return function (...args) {
    if (!isThrottle) {
      func.apply(this, args)
      isThrottle = true
    }

    setTimeout(() => {
      isThrottle = false
    }, delay)
  }
}

##Code Explanation

• The throttle function takes two parameters:

  • func: the function to be throttled.
  • delay: The minimum time (in milliseconds) that must pass before func can be called again.

• It returns a new function that controls the execution of func.

• isThrottle: A boolean flag that tracks whether it’s in a "cooldown" period where further calls are ignored

• The returned function uses the rest parameter (...args) to accept any number of arguments, which will be passed to func.

  • It checks if isThrottle is false, and if so, it calls func.apply(this, args) to execute the original function with the provided arguments.

  • Sets isThrottle = true to indicate that the function is now throttled.

• Then, it sets a setTimeout that resets isThrottle to false after the specified delay. This allows the function to be called again once the delay period is over.

##Real-World Example

Imagine a webpage that fetches data from an API every time a user scrolls. Without throttling, scrolling could trigger hundreds of API requests in seconds, overloading the server and slowing down the site. By applying throttling, you can limit the function to execute, say, once every second, significantly reducing server load and improving performance.

#Summary

• Debouncing: Ensures a function executes only after a period of inactivity, reducing unnecessary calls.

• Throttling: Limits how often a function runs within a time frame, ensuring controlled execution.

• Key Difference: Debouncing waits for a pause; throttling ensures a fixed rate of execution.

• Use Cases: Debouncing for search inputs or form validation; throttling for scroll or resize events.

Both optimize performance by reducing function calls, enhancing user experience and server efficiency.

Take Apple's website—its elegant personality shines through with high-quality product images and minimalist typography, leading to a 30% higher conversion rate compared to cluttered competitors like early eBay designs.

#Website Personalities

Every website has a personality that matches its brand—serious and elegant for luxury brands, or playful and fun for creative startups. Matching design elements to these traits creates memorable, emotional experiences for users. This section covers the seven main personalities and how they guide choices in typography, colors, and more.

• Elegant Personality: Ideal for high-end services; use thin serif fonts, pastel/golden palettes, and hero images of refined lifestyles.
• Minimalist: Focus on content clarity with sans-serif blacks, sparse icons, and ample whitespace for readability.
• Bold: Command attention via oversized bold type, vibrant blocks, and dynamic layouts for impact-driven sites.
• Startup: Energetic vibe through medium sans-serifs, light grays, and rounded elements to convey innovation.
• Calm: Evoke trust with soft pastels, rounded serifs, and soothing illustrations for wellness or care-focused brands.
• Neutral: Corporate staple with structured grids, neutral fonts, and subtle accents to prioritize information over flair.
• Playful: Infuse joy with colorful rounds, hand-drawn assets, and subtle animations for engaging, youthful audiences.

##Typography

Typography isn't just about fonts—it's the voice of your site. Limiting choices and scaling sizes strategically ensures hierarchy and accessibility, aligning with 2025's trend toward bold, experimental typefaces that enhance mobile scrolling experiences.

• Use popular, safe fonts from Google Fonts, limiting with 1 or 2 font-family that fit the personality.
• Apply a type scale: body text 16-32px, bold headlines 50px or larger for consistency.
• Use 20px or more for long text; keep line length under 75 characters and line height 1.5 to 2.
• Try more letter-spacing for short titles; avoid justifying or centering long paragraphs.
• Keep font weight 400 or higher; reduce letter spacing in headlines for smooth reading.

Example: The New York Times blog uses a consistent 20px body font with generous line height, making long articles scannable and reducing bounce rates by 15%.

##Color

Colors affect feelings and guide attention. Choose them to match your brand and keep accessibility in mind. In 2025, bold contrasts and AI-made palettes are popular for vibrant, inclusive designs that can boost engagement by up to 20%.

• Pick main colors that fit your brand (e.g., pastels for calm) and balance with grays; use tools like Coolors for accents.
• Make tints and shades for flexibility; main colors go on CTAs, accents highlight details.
• Use lighter text on dark backgrounds, without pure black or white extremes.
• Blend colors in images for unity; test how they affect emotions.

Example: Spotify uses bright greens and blacks to increase playlist clicks by 18%.

##Images, Illustrations, and Icons

Good visuals support your message without slowing the site. Crop, compress, and combine assets wisely. Trends like 3D illustrations and AI-upscaled images create immersive experiences in 2025.

• Choose relevant, original images; show real people to build connection; use gradients or boxes for text overlays; upload double-size compressed files.
• Use one SVG icon set; match icon roundness to fonts; use with text labels for features or bullet points; color icons to match or accent.
• Use scalable, fast-loading visuals.

Example: Duolingo’s hand-drawn owl icons and compressed images keep mobile load times under 2 seconds.

##Shadows, Border-Radius

Subtle shadows and rounded corners soften look.

2025 highlights micro-interactions with hover effects for a tactile feel.

• Use light shadows sparingly for subtle lift; bigger shadows for emphasis; animate on hover.
• Match border-radius to font style for playful buttons and images.

Example: Notion uses soft shadows and 8px border-radius on cards for a calm interface.

##Visual Hierarchy and UX

Hierarchy directs attention; UX makes navigation easy. Site speed affects rankings. Slow sites lose conversions (~7% per second delay).

• Place important items top and emphasize with size, color, weight, and space.
• Highlight areas like testimonials with backgrounds or shadows.
• Use familiar patterns, clear headlines, quick animations (200–500ms), and aligned forms with feedback.
• Break text with subheadings and images; use simple language; place actions where users expect them.
• Track UX: Monitor bounce rates and loading times

Example: Amazon’s bold “Add to Cart” buttons increase impulse buys by 12%.

##Components, Layouts, and Content Strategies

Combine standard components like cards and grids into tested layouts for efficiency

• Use common elements in patterns like hero or features.
• Optimize content marketing—add SEO-friendly alt text and create downloadable checklists for backlinks.
• Keyword Research: Use AI to find phrases (e.g., “responsive web design tips”) to include in alt text and headings.

Example: HubSpot doubles leads using grid layouts with animations guiding users through funnels.

#Conclusion: Master Design Trends and Performances

In 2025, web design changes fast. Using colors that fit your brand, focusing on user experience, and using AI tools helps make websites that attract and keep visitors. Test your pages, design for mobile first, and keep checking to get better.

Gradients are a powerful way to add visual flair to web elements, but transitioning them smoothly has always been tricky. CSS gradients are treated as images, so direct transitions between gradient states often result in abrupt changes rather than smooth animations.

Enter the CSS @property rule—a game-changer that lets us define custom, animatable properties to achieve gradient transitions.

In this blog, we’ll explore how to use @property to animate gradient colors on a button, complete with a real-world example.

Let’s create a simple webpage with two buttons: one using a standard gradient transition (which won’t work as expected) and another using the @property rule for a smooth transition.

<div class="box">
  <h2>Changing background gradient styles on hover</h2>
  <button class="btn btn-1">Hover Me</button>
</div>

<div class="box">
  <h2>Changing @property rule on hover</h2>
  <button class="btn btn-2">Hover Me</button>
</div>

##Styling the Buttons

Next, we style the buttons with a shared gradient background and define their hover behaviors in 2 different ways:

@property --color-primary-one {
  syntax: '<color>';
  inherits: false;
  initial-value: #ff3d3e;
}

@property --color-primary-two {
  syntax: '<color>';
  inherits: false;
  initial-value: #ff6f00;
}

/* common styles with initial gradient color */
.btn {
  padding: 15px 30px;
  color: #ffffff;
  border-radius: 5px;
  background: linear-gradient(to right, var(--color-primary-one) 0%, var(--color-primary-two) 100%);

  cursor: pointer;
}

.btn-1:hover {
  /* this will not work as expected */
  background: linear-gradient(to right, #d63e76 0%, #b90041 100%);

  transition: all 0.3s ease-in-out;
}

.btn-2:hover {
  /* this will work */
  transition:
    --color-primary-one 0.3s ease-in-out,
    --color-primary-two 0.3s ease-in-out;

  --color-primary-one: #d63e76;
  --color-primary-two: #b90041;
}

• Base .btn class: Applies a gradient background using the custom variables --color-primary-one and --color-primary-two.

• .btn-1:hover: Attempts to transition the entire background property to a new gradient. This won’t animate smoothly because gradients are treated as images.

• .btn-2:hover: Transitions the custom variables --color-primary-one and --color-primary-two to new color values. Since these are animatable color properties, the gradient updates smoothly.

The @property rule is supported in modern browsers like Chrome, Edge, and Safari.

Visit CanIUse to check compatibility details for all features.

#Summary

Using the @property rule, you can create stunning gradient transitions that elevate your web designs. Try it out and make your buttons pop!

##Type Coercion

Coercion - is when JavaScript automatically changes one type to another during operations—like mixing apples and oranges, but the code tries to make them work together. It can be helpful but sneaky, leading to surprises if you're not careful.

let result = 'Price: ' + 100 // Number 100 becomes a string, output: "Price: 100"

let sum = '5' - 2 // String "5" becomes a number, output: 3

But: "5" + 2 gives "52," not 7. Learn more about it here

##Scope

Scope is like a fence around your variables—it decides where they can be seen and used in your code. Without it, everything would be chaotic. There are three types of scope: global scope (available anywhere in the code - window object), function scope (inside a function only), and block scope (inside curly braces {} like in if statements, using let or const). This keeps your code organized and secure.

function calculateTax(price) {
  let tax = price * 0.1 // This 'tax' is visible only inside this function
  return tax
}
console.log(tax) // Error! Can't see 'tax' out here—it's scoped to the function

##Closures

A closure is like a backpack 🎒 that a function carries, holding onto variables from its "home" (outer function) even after the home is gone. It's great for keeping data private, like a secret pocket.

function makeCounter() {
  let count = 0 // The 'secret' in the backpack 🎒
  return function () {
    // Inner function with access to count
    count++ // Changes the outer variable
    return count
  }
}
let counter = makeCounter()
console.log(counter()) // 1
console.log(counter()) // 2  (Remembers the last count!)

##this keyword

this is like a pointer saying, "Me!"—it refers to the object that's currently running the code. It changes depending on how you call the function, which can be tricky at first, like a chameleon.

Example: In an object, this means the object itself.

The value of this depends on how the function is called.

• If this is used in the global object, the value of this is window object (but if strict mode is used, the value is undefined).
• In most cases, the value of this is the object to the left of the dot (the left rule of this).
• If a function is an arrow function, it ignores all the above rules and obtains the value of this from the lexical environment during its creation.
• If call, apply, or bind are used to create or call a function, this inside the function is the object passed as an argument.

Example 1

let User = {
  name: 'Alice',
  greet: function () {
    console.log('Hello, ' + this.name) // 'this' is User object
  },
}
User.greet() // "Hello, Alice"

Example 2

const Person1 = {
  name: 'Alice',
  greet: function () {
    console.log('Hello, ' + this.name)
  },
}

const Person2 = {
  name: 'Bob',
}

// change the context of `this` by binding the Person2 object
const greetPerson2 = Person1.greet.bind(Person2)

greetPerson2() // Output: Hello, Bob

Explanation:

• Person1 has a method greet that uses this.name.
• bind(Person2) creates a new function greetPerson2 where this is permanently set to Person2.
• Calling greetPerson2() uses Person2's context, printing "Hello, Bob".

##Object-Oriented Programming in JavaScript

OOP is like building with Lego blocks: you create blueprints - classes or prototypes for objects that can inherit traits, making code reusable. It's for organizing bigger projects.

Prototypes

Prototypes are like family trees—objects inherit methods (actions) from a parent prototype, saving space by sharing.

function Person(name) {
  this.name = name // Unique to each person
}
Person.prototype.greet = function () {
  // Shared action
  return 'Hi, ' + this.name
}
let Nick = new Person('Nick')
console.log(Nick.greet()) // "Hi, Nick"

##Arrow Functions vs Normal Functions

Arrow functions are shorthand versions of normal functions, like quick notes vs full letters. The big difference: arrows don't have their own this — they borrow from surroundings, which is handy in some spots but not others.

let obj = {
  value: 10,
  normal: function () {
    setTimeout(function () {
      console.log(this.value)
    }, 100)
  },
  arrow: function () {
    setTimeout(() => {
      console.log(this.value)
    }, 100)
  },
}

console.log(obj.normal()) // Undefined — wrong 'this' context
console.log(obj.arrow()) // 10—borrows obj's 'this'

##Promises

Promises are like "I Owe You" for code that takes time (async) — they promise a result later, either success (resolve) or fail (reject). Chain them with .then() for the next steps.

let promise = new Promise((resolve, reject) => {
  console.log('thinking...')
  setTimeout(() => {
    return resolve('Done!')
  }, 2000) // Wait 2 seconds
})
promise.then((result) => console.log(result)) // "Done!"

#Summary

• Scope: Fences variables; global everywhere, function/local hidden; prevents messes.
• Closures: Functions remember outer stuff; like private backpacks; useful for states.
• this Keyword: Points to current object; changes with call; watch in events.
• OOP: Blueprints with prototypes/classes; inherit to reuse; methods are actions.
• Arrow vs Normal: Arrows short, share this; good for quick anon funcs.
• Promises: Handle waits; resolve/reject; chain for steps.

##Internet

The Internet is a global network of computers used to exchange data.
It provides access to information, services, and communication across the world.

##Server

A server is a machine that provides services to other programs or devices, known as clients.
Its role is to share data, resources, and distribute workloads.

Types of servers:

• Web servers
• Database servers
• DNS servers

##Web Server

A web server accepts HTTP requests from clients (browsers) and sends back HTTP responses containing HTML pages, images, files, and other resources.

##Domain & IP Address

A domain is a memorable, human-friendly address used to access websites. Without domains, you’d have to remember complex IP addresses.

An IP address is a unique numerical identifier assigned to every device connected to the internet.
It works like a postal address, helping devices find each other and exchange information.

IP addresses are organized hierarchically (country → region → device) to optimize routing speed.

##DNS & DNS Lookup

DNS (Domain Name System) — acts like the internet’s phonebook, translating domain names into IP addresses.

For example, using the IP 142.250.190.78 or the domain google.com will take you to the same website — Google’s homepage.

DNS lookup is the process of finding the IP address of a server using its domain name (e.g., example.com → 93.184.216.34).

How it works

1. DNS Request: The browser sends a request to a DNS server to get the IP address of the domain.
2. Caching: Once fetched, the IP address is stored in the browser’s cache to speed up future visits.
3. Multiple Hosts: If a webpage loads resources from multiple domains (e.g., fonts, images, or scripts), the browser performs a DNS lookup for each domain.

Real-world example:
If your webpage loads Google Fonts, the browser will perform a DNS lookup not only for your site’s domain but also for fonts.googleapis.com.

##CDN — Content Delivery Network

A CDN is a network of servers distributed globally that stores copies of website content (pages, images, videos) and delivers them from the closest server to the user.

Benefits:

• Faster load times
• Reduced server load
• Better reliability

Real-world example:
Netflix uses CDNs to stream video from a nearby server, so you don’t have to wait for data to travel halfway across the world.

#Browser — Introduction

A browser is software that allows a user to access information on the internet via the World Wide Web.

In modern web development, knowing how browsers operate can make your websites faster, more accessible, and more reliable.

##How the Browser Loads a Web Page

Navigation is the first step in loading a web page.

When you type a URL into the browser's address bar, you’re directing your browser to connect to a specific web server.

The server processes your request and sends a response containing files like HTML, CSS, and JavaScript, along with media such as images and videos. If everything is fine, the server responds with a 200 OK status code.

The first request from a browser to a web server is always a GET request — a common interview question for junior developers.

##Request, Response, Parsing, Rendering

Request

The browser sends an HTTP/HTTPS GET request to the server for the page’s content.

Response

The server (or CDN) returns data — HTML, CSS, JS, images — which the browser processes.

Parsing

Parsing is converting the HTML into a format the browser can understand — the DOM (Document Object Model).

• CSS is parsed into CSSOM (CSS Object Model).
• JavaScript without async or defer stops HTML parsing until the script loads and runs.
• Render tree combines DOM + CSSOM for display.
• Non-blocking resources (images, videos) load in parallel.

The browser also builds an Accessibility Tree, which is essential for assistive technologies like screen readers.

##Rendering

Rendering is turning HTML, CSS, and JavaScript into a visual webpage.

1. Styles: DOM and CSSOM merge into a render tree of visible elements.
2. Layout: Browser calculates size and position (box model: content, padding, border, margin).
3. Painting: Browser draws pixels — text, images, colors.
4. Interactivity: JavaScript loads, enabling scroll, clicks, and animations.

#TTI — Time To Interactive

TTI (Time To Interactive) measures how long it takes from the first request (starting with DNS lookup) until the page becomes fully interactive.

• Shorter TTI = better user experience.
• Test your site’s TTI with PageSpeed Insights.

#Summary

• Domain & IP: Human-friendly name + unique numeric address for devices.
• DNS Lookup: Translates domain names to IP addresses; caching speeds up repeat visits.
• CDN: Speeds up content delivery using global servers.
• Navigation: Entering a URL sends a GET request; server responds with page files.
• Request/Response: Browser requests data; server returns HTML, CSS, JS, and media.
• Parsing: HTML → DOM, CSS → CSSOM, combined into a render tree.
• Rendering: Calculates styles, layout, and draws the page.
• TTI: Time until a page is fully usable.