SimWeek: I Didn't Spiral. I Just Worked

#webdev #learning #frontend #beginners

Five Days. One Dev. Zero Chill.

Welcome to SimWeek. I'm using my vacation to simulate being a junior developer with daily builds, real constraints, and brutal honesty. Because if I want to thrive in this industry, I need to stress both my technical skills and my workflow

TL;DR- July 9 - Day 1

It's 11:00 a.m. My phone and laptop are on DND. Amanati is playing in the background. There was no spiraling today. No structured schedule either, but it is a deep dive day. I briefly experienced a bittersweet realization. My pet project will have to live in the margins…for now. And I grapple with a new technical concept–retina images.

Skillcrush - 11:00 a.m. - 12:00 p.m.

I’m restarting the JavaScript Fundamentals. I passed it before, but the cracks started to show when I began the JavaScript React module, and the water started spewing out of the holes.

I emailed my instructor to reset the module. Why? Now that I have grasped the basics, I want to go deeper. The easy stuff? I flew through. But the moments where I copied the teacher's solution just to finish without understanding—that’s where I need to dig.

Data Types & Arithmetic Operators ✅
Comparisons & Conditionals ✅
Manipulating the DOM ✅.
Event and Event Listeners⚠️
I struggled with writing the classList and mixing up innerHTML vs innerText. But that's okay, right? No! Not if it shows up again when the stakes are higher
Functions🛑
Oh, look! Higher stakes!! Functions tripped me up. Not writing them, but using them as building blocks. I couldn’t tell when to abstract something out. I kept nesting anonymous functions until my code looked like a tangle of spaghetti. React only made it worse: suddenly, every prop seemed to depend on a function I barely understood. **Found it! The weak foundation, time to dig deeper!**

Through some digging, I learned that MDN Web Docs has a Core JavaScript Learning track, which has seven mini-modules and a comprehension check. So, I am adding it to my supplemental learning stack. Now, when I am stuck on Skillcrush, I jump to MDN Web Docs, but I am not staying there. My goal is to obtain my Front-End Certification before September 2025.

Errands & Lunch - 12:00 p.m. - 1:30 p.m.

Front End Mentor - 1:30 p.m. - 3:30 p.m.

After finishing the bare-bones HTML, I moved on to images. Usually, I add them last so I can focus on the layout. But that’s…well, dumb. Padding doesn’t mean much if your images destroy the flow.

As I started adding the image syntax:

      <img src="image.jpg" alt="A description of the image">

I noticed something new in the assets:

image-grid-3.jpg
image-grid-3. @2x.jpg

I understood the first one, but what the heck was @2x.jpg?

Retina Display: Why Your Images Look Blurry

The first explanation I found? Gibberish:

Basically an @2x image is twice the size in pixels as an @1x image and an @3x image is three times the size of an @1x image, e.g.
@1x – 50x50px normal size.
@2x – 100x100px; 2x the size of @1x.
@3x –150x150px; 3x the size of @1x.

Okay.

I keep digging, which leads me to this fantastic flowchart for choosing image formats. But still not quite what I was looking for, but eventually I found these three resources:

Retina Displays: Why This Matters

Retina Displays cram more pixels into the same physical space. When Apple introduced the Retina Display around 2012, they weren’t just showing off. They were raising the bar for what “sharp” actually looks like.

Remember when HD TVs came out and suddenly you could see lace fronts and caked-on makeup? That’s what high pixel density does: it exposes everything. Retina screens are brutally honest. If your UI graphics aren’t optimized, they won’t just look “fine”. They’ll look shoddy.

So what do you do? You give the screen more pixels to work with. If your image is supposed to appear 750px wide on the screen, serve up a version that’s 1500px wide (that’s 2x) and style it to display at 750px. That way, Retina Displays use the extra pixels to render a crisp, magazine-cover-level sharpness.

But here’s the catch: you can’t just throw high-res images everywhere. Too big, and your load times tank. Large images increase load times, delay content, and can leave users staring at “skeleton” loaders. That’s where the element or comes in. It lets the browser choose the right image for the screen, balancing sharpness and performance.

Here is how I implemented the element with in this build:

<picture>

<source  media="(min-width: 650px)"  srcset="image-grid-1.jpg 1x, image-grid-1@2x.jpg 2x">

<source  media="(min-width: 465px)"  srcset="image-grid-1.jpg 1x, image-grid-1@2x.jpg 2x">

<img  src="mobile/image-grid-1.jpg"  alt="">

</picture>

I am using this pattern in the art gallery build, which is finally making the images responsive and retina-ready. I have done other FEM projects without retina support. And I understand why. It isn't always necessary. But for this project? An art gallery? It matters.

High-resolution visuals reinforce the design integrity. They are part of the user experience, especially when the subject matter is visual art. Retina images aren't just a design flex. They are a UX investment. That realization made this day feel worth it.