DEV Community: Obasi Lilian U

Understanding State in a Vanilla JavaScript Web App

Obasi Lilian U — Tue, 22 Sep 2026 13:02:22 +0000

When I first started building small JavaScript applications, I thought the main challenge was writing the JavaScript.

I later realized the harder part was understanding what happens to the data while the user interacts with the application.

A user enters information.

JavaScript reads it.

The application stores it.

The data changes.

The interface needs to reflect that change.

This is where the idea of state becomes important.

What is state?

In a web application, state is the data the application needs to remember while it is running.

For example, suppose I am building a simple farm expense tracker.

I might start with an empty array:

const expenses = [];

At this point, the application has no recorded expenses.

If the user enters:

Seeds
₦5000

JavaScript might turn that information into an object:

const expense = {
category: "Seeds",
amount: 5000
};

The object is then added to the array:

expenses.push(expense);

The state has changed.

It is now:

[
{
category: "Seeds",
amount: 5000
}
]

That array represents information the application needs to remember.

State is not the interface

This distinction has helped me understand JavaScript applications better.

The array is the data.

The HTML elements displayed on the page are the interface.

They are related, but they are not the same thing.

For example:

const expenses = [
{
category: "Seeds",
amount: 5000
}
];

does not automatically put anything on the screen.

The browser needs JavaScript to take the current state and update the DOM.

For example:

const expenseList = document.querySelector("#expense-list");

expenseList.innerHTML = "";

expenses.forEach(expense => {
const item = document.createElement("li");

item.textContent = ${expense.category}: ₦${expense.amount};

expenseList.appendChild(item);
});

The JavaScript reads the state and creates the corresponding interface.

The basic flow

The pattern I am learning to recognize is:

User action
↓
JavaScript handles the event
↓
Read input
↓
Update state
↓
Render the state
↓
UI reflects the new state

For example, when a farmer clicks an “Add Expense” button:

Click
↓
Read form values
↓
Create expense object
↓
Add object to expenses array
↓
Render expenses
↓
Updated expense appears on screen

This way of thinking is more useful to me than thinking about each line of JavaScript in isolation.

Why rendering matters

Suppose I update the array:

expenses.push(expense);

but do not update the interface.

The data has changed, but the user will not see the new expense.

This is an important distinction.

Changing the data does not automatically mean changing the DOM.

I need to explicitly render the updated state.

A simple render function might look like this:

function renderExpenses() {
expenseList.innerHTML = "";

expenses.forEach(expense => {
const item = document.createElement("li");

item.textContent = `${expense.category}: ₦${expense.amount}`;

expenseList.appendChild(item);

});
}

Then after changing the state:

expenses.push(expense);

renderExpenses();

The sequence becomes easier to follow.

First, change the data.

Then, update the interface.

Where localStorage fits

There is another part of the process when the application needs to remember data after the browser is refreshed.

An in-memory array disappears when the page is reloaded.

For example:

const expenses = [];

starts again as an empty array when the application loads.

localStorage gives the application a way to persist the data in the browser.

A simplified example:

localStorage.setItem(
"expenses",
JSON.stringify(expenses)
);

When the application starts again, the stored data can be retrieved:

const savedExpenses = localStorage.getItem("expenses");

const expenses = savedExpenses
? JSON.parse(savedExpenses)
: [];

Now the application has another part of the flow:

User action
↓
Update state
↓
Save state
↓
Render state

And when the application loads:

Load saved data
↓
Create current state
↓
Render state

What I am starting to understand

Building small applications has changed how I think about JavaScript.

Instead of asking:

“Which JavaScript method do I need?”

I am starting to ask:

“What data does the application need to remember?”

“What event changes that data?”

“How should the interface represent the current data?”

“Does the data need to survive a page refresh?”

These questions lead to better implementation decisions.

I am still building with vanilla HTML, CSS, and JavaScript, but I am beginning to see the structure behind interactive web applications.

The syntax is important.

Understanding the flow of data is equally important.

That is the part I am focusing on now.

Building an Interactive Plant Album with Zero JavaScript

