DEV Community: Sylwia Laskowska

The Real Skill in Programming Is Debugging. Everything Else Is Copy-Paste

Sylwia Laskowska — Thu, 05 Mar 2026 08:17:23 +0000

I have a feeling this statement is even more true in the age of AI and coding agents. Sure, today we often write prompts instead of code. But if we’re honest, isn’t that just an extremely fast version of copy-paste?

When people imagine programmers, the picture is usually quite dramatic. In the most optimistic version, it's a handsome hacker sitting in a basement full of computers with Angelina Jolie, breaking into bank systems and secret Pentagon databases.

A slightly less romantic but still impressive image is a developer hammering the keyboard at insane speed while lines of code cascade down the screen like in The Matrix.

And to be fair, when you start learning programming, that vision is not entirely wrong (except of course Angelina Jolie). You actually write a lot of code.

Someone even commented under my article
Your GitHub Contribution Graph Means Absolutely Nothing (And Here's Why)
that the greenest contribution graphs are often from aspiring developers who are simply learning by doing — coding every day, trying things out, experimenting. That’s completely natural.

I often talk with junior and mid developers, and many of them understand the job exactly this way: your role is to deliver features. Ship code. And honestly, there is absolutely nothing wrong with that.

Small personal update: I recently got accepted into the AWS Community Builders program 🎉I hope they give out cool hats and t-shirts 😅 If you feel like supporting me, you can leave a like on my LinkedIn post here.

But What Happens Later?

Something interesting happens as you move further in your career.

The more senior you become — and the more responsibility you have for the system — the less time you actually spend writing code.

Instead, more and more of your time goes into debugging, investigating strange issues, and generally solving problems that nobody else managed to solve.

You can think now: but some seniors still code a lot!

And yes, if you are an experienced developer working in a small startup, you will probably still spend a lot of time writing code. Especially now, when AI tools can accelerate development so much.

But as projects grow and become more successful, their complexity grows as well. And with complexity comes a different kind of work.

Less writing code. More understanding systems. Because when something breaks in production, someone has to investigate it.

Suddenly the support team needs answers. Right now!
Then you spend the whole day analyzing logs.
Oh, there is a race condition somewhere! You're a senior, you need to investigate it.
Is something wrong with our configuration? You need to figure it out!

And of course juniors always will come with the most famous developer question of all:

“Why is this null?”

Wait… Isn’t Programming Also About Architecture?

Now you might say: programming is not just debugging. Developers also need to choose architectures, frameworks, and technology stacks.

That’s absolutely true.

But the longer I work in this industry, the more I realize that in many areas almost everything has already been invented. There are design patterns, well-known architectural approaches, and proven solutions to many classes of problems.

When you design a system, you rarely invent everything from scratch. Instead, you reuse patterns that worked before, adapt architectures that others already tested, and build on the collective knowledge of the developer community.

In that sense, architecture itself is often a kind of copy-paste — just at a much higher level.

Ignoring all that accumulated knowledge would be either genius… or stupidity.

When I Was a Junior

When I was a junior developer, I was shipping feature after feature. I must have written kilometers of code back then. If something didn’t work, I would spend some time researching, trying things, googling errors. If I still couldn’t fix it, I simply went to a senior developer.

And that was it. No matter how annoying and how time-consuming the issue was, the senior had to solve it. That was literally his job.

I remember one situation from that time when the project on my local machine suddenly stopped building. I spent hours trying to figure it out, until a senior checked a few things and calmly said: “Your Node version is wrong.” That was the whole mystery.

Back then I also felt a bit sorry for seniors. They were always on calls, constantly interrupted, rarely writing actual code. Meanwhile I was happily implementing feature after feature. Infrastructure? Pipelines? AWS? I barely even thought about those things.

Today

I’m now a senior developer myself, and I even have to coordinate work across multiple teams. Do I still write code? Of course. But do I deliver huge numbers of new features like I did when I was a junior?

Not really.

Instead, a lot of my work looks like this: upgrading a framework and trying to understand why everything suddenly breaks. Checking whether a dependency update introduced a regression. Investigating strange bugs that appear only in certain environments.

Remember these famous frontend CVE we had recently? The kind that suddenly appears everywhere and triggers a small wave of panic.

Does it affect our project? Fortunately not.

Now the only remaining task is spending a week replying to emails explaining that we don’t even use React 😉

The Real Skill

Writing code can look like copy-paste. Architecture is just a high-level copy-paste. But debugging is pure problem solving.

It forces you to understand the system deeply, follow data flows, analyze logs, and test hypotheses. Sometimes no Stack Overflow answer helps. Sometimes AI tools don’t help either.

You simply need to think.

And after hours of investigation, the root cause often turns out to be something surprisingly small: a missing property, an incorrect configuration, or a single line of code.

Debugging sometimes feels a lot like detective work.

The Responsibility

This reminds me one story.

Remember that senior that had to help me no matter what? Now I'm that senior for my teammates.

Some time ago, a junior developer came to me because, while implementing a complex form, he hadn’t noticed that validation wasn’t working in one place. He had no idea how to fix it and had already been stuck on it for quite a while. Deadlines were approaching.

I tried to guide him, pointing out a few places in the code that might help, but it didn’t work. In the end, I had to sit down and dig into that piece of code myself.

The day before the deadline (I finished at 1 a.m.).

Was it stressful? Maybe. Should he inform me about this issue earlier? Absolutely. But sometimes that's the reality.

So… Am I Unhappy About That?

Do I feel unsatisfied because I don’t ship as many features as I did when I was a junior?

Not at all.

After all — who didn’t want to become a detective as a kid?

Senior developers are basically software detectives. 🕵️‍♀️

16 Modern JavaScript Features That Might Blow Your Mind

Sylwia Laskowska — Wed, 25 Feb 2026 11:26:10 +0000

Ah, what a time to be alive!
As usual, I’ve taken way too much on my plate — there were just too many things that looked interesting 😄 Right now I feel like I have ten parallel storylines running in my life and not enough hands to handle them all.

But let’s be honest — I’m not going to skip my weekly post.
That said… this time I won’t dare to go for a deep dive again. Let’s keep it lighter 😉

Some time ago, one of my posts got surprisingly popular:
Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems

Apparently, these kinds of curated lists are something the community really needs.

Sure, we have documentation. Sure, we can Google everything — or ask Claude, GPT or Gemini. But there’s one small problem: before you can search for something, you first need to know that it exists.

So this time I decided to go through a handful of newer additions to the ECMAScript standard — features that landed in recent years and are already available in modern environments.

This topic isn’t new to me. Back in 2019, I gave a talk at meet.js Summit called “Beyond ES6 — What Comes After the Hype?” (or something along those lines 😄). If for some reason you’d like to revisit ECMAScript features from 2015–2019, you can probably still find the recording somewhere on YouTube.

Alright, enough intro.

Below you’ll find some of my favorite modern JavaScript features from recent years. I’m not listing everything — only the ones that feel practical, interesting, or quietly powerful.

And as you’ll see… they all connect into a bigger pattern.

📅 ES2022 — The Foundation of Modern JS

✨ Top-Level `await`

What problem it solves:
A nice quality-of-life improvement. Before this, you couldn’t use await directly at the top level of a module. You had to wrap everything inside an async function just to load config or initialize data. Not the worst thing ever — but honestly a bit pointless.

Old way (extra boilerplate):

async function init() {
  const config = await fetchConfig();
  startApp(config);
}
init();

Now:

const config = await fetchConfig();
startApp(config);

Why it matters:
Cleaner startup logic, less ceremony, easier reading.

🔒 Private Class Fields (`#`)

What problem it solves:
Let’s be honest — JavaScript never really had private class fields. We just pretended it did, creating weird conventions like _privateVar, which wasn’t private at all 😉 (well… unless you were using TypeScript).

Now:

class User {
  #id;

  constructor(id) {
    this.#id = id;
  }
}

Trying to access user.#id outside the class throws an error.

Why it matters:
Real encapsulation. Safer abstractions and fewer accidental modifications.

🧠 `Error.cause`

What problem it solves:
How many times have you lost half a day debugging because one error triggered another, but the connection between them was almost impossible to trace?

Old way: overwrite the error or manually attach metadata.

Now:

throw new Error("Failed to load data", {
  cause: originalError
});

Why it matters:
Better debugging and logging. You can track the full chain of failures instead of guessing.

🎯 `Object.hasOwn()`

What problem it solves:
Back in the day, checking if an object really had a property required creating this confusing monster:

Old way:

Object.prototype.hasOwnProperty.call(obj, "key");

Now:

Object.hasOwn(obj, "key");

Why it matters:
Cleaner syntax, easier to read, fewer edge-case surprises.

📍 `.at()` — Relative Indexing

What problem it solves:
Classic junior interview question: how do you get the last element of an array? Everyone above junior level eventually learned the same ugly hack.

Old way:

arr[arr.length - 1];

Now:

arr.at(-1);

Why it matters:
Maybe not revolutionary, but definitely clearer and more readable.

📅 ES2023 — The Immutability Upgrade

This release focuses on one big idea: avoid accidental mutation.

🧹 `toSorted()`

Problem:
Array.sort() is great… except it mutates the original array. Someone forgets that — and suddenly half your app is broken. Others remember, so they manually clone arrays every time.

Old workaround:

[...arr].sort();

Now:

const sorted = arr.toSorted();

What it changes:
You get a sorted copy without touching the original data.

Why it matters:
Huge for state management and functional-style code.

🔁 `toReversed()` & `toSpliced()`

Same philosophy: copy instead of mutate.

arr.toReversed();
arr.toSpliced(2, 1);

Why it matters:
Predictability. You don’t accidentally break code sharing the same array reference.

🔎 `findLast()` / `findLastIndex()`

Problem:
We had find, but what if you wanted the last matching element? The old workaround was… not exactly pretty, and definitely confusing for juniors.

Old way:

[...arr].reverse().find(fn);

Now:

arr.findLast(fn);

Why it matters:
Less noise, clearer intent — the code says exactly what you mean.

📅 ES2024 — Data Transformation & Async Control

🧩 `Object.groupBy()`

Problem:
Grouping arrays usually meant writing reducers that looked more complex than the problem itself.

Old way:

users.reduce((acc, user) => {
  (acc[user.role] ??= []).push(user);
  return acc;
}, {});

Now:

const grouped = Object.groupBy(users, u => u.role);

Why it matters:
Massive readability upgrade. What used to be a helper function is now a one-liner.

⚡ `Promise.withResolvers()`

Problem:
Creating external resolve / reject handlers was always awkward.

Old way:

let resolve;
const promise = new Promise(r => resolve = r);

Now:

const { promise, resolve, reject } =
  Promise.withResolvers();

Why it matters:
Cleaner async orchestration — especially for queues, events, or complex flows.

📦 Resizable ArrayBuffer

Problem:
Buffers used to have fixed sizes, which was frustrating when working with streaming or dynamic data — especially if you were one of those weirdos (like me 😄) experimenting with edge JavaScript, workers, or binary data.

const buffer = new ArrayBuffer(8, {
  maxByteLength: 16
});

Why it matters:
More flexible memory handling for advanced scenarios.

📅 ES2025 — Functional JavaScript Gets Serious

🧠 Iterator Helpers

Problem:
Array methods are great — but they create intermediate arrays at each step. Sometimes that’s unnecessary work.

Old way (creates extra arrays):

const result = arr
  .map(x => x * 2)
  .filter(x => x > 5)
  .slice(0, 3);

Each step allocates a new array.

Now (lazy processing):

const result = iterator
  .map(x => x * 2)
  .filter(x => x > 5)
  .take(3)
  .toArray();

What it replaces:
Manual generator pipelines or performance-heavy array chains.

Why it matters:

values are processed step by step (lazy evaluation)
fewer allocations
better performance on large datasets
more functional-style pipelines

Think: streaming mindset instead of “build another array”.

🧩 New Set Methods

Problem:
More advanced set logic always required custom helpers or awkward conversions to arrays.

Old way:

const intersection = new Set(
  [...a].filter(x => b.has(x))
);

Now:

a.intersection(b);
a.union(b);
a.difference(b);

Why it matters:
Math-like operations directly in the language. Less boilerplate, clearer intent.

🔐 `RegExp.escape()`

Problem:
Security. Building regular expressions from user input could easily break the pattern or even introduce vulnerabilities.

Old way:

const safe = userInput.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
const regex = new RegExp(safe);

Now:

const regex = new RegExp(RegExp.escape(userInput));

Why it matters:
Safer regex creation without writing your own helper every time.

⚡ `Promise.try()`

Problem:
Sometimes you want to treat sync and async code the same way — especially when a sync function might throw.

Now:

await Promise.try(() => mightThrow());

Why it matters:
Everything becomes promise-based automatically, which simplifies error handling pipelines.

🧊 Float16 Support

JavaScript has always been a bit awkward with numbers — the default is 64-bit floating point. We’ve had Float32Array for a while, which was already useful, but now JS goes one step further.

const data = new Float16Array(1024);

What this actually means:

smaller numeric representation (16-bit)
lower memory usage
faster data transfer in some GPU/ML scenarios

Why it matters:
Graphics, WebGPU, machine learning, and performance-oriented workloads benefit from more compact data.

🧭 The Bigger Picture

If you zoom out, you’ll notice a pattern:

less mutation
clearer intent
safer async handling
more functional data processing

JavaScript isn’t changing through flashy revolutions anymore.
It’s evolving through small, practical upgrades that quietly make everyday code cleaner and easier to reason about.

And honestly — that’s the kind of evolution I like most 🙂

If You See These Red Flags in an IT Interview — Run (Real Stories)

Sylwia Laskowska — Wed, 18 Feb 2026 10:54:17 +0000

We often prepare for interviews by polishing our CVs, grinding LeetCode, and rehearsing answers to “What’s your biggest weakness?”
But we rarely talk about the other side of the table.

Because interviews aren’t just about companies evaluating candidates.
They’re also a window into how a company thinks, communicates, and treats people.

And sometimes, that window shows more red flags than a beach on a stormy day 🚩

I originally planned to write about WebGPU this week. But I fell into a deep research rabbit hole and honestly… I’m not coming out anytime soon 😅 So that post will probably arrive in a week or two.
Meanwhile, this topic has been on my mind for a while — actually since I wrote Your GitHub Contribution Graph Means Absolutely Nothing (And Here’s Why). I kept postponing it, but my main thoughts were slowly evaporating. So I guess its time has finally come 🙂

I’ve been on many interviews (and I’ve also conducted over a hundred technical interviews myself). I remember most of them as perfectly normal or even positive experiences — even when I didn’t get the job.

But some of them? Absolutely horror stories.

This post won’t be an HR guide or a “how to interview” tutorial. These are real stories — mine and my friends’. All of them actually happened. And they show how weird, chaotic, or simply unhealthy recruitment can sometimes get.

Grab some popcorn 🍿

⏳ The Recruitment That Lasted a Year

This one isn’t about me, but a close friend. I won’t name the company, but think big, famous corporate. If you’ve ever written export class, or even just bought a computer, you definitely know them.

My friend applied and waited a month or two for a response. Then:

HR interview
weeks later → technical interview
weeks later → live coding
weeks later → manager interview

The manager liked him a lot… but didn’t need him. Another team did, though. So:

another technical interview
another live coding session (very similar task)

Then silence. For months.
No one from HR could even say what was going on.

After several more months (!!!), they came back.

And guess what?
Just one more technical interview, two live coding sessions, and a take-home task… and he’d get an offer 😀

Yes, for a regular developer role.
With a lower salary than he already had.

He declined.

👉 If a company can’t organize its own hiring process, imagine how they organize their projects.

⚖️ “How Much Do You Value Work-Life Balance?”

This one is mine. Actually, more than once.

I once filled out a form for a unicorn startup. One question was:

“How much do you value work-life balance? (1–10)”

Let’s be honest — I doubt they were looking for people who value it highly 😅

To be clear: I do value work-life balance.
Yes, I sometimes code at night, write articles, explore new tech. But I like the freedom to not do it when I don’t feel like it. To watch a series or read a book (currently polish noblist Olga Tokarczuk ❤️).

I’m also realistic. Sometimes you push harder near deadlines. Sometimes weekends happen. That’s part of the job.

But if during recruitment someone digs too deeply into your overtime tolerance — be careful.

I once ignored my intuition and joined such a startup.
10–12 hour days. Constant pressure. Endless urgency.

I lasted a year.
That was the average frontend tenure there.

I learned a lot, yes. Probably the most of any job.
But you should enter that world consciously — not by accident.

👉 If a company treats overwork as culture, believe them the first time.

👀 “Who’s Helping You There?”

A friend of mine was interviewing for an automation tester role.
Combined manager + technical interview.

Manager part? Great. She was impressed.

Then came the technical part. The recruiter quizzed her almost like a Python documentation exam.

She answered well, but then paused for a second, thinking how to phrase a more precise answer. Her gaze drifted slightly to the side while thinking.

The recruiter interrupted:

“What, is your husband helping you from the side?”

She politely ended the call.
No apology ever followed.

This story still shocks me. It sounds like a bad joke, but it wasn’t.

Imagine saying to a male candidate:
“Oh, your wife is helping you?”

Exactly.

👉 Disrespect during an interview is a preview of your future workplace.

😤 Offended Recruiters

Another of my stories.

Multi-stage recruitment, weeks long. Final stage — a discussion with developers after a technical task.

There was one tricky security-related part in the task about passing data from host to child. I secured it minimally, knowing it wasn’t perfect.

They pointed it out. Fair.

I was genuinely curious how they solved it internally. It was an interesting technical challenge.

Then they explained.

And… their solution was extremely vulnerable.
Like “people could potentially use their app for free and leak client data” vulnerable.

I thought I misunderstood and asked follow-up questions.
Nope.

They insisted it was “sufficient” and that the data “wasn’t that sensitive” 😅

To this day I don’t know if they rejected me for questioning it or for my poor TypeScript answers later on. 🙃

👉 If a company is defensive about flaws instead of curious, that’s a red flag.

🎥 Total Surveillance Mode

Last one 😀

A friend got a recruitment task on a HackerRank-like platform. Sounds normal, right?

Except:

full screen sharing required
camera on, wide angle
no documentation allowed
no external help
fully recorded session
strict time limit

All to ensure the candidate wasn’t cheating.

For a regular SaaS company.
Not nuclear code. Not Area 51.

In the era of AI, what does this really test?
Memorized syntax? LeetCode muscle memory?

👉 If a company assumes you’re a cheater before you even join, trust works both ways.

🤔 Final Thoughts

Interviews are a two-way street.

You’re not just being evaluated — you’re evaluating them too.

A bad interview process often reflects a messy culture, poor organization, or lack of respect for people’s time.

Sometimes the best offer…
is the one you decline.

What about you?
Any recruitment horror stories or red flags you’ve seen? 🚩

I’m genuinely curious 🙂

How Seriously Should We Take State of JS and Other Developer Surveys?

Sylwia Laskowska — Tue, 10 Feb 2026 10:43:07 +0000

There was a time when I treated State of JS results almost like prophecy.

A new edition dropped and I’d read it with excitement, looking for the future of JavaScript hidden somewhere in those charts.

Today I still read it.
But with much less awe and much more distance.

If you haven’t seen the 2025 results yet, you can explore them here:
https://2025.stateofjs.com/en-US/

It’s honestly a fantastic piece of work. Beautifully built, interactive, full of data. Huge respect to the creators — it’s not a small project.

But the real question is:

How seriously should we treat it?

A Very Short Recap of 2025 📊

I won’t do a full summary. Plenty of people already did, and you can just look at the charts.

In short:

TypeScript is firmly mainstream
Big frameworks mostly hold their positions
Tooling keeps evolving

Surveys like this are great for sensing the ecosystem.
What’s popular. What’s growing. What annoys developers.

Sometimes tools highly praised in surveys reach real production adoption years later. Vite is a good example.

So yes — these surveys are useful.

But they come with a lot of nuance.

My Younger-Developer Phase 😄

I remember being a junior and wanting to immediately try (or even introduce to production) everything that ranked high in satisfaction.

Luckily, nobody asked for my opinion back then 😉

I also used to feel genuinely sad seeing Angular score poorly in satisfaction.
Because… I liked working with it. My teams liked it. Our projects worked.

Was Angular dying?

Spoiler: many years later, it’s still doing just fine.

And it made me wonder:

If some tools are so loved in surveys, why don’t they dominate job listings?
Why is there constant demand for React and Angular devs, but much less for Vue or Svelte (at least where I live)?

A Little Story About Surveys 🧠

Fun fact: when I was very young, I had a part-time job in a company that conducted surveys.

That’s where I learned how serious research is actually done.

A reliable study needs:
carefully selected demographics, well-phrased neutral questions, controlled variables, clear definitions, sometimes even different question orders to avoid bias.

As you can guess — State of JS (and most dev surveys) don’t meet those strict scientific standards.

And that’s okay. They’re not academic research.

But it’s worth remembering.

Who Actually Answers? 🔥

Most likely:
people who care about tech, follow trends, hang out on DEV, Reddit, Twitter, and enjoy exploring tools.

Also people willing to spend time filling out a long survey.

Who probably doesn’t?
Developers who treat programming as a normal job and close their laptop at 5 PM.

That group might be huge. Possibly the majority.

So we’re mostly hearing from the curious and passionate slice of the community.

Which is interesting — but not the whole picture.

Regional Reality 🌍

Participation is open, which is great, but it also means representation isn’t proportional.

The US is strongly represented.
India has one of the biggest developer populations in the world, yet doesn’t always show up proportionally.

And regions differ.

Vue is strong in parts of Asia.
In Poland and much of Europe, React and Angular still dominate job markets.

So survey trends don’t always match local reality.

What Does “Usage” Even Mean? 🤨

This one always makes me think.

If I heard about a tool once by an accident in an office kitchen, do I have awareness?
If I did a tutorial, does that count as usage?
Or should usage mean delivering a real project?

When someone says they like a tool, is it after comparing many options, or just because it feels nice? Or maybe it's the only tool he/she knows? 🤔

And even in anonymous surveys, some people may hesitate to admit they don’t know something.

Human psychology never disappears from data.

Surveys vs Real Careers 💼

Can surveys help choose what to learn?
Sometimes.

Can they guide tech decisions?
Maybe.

But surveys and job markets are two different worlds.

You can learn the “best” framework and still land in a 10-year-old legacy codebase.
You can study modern React and get class components on day one 😉

Real careers are messy and non-linear.

How to Read Surveys 🧭

What works for me:

Look at trends year to year.
Compare satisfaction and usage.
Watch movement, not winners.
Remember that popular tools get more criticism simply because people use them daily.

And most importantly:
treat surveys as insight, not truth.

Yesterday’s winner can be tomorrow’s loser.

So… Should We Care? 🙂

Yes. But calmly.

State of JS doesn’t tell you what to use.
It shows what developers are curious about right now.

Think of it as a compass, not a GPS.
Direction, not destination.

It reflects the mood of the community more than the future of the industry.

Still useful. Just not absolute.

What do you think?
Do surveys influence your decisions, or do you mostly treat them as interesting reading?

Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems

Sylwia Laskowska — Wed, 04 Feb 2026 11:05:13 +0000

The web platform is way more powerful than most developers realize — and every year it quietly gains new superpowers.

Sometimes choosing a topic is harder than writing the article itself.

When I thought about what to write this week, only two types of ideas kept comming to mind:
either potential bangers, or deep technical dives.😅 But I wanted something lighter. Still technical, still useful. But not a 3-day research rabbit hole.

And since I genuinely love exploring what the browser can do (and how far we can push it), I landed on a sneaky topic: underused Web APIs.

Some of these might be daily bread for you.
But I’m pretty sure at least a few will make someone go “wait, this exists?!” 😉

And if you enjoy edge-tech topics and happen to be in Italy this April — come to jsday.it, where I’ll be speaking about WebGPU + WASM 🙂

Alright, enough intro. Let’s start.

Here are 10 browser APIs that deserve way more love.

1) Structured Clone API

