DEV Community: Kaden Wildauer

A hopefully helpful article I made on how to chose and apply color when designing a website.

Kaden Wildauer — Sat, 14 Feb 2026 23:59:54 +0000

How to Choose Colors When Designing a Website

Kaden Wildauer ・ Feb 14

How to Choose Colors When Designing a Website

Kaden Wildauer — Sat, 14 Feb 2026 23:58:16 +0000

This article is going to cover colors - specifically, how to choose them when designing a website, and how to select them in a way that aligns with feelings, themes, and ideas like calm, trust, elegance, playfulness, or professionalism. Furthermore, the goal is to demonstrate how to choose colors that work within real design philosophies, systems, and standards such as Material UI, WCAG, and more.

How to Pick Colors

Before you start picking colors for a website, one of the most important things to do is define what your website needs to convey. This is where most true professionals start. Perhaps that’s professionalism and calm, or playful and exciting. In those cases, you need to define colors that convey those emotions. For playful, perhaps it’s dreamy colors like light pink and purple, or it could also be green and yellow for something playful and exciting, etc. As such, defining this is where we are going to start as well.

Defining Emotions

So let's start by saying we are making a high-quality landscaping site made for a professional, and we want to choose three colors: two accents and a background color. So, let's define the feelings a landscaping site should convey, and something that works is the following.

Calm
Trust
Professionalism
Warmth

These work. They are simple and generally convey what a basic landscaping business would want: trust, professionalism, and a little bit of closeness in the form of calm and warmth.

But before we go into actually picking colors, I want to provide some tools so you can define what feelings certain colors convey. To do so, I added a cheat sheet below so you can get an overview. You can also use Google or what I will personally be using for most of this article, coolors. This tool specifically can both help you find colors and understand the psychology and emotions of any color, among many other useful things the website offers.

Picking Initial Colors

So to start let’s pick accents first, then a background. And for our first accent maybe we choose blue? That works; it fits the feelings of calm, trust, and professionalism. But it's also a little cold along with being dreadfully common so since we are doing a landscaping site, a better color might be green. It’s on brand and conveys life, growth, health, and generally hits our emotions, primarily warmth, trust, and calm.

Naturally, let’s choose our second accent. Currently, we need something more trust-generating and professional. We have an exciting, lively color, but it needs balance. Orange would work, it hit's our emotions but again it’s a little loud, so perhaps brown. It’s on theme with landscaping and conveys stability, warmth, and reliability, which promotes what we are currently missing: professionalism.

This is the easy part: the background. This usually splits into two camps for websites: dark themes and light themes. And those usually are either black or white for light and dark themes, respectively. Now, a dark theme is not at all what we want; the emotions are off. Therefore, that means we need a light theme, but pure white is cold and empty. And though backgrounds need to be neutral, we can still add a splash of color. So what do we add?

Well, we know we want white, but let’s add yellow, giving us a tan or ivory color like old paper. It’s no longer cold and empty, and the feelings it conveys are within our emotions so why not?

Basic Color Theory

Now before we take our colors into the next section, let’s talk about color theory. What I am going to go over here is warm vs. cold, color systems, consistency, and common pitfalls thing's that will help you in the next section.

First, let’s go over warm vs. cold colors. There are many use cases in understanding warm and cold colors; for example, the separation of colors into cold and warm alone cuts your millions of choices in half. It can help you feel the difference between something like deep purple and light purple. It can also help with understanding contrast as well, as warm colors often stand out on top of colder colors and vice versa. So how can you tell what’s colder or warmer? Well, in most cases, you can just see how warm something is based on its blue vs. red. If a color has more red, it’s warmer; if it has more blue, it’s colder. This also, of course, affects some of the emotions a color gives off. You can infer that even an exciting color like yellow, which is a color close to red, can be “colder” than another yellow if it has more blue in it, and as such, that color would feel more prominent next to each other.

Any professional is extremely picky about design and coloring, and as a result, you will likely want to edit colors when you are choosing them. And no, you will never know every color or even remember a couple of color codes. But you will often pick a color you like, and it’s close but off. Maybe it’s a tad too cool or too warm. And understanding what HSL means can be extremely helpful in such a situation. Rather than just messing with a slider, you can safely edit a color using the HSL measuring system.

Now, in HSL, H stands for hue, and it is the color; S stands for saturation, and it’s the purity of the color; and L stands for lightness, and it’s rather self-explanatory. But the most important of these are saturation and lightness. If you need to change hue, it’s likely best to find another color. As for saturation, messing with and understanding this can help you cool or warm colors up without really changing them.

So let’s talk about saturation. You can think of it as purity - how intensely brought forward the hue is - and at zero, we are only dealing with lightness, so black or white. And lightness is how dark a color is; this is not accurate, but you can think of it like adding white or black drops of paint into a color.

Now lastly, something I struggled with when starting is color relationships like complementary, analogous, triadic, and mostly these are distractions. Choose accents based on feeling and contrast with the background. And furthermore, you are not merging the colors; they are usually separate. So choose based on how they feel, and that usually naturally makes them fit together. And as a result, usually everything matches well. But there are edge cases - if you’re going for a very colorful website or something generally esoteric, maybe with no neutrals or multiple accents (4 or more) for something like a portfolio - then understanding true color theory is 100% needed. But in 99% of cases, true color relationships can be ignored.

What a Design Needs

Now that we've picked some colors, let's make sure they actually work on a site. As such there are a few rules, systems, and guidelines we will use when finalizing our colors that I want to go over. Understanding these will also show you, somewhat, how to apply colors to a website.

Readability and Contrast

First, readability. This means your accent colors and text colors must be easily visible when placed over your background color or colors. Giving a quick example: say we choose a light scheme and the background color is white. First, our text colors would be two shades of black, naturally contrasting well. But accents are also often used as text colors for important headings, so your accents must be clearly visible above your background. There is even a scale for this called WCAG, but remember only your accents and text colors compared to your background must pass WCAG.

Color Hierarchy

If there is one word to encompass how to make a good design, it’s hierarchy. And of course, this encompasses colors as well and is something we should understand when picking colors and applying them. The most important things to understand are depth/elevation and balance.

Let’s discuss balance. Imagine you use too much of an accent or too little; your entire website can seem unbalanced - either in that it’s bland and not impactful, or too impactful because your impactful colors (accents) are being randomly applied without consistency or balance. This causes attention to not flow where you want it. Users ignore your headings or call to actions because they don’t pop out. Even if you choose great accents and background colors and shades, this can still happen. The best way to avoid it is to follow a rule or idea called the 60/30/10 rule. This is all about percentages of color: 60% of your website is your background, and the 30% and 10% are your two accents. Following something like this can make sure your colors, pages, buttons, and headings stay consistent, impactful, and balanced.

Furthermore something else to note on balance and the 60/30/10 rule: first, the 60/30/10 does not need to be mathematically followed; it’s just a framework for how often to use color. There are even different variations, like the 80/20 rule, or even flipping the rule in certain areas, such as making your 60% swap with your 10% to add some extra excitement, flexibility, and uniqueness to a design. It’s called a rule, but it’s really a guideline.

Now onto elevation. This is something in Material UI, where more important items should feel closer to the user. There are many ways to do this, but here it’s about making sure our colors increase in elevation visually as they get rarer. For example, if we have a white and dark green, and that dark green is on top of the white, it feels closer, it contrasts well, and is less common visually than the white, so it’s “higher” in the 2D design. This also ties into the 60/30/10 rule, where if your website is balanced, no matter what color the 10% is, its rarity alone increases its elevation, making it good for calls to action.

Creating a Palette

So we have picked our colors and defined what rules they need to follow, now let’s actually pick shades to create our palettes.

Background Shades

Backgrounds are a large portion of our website; since we are following the 60/30/10 rule, they are around 60%. But again, that 60% does not need to be a single color, so let’s make a few tan shades. But before getting into that, let’s go into the process of actually finding shades - we can’t just materialize a tan out of thousands of possibilities. So for most color picking and editing, I am again using Coolors to find promising options.

We want tan/ivory, so I found EADCAE on Coolors. It’s nice; it has an old paper look and follows our theme. But say we want a card to sit above this tan, and we don’t want to use our accents because perhaps it will violate the 60/30/10 rule, or maybe it just does not look right. And because of this, we will create multiple shades - at least three colors that are whiter than our current color but not too different that they seem like a completely different color, because that would violate the 60/30/10 rule. So we use HSL and decrease lightness by 5 percent twice to get two more colors, getting these three: F5EED6, EFE5C3, and EADCAE.

And now we have our background. It’s subtle and fits while being balanced and neutral. We can even flip this: currently, the darkest shade is the main background, then lighter shades can sit on top, but there is no problem doing the reverse either. It’s still balanced, follows our rules, and the shades subtly stand out.

Accents

Finally we now get to pick out accents, knowing that first they must contrast against our background and somewhat against each other. As for the “against each other” part, sometimes we might layer the accents themselves over each other, so it’s important that they are at least somewhat passable when layered. However, this part really depends on design choice.

