Forem: Ecaterina Sevciuc

The Invisible Scales: A Frontend Art Performance on Gender Equity

Ecaterina Sevciuc — Mon, 30 Mar 2026 13:52:37 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

1. The Motto: "Insanity and Courage"

As my daughter often says, my motto for this life chapter (and especially this project) is "Insanity and Courage".

To be honest, I never saw myself participating in something like this. My previous attempt at the first stage of this challenge, Echoes of Experience, was met with such a "polite silence" in terms of reactions that it felt like a clear hint: "Maybe you're in the wrong garden, Katya."

But then, the idea for this visual performance hit me. It was so persistent that it wouldn't let me sleep. I didn't think about how I would build it; I just knew I had to. And that’s when the "real fun" began...

2. The Artistic Vision: Scales of Reality

The central motif of this installation is a pair of scales that remain visually balanced by design. This represents formal, legal equality in the workplace. However, the true story is told through the falling items:

The "Second Shift": While both sides show equal professional standing (the laptops), the female side is gradually overwhelmed by the "invisible" weight of unpaid domestic labor.
The Invisible Burden: Falling household items (strollers, pans, appliances) represent the mental load and multitasking that often fall disproportionately on women.
Pressure & Stress: The pulsing gender symbols and the darkening gradient are visual metaphors for the mounting systemic pressure that grows as responsibilities multiply.
The Finale: A theatrical ending serves as a reminder: we all see the imbalance, we all acknowledge it, yet the cycle continues. This piece is a call to look closer at the "hidden" side of the scales.

3. The Performance (Video)

4. Project Structure & The "Renovation Budget" Rule

If you’ve ever done a home renovation, you know the rule: calculate your budget and time, then multiply by two. If you’re lucky.

My "renovation" of this code was supposed to take a week. It took that week plus another 8 days of pure troubleshooting.

The Tech Stack:

Vanilla JavaScript (No libraries, just raw logic).
CSS Custom Properties for deep design tokens.
SVG for the scales architecture.
AudioDirector Class for rhythmic synchronization.

5. The "Behind the Scenes" Struggles

Here is a list of things that made me want to pull my hair out (and how I fixed them):

The Z-Index Layer Cake: Managing 6 layers of depth was like hell’s accounting. Making sure a falling pan lands inside the scale pan—behind the front rim but in front of the back wall—required a level of CSS discipline I didn't know I possessed.
The Spiral of Despair: I tried doing the spiral fall with pure CSS. My laptop almost turned into origami. I switched to a JS-based spiral using polar coordinates ($r = a + b \cdot \theta$) and requestAnimationFrame. No more "jumping" icons!
The Zoom Conflict: Scaling the body messed up every absolutely positioned element. I had to create a dedicated .page__zoom container and move the entire universe inside it.
Audio-Visual Sync: My discrete zoom felt "soft" and lagged behind the music. I had to implement a "Snap Mode" and fine-tune parameters like frontloadFactor and leadSeconds to make the zoom feel snappy and anticipatory.
The Ghost of Backgrounds: At one point, the background just stopped showing up on restarts because of a conflict between body and .start-overlay. I had to clear the document background and move all scene-active styles into a predictable CSS class.

6. Repository & License