I have a love–hate relationship with this one.

For years, one of my favorite interview questions to ask candidates was:

“How do you copy an object?”

You could learn so much from the answer:

Do they understand references?
Do they know Object.assign, spread, JSON tricks?
Do they mention libraries?
Do they panic? 😄

Now?

const copy = structuredClone(original);

Boom. Perfect deep copy.

Part of me is happy.
Part of me misses that interview question already.

Nice extras

Works with Map, Set, Date, Blob, File, ArrayBuffer
Handles circular references (no more JSON stringify explosions 💥)
Does NOT clone functions

Support: Modern browsers (Chrome, Firefox, Safari, Edge). Safe for production.

2) Performance API

Very underrated.

We talk a lot about performance. We install tools. We run Lighthouse. We debate optimizations.

But sometimes you just want to check:
“Is A actually faster than B, or am I overengineering?”

performance.mark("start");

// code to measure

performance.mark("end");
performance.measure("calc", "start", "end");

console.log(performance.getEntriesByName("calc"));

Perfect for:

micro-benchmarks
checking if a Worker or WASM is worth it
reality-checking your assumptions

Because sometimes the “optimized” version is slower 😅

Support: Excellent across all modern browsers.

3) Page Visibility API

Detects whether the tab is active.

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    video.pause();
  }
});