But how do we pick our colors? We want brown and green. The best way is to simply browse palettes, find something you like (or somewhat like), then use that. If it’s not perfect, you can edit it with HSL or look at similar shades to the color you are considering. Just make sure they pass contrast. Something that can help here is keeping warm vs. cool tones and your background color in mind. This can stop you from going back and forth checking WCAG for a color that obviously won’t work. For me I found and edited to get these two color's 496B48 and 44362F a dark green and dark brown.

Testing your Palette

Now we have everything - backgrounds and accents that contrast well against them. That's it, right? We can move forward! Well, no. Just because theoretically everything seems well, there is still visual testing needed. Usually, that means making something to test all variations you might or will use, like so.

What we are doing here is testing all possible variations in a card-like format, seeing our color limitations, strengths, and general visual aesthetics (ps, it’s also a great place to test fonts!).

Now often, when starting to use your palette, even after doing all the mentioned tests, it can feel off or wrong when in actual use. And in that case, as long as it still contrasts well and is the same general colors as you originally (green, brown, and tan), then you can change on the fly or mid-design safely. People do it often, just as long as you still follow the original colors, rules, and thoughts so you don’t move away from your keywords without thinking it through.

Conclusion

Choosing colors is hard. Everyone says different things, and for me, nobody actually talked about the fundamentals like needing a neutral background, contrast, and balance. And those who did showed boring websites or a system with no flexibility, or just collapsed with common rules people use. I hope this article laid out the most important fundamentals so you don’t have to guess around like I did, and in a way that you can edit and grow what I showed here. Otherwise, have a good day! PS my portfolio has many other interesting things as well if your curious!

Modern Card Hover Animations, CSS and JavaScript

Kaden Wildauer — Tue, 04 Nov 2025 20:00:09 +0000

A great hover effect can make user interfaces feel alive it's a small detail that adds visual polish and depth. This article will cover hover effects on cards, walking through three custom-made variations for a card's background. The main idea? Adding unique twists to the classic subtle glow where your mouse hovers. As usual with my articles, expect imagery, code examples, and a live demo at the end!

Overview the effects!

For this, I'll be using HTML Canvas, CSS, JavaScript, and React. But you can follow along with the ideas regardless of your tooling if you prefer GSAP or no React at all, that's fine too. The first is the classic: When the mouse hovers over a card, add a glow beneath the cursor. Simple, no?

The second, is quite a bit more interesting, it will use HTML Canvas and :before to apply a blur over the canvas. But what will the canvas do? Well, the idea is to make a pixelated, almost dithered hover effect. If you are curious about dithering, here is a cool dithered shadow on CodePen similar to what I am imagining here. How will this be done? Well, the idea is we will color 'pixels' around the mouse randomly in a circle. The coloring will happen more often in the center and less often at the edges of the circle. And every frame, the mouse chooses new pixels to color around the mouse, leading to a blurry dithered shadow.

The third effect will use the scaffolding of the first while visually being less chaotic. We will use a canvas again and create a grid over the card and on hover the grid fills with color and slowly fades when the mouse leaves the cell. But this is too intense for a card, so using :before we can add a gradient the same color as the card's background, then have it fade to transparent. Positioning this gradient allows us to cut off large sections of the effect, allowing us to make it visible in only a corner.

Effect one

Now starting off simple, let's go over the classic glow on mouse hover for a card. This one, unlike the following, is nearly pure CSS in essence. The following is our CSS code for this effect.

.card::before {
  content: "";
  position: absolute;
  width: 100%;
  height: 100%;
  //Notice --mouse-x and --mouse-y for possitioning
  background: radial-gradient(
    600px circle at var(--mouse-x, 50%) var(--mouse-y, 50%),
    rgba(181, 26, 43, 0.6),
    transparent 40%
  );
  opacity: var(--glow-opacity, 0);
  filter: blur(100px);
  transition: opacity 0.4s ease-out;
  pointer-events: none;
  z-index: 1;
}

Now this acts as our 'glow' that happens on hover. It is just a radial gradient that fades to transparent. We use --mouse-x and --mouse-y to position the radial gradient around the card, then use --glow-opacity to fade the effect out. So, if we want to make the radial gradient follow the mouse, we just update --mouse-x and --mouse-y if the mouse is inside the card. Then to have it fade out as it moves away from the card, we just change --glow-opacity. To create this we attach a mouse move function to the card that looks like so.

export function basicHandleMouseMove(e, cardRef) {
  //Store card so we can use the shorthand
  const card = cardRef.current;
  if (!card) return;
  //Cards height and width
  const rect = card.getBoundingClientRect();
  const x = e.clientX - rect.left;
  const y = e.clientY - rect.top;

  // Calculate distance from card edges
  const distanceX = Math.max(0, Math.max(-x, x - rect.width));
  const distanceY = Math.max(0, Math.max(-y, y - rect.height));
  const distance = Math.sqrt(distanceX * distanceX + distanceY * distanceY);

  // Calculate opacity based on distance (fade out over 100px)
  const maxDistance = 100;
  //The 3 bellow is used to lower the entire opacity further :)
  const opacity = Math.max(0, 1 - distance / maxDistance) / 3;

  card.style.setProperty("--mouse-x", `${x}px`);
  card.style.setProperty("--mouse-y", `${y}px`);
  card.style.setProperty("--glow-opacity", opacity.toString());
}

Here is the JSX for the card. This will remain generally the same, minus some additions such as canvas and new classes, for the whole project.

<div className="card-container" ref={containerRef}>
  {/* Card 1 */}
  <section className="card" ref={cardRef}>
    <h2></h2>
    <p></p>
  </section>
</div>

Now here in React, we would attach our mouse move to a parent element, then pass it our cardRef and our effect works! Something to note is we attach to a parent element because we need the mouse's location even when it's outside the card to simulate the smooth fade. You could attach the mouse to a window instead and to affect multiple cards, feed an array of refs to the basicHandleMouseMove function. Here is an image of the effect in action!

I recommend lower opacities and perhaps a blur effect to make the glow even more subtle. It pairs well with a gradient!

Effect Two

And now onto effect two, the dithered effect. Here is an example of what it looks like without the blur.

The idea behind how this works is putting a canvas in our card space. Then creating a grid and 'coloring' the grid's cells randomly in a circular area on mouse hover. The logic is based on a common programming pattern sometimes referred to as a 'pixel array'. I have even covered this before in my article about flow fields if you are interested. But before we walk through how this works, I wanted to note that this section will have the most code! The third effect is a slight alteration to the following code and therefore less dense.

Creating the pixel array

First we need to set the canvas up with a width and height of the parent, aka the card. If you need help or want the code, here I will link the repository at the end! After that we need to create the 'pixel array', which is just a mathematical representation of the grid. We do this so we can store the x and y location of every cell, allowing us to represent the cell logically one after the other and therefore color them in according to their locations. To do this we first create a function called impose();. Its job is, when given the size for every cell, it defines how many columns and rows we need to fill the canvas. As you can imagine, the lower the cell size, the more cells we get and the more defined our output will appear, but this will also take up more compute. The cell size being pixSize here. This is the code.

function impose() {
  const canvas = canvasRef.current;
  if (!canvas) return;
  //pixSize = width and height of every cell
  const rows = Math.floor(canvas.height / pixSize);
  const cols = Math.floor(canvas.width / pixSize);
  //Saving our rows and cols
  rowRef.current = rows;
  colRef.current = cols;
  // Passing them into 2D array function
  let initialGrid = create2DArray(rows, cols, 0, 0);
  gridRef.current = initialGrid;
}

We now have the size of the grid in the form of how many rows and columns we need. But as mentioned, we need to mathematically represent each cell. We do this by creating a 2D array and storing locations and the unique individual cell data inside of it. But let's visualize this a bit. Here is a 2D array.

let arr = [
  [0, 0, 0],
  [0, 0, 0],
  [0, 0, 0],
];

It is just a nested array, but imagine this is a grid. Each child array is a row and its children, the 0's, are columns. But in practice the 0's are objects containing the cell's values like location, color, and opacity.

But how do we get the x and y value to store in the cell? Well, conceptually it is rather simple math. We use pixSize and multiply, that's it! So say for the x value, we just multiply by whatever column we are on. If it is the second column, it is 2 * pixSize to get its x value. This accounts for the space its predecessor cells take up. Here is the code implementing this idea while creating the 2D array.

function create2DArray(Rows, Cols, leftX, topY) {
  let arr = new Array(Rows); //Create array of empty rows

  for (let i = 0; i < arr.length; i++) {
    //Index into row and create empty columns
    arr[i] = new Array(Cols);
    //Iterate over the empty columns in the row
    for (let j = 0; j < arr[i].length; j++) {
      arr[i][j] = {
        x: leftX + j * pixSize,
        y: topY + i * pixSize,
        opacity: 0.0,
        color: "#b51a2b",
      };
    }
  }

  return arr;
}