Obasi Lilian U — Fri, 22 May 2026 13:17:23 +0000

Subtitle: How I used CSS :target, viewport units, and image optimization to ship a performant, JavaScript-free project.

I’ve posted on Dev.to before about concepts I’m learning, but this is different. This is the first time I’m sharing a complete, shipped project, one that bridges my past life as an agricultural scientist with my new path in frontend development.

Meet the Plant Photo Album: an interactive guide to 27 plants, built entirely with semantic HTML and pure CSS. No JavaScript. No frameworks. Just clean code and a lot of problem-solving.

The Goal: Interactivity Without JavaScript

I wanted users to tap a plant name and see only that plant’s details, hiding everything else. My first instinct was to reach for JavaScript, but I challenged myself: Can I do this with CSS alone?

The answer was yes, using the :target pseudo-class.

Here’s the core logic:

Each plant lives in its own <section> with a unique ID (e.g., #carrot).
By default, all sections are hidden (display: none).
When a link is clicked, the URL hash changes (e.g., #carrot), and the matching section becomes visible (section:target { display: block; }).

It’s a simple trick, but it creates a seamless, app-like feel without a single line of JavaScript.

The Hurdle: When “It Works” Isn’t Enough

The structure was solid. The navigation worked. But when I tested it on mobile, the images were crawling, some taking seconds to load, others failing completely.

I initially blamed my CSS. Were viewport units (vh/vw) causing reflows? Was the display logic too heavy?

Then I checked the file sizes.

Some images were 7–9MB. I had pulled high-resolution photos directly from my camera roll and uploaded them as-is. Of course it was slow. The browser had to download massive files before resizing them for a phone screen.

The Fix: Compression Matters

I pulled all 27 images down, ran them through Squoosh.app (and TinyPNG for a few), and compressed them to 200–600KB each. The visual quality stayed sharp, but the load times dropped dramatically.

Lesson learned: Performance isn’t just about code. It’s about assets. A beautiful layout means nothing if the user is staring at a loading spinner.

The Result

Now, the album loads smoothly on mobile. Users can tap through 27 plants, from carrots to baobab trees, with instant transitions. The entire project is under 500 lines of code, fully responsive, and live in my portfolio.

What I Learned

CSS is more powerful than I gave it credit for. The :target pseudo-class handled complex state changes without JS.
Optimization is part of the build. Don’t wait until the end to check file sizes.
Your background is an asset. My knowledge of plants helped me curate accurate content, and my debugging skills helped me ship a performant product.

This project reminded me that transitioning careers doesn’t mean leaving your past behind. It means bringing it with you, in this case, literally, from garden to glass.

You can check out the live demo and code on my portfolio : https://obasililian59-cell.github.io/Web-development-portfolio/plant.html

Week 2 in Frontend: Layout, Structure & New Insights

Obasi Lilian U — Sun, 17 May 2026 11:09:19 +0000

I spent the previous week deepening my understanding of how layout actually works in CSS.

Continued studying and practicing CSS units (ems, rems, vh/vw), with a focus on how relative units respond to font size and viewport changes.
Practiced switching between pixel and percentage units to observe fixed vs flexible sizing behavior hands‑on.
Discovered why CSS margin‑left worked visually but didn't feel structurally right, and instead restructured the element hierarchy to solve it.
Explored the <dialog> element, learned that it's hidden by default (unless the open attribute is present), and used it to build a reusable newsletter form dialog.
Wrote about design concepts like hierarchy, contrast, color, and whitespace without prior vocabulary, then named them and refined my eye for layout.

Last week reinforced that structure decides everything; content, spacing, and visual hierarchy far more than quick fixes like margins do.

What I learned: CSS isn't abstract. It reveals itself through behavior, not theory alone. Fixing layout issues becomes easier when you ask, "Where did this element belong?"

Week 1: Gradients, SVGs, and the Art of Consistency (#100DaysOfCode)

Obasi Lilian U — Sun, 10 May 2026 10:45:47 +0000

Status: ✅ Complete

Focus: CSS Backgrounds, Borders, SVG Basics, Iframes

Project Highlight: The Digital Art Frame.

🛠 What I Built

Savannah Brew Menu (Live Demo)

A fully responsive café menu page.

Key Tech: Semantic HTML, CSS Grid/Inline-block, Warm Color Palette (#F3EDE6, #E8DDD0).
Win: Successfully embedded live via GitHub Pages and added icons using HTML entities.
Link: Savannah Brew Menu

The Digital Art Frame

A compositional experiment to test layering.

Key Tech: Linear Gradients, SVG Shapes (<rect>, <circle>), Iframes.
Challenge: Positioning an iframe under an SVG frame without Flexbox (solved with negative margins for now).
Lesson: SVG is just a coordinate system, not magic.

Portfolio Refinement

Spent time tweaking spacing on existing projects.

Focus: Margins, padding, and border consistency.
Decision: Identified layout issues I’ll fix once I learn Flexbox (managing technical debt).

🧠 Key Takeaways

SVG Coordinates: Learned that cx, cy, and r are just math instructions for position and size. Experimenting with numbers made it click faster than theory.
Layering Context: Understanding how z-index and negative margins interact to create overlapping effects.
Consistency > Intensity: Posting daily on X, even with small updates, keeps the momentum going without burnout.
Technical Debt: It’s okay to leave a “good enough” fix in place if you know why it’s not perfect and have a plan to refactor later.

🚧 Challenges & Solutions
At first, SVG shapes appeared as text, then I realized I saved the file as .txt instead of .html.

When my text was not centering vertically in a div, I used padding-top for moment; flagged Flexbox as the future fix.

I actually felt overwhelmed by new concepts but then broke them down into tiny experiments (e.g., changing one coordinate at a time).

🏪Next Week’s Plan

Learning: Diving into Design Principles in CSS course.
Building: Continue refining portfolio spacing and typography.
Habit: Maintain daily X posts + Sunday Dev.to wrap-ups.

💬 Final Thought
"You don’t have to see the whole staircase. Just take the first step."

This week proved that small, consistent experiments build confidence faster than waiting for perfection.
See you in Week 2! 👋

From Negative Margins to Clean Layouts: How I Stopped Fighting CSS

Obasi Lilian U — Mon, 04 May 2026 20:10:15 +0000

Hi everyone! 👋

I'm Lilian, a frontend developer transitioning from Agricultural Science. This week, I launched my first professional portfolio hub, and I want to share a specific lesson I learned about CSS spacing that changed how I approach layouts.

The Problem: Forcing Things to Fit

When I was styling my portfolio, I noticed some elements felt too far apart. My quick fix? Negative margins.

I wrote code like this:

blockquote {
    margin-top: -40px; /* Pulling it up by force */
}

On my desktop screen, it looked perfect. But when I checked it on mobile, things started overlapping unpredictably. I was essentially "pulling elements upward by force" instead of letting them flow naturally.

The Realization

I realized that negative margins are often a shortcut that fights the document flow. They might solve a visual problem in one specific view, but they break easily when the screen size changes.

The Solution: Working With the Flow

Instead of forcing elements to move, I learned to adjust the natural spacing of the elements around them.

The "pro move" I discovered:

Reduce the margin-bottom of the element above.
Or reduce the margin-top of the element below.

So instead of this:

/* ❌ The old way */
blockquote {
    margin-top: -40px;
}

I did this:

/* ✅ The new way */
.intro-section {
    margin-bottom: 10px; /* Gentle spacing */
}


blockquote {
    margin-top: 10px; /* Natural flow */
}

The Result

My layout is now:

✅ Stable on all screen sizes.
✅ Easier to maintain.
✅ Predictable when I add new content.

The Takeaway

If you find yourself using negative margins to fix spacing, pause. Ask yourself: Am I fighting the flow?

Often, the solution isn't to pull harder, but to adjust the space around the elements gently.

You can see the final result of this lesson in my live portfolio here:
🔗 Web Development Portfolio Hub

I'm still learning, but sharing these small wins helps me remember them. Thanks for reading!