Real talk:
Users will open your app, then switch tabs for 20 minutes.
Or 2 hours.
Or forever.

Use cases:

pause videos
stop polling
reduce CPU usage
cleaner analytics

Your backend (and battery life) will thank you.

Support: All modern browsers.

4) ResizeObserver

Finally — observing element size, not just window size.

const ro = new ResizeObserver(entries => {
  for (const entry of entries) {
    console.log(entry.contentRect.width);
  }
});

ro.observe(element);

If you ever built responsive components, charts, or dashboards, you probably wrote some cursed resize logic in the past.

This API feels like the browser saying:
“Relax, I got you now.”

Support: Modern browsers, widely available.

5) IntersectionObserver

The sibling of ResizeObserver.

Checks if an element is in the viewport.

const io = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      console.log("Visible!");
    }
  });
});

io.observe(element);

Amazing for:

infinite scroll
lazy loading
scroll animations

Anyone who implemented infinite scroll manually once…
never wants to do it again 😄

Support: All modern browsers.

6) AbortController

Many devs know it for fetch…

But it can cancel more than just fetch.

const controller = new AbortController();

fetch(url, { signal: controller.signal });

// later
controller.abort();

You can also use it for:

event listeners
streams
any abortable API

Even better:
👉 One signal can cancel multiple operations.