Now after creating this, you should be able to color pixels in. If you want to, you can just index into your grid, get a cell's x and y location, and then pass it to a draw function using the canvas API. Now the most important part is storing the x and y location. But this also stores the opacity and color, but why? Well, as for opacity, it is for compatibility with the third effect and to make the entire thing smoother. We fill every cell with opacity, and later in the render(); function, we will decrease it every frame so colored elements fade away rather than instantly disappearing when we clear the frame. And as for color? Well, I did that to show that if you want, you can make the cells different colors if you want to make a rainbow or reds and oranges, anything really.

Creating the mouse effect

So now onto the actual effect. We have created the grid mathematically, but what is next? Well, for this effect, we have three main functions. First, one that iterates over the grid we made and draws all the cells every frame: the 'render', our mouse tracker, and our MouseEffect. To start lets consider the mouse tracker. We need to track our mouse according to its position inside the canvas so we can use it in MouseEffect to find the cell it is under and fill in cells surrounding. So to do that, we grab our canvas's rect size and subtract it against our mouse like so.

function mouseTracker(e) {
  const canvas = canvasRef.current;
  if (!canvas) return;

  // Get canvas position directly
  const canvasRect = canvas.getBoundingClientRect();

  // Get mouse position relative to canvas
  const mouseX = e.clientX - canvasRect.left;
  const mouseY = e.clientY - canvasRect.top;

  mousePosRef.current.x = mouseX;
  mousePosRef.current.y = mouseY;
}

We can now track its location inside our card. We will then provide this data to our MouseEffect so it can apply effects around the mouse. So how does this function work? Well, it is pretty simple conceptually. And has three main stages, which are the following.

We transfer the x and y of the mouse into a row and column location
We define our variables like effect radius and fall-off points
Iterate over the effect-radius cells and apply our effects

So we find what column and row is under our mouse. Define how large an area we want our mouse to randomly pick cells from, along with defining the minimum and maximum value we want to increase said cell's opacity, which is based on distance. This will make far-off cells fade faster when the render decreases every cell's opacity. Then in the third part, iterate over the space we defined and calculate how much we increase its opacity, see if it is in the radius, and see if it has been chosen. This has about a 50% chance, and it is what adds the dithered look because we are going to be constantly changing and increasing different cells' opacity. Now how many times did I say 'cells'... here is the code.

function MouseEffect() {
  const canvas = canvasRef.current;
  if (!ctx || !canvas) {
    return;
  }

  // Get column and row location of the mouse's x and y
  let cenCol = Math.floor(mousePosRef.current.x / pixSize);
  let cenRow = Math.floor(mousePosRef.current.y / pixSize);

  // Defining our var's
  let radius = 30; //How large the effect circle is in cells
  const minChange = 0.05; // How little we can increase opacity
  const maxChange = 0.1; // How much we can increase opacity

  //Iterate over effect our and apply effects
  for (let i = -radius; i <= radius; i++) {
    for (let j = -radius; j <= radius; j++) {
      //Distance of center cell to the current cell
      const distance = Math.sqrt(i * i + j * j);
      //If not outside radius and chosen 50% chance
      if (distance <= radius && Math.random() < 0.5) {
        //Current iterated cell location
        const curCol = cenCol + i;
        const curRow = cenRow + j;
        //Make sure the cell is one screen/exists if so continue
        //This is important for edges and of screen checking
        if (
          curCol >= 0 &&
          curCol < colRef.current &&
          curRow >= 0 &&
          curRow < rowRef.current
        ) {
          // 1 at center -> 0 at edge
          const normDis = 1 - distance / radius;
          // Map to [minChange..maxChange]
          const change = minChange + (maxChange - minChange) * normDis;

          gridRef.current[curRow][curCol].opacity = Math.min(
            1.0,
            gridRef.current[curRow][curCol].opacity + change
          );
        }
      }
    }
  }
}

And that is truly it. That is the main function for the effect. All we have to do now is put the entire effect under a requestAnimationFrame, which also has the render function, which is super simple. I have practically alluded to it and already explained it, but for clarity, here is how it works. The render function clears the previous frame. Then it iterates over the cells and decreases the opacity unless it is too close to 0. If it is, we ignore it. Which looks like so.

function render() {
  const canvas = canvasRef.current;
  if (!ctx || !canvas || !gridRef.current || !gridRef.current.length) return;
  //Clear our frame
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  //Iterate over our cells
  for (let i = 0; i < gridRef.current.length; i++) {
    for (let j = 0; j < gridRef.current[i].length; j++) {
      //If we are geater then 0 opacity decrease opacity
      if (gridRef.current[i][j].opacity > 0)
        gridRef.current[i][j].opacity -= 0.05;
      //If we are greater than 0 opacity draw the cell
      //Otherwise ignore it
      if (gridRef.current[i][j].opacity > 0) {
        drawSquare(
          gridRef.current[i][j].x,
          gridRef.current[i][j].y,
          gridRef.current[i][j].color,
          gridRef.current[i][j].opacity
        );
      }
    }
  }
}

We need this to update every cell visually as MouseEffect changes its opacity but does no actual drawing of anything. And also a convenient place to slowly decrease every cell's opacity as we draw them all. Now all we do now is apply a :before at a higher z-index than the canvas with a blur for a more subtle effect, which is the image I showed. This is also most of the code since we are just altering what we already have for the next effect!

Third Effect

And here is the final one. Here is what it looks like for reference!

Thankfully, this effect is heavily based on the fundamentals of the previous one, so not much more code is needed! But first, to make this, we increase pixSize from whatever you chose previously to a larger number like 40px. Now we have a larger grid, but! There is a problem. We have larger cells now, and if the container is not a perfect multiple of our pixSize, we have leftover space at the edges where there is not enough room for a new cell, causing large visible gaps. This existed before but is made more apparent at larger sizes.

So... How can we fix this? Well, if we simply increase the canvas size so it is 110% in CSS and when we update its resolution on resize, we add something like.

canvas.width = parentRect.width * 1.1;
canvas.height = parentRect.height * 1.1;

Now the grid's edges or gaps are simply not visible to us anymore because we have in essence zoomed in by increasing its size while that size is just cut off by the overflow: hidden in our CSS parent card. The issue still exists. It is just on an area of the canvas that is no longer visible.

All we need to change is render(); and MouseEffect. Everything else stays the same. And unlike before, all we want to do is increase the opacity of a single cell under our mouse and have it fade out when the user navigates elsewhere. So here I just turned MouseEffect into a function that simply updates an overhead on what column and row the mouse is under. Then using that data in the render, I updated that cell by increasing its opacity like so.

function render() {
  if (!ctx || !gridRef.current.length) return;
  ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
  //Collect the current hover cell position'updated via MouseEffect
  let hovCol = rowRef.current;
  let hovRow = colRef.current;
  //If on screen
  if (hovCol !== undefined && hovRow !== undefined) {
    //Increase opacity dont pass 1
    gridRef.current[hovRow][hovCol].opacity = clamp(
      gridRef.current[hovRow][hovCol].opacity + 0.05,
      0,
      1
    );
  }
  //Iterate over all cells
  for (let i = 0; i < rowColRef.current.row; i++) {
    for (let j = 0; j < rowColRef.current.col; j++) {
      //If cell is not being hovered over decrease it opacity
      //Clamp just makes sure it can't go above or bellow 0 and 1
      if (i !== hovRow || j !== hovCol) {
        gridRef.current[i][j].opacity = clamp(
          gridRef.current[i][j].opacity - 0.01,
          0,
          1
        );
      }
      //Draw cell
      drawSquare(
        gridRef.current[i][j].x,
        gridRef.current[i][j].y,
        gridRef.current[i][j].color,
        gridRef.current[i][j].opacity
      );
    }
  }
}

And that is it, pretty much it. I also put a :before over it using the card's background color that fades to transparent so the grid is only visible on the edge. In my opinion, it makes it more realistic for actual use by adding subtlety.

Live

If you want to see these effects live and in practice, then here :) sorry if the code pen sizing looks weird!

Afterword

I hope you enjoyed this! It was slightly different from my usual articles, simpler in a sense, but still fun. But I did want to link two subjects and examples of a 'pixel array' in use. Along with the codebase I made this in :)

Hope you have a great day! If you want to see more of my stuff check out https://www.kadenwildauer.com/ otherwise bye bye!

Pretty in depth backend tutorial I made. Check it out if you want :)

Kaden Wildauer — Tue, 14 Oct 2025 19:00:54 +0000

Kaden Wildauer

Oct 14 '25

What a backend looks like JavaScript, Express and Node.

#webdev #backend #beginners #tutorial

Comments

12 min read

What a backend looks like JavaScript, Express and Node.

Kaden Wildauer — Tue, 14 Oct 2025 15:31:16 +0000

This article is going to go over the backend! More specifically, what a simple backend looks like, how everything fits together with a database, and folder structures. So to do this we are going to walk through each major folder of a common backend and discuss why they exist, what they do, what they contain, and how they tie in with the frontend.

Why what's the goal?