You can find the "gory details" of my code here:
👉 GitHub: wecoded-gender-art-2026 (https://github.com/kate8382/wecoded-gender-art-2026.git)
The project is shared under the MIT License (yes, the one I have on GitHub—feel free to use it, just don't blame me for the z-index trauma!).

7. Conclusion

In the end, despite the headaches, the minutes of total despair, and the constant internal question—"Why am I doing this to myself?"—I am incredibly glad I reached the finish line.

Regardless of the contest results, I am proud of this work. It might not look exactly like the "perfect" version I initially imagined, but it is a living, breathing visualization of a thought that was important to me. I survived the 8-day budget overrun, and I’m still standing.

P.S. No laptops or chipmunks were harmed in the making of this project. 🐿️💻

How I migrated my pet project to TypeScript, or Katya in Wonderland

Ecaterina Sevciuc — Fri, 13 Mar 2026 17:23:09 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I’ve finished my TypeScript course!.. But there's no need to congratulate me yet...

At first, I thought that after JS, nothing could surprise me anymore. When you read the textbook and look at the examples, you think: “Oh, everything's clear!”. But then you look at a blank file in VSCode and have no idea what to write: the textbook examples don’t seem to apply, and my imagination (or experience) is just not there. And on top of that: my logic seems to be acting up, too! 😂

In moments like these, you feel like Alice in Wonderland — the further you go, the “curiouser and curiouser” it gets. But at least Alice had a Caterpillar who helped her adapt to the situation — by offering mushrooms! 😂 But I have no caterpillar, and certainly no mushrooms.

❓ But in all seriousness:

Why is TypeScript a separate topic from JavaScript? If the goal is reliable code, wouldn't it be more logical to start learning with a typed approach right away, so that all the "Alices" out there learn on safe examples from the start?

If TypeScript is just a superset of JS, where is the boundary — should you learn "pure JS" first and then TS, or just take TS as your primary language?

Which JS weaknesses actually hinder production, and does TS really solve them all?

Do TS types actually help catch bugs earlier? And how much do they complicate fast, JS-style prototyping?

📁 About the project:

The migration goal: To increase code reliability, unify types between the frontend and backend, and simplify refactoring — that’s if we're putting it nicely and professionally.
But if we're being blunt: I just wanted to finally understand what TS is and "what you eat it with" (how it actually works) 😂

📁 What I migrated:

Frontend: UI and log display logic:

export interface ErrorItem {
  id: string;
  message?: string;
  status?: string;
  type?: string;
  firstSeen?: string;
  lastSeen?: string;
  [k: string]: unknown; // For those unexpected Wonderland surprises
}

Backend: handlers, API contracts, validation:

export interface CreateErrorRequest {
  message: string;
  stack?: string;
  type?: string;
  apiKey?: string;
  projectId?: string;
  user?: string;
}

Build configs and types for external libraries

📁 Key changes and approach:

Moved shared types into a single module so that front and back use the same data model.
Enabled strict: true in tsconfig and did a gradual migration using allowJs.
Added types for API responses and log structures.

📁 What I’ve learned (at least, I really hope so!):

✔️ Types act as documentation and prevent errors at early stages.
✔️ Iterative migration with small PRs saves time.
✔️ Shared types between layers reduce the number of runtime errors.

❗ Conclusion: A total brain-melt and "bleeding eyes" are guaranteed for quite some time!

You can find the code and all the details here: https://github.com/kate8382/error-logger-viewer.git

"Thank you for reading my Alice-inspired journey! I’m still looking for answers to the 4 questions above. If you have any thoughts, experiences, or even the wildest metaphors to share, I’d be happy to hear them in the comments!"

Error Logger & Viewer — tiny SPA for tracking JS errors

Ecaterina Sevciuc — Fri, 31 Oct 2025 18:54:07 +0000

TL;DR: Tiny SPA to capture and group browser JS errors — filters, charts, demo and server modes. Try the "Create test error" button on the demo: https://kate8382.github.io/error-logger-viewer/

Why I built it

What happens when a small idea turns into a few months of late‑night debugging? I wanted a lightweight tool that helps developers see runtime problems quickly, group similar errors, and track fix progress. The app runs in two modes: demo (localStorage) for quick tests and server (Node.js + Express + LowDB) for persistent storage.

What it does

Captures global JS errors (window.onerror, onunhandledrejection), resource load errors, and fetch failures.
Groups and deduplicates errors by message/stack to reduce noise.
Searchable, sortable error table with status tracking (new / in progress / fixed / ignored) and comments.
Charts for error dynamics (day/week/month), visual filters and quick actions.
Supports light/dark themes and i18n (EN/RU).
Accessibility features: ARIA labels and keyboard navigation.
Tests: Jest (unit) and Cypress (E2E). CI via GitHub Actions.

Quick architecture

Frontend: vanilla ES6 + Webpack, modular components for table, charts and modals.
Backend (optional): Node/Express + LowDB for a simple REST API. Client switches between demo (localStorage) and server modes via a small adapter.

Demo & source

Live demo: https://kate8382.github.io/error-logger-viewer/
Source: https://github.com/kate8382/error-logger-viewer

Screenshots
Dashboard — overview, quick stats and theme example.

Error table — search, sorting, status and actions.

Charts — error dynamics by period (week/month/year).

Lessons learned

Grouping errors across browsers and minified stacks is tricky — tests and careful matching rules help a lot.
Small UX details (filters, inline status change) make the tool useful for teams.
Next steps: add a project registration flow (projectKey + drop‑in client snippet) and a lightweight admin to manage multiple projects.

Feedback welcome — what metrics would you add to a simple error dashboard?