Clean, scalable, and very “grown-up codebase” friendly.

Support: All modern browsers.

7) Idle Detection API

Page Visibility tells you if the tab is active.
Idle Detection tells you if the human is active.

const detector = new IdleDetector();

await detector.start();

detector.addEventListener("change", () => {
  console.log(detector.userState);
});

Meaning:
User might have your app open…
but is actually making coffee ☕ or in a meeting.

Use cases:

auto-logout
“away” status
background optimizations

Yes, you can detect if the user left the computer.
A bit creepy. Very useful 😄

Support: Mostly Chromium-based. Requires permission.

8) BroadcastChannel API

Easy multi-tab communication.

const channel = new BroadcastChannel("app");

channel.postMessage("logout");

channel.onmessage = e => {
  console.log(e.data);
};

Great for:

logout sync
auth state
shared session logic

Surprisingly practical in real apps where users open 5 tabs “just in case.”

Support: Modern browsers. Safari joined later but supports it.

9) Web Locks API

The cousin of BroadcastChannel.

Prevents duplicate work across tabs.

navigator.locks.request("data-lock", async lock => {
  await fetchData();
});

Example:

only one tab fetches notifications
avoids backend spam
coordinates shared resources

Feels very “distributed systems meets frontend.”

Support: Mostly Chromium. Not universal.

10) File System Access API

Yes — real filesystem access from the browser.

const [fileHandle] = await window.showOpenFilePicker();
const file = await fileHandle.getFile();

Great for:

web editors
import/export tools
power-user apps

The first time you use it, it feels slightly illegal.
Like “are we really allowed to do this on the web?” 😄

Support: Chromium-heavy. Limited elsewhere.

Reality Check 🧠

Many of these APIs are well supported in modern browsers.
But some (Idle Detection, File System Access, Web Locks) are still Chromium-centric.

So always check compatibility before going all-in.

But simply knowing these exist?
That already gives you an edge.

The web platform evolves fast.
Sometimes the “new tech” isn’t a framework — it’s a native browser feature that’s been sitting there quietly.

What’s your favorite underrated Web API that nobody talks about?

Is Learning CSS a Waste of Time in 2026?

Sylwia Laskowska — Thu, 29 Jan 2026 11:07:18 +0000

With modern frameworks, component libraries, and utility-first CSS, it’s a fair question.

Most frontend developers today rarely write “real” CSS. Layouts come prebuilt. Responsiveness is handled for us. Accessibility is supposed to be baked in. If something needs styling, we tweak a variable, add a utility class, or override a component token.

So… why spend time learning CSS at all?

For a long time, I thought the same.
Until accessibility forced me back into it.

Recently, I had a task that sounded quite innocent:
take an old component and bring it up to modern WCAG accessibility standards.

You know — better accessibility, higher contrast, proper focus states.
Not a nice-to-have. A hard requirement, because I treat accessibility very serious.

In practice, it meant a lot of CSS work.
The container had to be heavily reworked, but the visual design had to stay exactly the same.

And wow… I struggled. A lot. 😅

At some point I caught myself thinking:

CSS might actually be the hardest part of frontend development.
More complicated than JavaScript.

(Okay, maybe it didn’t help that the previous developer clearly didn’t understand CSS either 😬)

CSS Used to Be My Thing

What makes this funny is that I used to be really good at CSS.

Box model? Easy.
Layout tricks? Daily bread.
I could even center an element both vertically and horizontally — without Googling 😄

A long time ago, I even made some extra money building WordPress websites.
Technically simple stuff, but clients paid me because the pages looked good. That was the value.

So… what happened?

The Accessibility Wake-Up Call ♿

This recent task was a harsh reminder.

The real problems weren’t colors or fonts — they were things like:

focus outlines breaking the layout
keyboard navigation suddenly revealing broken DOM order
outlines appearing on only half of a component
positioning hacks collapsing once :focus-visible came into play

Fixing keyboard navigation alone exposed how fragile the layout really was.

Nothing “advanced”.
Just CSS fundamentals meeting real-world constraints.

And that’s when it hit me:
I’ve been out of serious CSS practice for a long time.

CSS Slowly Slipped Into the Background

I don’t know if you feel the same, but for years now CSS has been… secondary.

In most projects we use:

a component library
a design system
a framework that already handles layout and responsiveness

Our “CSS work” usually means:

styling a single component
tweaking a few variables
overriding something that almost fits

Mobile view? Out of the box.
Grid? Already solved.
Spacing? Tokens.

And then there’s Tailwind.

Don’t get me wrong — I use it too. A lot.
It makes things fast and predictable. Combined with shadcn/ui, you can ship decent-looking UIs without really designing anything.

Honestly, for hobby projects or demos, I don’t even try anymore.
I just ask an LLM to generate a nice layout — Tailwind included — and move on.

Zero CSS struggle. Zero pain.

Sure, sometimes something breaks.
A z-index here, a weird overflow there.
But that’s nothing compared to designing and maintaining entire layouts by hand.

I often don’t even install Stylelint anymore — even though I once contributed a few lines to it, which probably makes me like it even more.
Why bother, if the whole component has five lines of CSS?

Meanwhile… CSS Is Actually Thriving ✨

And that’s the irony.

CSS has evolved massively in recent years.

We now have things like:

CSS variables (okay, not brand new — but still fundamental)
Container queries
:has()
Cascade layers
Native nesting
Modern color spaces
Scroll-driven animations

CSS today is more powerful than it has ever been.

Do I follow all of this closely?
Kind of. But not deeply.

Because in day-to-day work, I rarely need it.
The framework handles it. The library abstracts it. The system hides it.

The Generational Gap

What’s interesting is that when I look at younger developers, I still feel like the old guard understands CSS better.

I’m not even sure CSS is properly taught anymore.
University? Probably not.
Bootcamps? Two days of CSS, then straight to JavaScript or “fullstack”.

(By the way — do bootcamps still exist? 😅)

Is that the right direction?
Or just a natural evolution?

Handmade Pasta and CSS

Sometimes I wonder if my nostalgia for CSS is like grandmothers making pasta from scratch.

Sure — it’s better.
Sure — it’s more satisfying.

But how often do we actually have time for that?

Frameworks, utilities, and abstractions exist for a reason.
They make us faster. They reduce mistakes. They standardize work.

But accessibility doesn’t care about abstractions.

To be fair, most modern frameworks and component libraries do provide accessibility out of the box — sensible ARIA attributes, keyboard support, focus management.

But that accessibility is often limited to the “happy path”. The moment you need custom layouts, visual tweaks, or non-standard interactions, you’re back to raw CSS — and whatever knowledge you still have.