The general goal is for you to understand at a high level how a backend works and what it looks like code-wise, regardless of the tooling we are going to use (Express and Node). When I was getting into backend development, it was hard to find something that really showed me what a backend looked like in practice both the code, concepts, and file structure. There was a lot of wand waving! People didn't show me what actually mattered; I had to figure that out myself.

So, to rectify that here, I am going to go over each major backend directory and file, those being the entry point, routing, middleware, and controllers, showing what each part does, what its code looks like, why it’s there, and how it’s expanded upon in more advanced settings.

What is the backend?

The backend in a full-stack app is a communication point between a database or databases and the frontend, a middleman that in the end, is just a collection of endpoints. For example, say you have a backend server URL that looks like this: backend-url/api/login and the frontend sends a POST request to api/login using HTTP the backend then receives that request and does something based on our logic at that endpoint.

Using the same example, that POST request might check the database to see if a username is in use and return true or false to the frontend depending on the result. Or rather than communicate with a designated database, it could even send requests to other servers/backends instead!

Entry point

So let's get right into it! First what is an entry point? Well, here in Express, it’s a place that both applies settings to our server(otherwise known as the backend) and starts it! Consider the following code.

import express from "express";
import dotenv from "dotenv";
import cookieParser from "cookie-parser";
//Middleware
import errorHandler from "./middleWare/errorMiddleWare.js";
import limiter from "./middleWare/rateMiddleWare.js";
import corsMiddleware from "./middleWare/corsMiddleWare.js";
//Routes
import routes from "./routes.js";

//Configures the environment variables and express
dotenv.config();
const app = express();

//Middleware
app.use(corsMiddleware);
app.use(limiter);
app.use(express.json());
app.use(cookieParser());

//routes
app.use("/api", routes);

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Let’s just walk through it, starting at dotenv.config downward. First, the line itself configures dotenv, which provides variables for the entire server. Think of integral data for our backend like: where is the database? What’s the database’s password? Username? What about the location of the frontend? What are our data encryption keys? All very important information that is sensitive and subject to change. Changes like a switch from a test database to a live one and sensitive meaning that if someone has the encryption key, they could falsify data, or if they have the database sign-in, they can steal all our data! So, .env acts as a safe storage container, basically. And dotenv.config allows our server to access our .env file. Ps add .env in your .gitignore to keep them a secret from github!

The next line initializes the Express app. After that, we get to the middleware but what is middleware? It’s kind of like a layer that data passes through before reaching something else. This middleware is located at the root, meaning all data must pass through our root middleware layer before getting to our routes. Some middleware like CORS and our rate limiter act as security for our backend like Gandalf! While others, like express.json() and cookieParser, put certain data under convenient names for example, all incoming requests that have cookies are placed under req.cookies. But more on the usage of middleware later.

Now, after passing through our middleware, we get to app.use("/api", routes), which is saying every request to backendUrl/api should use the routes file to locate its endpoint for example, backendUrl/api/login looks into routes for a listener for /login, which then provides or requests to our controller. This allows for separation of concerns quite literally like folders or directories allowing us to organize our API as such.

But what about app.listen? Well, this starts our server at port 3000, or if present, our .env’s PORT value. So, we actually find our backend at something like backendUrl:3000/api.

Routes

Now let’s walk through routes! Probably the simplest part of this entire backend thing, here’s an example.

import { Router } from "express";
import { login, register } from "./Controllers/authController.js";

const routes = Router();

routes.post("/login", login);
routes.post("/register", register);
//What we import in the entry point!
export default routes;

Let’s consider our previous example through routes.post("/login", login);. Say we make a request to our backend at the point backendUrl:3000/api/login it goes through our global middleware defined in the entry point, and once its done since it has /api, it then goes through the imported routes as mentioned in the previous section. Then, if it finds a match, it passes the request body to the route, which in this case immediately passes the request to our controller function login but more on controllers later! Now, something important to note is that a match must possess both the name /login and the HTTP type. For the sake of example, consider the following

routes.post("/login", login1);
routes.get("/login", login2);

These are both different routes. A POST request at /login passes its request to the login1 controller, and a GET request to login will pass its request to login2. This is done for one big reason separation of concerns. Endpoints and APIs typically do one thing, that’s it. For example, a POST to /register would provide user data that is then inserted into the database, while a POST to /login might check login info against existing records.

Now, another thing to note is this can be chained in Express. For example, say you send a cookie and a JSON Web Token along with a request body you would want to validate the request before it gets to the controller. In that case, you would slap some middleware in that route like so.

routes.get("/getData", auth, loadData);

So here, it would look and function like this: request -> auth -> loadData. And since our middleware here, auth, is a true or false deal, if that fails, our request never gets to our controller loadData; it just returns an error to the frontend. And something to note in larger applications, your API routing works like frontend directories. Simply put, folders are sorted by purpose. Your /api router would link to other routers like a tree.

Middleware

We have somewhat gone over what middleware is a layer. But what is this layer truly? Well, it’s just code that does 'something' to incoming data. Sometimes that’s data modification, rate-limiting checks, authorization, or error handling. Usually, it represents performing an action on a request before it reaches the main controller logic. Sometimes this is global, like checking every request to see if it follows our CORS settings. Other times, it’s specific to certain routes, like authorizing a GET request before fetching data for a user. Here is one of the most common middleware functions in any backend.

import jwt from "jsonwebtoken";
import dotenv from "dotenv";

dotenv.config();

function auth(req, res, next) {
  try {
    const token = req.cookies?.jwtToken;
    if (!token) {
      return res
        .status(401)
        .json({ message: "Authentication required", success: false });
    }

    const decoded = jwt.verify(token, process.env.ACCESS_TOKEN_SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    res
      .status(401)
      .json({ message: "Invalid or expired token", success: false });
  }
}

This is an authorization middleware for a protected route. So, imagine our frontend requests data from a route that looks like this: routes.get("/getData", auth, loadData);. We added our auth middleware before our controller, defining this route as protected, so any request has to pass through our auth first to see if the credentials are valid. If they are, we pass it onward using next();, which in this case passes it to loadData otherwise, it sends back an error. As a whole, it would look like this: Request -> auth -> loadData -> response. In our middleware here, we validate data by decoding our request data using our web token key. This also shows how convenient and necessary a .env file is we can change access keys often while also keeping them safe!

Now, let’s show you a global middleware I glossed over at the start. Consider this line: app.use(corsMiddleware);. Let’s see what the corsMiddleware looks like.

import cors from "cors";
import dotenv from "dotenv";

dotenv.config();

const corsOptions = {
  origin: process.env.FRONTEND_URL,
  methods: "GET,HEAD,PUT,PATCH,POST,DELETE",
  credentials: true,
  optionsSuccessStatus: 204,
};

const corsMiddleware = cors(corsOptions);

export default corsMiddleware;

All this does is implement CORS for every incoming request in our entry point through app.use(corsMiddleware);. The idea behind middleware is not that it’s a function or security mechanism it’s that middleware is code that does something to a request at certain points in its journey. Sometimes that’s stopping it, other times it’s putting cookies under .cookies, and sometimes it’s handling errors.

Controller's

Controllers (sometimes also called services or modules) are arguably the most important part of a backend. We’ve gone over everything that happens before reaching this point but what is a controller? Well, it’s just a function that completes API logic. Sometimes that’s inserting data, deleting data, or checking up on data like seeing if a payment has gone through. You can think of an API request to an endpoint as a function call, and the request body as the function parameters, with the controller being the function itself. So, let’s see one that communicates with a database :)

import db from "../../db.js"; // Assume db is a configured mysql2/promise connection

// Gets the share info for the user
async function getShareInfo(req, res, next) {
  try {
    const userId = req.user.id;
    const [rows] = await db.execute(
      "SELECT share FROM dailyfitinfo WHERE userid = ? LIMIT 1",
      [userId]
    );
    if (!rows || rows.length === 0) {
      return res
        .status(404)
        .json({ message: "No record found for user", success: false });
    }

    res.status(200).json({ success: true, shared: rows[0].share });
  } catch (error) {
    //next(error) represents sending unknown error's to a global error handling software for later review
    next(error);
  }
}

This is a very simple controller function we send over the userId in the request and then, using our ID sent in the request, we send a query to our database. All our query does is pick a piece of data, and we return the true or false .share value of said data in our response (res).

But not all controllers talk directly to a database some fetch data from other services. For example, you might make a request to another service to check payment information, or maybe you want to get data from Spotify? In both those cases, you follow that API’s documentation, make your request, and then have data to presumably send to a frontend to display! Although, as you can imagine, all the payment service or Spotify is doing is requesting data from their own database.

And just like routes, each controller lives in its own folder under /controllers, separated by purpose. Most of the time, you would separate folders based on how you separate your routes so they both have the same corresponding folders.

Our database

But we glossed over db and how we communicate with our personal database. So what is db? Well, here we use MySQL as our database, and to write queries and receive data from our database, we need to connect to it and use some sort of method to send an SQL query over. Here we are using the mysql2 npm package, which allows us to connect to a MySQL database and send queries. The connection is represented as db, and it looks like this.