And when something breaks — focus, keyboard navigation, layout flow —
there’s no Tailwind class or component prop that saves you.

Only CSS knowledge does.

So… Did CSS Get Worse?

I don’t think so.

I think we just stopped learning it.

And accessibility has a brutal way of exposing that.

What About You?

Do you still work with CSS on a regular basis?
Do you ever design layouts from scratch anymore?

Or maybe CSS is becoming a kind of dark knowledge —
something you only rediscover when things go wrong?

Maybe it’s worth exercising those muscles once in a while —
even just for fun.

Why NaN !== NaN Makes Perfect Sense (I Promise)

Sylwia Laskowska — Sun, 25 Jan 2026 15:11:47 +0000

No, JavaScript Isn’t Broken (Again)

I’ll admit it — sometimes I like publishing a post on the weekend, when both the internet and real life slow down a bit. But weekends are not the time for heavy technical or philosophical deep dives. It’s better to go for something lighter.

I spent a while looking for the right format. Topics like “the funniest commits ever” are fun, sure — but how many times can you do that?

And then it clicked.
This format — let’s call it JS WTF — fits my weekend vibe perfectly 😄

The first part,
Yes, true + true === 2. No, JavaScript isn't broken,
got quite a bit of attention.

And let me tell you something else — the comments under that article were absolute gold ✨
I love all of your comments. But the nerdy discussions? Pure treasure:

“I agree with you 99.9%, but this part needs clarification”
“This isn’t really computer science — that term is slightly off”
“You’re right, but I think JS should’ve solved this problem differently”

My heart grew three sizes that day. Please, more of this 💙

After that article and all the discussions, the next natural candidate for the series is a classic JS WTF:

NaN !== NaN

As weird as it looks, this behavior is actually fully logical — and I hope that after reading this article, it won’t feel strange to anyone anymore.

As before: if you enjoy this series, smash that like button 😄😄😄
Alright — let’s get to the point.

So… what is NaN anyway?

NaN stands for Not a Number.
In JavaScript, it’s a special numeric value of type number:

typeof NaN // "number"

You usually get NaN as the result of an invalid numeric operation:

0 / 0         // NaN
Math.sqrt(-1) // NaN
Number("💩")  // NaN

So far, so good.

Now comes the fun part 👀

Why is `NaN !== NaN`?

Let’s start with the surprise:

NaN === NaN // false
NaN !== NaN // true

At first glance, this feels completely insane.
I mean… if something is not a number, shouldn’t it be equal to… itself?

But here’s the key idea:

NaN does not represent a specific value.
It represents an unknown or invalid result.

Think of NaN as:

“I tried to compute something, but the result is undefined.”

If two computations both fail, JavaScript has no way to prove that they failed in the same way.

This behavior is not a JavaScript quirk.
It comes straight from the IEEE-754 floating-point standard, which many languages follow.

The IEEE-754 actually allows multiple NaN representations internally. JavaScript does not expose those details, so from the language’s point of view, all NaN results are simply unknown.

So instead of pretending they’re equal, the language says:
👉 “I don’t know — so I won’t say they are.”

A useful mental model 🧠

Imagine this:

let a = Math.sqrt(-1)
let b = 0 / 0

Both a and b are NaN.

But are they the same NaN?
According to the spec: you cannot know.

Because of that, all equality comparisons involving NaN return false — even when comparing it to itself:

NaN === NaN // false

This rule also applies to relational comparisons:

NaN < 1   // false
NaN > 1   // false
NaN <= 1  // false
NaN >= 1  // false

Once NaN appears, comparisons stop making sense — and JavaScript refuses to lie about it.

“Okay, but how do I check for NaN then?”

Excellent question 😄
And yes — JavaScript gives you tools.

❌ Don’t do this

value === NaN // always false

✅ Do this instead

Number.isNaN(value)

This is the correct and safe way.

There’s also the global isNaN(), but it performs implicit type coercion and can lead to surprises:

isNaN("123")   // false
isNaN("💩")    // true

Number.isNaN("💩") // false

In most real-world cases, Number.isNaN() is exactly what you want.

A small plot twist 👀

JavaScript does give you one way to say that NaN equals NaN:

Object.is(NaN, NaN) // true

Object.is() is a more precise comparison algorithm that treats special numeric edge cases differently.

For example:

Object.is(+0, -0) // false
+0 === -0         // true

This makes Object.is() extremely useful in low-level or numeric-heavy code.

Is JavaScript the only weird one?

Short answer: nope 😌
This behavior exists in many popular languages that follow IEEE-754.

☕ Java

Double.NaN == Double.NaN // false

Java even documents this explicitly.

🐍 Python

float('nan') == float('nan')  # False

Same idea, same rule.

🦀 Rust

let x = f64::NAN;
x == x // false

Rust stays very close to the floating-point standard here.

🧠 C / C++

NaN == NaN // false

Classic behavior — nothing special.

🟢 So who behaves differently?

In environments that avoid IEEE-754 floating-point numbers altogether — for example, integer-only domains or exact decimal/rational numeric types — you may never encounter NaN.

But for mainstream, numeric-heavy languages, this behavior is the norm.

JavaScript is not broken.
It’s just being honest 😄

Why this actually makes sense

The alternative would be worse.

If NaN === NaN were true, invalid results could quietly behave like meaningful values and slip through equality checks.

By making all NaN comparisons return false, languages prevent invalid computations from masquerading as valid ones.

And bugs that fail loudly are much easier to debug than bugs that pretend everything is fine.

Final thoughts

NaN !== NaN looks like a joke at first glance.
But once you understand that NaN means “unknown result”, everything clicks.

It’s not a JavaScript WTF.
It’s a floating-point reality check 😉

Why WebGPU Feels Like the Future of the Web (Live Demo 🚀)

Sylwia Laskowska — Wed, 21 Jan 2026 12:54:52 +0000

WebGPU is the hot topic right now. A brand-new web API that will most likely replace WebGL sooner rather than later (I won't miss you, bro 👋).

It’s already supported by all major browsers, and honestly… how could I not try it?

So I did what any curious frontend-centric software dev would do: I built a small interactive demo and learned a lot more than I initially expected.

First things first: why GPUs?

For many of you this might sound obvious, but let’s do a quick intro for anyone new to this area.

CPUs are great at doing a few complex things one after another.
GPUs are great at doing simple things, massively in parallel.

That’s why GPUs shine in:

graphics and image processing
simulations
matrix-heavy workloads
and yes — things like LLMs

Whether you’re rendering pixels, blurring textures, or multiplying huge matrices, GPUs are simply built for this kind of work. WebGPU finally gives us proper access to that power directly in the browser.

So… how is this different from WebGL?

WebGL is based on OpenGL, which is… well… old. Very old in GPU years.

With WebGL:

there were no real compute shaders
everything had to be expressed as a “rendering problem”
lots of hacks, tricks, and workarounds
a lot of hidden global state

If you ever implemented GPGPU in WebGL, you probably remember encoding data in textures and pretending triangles were something else entirely 🙃

WebGPU fixes this properly:

explicit compute passes
explicit pipelines and bind groups
no magical global state
APIs that map directly to modern GPU architectures (Metal, Vulkan, DirectX 12)

In short: WebGPU is how GPUs actually work today.

Is WebGPU production-ready?

The honest answer: it depends.

If you can:

require modern browsers
target up-to-date Chrome, Edge, Firefox, Safari

→ then yes, WebGPU is absolutely usable today.

If, however:

you have a very broad audience
someone out there is still using an ancient Safari
or (please no) IE 11

→ then you either invest in a WebGL fallback, or you skip WebGPU for now.

For experiments, demos, internal tools, and forward-looking products?
It’s already a very solid choice.

WGSL – those “weird” new shader files

WebGPU introduces WGSL (WebGPU Shading Language).

At first glance, it looks strange — but if you’ve ever seen shaders for:

Metal
Vulkan
or modern DirectX

…it actually feels quite familiar.

WGSL is:

strongly typed
explicit
designed to avoid a whole class of GPU bugs

In this project I keep shaders in separate .wgsl files, but you can also inline them as strings in TypeScript if you want. VS Code already has syntax highlighting for WGSL in both cases, which helps a lot.

Now, about my demo

I won’t lie — this demo was harder to write than many of my other experiments.

Maybe it’s because WebGPU is still relatively fresh.
Or maybe it’s because I’ve never been particularly passionate about computer graphics… and this demo is very graphics-heavy.

But in the end? I’m really happy with the result.

Visually, it looks like glowing ink or smoke that appears when you move your cursor across the canvas.
Technically, it’s a GPU-driven simulation where:

pointer input injects color into a floating-point texture
compute shaders blur and transport that data over time
values slowly fade out, creating trails
a render pass displays the result

Is it physically accurate? Absolutely not 😄
Does it look cool? Oh yes.

Live parameters like trail length, brush size, swirl strength, and color can all be tweaked via a control panel — no shader recompilation needed.

React… for a WebGPU demo?

Most WebGPU demos you’ll find are written in plain HTML + JS. I could’ve done that too.

But I decided to use React + TypeScript as a thin wrapper:

clean UI
easy state management for sliders
zero manual DOM wiring

It worked great — with one important caveat.

To make this demo usable, I had to disable React Strict Mode.

Why? Because Strict Mode intentionally runs effects twice in development to detect side effects. That’s normally fantastic… but not when you’re creating GPU devices, pipelines, textures, and buffers. Double initialization can break things very quickly.

Low-level GPU code is one of those rare cases where Strict Mode gets in the way.

A TypeScript gotcha

One more small thing:
TypeScript doesn’t ship WebGPU types fully enabled out of the box yet.

You need to explicitly enable WebGPU typings in your TS config, otherwise none of the GPU types will exist. It’s a one-time setup, but worth mentioning if you’re trying this for the first time.

Final thoughts

WebGPU feels like a real step forward for the web.
Not just “slightly better graphics”, but an entirely new class of things we can realistically build in the browser.

This demo is just a visual experiment — but it already shows how powerful, expressive, and fun GPU-driven web apps can be.

If you’ve been curious about WebGPU… this is your sign to try it 🚀

Your GitHub Contribution Graph Means Absolutely Nothing - And Here’s Why

Sylwia Laskowska — Tue, 13 Jan 2026 11:42:28 +0000

If your GitHub contribution graph disappeared tomorrow, would that make you a worse developer?

For years, we’ve been trained — consciously or not — to treat green squares as a proxy for competence, discipline, or even passion.

TL;DR:
A GitHub contribution graph measures neither productivity, nor skill, nor engagement as a developer.

Let me start with two very short stories that inspired me to write this article.

Story #1: Auto-commits and visible consistency 🤖

This discussion was inspired by an article I recently read on DEV.

The author described how he created an app that automatically commits his code. According to him, he programs a lot, but often simply forgets to commit and push his changes — which makes his GitHub contribution graph look… poor.

And while I absolutely respect the curiosity, creativity, and the act of turning an idea into a working project, one thought immediately crossed my mind:

Who on earth evaluates developers based on the number of their commits?

That makes very little sense.

Many people in the comments agreed, but some shared stories from job interviews where managers actually asked candidates why their GitHub activity was so low. Even if the answer made perfect sense (for example: most of their work lives in private company repositories) and the interview continued normally, there was still that unpleasant feeling — the candidate was pushed into a defensive position for no good reason.

Personally, I’ve participated in many recruitment processes and was asked about my GitHub exactly once. But maybe I’m just lucky?

Story #2: The graph of doom 😱

A few days earlier, a friend from my previous job shared a screenshot of someone’s contribution graph. I’ve modified it here to protect privacy, but it looked roughly like this (The AI stubbornly paints 8 days a week instead of 7 — let's keep it that way 🙃):

Impressive? Maybe. Terrifying? Also maybe.

My friend — a very empathetic person — didn’t feel admiration at all. Instead, he felt concern.

Where is the work-life balance?
When does this person rest?
How does this human being even function?

The mystery was solved pretty quickly. The graph most likely looked like this because the user had a job that ran a daily database backup.

For the record: this person actually was very active on GitHub and contributed to many open-source projects — just… not that much.

And this is where we get to the core of the problem.

When did a contribution graph become a way to judge someone as a developer? 🤔

By design, it never should have been.
And it doesn’t hold up to even basic common sense.

And yet, somehow, we still look at it and think:

“Oh, this person works a lot.”
“This dev commits once in a while — probably not very engaged.”

It’s one thing when random people think like this.
It’s much worse when it happens during recruitment.

Because based on a contribution graph, you can’t tell:

how good someone is,
how busy they really are,
or even whether the activity is meaningful at all.

One person may forget to commit or work mostly in private repositories. Another may solve complex problems for weeks with very few commits. Meanwhile someone else may just be running an automated job every day.🤷‍♂️

My own empty graph 🙃

I’m actually a great example of this.

Here is my impressive GitHub contribution graph for 2023:

So what happened in 2023? Maybe some of you will ask: “Sylwia, did you sleep through the whole year? Or maybe you won the lottery?” 🤔

The truth is I was a tech lead in a startup building Anti-Money Laundering technology. I worked hard, built a lot of things, and honestly — thanks to contributions to my company’s private repositories, my GitHub looked pretty impressive.

Then, in 2025, I changed job and was simply removed from those repositories. And just like that… my graph vanished.

Today, I create small demo repositories once a month — and given my current lifestyle, I consider that a lot.

What actually matters on GitHub 🧠

Of course, there is value in looking at someone’s GitHub more closely and seeing what they build.

Do they contribute to open source?
Do they create their own interesting projects?

Sometimes a person with a few solid projects and even a few months of inactivity is far more valuable than someone who commits a few lines of code every single day.

And besides…

Not everyone has to contribute to open source 🚶‍♀️🚶‍♂️

People contribute to the community in very different ways.

For example, I like writing blog posts. It doesn’t stress me out, I enjoy sharing my thoughts, and writing comes easily to me. I write fast, I read fast, and I don’t use my brain while doing any of it. 😅 After a full day of coding at work — plus endless calls like “Sylwia, how does this work?” — writing code in the evening is simply exhausting.

But I can easily imagine people for whom writing is painful, while coding after hours is pure relaxation.

Others create tutorials.
Some record videos.
Some prepare conference talks.
Some share work on StackBlitz or CodePen.

And some are so deeply engaged in their full-time jobs that they simply have no time or energy left for anything else related to code.

Which leads me to another question.

Does everyone really need to be active in the community? 🧩

IT is kind of a cultural anomaly here.

Is there any other industry where people are almost expected to work for free after hours for the benefit of others?
Do journalists write free articles at night just in case?
Do lawyers prepare guidelines for the community so they can get their next job?
Do shopkeepers learn about the products they sell after work to better help customers? 🤔🤣

I personally love the IT community and I’m happy to contribute. But not everyone has to.

People have families, hobbies, and different priorities. Some just come to work, do their job well, and then live their lives. And you know what? They might still be absolutely brilliant developers — sometimes better than the loudest community heroes.

Not every programmer has to be obsessed with IT or follow every new trend. We also need people who simply show up and deliver. And yes — we need them very much.

Over to you 💬

How about you?
Have you ever been asked about your GitHub contribution graph during recruitment?
Or has no one ever mentioned it?

I’m genuinely curious what your experience has been.

When React Starts Acting Like jQuery (and You Can Totally Tell 😅)

Sylwia Laskowska — Thu, 08 Jan 2026 13:00:12 +0000

I’m not a fangirl of any single framework. For me, frameworks are tools. Just like I prefer a good, sturdy hammer over a rusty one with holes... I also prefer tools that help me build software that’s maintainable and pleasant to work with. That’s why I like to stay up-to-date, understand how things work under the hood, and not just “use the thing everyone uses”.

I work with Angular on a daily basis — and yes, Angular forces you into a certain architecture (although believe me, you can still build absolute spaghetti in it… ask me how I know 😬).

But I genuinely love React. Whenever I do a side project, I very often reach for it. I adore JSX and how close React feels to plain JavaScript, especially compared to Angular. But… you know what they say: with great power comes great responsibility 😎 And in the wrong hands… that freedom can burn a project.

I’ve seen more than a few projects that weren’t just messy.
They looked like someone wrote them in jQuery, deleted $(document).ready, sprinkled some JSX over it… and genuinely tried to make it work 🤡

Was it a blind migration from an old codebase?
Was it devs who, deep in their hearts, never really left jQuery behind? 😉
Hard to say.

Either way - here are some classic signs your React code isn’t really React… it’s just jQuery wearing JSX. And yes, it shows. Loudly.

1️⃣ One giant component that “does everything”

React file. Looks like .tsx. Technically it has sub-components. Maybe even a utility for CSS class names. But emotionally?

Emotionally, it feels like an old-school index.html with a giant script tag living inside 😂

Big blob. Fetching data. Updating UI. Managing events. Managing layout. Oh, and probably a modal, three dropdowns, a table and a sidebar too, because why not.

🧨 Example

function App() {
  const [data, setData] = useState([]);
  const [sidebarOpen, setSidebarOpen] = useState(false);
  const [filter, setFilter] = useState("");

  useEffect(() => {
    fetch("/api/items")
      .then(res => res.json())
      .then(setData);

    document.getElementById("loader").style.display = "none";
    document.getElementById("list").style.display = "block";

    const el = document.getElementById("filter");
    el.addEventListener("input", e => setFilter(e.target.value));
  }, []);

  return (
    <>
      <input id="filter" />
      <div id="loader">Loading...</div>
      <ul id="list">
        {data.filter(d => d.includes(filter)).map(d => <li>{d}</li>)}
      </ul>
      <button onClick={() => setSidebarOpen(!sidebarOpen)}>Toggle</button>
      <div className="sidebar">{sidebarOpen && "Hello"}</div>
    </>
  );
}

🤔 Why does this happen?

Someone migrated from jQuery and just shoved everything into one file.
“It works, don’t touch it”.
No architecture decisions early on.
“We’ll refactor later” (we all know how that story ends).

✅ How it should be

split components by responsibility (Single Responsibility Principle)
separate:
- data / logic components
- presentation components
move logic to custom hooks when appropriate
avoid direct DOM manipulation — let React own the UI
remember: lots of small components > one god-component

2️⃣ One giant `useEffect` that does… everything

useEffect(() => { /* 🤹‍♂️ everything happens here */ }, [])

Fetching data, adding event listeners, toggling classes, updating the DOM, talking to 7 different services, scrolling, analytics, toast notifications… all in one glorious effect.

Basically:

Take $(document).ready, replace it with useEffect, ship to prod 😎

🧨 Example

useEffect(() => {
  fetch("/api/stats")
    .then(res => res.json())
    .then(data => {
      setStats(data);
      document.title = "Dashboard";
      document.getElementById("counter").textContent = data.users;
    });

  const resize = () => document.body.classList.toggle("mobile", window.innerWidth < 700);
  window.addEventListener("resize", resize);

  window.scrollTo(0, 0);

  return () => window.removeEventListener("resize", resize);
}, []);

🤔 Why does this happen?

Lack of mental model: “effect = place where magic happens”.
Copy-paste from older code.
“Hey, it runs once, perfect place for everything!”
No understanding that effects should be focused and scoped.

✅ How it should be

every effect should have one clear responsibility
split giant useEffect into multiple focused effects
don’t put logic in effects if it can live in render
remember:

useEffect !== lifecycle method

avoid stuffing all app behavior into a single “runs once” effect

3️⃣ `useEffect` for things that should simply be in JSX

This one hurts a little 😅
Doing DOM manipulation in an effect just to update text, class, visibility, or something that JSX can declare naturally.

Instead of:

if condition → change DOM

React wants:

if condition → render something else

🧨 Example

useEffect(() => {
  const el = document.getElementById("message");
  if (error) {
    el.classList.add("visible");
    el.textContent = error;
  } else {
    el.classList.remove("visible");
  }
}, [error]);

Meanwhile React:

{error && <p className="message">{error}</p>}

🤔 Why does this happen?

Still thinking imperatively: “UI is something I change, not something I describe.”
Old patterns: “Everything dynamic? ➝ must go in useEffect!”
Old habits die hard.

✅ How it should be

UI changes should be expressed declaratively in JSX
show/hide things using conditional rendering
derive classes from state, don’t toggle them manually
think:
- “state changes → React rerenders”
- not “state changes → I patch the DOM”

4️⃣ A giant “switch” on CSS classes instead of real logic

UI state stored… not in state
…not in props
…but… 🥁 in CSS class names.

The application logic becomes:

“if it has this class then it means it’s open”
“if it doesn’t then it’s closed”
“if it has this plus that then it’s in some magic state nobody fully understands anymore”

Congrats, you built a state machine… in your stylesheet 🙃

🧨 Example

useEffect(() => {
  const steps = document.querySelectorAll(".step");
  steps.forEach(step => {
    step.addEventListener("click", () => {
      steps.forEach(s => s.classList.remove("active"));
      step.classList.add("active");
    });
  });
}, []);

🤔 Why does this happen?

Legacy thinking.
“This used to work in jQuery, why change it?”
CSS was used as a state holder for years — the habit sticks.

✅ How it should be

keep UI state in React state or a store
make UI derive from state instead of encoding logic in CSS
for complex flows consider:
- useReducer
- a proper state machine
rule of thumb:
- CSS = styling
- React state = logic

5️⃣ Animations as “just toggle the class in JS”

Need animation?

Add/remove class in JS. Done.
React? Oh yes, still technically there 👀 Just quietly watching.

No state. No declarative transitions. No structure.

Just:

click → add class → remove class later → hope nothing breaks

🧨 Example

function Notification() {
  useEffect(() => {
    const btn = document.getElementById("show");
    const box = document.getElementById("note");

    btn.onclick = () => {
      box.classList.add("visible");
      setTimeout(() => box.classList.remove("visible"), 2000);
    };
  }, []);

  return (
    <>
      <button id="show">Show</button>
      <div id="note" className="notification">Hello!</div>
    </>
  );
}

🤔 Why does this happen?

Familiar old pattern.
Quick hack delivered to production.
Zero time allocated for frontend architecture.

✅ How it should be

base animation triggers on React state, not manual DOM
simplest option:
- state → class toggle in JSX
better options:
- CSS transitions driven by state
- React Transition Group
- Framer Motion
avoid imperatively driving animations when you can declare them

6️⃣ Keeping DOM elements inside state 😱

Rare… but I’ve seen it.
And once you see it, you never really forget it — it leaves a mark 😅

useState<HTMLDivElement | null>(null)

And then logic like:

“if we have this element, do things directly on it”
instead of storing intent in state.

That’s not React. That’s absolutely raw DOM puppet-mastering.

🧨 Example

const [el, setEl] = useState(null);

useEffect(() => {
  setEl(document.getElementById("target"));
}, []);

function highlight() {
  el.style.background = "yellow";
}

🤔 Why does this happen?

Confusing refs, state, and DOM.
Treating React as just a helper to render markup.
Not really understanding React’s role at all.

✅ How it should be

if you need to access DOM → use ref
store intent in state, not raw DOM nodes
DOM is implementation detail
state describes what you want to happen, not how to mutate the element

💬 Why this matters

I’m not saying code must always be perfect.
Sometimes quick hacks are fine. Sometimes deadlines win. Sometimes legacy constraints are real.

But when React is used like jQuery with JSX…

maintenance becomes nightmare
team onboarding becomes painful
bugs hide in dark corners nobody understands
architecture collapses under its own weight

React is powerful not because it manipulates DOM better.
It’s powerful because:
✨ State → UI
not
🔧 UI → patch → patch → patch

🤍 A little reflection

React gives freedom. And that freedom is beautiful.
But freedom requires responsibility. Without it, React becomes:

a jQuery with better branding

And that’s a bit sad, because React can give us structure, clarity, predictability — if we let it.

If your project smells like the things above…
it’s not a shame.
It just means there is history, pressure, context, and human decisions behind it.

But maybe it also means…

it’s time to pause, breathe, and rethink a little 😊

🙋‍♀️ Your turn

I’m super curious:

👉 Have you seen “React in jQuery cosplay” in the wild?

Share your stories, scars, confessions, or survival tips!

Yes, true + true === 2. And No, JavaScript Isn’t Broken

Sylwia Laskowska — Sun, 04 Jan 2026 12:19:52 +0000

JavaScript has been my main work language for years now (and of course these days it’s mostly TypeScript 😉). I started working with it before ES6, back when the language felt a lot more “primitive” than it does today – no let or const, no spread operators, no Promises, not even classes, only prototypes.

Writing JS back then was pure chaos in the best and worst sense – a total roller coaster where you really had to understand the language to avoid shooting yourself in the foot. I remember reading a ton about it. The books that really stuck with me were You Don’t Know JS (later You Don’t Know JS Yet) by Kyle Simpson. You can still find them on GitHub today, and they’re an absolute goldmine of JavaScript knowledge.

So nowadays, when yet another backend colleague laughs at JS quirks like true + true === 2, I just smile politely and nod… while internally screaming: “but it’s completely obvious, because this and that and also…” xDDD I used to actually try to explain it, but usually after about 10 seconds they’d just stare at me like I’d lost my mind, so I gave up 😅

But here, on dev.to, I’m hoping I’ll find people who actually want to hear the explanation 😂

I could write one long article about a bunch of JavaScript oddities, but how about a weekend series instead? If you like the idea, hit the like button 😉

Why `true + true === 2`

Here’s one of JavaScript classics people love to joke about:

true + true === 2 // true

At first glance, this feels ridiculous.
How can adding two booleans give you a number?

The key: `+` is (mostly) a numeric operator

In JavaScript, the + operator works in two modes:

if there’s a string involved → string concatenation
otherwise → numeric addition

Since true isn’t a string, JavaScript assumes this is math and converts both values to numbers.

And what is the numeric value of `true`?

JavaScript uses a standard internal conversion rule called ToNumber.

true → 1
false → 0

So:

true + true
// becomes
1 + 1
// which equals
2

This isn’t random. Many languages treat booleans as numeric under the hood:

Python: True + True === 2
C / C++: true behaves as 1

So again, JavaScript is not being uniquely weird here - it’s actually pretty normal computer science behavior.

It also explains other “strange” cases

For example:

true * 10   // 10
false * 10  // 0
true - 1    // 0

Once you know booleans convert to 1 and 0, nothing here is magical anymore.

Practical takeaway

+ performs numeric addition unless strings are involved
true converts to 1, false converts to 0
it’s not JavaScript being silly - lots of languages behave similarly

And that’s why true + true === 2 is not a bug… just logic wearing a funny hat 😎

“Why Do You Code?” - A Surprisingly Hard Question

Sylwia Laskowska — Tue, 30 Dec 2025 13:03:01 +0000

The end of the year is coming, and for me it’s always a time of reflection. I’d like to invite you to ask yourself one simple question.
Imagine that from January, the IT job market simply stops existing. No more well-paid jobs, no more “career in tech”. Programming becomes just a hobby.

Do you keep coding?
Or do you throw it all away and say “I’m done”? 😅

To be honest, my own answer isn’t that simple. I’ve technically been coding “forever” — I wrote my first website when I was 12, back in glorious HTML 4.01 😎 But programming has always been more of a medium of expression for me than a goal in itself.

Over the years, my approach to coding has evolved a lot — maybe you’ll recognize yourself somewhere on this spectrum 👇

🔹 First, there was curiosity

How does this even work? Why does something show up on the screen? How does the internet work? How do you build your own website?
That curiosity is still there. I love exploring new technologies and playing with things.
But let’s be honest… curiosity doesn’t pay the bills 😉

🔹 Then came the money phase 💸

If I already have this skill, why not make a career out of it?
I still remember my first manager laughing when, after my internship, he asked about my career plans and I said:
“Well… I don’t really have any. I just wanted to become a junior developer and I did it.” 😄
Luckily he was a great guy and helped me figure out what to do next.

🔹 Then I went full tech-fangirl mode 🤓

New stacks! New frameworks! No legacy ever!
It didn’t really matter what the project did — NGO app or cigarette factory system — what mattered was ANGULAR/REACT/VUE (delete as appropriate 😂). Definitely the newest store management, the newest tools, shiny everything.

I never reached the “I’ll build the worst garbage as long as it pays” mindset… but yeah, once I had the skills and leverage, I negotiated my rates pretty hard 😉

🔹 And then… the famous “what now?” stage

You know the one.
I’m not building a revolutionary product. I’m not inventing a new framework. I’m not writing a browser engine. I’m not a startup founder.

I work in regular enterprise Angular. Problems start feeling repetitive, pressure grows, everything “has already been done”, expectations rise.
Yep. That’s a very comfy road straight to burnout 🥲

🔹 So I had to figure things out

I didn’t want to leave tech — I genuinely like programming.
So I decided: if I’m spending 8 hours a day coding anyway, those 8 hours better mean something.

Since then, whenever I changed jobs, I paid a lot more attention to the project itself. It needed to tick at least one (ideally both) boxes:

interesting technology
social impact / meaningful purpose

Thanks to that, I’ve helped build a Fair Trade certification platform, software for retirement homes, hospital equipment management tools, worked in anti–money laundering, and now I work for the European Commission on a huge socially important project. And I can even visit Brussels a few times a year. 🥰

And yeah — work is still work. We joke, gossip, talk about the gym, complain, drink coffee. Nothing magical 😅
But if every job more or less feels the same, and I can choose the kind of work I do… why not choose something that actually contributes something good to the world? 🌍

So now I’m curious:

👉 Why do you code?

What’s your motivation today?
Would you still do it if programming was only a hobby?

Share your thoughts — I’d love to read your stories! 💬

DEV Community: Sylwia Laskowska

The Real Skill in Programming Is Debugging. Everything Else Is Copy-Paste

But What Happens Later?

Wait… Isn’t Programming Also About Architecture?

When I Was a Junior

Today

The Real Skill

The Responsibility

So… Am I Unhappy About That?

16 Modern JavaScript Features That Might Blow Your Mind

📅 ES2022 — The Foundation of Modern JS

✨ Top-Level await

🔒 Private Class Fields (#)

🧠 Error.cause

🎯 Object.hasOwn()

📍 .at() — Relative Indexing

📅 ES2023 — The Immutability Upgrade

🧹 toSorted()

🔁 toReversed() & toSpliced()

🔎 findLast() / findLastIndex()

📅 ES2024 — Data Transformation & Async Control

🧩 Object.groupBy()

⚡ Promise.withResolvers()

📦 Resizable ArrayBuffer

📅 ES2025 — Functional JavaScript Gets Serious

🧠 Iterator Helpers

🧩 New Set Methods

🔐 RegExp.escape()

⚡ Promise.try()

🧊 Float16 Support

🧭 The Bigger Picture

If You See These Red Flags in an IT Interview — Run (Real Stories)

⏳ The Recruitment That Lasted a Year

⚖️ “How Much Do You Value Work-Life Balance?”

👀 “Who’s Helping You There?”

😤 Offended Recruiters

🎥 Total Surveillance Mode

🤔 Final Thoughts

How Seriously Should We Take State of JS and Other Developer Surveys?

A Very Short Recap of 2025 📊

My Younger-Developer Phase 😄

A Little Story About Surveys 🧠

Who Actually Answers? 🔥

Regional Reality 🌍

What Does “Usage” Even Mean? 🤨

Surveys vs Real Careers 💼

How to Read Surveys 🧭

So… Should We Care? 🙂

Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems

1) Structured Clone API

Nice extras

2) Performance API

3) Page Visibility API