import mysql from "mysql2/promise";
import dotenv from "dotenv";

dotenv.config();

const db = mysql.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER, // e.g. "root"
  password: process.env.DB_PASS, // password
  database: process.env.DB_NAME, // db name
  waitForConnections: true,
  connectionLimit: 10,
  queueLimit: 0,
});

export default db;

All db really is is a pool of connections to the database, and when you write SQL using db, it chooses a connection from our pool for you to send and receive information from your database. We use a connection pool for a few reasons first, so we’re not opening and closing connections constantly; second, so we can handle multiple requests concurrently; and third, so we can add limiters (10 here) to ensure our database never gets overloaded.

You also, of course, need to provide your connection information so mysql2 can locate the database and log in as a user. That happens to be sensitive information, so we put it inside of .env as well! Almost all APIs connect to a database in some way, and they all have some connection or config file like this.

What else you might see

Backend is complex way more than what I can put here. There are so many layers to it, just like the frontend! But before I wrap this up, I wanted to show a few more commonly seen backend practices so you never get lost. This will especially help anyone looking in biger production level backend's.

ORM's

Often times, production-level backends don’t usually use raw queries to communicate with their database. Instead, they use 'pre-built' queries these are called and used like any JS function but convert into SQL queries using the parameters and data you provide them. The controller function I showed would look like this using a common MySQL ORM, Sequelize.

async function getShareInfo(req, res, next) {
  try {
    const userId = req.user.id;
    //New part ORM part!
    const sharedRecord = await dailyfitinfo.findOne({
      where: {
        userid: userId,
      },
    });
    //End
    if (!sharedRecord || sharedRecord.length === 0) {
      return res
        .status(404)
        .json({ message: "No record found for user", success: false });
    }

    res.status(200).json({ success: true, shared: sharedRecord.share });
  } catch (error) {
    next(error);
  }
}

Okay, so this looks simpler than before, but why even bother with an ORM at all? First, they are faster to code with, more compatible and more secure. What do I mean by compatibility and security? Well, many ORMs work with multiple databases, so switching to a different database won’t immediately break all of your backend. Now, as for security and this is a big one. First, all your queries validate data automatically, so no accidentally inserting incorrect data. Along with this, ORMs have a few helpful side effects, like preventing SQL injection and handling table relationships in code, which leads us into ORM models!

One of the biggest parts of an ORM is models. Think of a model as a definition for each table in your database it defines the table’s name, row names, primary keys, types, uniqueness, and more. Basically the same as what someone would do by writing raw queries, but using JavaScript, making it easier and faster to work with. One of the biggest things this helps with is type checking you can’t insert wrong types, and it generally enforces rules according to your models, so happy little accidents while coding end up highlighted! Another big point for compatibility is if you migrate to another ORM and DB, all you need to do is update your models, and they will automatically sync your database to follow your model. Here is a super simple and short example of a user model.

import { DataTypes, Sequelize } from "sequelize";
import ConfigDb from "../config/configDb.js"; //Sequalize connection very similar to db in previous examples
//
// User model
//
const User = ConfigDb.define("User", {
  UserName: {
    type: DataTypes.STRING,
    allowNull: false,
    unique: true,
  },
  Password: {
    type: DataTypes.STRING,
    allowNull: false,
  },
});

export default User;

Now remember, just like routes and controllers, models usually get their own folders, each representing a table in your database. You can structure this the same way you do your controllers and routes for example, all auth-related models being under models/auth, keeping things easily accessible between those portions of the backend.

Data validation

Now, something else that can add complexity to a backend in code, files, and directories is data validation. We touched on this in ORMs by preventing the insertion of invalid data and checking syntax, but this goes much deeper.

First, a big concept in backend development is never trusting incoming data. Every request could include malicious or unexpected data, so we need to validate the data to prevent database errors or security issues. We do this by type-checking incoming data, so many backends use something like an npm package called Zod. This then leads to another folder called pipes (or names like validation, maybe schema), where you define your Zod schemas. A Zod schema is pretty much a model for incoming API request data. This ensures incoming data is exactly what you want it to be in type and length.

So, expect or implement some form of validation in a backend.

Afterword

If you want to dive deeper, here are some useful resources on areas I glossed over a bit :)

Andddd that’s pretty much it! Hopefully, you learned something here I spent lots of time on this, over 2700 words! Longest article I have ever written I even drew a thumbnail(didn't use it though!). If you want to see other stuff I have made, just visit my portfolio should be interesting for dev's, and have a good day!

Spent a lot of time on this article it was a fun topic as well. Check it out if you interested!

Kaden Wildauer — Fri, 26 Sep 2025 21:53:34 +0000

Kaden Wildauer

Sep 26 '25

Flow Fields, Painting with Math

#webdev #programming #tutorial #frontend

Comments 1

10 min read

Flow Fields, Painting with Math

Kaden Wildauer — Fri, 26 Sep 2025 20:28:36 +0000

This article is going to go over flow fields! A really fun and interesting concept used in computer graphics, generative art and fluid mechanics. Flow fields can be used in so many creative ways a website background, for a card or maybe for illustrating a simple image? By the end you will (hopefully) have your own flow field to work with while also understanding how it works and how to dive deeper if you want. And of course all with diagrams, cool imagery and a live example at the end.

Flow fields the idea

But what is a flow field? Well young padawan, it is a method for drawing lines using vectors, more specifically a field of vectors. When we draw lines through the field, each vector below it pushes it around, forming a shape. Like a pen over a piece of paper that's being pushed around before it reaches its destination. That is then repeated over and over until we have drawn the shape of the vector field with the curved lines. The result can be something like the image shown below.

This uses a smooth water-like vector field. The entire idea is switching out the program that forms the vector fields, the curve or the coloring to create an image. You can even form proper shapes like animals or faces.

Step's to build

First let's define the stages we will use to build a flow field. First we will build a grid think of something like graphing paper, we provide each cell a vector and finally actually drawing a curved line. Each stage is equally important in creating the final result. And as a side note, I will be using React and TypeScript and will have to gloss over some of the setup, i.e., canvas, for the sake of time so keep that in mind! But there is a link to the code at the end for you to peek at. Most of what's taught here is the less language-specific knowledge so don't worry.

Grid

Here we first start by creating a grid again, again imagine something like graphing paper. And each cell in this grid holds three values: an x and y location along with a vector. You can think of the vector like an arrow pointing in a direction while the x and y are the cell's center.This grid acts as a map when we draw our curves so we can find the vector below any point.

Grid vector's and perlin noise

The next step is filling the grid we just created with the vectors. Now there are many ways to do this, but here we are going to use perlin noise. This allows us to get random numbers, or in our case vectors, that are less... well, random. The idea is the numbers that are generated are more gradual no huge jumps which will create very cohesive and smooth wave like patterns.

Curve's

And the last step is drawing the lines across the grid. The idea behind this is the line curves according to the vector of the cell beneath it. We can then control how long the lines are and how they are colored. For example, making shorter lines darker while longer lines are lighter, adding depth. This step brings the field we made in the second step to life like the image above!

Creating our grid

Ok, now for the fun stuff. To make our grid we need to divide our window into rows and columns. But! Before that we need to define our resolution, otherwise known as the width and height of each cell in our grid. Then, after defining that, we divide it by the length and height of our window. This will give us how many cells we need based on our window dimensions. Here is the function I am using for getting the row and column count.

//What
const leftRight = useRef({
  leftX: window.innerWidth * -0.25,
  rightX: window.innerWidth * 1.25,
});
const topBottom = useRef({
  topY: window.innerHeight * -0.25,
  bottomY: window.innerHeight * 1.25,
});
const rowRef = useRef(0);
const colRef = useRef(0);
const Pix_size = 15; //Act's like a resolution

function Impose() {
  const rows = Math.floor(
    (leftRight.current.rightX - leftRight.current.leftX) / Pix_size
  );
  const cols = Math.floor(
    (topBottom.current.bottomY - topBottom.current.topY) / Pix_size
  );
  rowRef.current = rows;
  colRef.current = cols;
  // Creates the grid based on the number of rows and columns
  let initialGrid = create2DArray(
    rows,
    cols,
    leftRight.current.leftX,
    topBottom.current.topY
  );
  gridRef.current = initialGrid;
}

Let's walk through this first. Why am I not just using window.innerHeight and window.innerWidth? That's because when we draw the curves we want some to start off-screen so some curves can flow into the viewable space. That means we need cells for this extra space, and here every side gets a 25% increase from the natural window size. Now considering the height, to get the amount of columns we need, it would be screen height divided by our cell's width to get the number of columns we need, and width divided by cell width for rows.

We now have the amount of rows and columns we need for our grid, but now let's actually create it. To do this we should create a 2D array to store each cell's location and angular data. We do this in create2DArray();, which looks like so.

function create2DArray(
  Rows: number,
  Cols: number,
  leftX: number,
  topY: number
): GridEl[][] {
  let arr = new Array(Rows); //Create array of empty rows

  for (let i = 0; i < arr.length; i++) {
    //Index into row and create empty columns
    arr[i] = new Array(Cols);
    //Iterate over the empty columns in the row
    for (let j = 0; j < arr[i].length; j++) {
      arr[i][j] = {
        x: leftX + i * Pix_size,
        y: topY + j * Pix_size,
      };
    }
  }
  return arr;
}

Before we go into the code, remember each cell's x and y represents its location; otherwise, it's just a 2D array!

So let's just dive into the code before showing the result. First we create an empty array full of uninitialized slots, each slot representing each row and its children, the columns. Now, considering the i loop, we index into the row here arr[i] = new Array(Cols); and fill it with empty slots representing the number of columns we need. Then in j we fill those columns using arr[i][j] so we can visualize, say arr[i][j] = 0, and Cols and Rows are both 3, the data structure would look like so.

let arr = [
  [0, 0, 0],
  [0, 0, 0],
  [0, 0, 0],
];

But in the final product we actually push an object, so in reality imagine each 0 being an object like so {x: 0, y: 0, angle: 0} with the proper x, y, and an actual angle present. But we will add in the angle later; for now, consider the x-axis of a cell specifically: x: leftX + i * Pix_size. We get the proper x location of each cell by adding the leftmost point, then multiplying it by the index and Pix_size, pushing it to the right by the number of cells that already exist.

Now, for a little visualization, I made a simple draw function that loops over arr and draws a rectangle around the center. Its width and height are, of course, still the Pix_size, but I did increase Pix_size temporarily to 25px so it’s more obvious.

Grid Vector's

Now let's consider how we fill our grid with angles, which is, as mentioned, using Perlin noise. Now I could go into how Perlin noise actually works and how we can implement it from scratch, but the truth is... I have no clue how it works! But luckily you don't really need to know how it works, just the general idea.

Which is generating smooth random numbers. But what do I mean by smooth? I mean there are no jumps in the randomness. To visualize, consider a mountain in array form with a max of 100 and a min of 1, like so [0,4,8,10,15]. Now let's say our next number is randomized it could very well just be 80. No mountain or natural formation, just suddenly gets a 5x increase in size. Perlin noise makes sure the randomness is within reason: small jumps either up or down, considering the mountain. But going back to code, there are multiple npm packages and implementations online. Here is the one I am using.

But moving past Perlin noise, let's visualize the angles themselves. For this, I am going to draw a point in the center of each rectangle and a line a fourth the size of the Pix_size in the direction of each cell's angle. Furthermore, I am going to remove the Perlin noise so you don't need it to go further and to simplify the following visualization. I also increased Pix_size to 40 so it's easier to see.

Here is the new loop inside create2DArray with the angles actually added this time. I am also using the simplified angular math instead of Perlin noise here.

//Inside the create2DArray function!
for (let i = 0; i < arr.length; i++) {
  //Index into row and create empty columns
  arr[i] = new Array(Cols);
  //Iterate over the empty columns in the row
  for (let j = 0; j < arr[i].length; j++) {
    const angle = (i / Rows) * Math.PI * 2; //Simplfied angle
    arr[i][j] = {
      angle: angle,
      x: leftX + i * Pix_size,
      y: topY + j * Pix_size,
    };
  }
}

Drawing the curve's

Before we get into the code for our curves, it's good to know how people even draw curves in computer graphics. And that is drawing a series of very short lines to form a curved shape. As for the next part, the coloring, I will be using length to determine color. Just keep this in mind!

function drawCurve(
  ctx: CanvasRenderingContext2D | null,
  gridRef: React.RefObject<GridEl[][]>, //Array of cells
  //Our modifyed window
  leftRight: React.RefObject<{ leftX: number; rightX: number }>,
  topBottom: React.RefObject<{ topY: number; bottomY: number }>,
  colorValues: { h: number; s: number; l: number }, //Orginal color
  Pix_size: number //Passing over current cell size
) {
  if (!ctx || !gridRef.current.length) return;

  // Random start point
  let x =
    leftRight.current.leftX +
    Math.random() * (leftRight.current.rightX - leftRight.current.leftX);
  let y =
    topBottom.current.topY +
    Math.random() * (topBottom.current.bottomY - topBottom.current.topY);
  //Line length
  const num_steps = 100;
  const max_step_length = 5;
  const step_length = Math.floor(Math.random() * max_step_length);
  const grid = gridRef.current;
  //Color pick
  let Lencolor = lengthColorPick(
    num_steps,
    max_step_length * num_steps,
    step_length * num_steps,
    colorValues
  );

  // Begin curve
  ctx.beginPath();
  ctx.lineWidth = 1;
  ctx.strokeStyle = Lencolor;
  ctx.moveTo(x, y);

  for (let i = 0; i < num_steps; i++) {
    // This updates the line by using the new x and y
    ctx.lineTo(x, y);

    // Calculate grid indices allowing us to get the cell data under our current x and y
    const column_index = Math.floor((x - leftRight.current.leftX) / Pix_size);
    const row_index = Math.floor((y - topBottom.current.topY) / Pix_size);

    // Check bounds
    if (
      column_index < 0 ||
      column_index >= grid.length ||
      row_index < 0 ||
      row_index >= grid[0].length
    ) {
      break;
    }

    // Get angle from grid
    // Calculate step based on angle and apply to its current position
    const grid_angle = grid[column_index][row_index].angle;
    const x_step = step_length * Math.cos(grid_angle);
    const y_step = step_length * Math.sin(grid_angle);
    //Update position
    x = x + x_step;
    y = y + y_step;
  }

  // End curve
  ctx.stroke();
}

Now let's walk through this. First, we pick our starting point in relation to the modified canvas the random x and y. We then define the length and amount of lines which form the curve, which is num_steps, the number of straight lines that make up a single curve. Then step_length determines how far each straight line will travel. Depending on how these two variables are set, you can get more blocky or geometric lines; here they end up pretty smooth. We also set the step_length as any number between 1 and 5, giving us different curve lengths. After this, we pick our color ignore lengthColorPick, I will cover that shortly. The next portion is moving our x and y continually to draw the curve.

In the loop, we draw a line to x and y, then the real bread and butter: we find the indices so we can slice into our grid and get the location of the cell under the current line's x and y position. Store that in column_index and row_index, and then create an if check to be sure it's in bounds. We do this because mathematically we want space outside the visible space, but we can't actually draw off screen. After we have the indices set, we can get the angle of the cell under the x and y location. Then we can just use cos and sin multiplied by our step_length to get the x and y velocity and apply that change to our curve's current line. This pushes the curve in that specific angular direction, creating the entire flow effect.

So next, let's quickly go over how we actually color the line. The lengthColorPick I glossed over looks like this.

export function lengthColorPick(
  min_length: number,
  max_length: number,
  current_length: number,
  colorValues: { h: number; s: number; l: number },
  intensity: number = 0.5
) {
  // Normalize current_length to a value between 0 and 1
  const normalized =
    Math.max(
      0,
      Math.min(1, (current_length - min_length) / (max_length - min_length))
    ) * intensity;

  // Use normalized value to adjust the original lightness
  const adjustedLightness = colorValues.l * normalized;

  return `hsl(${colorValues.h}, ${colorValues.s}%, ${adjustedLightness}%)`;
}

This returns the color we set a single time for each curve. The idea is we give it an original color value inside colorValues, like pure red, then give it the max possible and min possible range, and have it normalize the distance compared to the max. For example, between 0 and 1000, our normal would be 0.4 at 400. Using that normal, we can decrease the original lightness, which is adjustedLightness. For some extra control, I also added intensity, which decreases our normal value. Say we use the default 0.5 for intensity and our normal is again equal to 0.4; we perform 0.4 * 0.5, halving our normal, which in turn decreases our lightness.

Variations

Now before this gets any longer, I want to show you some variations! Below, I gave every cell a color based on its position, column wise, splitting it into 5 sections, each holding a different color in the cell. Then in drawCurve, I would slowly alter each stroke according to what the cell's color below it is. Which, if given gold and reds, looks like so.

And here is a live look. Here I went back to using lengthColorPick but put the logic into a render loop so we slowly see the image being created.

And to be clear everything shown here only scratches the surface of flow fields, so if you want to go further or just want some more resources, here are some links!

Afterword

I hope you learned something from this or at least found it to be a fun read. I did put a lot of effort into it! If you want to check out more of my stuff then visit my portfolio at https://www.kadenwildauer.com/scriptorium
spent easily more than 100hr's making that website should be interesting for dev's to visit.

A high effort hopefully fun article :)

Kaden Wildauer — Sun, 21 Sep 2025 02:50:28 +0000

Kaden Wildauer

Sep 16 '25

Building a Mouse-Responsive SVG Polygon Background with JavaScript and CSS

#webdev #javascript #beginners #frontend

Comments 1

6 min read

Building a Mouse-Responsive SVG Polygon Background with JavaScript and CSS

Kaden Wildauer — Tue, 16 Sep 2025 00:40:20 +0000