4) ResizeObserver

5) IntersectionObserver

6) AbortController

7) Idle Detection API

8) BroadcastChannel API

9) Web Locks API

10) File System Access API

Reality Check 🧠

Is Learning CSS a Waste of Time in 2026?

CSS Used to Be My Thing

The Accessibility Wake-Up Call ♿

CSS Slowly Slipped Into the Background

Meanwhile… CSS Is Actually Thriving ✨

The Generational Gap

Handmade Pasta and CSS

So… Did CSS Get Worse?

What About You?

Why NaN !== NaN Makes Perfect Sense (I Promise)

No, JavaScript Isn’t Broken (Again)

So… what is NaN anyway?

Why is NaN !== NaN?

A useful mental model 🧠

“Okay, but how do I check for NaN then?”

❌ Don’t do this

✅ Do this instead

A small plot twist 👀

Is JavaScript the only weird one?

✨ Top-Level `await`

🔒 Private Class Fields (`#`)

🧠 `Error.cause`

🎯 `Object.hasOwn()`

📍 `.at()` — Relative Indexing

🧹 `toSorted()`

🔁 `toReversed()` & `toSpliced()`

🔎 `findLast()` / `findLastIndex()`

🧩 `Object.groupBy()`

⚡ `Promise.withResolvers()`

🔐 `RegExp.escape()`

⚡ `Promise.try()`

Why is `NaN !== NaN`?

2️⃣ One giant `useEffect` that does… everything

3️⃣ `useEffect` for things that should simply be in JSX

Why `true + true === 2`

The key: `+` is (mostly) a numeric operator

And what is the numeric value of `true`?