This article will go over how to transform a static SVG image into a cool mouse responsive background! It can be used as a cool add on for a hero for portfolios, interactive websites, or even in more professional settings if you're feeling like creating something interesting. More specifically, this article is about manipulating a polygon background generated from Haikei, a free SVG pattern and effect generation resource.

The Idea

The goal is to have a Haikei polygon background change colors on mouse hover. When a user hovers their mouse over the SVG image, the triangles below subtly change color, with a lesser effect on the immediately surrounding triangles. We can implement a few different interesting effects, such as darkening the surrounding triangles, lightening them, or adding glow effects. There is a CodePen at the end if you just want to see the result! Or just want to see any code I gloss over here.

Getting our background ready

Ok, let's go over where to go if you want to follow along. Here is the resource: https://app.haikei.app. Below is the image I will be using.

First, we need to import the image into Figma. Because Haikei exports are typically smaller than what we want for a PC screen (1920, 1080), and we can change this easily there. If you want maximum compatibility, you can also generate another smaller image for phones.

Now comes the hard part. Do you know how many polygons are in that image? 108... We need unique IDs for every polygon, so you can either edit the SVG in Figma and give each path/vector a name and then click Export as ID, or you can manually edit the SVG code in your project. For flexibility, give them an iterable name like Vector1, Vector2, etc. Have fun! You could make a script for this but it's only a one time thing so why not just suffer a bit?

Now for the last bit of the basic setup, we should give the SVG tag more flexible sizing options, something like so.

    <svg
      width="100%"
      height="100%"
      viewBox="0 0 1980 1080"
      fill="none"
      // This allows the SVG to stretch without preserving aspect ratio
      preserveAspectRatio="none" 
      xmlns="http://www.w3.org/2000/svg"
    >

We also should put it inside a div that looks like so.

.poly-container {
  position: absolute;
  top: 0;
  left: 0;
  height: 100%;
  width: 100%;
  overflow: hidden;
}

Then we are good that's all the setup. Now it is the more complex stuff.

Manipulating the polygons

There are multiple ways to go about this. To change a single polygon, we only need to add a :hover effect to the CSS for the SVG paths with a transition. But that's not the goal; we want to affect multiple. Now I had a few ideas the first was creating a grid of points around the mouse in a circle and changing the colors based on distance. But that runs into a few issues first, it's unnecessarily complicated, and we would need to constantly check the element below a point with elementFromPoint. Which is a little much considering we want a lightweight background. But good news! I landed on a different solution shown below.

Initialize poly data

My idea was we iterate over the SVG internals once at the start and collect 4 values. First the distance, then the color, ID name, and finally the center of the polygon. We can then store all 108 elements in an array. The type/object structure is shown below.

type IdValue = {
  id: string;
  distanceToMouse: number;
  color: number[];
  elCenter: DOMRect;
};

Now, why do we need to store these things? First, we need the ID for the reference and location, the distance as a placeholder, and the color as the initial value. For color, we of course need to change it, and if we want to return to the original, we need it in memory. As for elCenter, we only want to store each polygon's center point once on initialization or on resize. Otherwise, if we don't store it, we run getBoundingClientRect(); every frame, which is intense and unneeded.

Mouse loop

Now we have initialized our values, we can now consider the main loop. Now I put my functions into an on mousemove event listener. We only need to consider changes when the controller aka the mouse moves. Here is what it looks like.

  // mouseRef is a react ref its a obj like so { x: 0, y: 0 }
  // otherPolyRef is also a react ref but it contains all the IdValues
  function mouseMove(e: MouseEvent) {
    //Storing mouse pos
    mouseRef.current.x = e.clientX;
    mouseRef.current.y = e.clientY;
    // Looping over the array of IdValue the initialized values
    for (const i of otherPolyRef.current) {
      updateDistances(i);
      darkenDistance(i);
    }
  }

Now we store the mouse position for use inside updateDistances, the bread and butter of the entire effect. Now updateDistances is as it sounds; we pass it every IdValue, it calculates the Euclidean distance from the center of the polygon to the mouse, and stores the new value inside the IdValue.

Applying color based on distance

Now from this point, every IdValue has the updated distance value. Now we can look at what creates our effect darkenDistance, which to simplify for now is just a black and white color change. The elements closer to the mouse are darker those further to a point are just white. The code and what we expand upon for the colored version is like so.

export function darkenDistance(
  i: IdValue,
  distanceMax = 1000,
  intensity = [0.01, 0.99]
) {
  //Collect needed elements and values
  const el = document.getElementById(i.id);
  if (!el) return;
  const distance = Math.min(i.distanceToMouse, distanceMax);
  const originalLightness = 100;
  // Normalize: 0.01 (close) to 0.99 (far)
  const norm = intensity[0] + intensity[1] * (distance / distanceMax);
  const lightness = Math.round(originalLightness * norm);
  // Apply new color
  el.style.fill = `hsl(0, 0%, ${lightness}%)`;
  el.style.stroke = `hsl(0, 0%, ${lightness}%)`;
  el.style.transition = "fill 0.3s linear, stroke 0.3s linear";
}

Ok, let's walk through this. First, we collect our important values from IdValue: the ref, the colors, and the 'originalLightness'. Again, this is set to 100, and hue and saturation are set to 0; it shows a more professional-looking version of the effect.

Now, the most important thing is the math. Here, it's super simple and linear, but in essence, say we are far from the mouse but still in range. Our normalized distance comes to 0.99 we multiply that by our lightness, it slightly decreases, but if we are close or the closest, our original lightness is multiplied by 0.01, shrinking drastically. Our intensity acts as a range if we don't want such drastic darkening, we make 0.01 something like 0.1 or more. As such, when moving our mouse, we will get something like so.

Now for color, we just extract and store the proper original inside i.color instead of just using pre-made values. And when inputting our new lightness, we add the original hue and saturation.

  el.style.fill = `hsl(${i.color[0]}, ${i.color[1]}%, ${lightness}%)`;
  el.style.stroke = `hsl(${i.color[0]}, ${i.color[1]}%, ${lightness}%)`;

Now this is where it gets fun; you can add glows to it as well. Reverse the effect, make it appear lighter the closer it is to the mouse. Or just decrease the effect in general, make it less noticeable so it works in a proper design instead of a fun animation.

Variations

Here I am going to show off some images of a few variations I made before linking to a CodePen of my favorite effect. All of these can by altering the darkenDistance function or altering the SVG coloring on initialization. Before that, a side note if you don't want to regenerate a new SVG from Haikei to change the colors to something new, you can just stick something in the initialization stage that alters the colors to a range you desire! And here is my favorite, the simplified black and white with solid black strokes. Still using the purple poly svg.

Here is the original idea. A little disappointing, to be honest, but I am pretty sure that's because of the colors here.

Here is a fun one. I added a glow along with darkening the color. Furthermore, at a distance, I also added a lightening effect.

And finally, here is a CodePen so you can mess around with it yourself.

Foreword

First, I hope you enjoyed this or found it interesting! I love making things like this it's highly flexible, interesting, and I could really see it making fun backgrounds for websites. I hope you learned something from this. And if you want to check out more of my stuff, you can visit my website https://www.kadenwildauer.com/ or wait for my next article it's sure to be interesting!

High effort article I made a few months ago :)

Kaden Wildauer — Tue, 09 Sep 2025 21:23:07 +0000

Mapping a Full Stack Application

Kaden Wildauer ・ Sep 9

#webdev #beginners #tutorial #architecture

Mapping a Full Stack Application

Kaden Wildauer — Tue, 09 Sep 2025 21:04:15 +0000

This article is going to map a full stack system: the what, where, and why. This isn't really system design but going over a pre designed system and aimed at beginner to lower-intermediate web developers. There are going to be three sections. First is serving code; this will go over what happens when you visit a full stack application. The second is logging in, this is a smaller section, but in most full stack applications, being logged in is fundamental. The third section is common operations, this section is going to go over what happens when someone logs in and is using the application. Where does JWT fit? Cookies? CORS? HTTPS? API calls? And other things that are important to understand when building a full stack application.

Serving the website

I. Initiation

As shown in the image, the first step is simply typing the domain in. This is important to mention because we are going to be going over domain names and how they work.

II. DNS Lookup

This is the second step and leads into how the internet works. And the internet is all about endpoints and IP addresses. You see, google.com or www.kadenwildauer.com don't really exist, they are just human-readable names that point to an IP address. The true name is just a random string of numbers that point toward the location of the server/endpoint. So let’s go over how and what a DNS is. DNS is a bit complex. In truth, first, in some cases, they aren’t even used because you have already visited the site and your browser has cached(saved) the IP address. But in the case that you have not visited it, your browser's memory will look through a DNS server to find the endpoint of your domain name. Every device or tech that connects to the internet has an IP address, and the DNS server is a database that maps domain names to IP addresses.

III. TCP/TLS Handshake

First, TCP stands for Transmission Control Protocol. Using a metaphor of what this does, it’s like a pipe that connects both the client and server otherwise, we are just spraying water and hoping it gets to the other side. More directly, it ensures all data packets are sent and received in the correct order, a connection exists before data is sent, data integrity is verified and protects devices against to much data aka data flow. And that’s what it does and why it's used. How it’s set up is a three-way handshake. You can research this more on your own, but basically, we request a connection, the server says yes, and then we say yes back.

TLS is a wrapper for TCP that adds encryption to the data being sent and received. And this is used everywhere a website with https:// uses TLS and is using high level and impactful encryption sometimes marketed as 'military grade'. Now, this is rather simple to know why it's used, but let’s go over how it initiates, which is arguably more important than understanding TCP specifics, because you might actually need to know specifics of how TLS works, while TCP is more automated and you don’t need to know the specifics. First, the client initiates a connection with a 'hello' message, which includes the TLS version, cipher suites, and a random number. The server responds with its own 'hello' message, which includes its chosen TLS version, cipher suites, random number, and SSL certificate. The client then verifies the server's certificate against a list of certificate authorities or, more commonly, the exact authority that issued the certificate. This is to ensure the server is who it says it is. Then the client sends a pre-master secret encrypted with the server's public key and can only be decrypted by the server's private key. And the client gets the server's public key from the SSL certificate. Then the server decrypts it with its private key, and both client and server generate a session key using the pre-master secret and the random numbers exchanged earlier. The key should be the same on both sides. They exchange a 'finished' message encrypted with the session key to confirm the handshake is complete. And now both client and server can communicate securely using the session key.

SSL certificates are an important thing I want to add to a bit more. First, SSL is the old name for TLS technically it’s a TLS certificate and you can just think of it as a base64 encoded file that contains things like the public key, the domain name, the certificate authority that issued it, and the expiration date. It’s not some special certificate, just some key-value pairs that the client uses to verify information and acquire information.

IV. HTTP Request

The HTTP request is the next step and probably one of the most basic steps in the process. We are just sending a request to get the compiled frontend code for the website. This step is practically the same as any other HTTP request you would make to a server, and also, in most cases, automated by the browser.

V. HTTP Handling

Now here, there is a wide variety of how a response is received and sent back. In many cases, you do nothing and some other service handles the response for you for example, Nginx, Apache, Caddy, or Serve. So most all the time, this is something automated but necessary to understand.

VI. Response

This response is the final step in most cases. We send back the compiled frontend code, and the browser renders it. This is the end of getting a website on your screen.

Logging In

This is meant to be a short section that's important for understanding how a full stack application works, and that’s logging in and how it ties into the last section, which is mapping common operations. We need to know where the data is stored in this stateless application.

I. User Submits Login Form

This is rather simple and self-explanatory the user is sending login or signup information to the server.

II. Server Validates Credentials and JWT Explanation

The server checks the credentials against a database, checking if it exists, if the information is correct, etc. And wraps the information with a JWT. We don't store this on the backend to keep things stateless I will link a resource at the end about stateless apps. But the JWT, while having nuances, is a kind of wrapper for information. It holds 3 important pieces of information. The first is the header, which is the algorithm used to sign the token. The second is the data or information we are wrapping. And the third and most important is the signature, which is a combination of the header and payload that is signed with the secret key. The idea is: Header algo + Payload + Secret key = Signature this is calculated when we sign (aka create) the JWT. And when the data gets back, we run the same calculation and compare it to the signature in the JWT. Someone tampering with the data does not have the secret key, so they can’t create a valid signature. And this is how we verify the JWT and its data.

III. Storing JWT in Cookies and Cookies Explanation

First, the JWT is sent back with the important information and, in this case, stored/sent in a cookie. Cookies are very similar to local storage but with key differences. The first is that they are automatically sent with every request, which promotes security and statelessness. The second is size limitations it’s vastly smaller than local storage and has a limit of 4KB per cookie, and most browser's have a max cookie limit. The third, and most important, is flags that can be set on a cookie like HttpOnly, Secure, SameSite, Domain, and time. These all have meanings and reasons, but here I am going to talk about time. The rest is a little bit of research you can do on your own but each protect against a type of attack. Time is like a JWT a cookie has a storage expiration time. Depending on the time and type of application, this can be a few minutes to a few months.

Mapping Common Operations

This section is all about mapping common operations in a fullstack application. The definitely really cool, and well designed looking diagram below will be explained in numerical order and will be a walkthrough over each step and important pieces of information...

I. HTTPS

Here, especially after we had that long explanation of TLS and SSL, what is the point? What does https:// do? Well, it does one really important thing and that is encrypt the data being sent and received. But only if the other endpoint is also using HTTPS. If not, it's a normal naked HTTP request. So, as shown on the diagram, the backend is hosted on, for example, https://kadenwildauer.com/api, so it's still protected by TLS and SSL. While our communications to the SQL database are not encrypted. It's not really needed because it's a private network and not exposed to the internet. But that's HTTPS.

II. Cookies

Now, I already went over this, but it's still something to note that since this is a stateless application, we need all the information to be sent with every request so we can query based on that data. Now, of the available cookies we can use a certain amount which is different for each browser we are using only one, which is wrapped in a JWT.

III. API Calls

The API calls are the next step. Let's go over requesting data:
First, we send a cookie and information related to the backend function we are calling. If we pass certain checks decided by the backend like for example authentication, CORS, and other things I will go over later, we get a response back with the included data. This is generally the same for all API calls and is the most basic operation in a full stack application. But it's important to note the amount of control the backend has over the frontend. It's ideal for that to be a lot of control because the frontend is just the client. And they can manipulate it in any way they want. So depending on the app, the backend can have a lot of control over the frontend.

IV. Pages and Routing

This is a part that I debated on whether to include, but it feels integral enough to an application given that most full stack applications are not single page and have routes and pages. Now, a route is just a path that can be easily created by a programmer and is a way to organize the application. When you click on a button, for example, we go to another route and unload the previous page and load a new one a page being code like html, CSS, etc. It's easy for us to implement and use. Some websites don't have this, and that's fine, but most do.

Now, what about backend routing? Well, it's kind of similar, but not really. It's a way to organize requests and responses. For example, to log in we might go to https://kadenwildauer.com/api/login, and this route expects certain information to be sent with the request and runs certain functions based on the route. Commonly, this is something called a controller directory that holds controllers functions that handle the request and response. And this is how we organize our backend code.

V. Database

Now this is an integral part of a website. Most everything on a website specific to you, the user, is stored in a database. We store things like login information, user data, posts, comments, and other things. This is a very important part of a full stack application. There are many types of databases or methods of storing data. But most commonly, we use a SQL database like MySQL, PostgreSQL, or SQLite. We also most commonly use an ORM, or Object Relational Mapper, to interact with the database. This is a way to interact with the database using code instead of writing raw SQL queries. It’s more flexible, fast, and easier to use than writing raw SQL queries. Although it can be slower and less efficient in that case, you still need to write raw SQL queries. I won’t go into too much detail, but as for security, it consists mostly of a few things. Such as sanitizing inputs, not exposing the database to the internet, using .env files to connect and store the database connection information, limiting types of connections allowed, permission monitoring, and using a TLS connection to the database.

VI. Backend Protections

We have covered most everything integral to a basic full stack application the more external stuff and here we are going over backend protections. This is very important and often overlooked by beginner developers I know I did. But it’s important because if you're doing things correctly, then the backend is the gatekeeper for portions of frontend code and data. So we need to protect it. The first is CORS, or Cross Origin Resource Sharing. Think of it like a wall that protects from request types that you don’t allow for example, from a different domain or origin, a non HTTP request, or a request without credentials. The second and most important is middleware, often called auth or something similar. This is a function that checks a request's credentials. Do they have a valid JWT? Is it expired? Is it a valid user? And other requests that a programmer might want to check. If I visit a site and go to a protected route, something like an auth middleware will check and, in this case, not allow me to access any HTTP request or even load the component depending on the developer. Although, as we went over, frontend code does not really do much if someone is determined to get the data. There are other protections like rate limiting, input sanitization, and other things that are important to know about but not really needed to understand a full stack application.

Puzzle Pieces

This is a basic high level overview of a full stack application and how it works. I did not go over the why of everything because that goes into system design, and that is not what this article is about.
This is about if someone is building a full stack application what are the pieces they need to know about and how they fit together.
Any of these things that I mentioned can be moved around, manipulated, changed, and I have no doubt that some research into any of these topics will lead you to ways of improving your full stack application.
But no matter what, almost all full stack applications will have these pieces, and it's important to understand how they fit together.
It gives more freedom of thought and creativity for a developer. And if you know this, abstractions? Are easy. SaaS products? You’ve already made a full stack application manually or understand what’s actually happening.
So an abstraction? That’s light work. If you understand this stuff, maybe implement it yourself. Then all full stack applications are just these pieces implemented in different ways.

Conclusion

I hope you gained something from this article and learned something new. Apart from my bad diagram skills, I hope you learned something about how a full stack application works and how the pieces fit together.
Regardless, have a good day. I am going to include some resources below for steps that I had trouble with or that I think are important to understand and as for some proof two of my
full stack apps used a modified version of what I just showed you with an ec2 you can see them in the skills section.