DEV Community: Sylwia Laskowska

How Are Developers Actually Using AI At Work?

Sylwia Laskowska — Wed, 27 May 2026 07:11:18 +0000

JSNation is coming soon, and besides my talk (I’ll drop the link in the comments so I don’t spam you with it for the tenth time 😅), there are also discussion rooms. And somehow, I got invited to two of them.

Now, a normal person would probably stop for a second and think: “Do I even have time for this?”, “Is it worth it?”, “Should I maybe not overcommit myself for once?”. Meanwhile, in classic Sylwia fashion, I replied almost instantly: “Oh, that sounds amazing! Sure, sign me up for everything!” 😎

And that’s how I ended up in a discussion room called “The New Senior Engineer: Builder, Reviewer or Orchestrator?”.

Now, my career advisor, ChatGPT, always tells me: “Sylwia, please get your life together. And if you insist on doing ten things at once, at least reuse the content.” 😅 So instead of coming up with all the conclusions myself, I thought: why not ask the DEV community?

But before I ask the big question — what should a Senior Engineer become in the AI era — I think there’s another, more interesting one first: how are you actually using AI at work?

Not in conference demos. Not in viral Twitter threads. Not in “my AI agent rewrote Kubernetes during lunch” stories. I mean real work. Real projects. Real teams.

Of course, feel free to jump straight into the comments (you know I love talking with you all ❤️), but first, a few observations from my side.

AI Above Everything

At least that’s the image the internet gives us. Conference titles. Newsletter headlines. LinkedIn prophets.

Matteo Collina opens a 100k-line PR for Node.js and people panic.

Someone rewrites an entire React application to Svelte in two weeks. Hundreds of thousands of files.

The creator of Bun rewrites it from Zig to Rust in one evening, while casually mentioning he also went on a date that night. (Am I the only one getting weird associations here? 😅)

Armies of agents replacing development teams. Agents opening PRs for other agents to review. Everything automated. And somewhere in the middle of all this, the Senior Engineer becomes some kind of AI shepherd, occasionally checking whether the robots are heading straight into a cliff.

Honestly, it’s both fascinating and mildly terrifying. Sometimes it makes you wonder whether we should all reconsider our career choices and maybe sign up for hairdressing school before the robots learn that too 😅

But then I stop for a second and think: I actually work in this industry. I know a lot of developers. And real life often looks… very different.

From Excitement to Cost Optimization

A friend of mine works at a huge tech corporation. One of those companies you definitely know — and probably either love or hate 😄

Of course they started using AI tools very early, including Copilot. But things really escalated once they got proper coding agents — I think Claude Code.

At first, the company was completely mesmerized. They bought the most expensive plans possible and encouraged people to use AI aggressively. If someone hit token limits, management basically said: “Don’t worry, we’ll buy more. It’s revolutionary!”

My friend happened to be building a new application from scratch and honestly — he loved it. The amount of code generated was absurd. Normally, building something like that would take months with an entire team. Now? A few days and huge chunks of the system already existed.

And because he’s genuinely an excellent developer, he became very good at noticing the exact moment Claude started going completely off the rails. Interestingly, this often happened around 5 PM. Apparently the AI wanted to clock out too 😅

But after a few months, the excitement slowly started fading. Turns out that while AI sometimes makes development dramatically faster, it definitely doesn’t always.

And then came the second surprise: the company actually calculated how much all this AI usage was costing. Suddenly everyone discovered that — surprise, surprise — unlimited AI agents aren’t exactly cheap 😄

So now there are discussions about limits, optimization, and reducing token usage. At this rate, maybe hiring interns will eventually become the cheaper option again 😂

And honestly, we’re already seeing this trend more and more. Wasn’t it Meta that introduced some kind of “tokenmaxxing” culture where people were rewarded for using fewer tokens?

And Finally, My Own Story

Now let’s move to my world.

A massive international institution. An enterprise ship that takes three years to turn right. A place where privacy is treated almost like religion. So naturally, people were extremely skeptical about LLMs for a long time.

But eventually AI arrived there too, which honestly makes me think these tools are now basically everywhere 😄

So: do coding agents massively accelerate development in enterprise legacy systems?

Well… that’s where things become complicated.

Sure, there are tasks where AI is genuinely useful. Simple bugs. Small features. Boilerplate work. But on some tasks? It completely collapses.

The agent reads library code. It crawls through the application. It searches half the repository. And still somehow understands absolutely nothing 😅

Sometimes I literally have to tell it: “Maybe check that weird file written by a junior developer seven years ago.” Or: “Our UI library has some very specific legacy quirks, maybe investigate that direction.”

And honestly? After 2.5 years in this project, I’m simply faster than the AI agent in many debugging scenarios.

Not because I’m smarter. Not because AI is useless. But because enterprise systems accumulate context, history, weird decisions, tribal knowledge, hidden dependencies and architectural scars over many years. And I have that context. The AI usually doesn’t.

And I honestly doubt my project is unique here. A huge percentage of software running the world today is enterprise legacy that survived far longer than anyone originally planned — and is still actively evolving 😄

So maybe, somehow, I’ll actually survive as a programmer until retirement after all. And maybe I won’t need to learn hairdressing.

Which is probably good news for humanity, because I’d be terrible at it 😅

But now I’m genuinely curious: what does AI usage actually look like in your work?

Million-line AI PRs? Daily battles with legacy systems? Token optimization? Or maybe something completely different?

BTW, If you like my posts, feel free to follow me on Linkedin!

Every Developer Is Lying About Something — And AI Won’t Fix It

Sylwia Laskowska — Thu, 21 May 2026 07:06:41 +0000

Yes, all of us are lying. And you are probably lying too. Let me prove it 😉

Oh, I have so many article topics in my head right now. The really exciting kind. But this week absolutely steamrolled me 😅 I finally finished preparing my JSNation talk, and at the same time two other amazing opportunities appeared — one professional, and one that feels more like a childhood dream coming true ☺️ But I don’t want to jinx it yet.

And just so it doesn’t sound like everything magically works out for me — I’ve also had a few CFPs rejected recently. The ones I actually cared about! But honestly? That’s just part of the game. One conference may reject your talk this year and happily accept another one from you the next.

So yes, the really big topics will have to wait a little bit longer 🙂 Which doesn’t mean this one is trivial.

We talk about AI everywhere now, as if it’s going to solve all our problems. But as we’ve already noticed, there’s no AI without humans, and behind every “smart” model there’s still some human being — at least for now 😉

Which is probably why, in practice, coding agents do speed things up… but not nearly as much as many people expected. Some studies even suggest they slow developers down.

Because the real problem is often not the code itself. The real problem is the people writing or generating that code.

And unfortunately, all of us lie in one way or another. Sometimes to others. Sometimes to ourselves.

Some Developers Lie About Knowing What They’re Doing

One of the best developers I know once confessed something to me.

This guy is genuinely brilliant. The kind of engineer companies fight over. He currently works on optimizing drivers for LLMs, gets promoted constantly, and even in this lovely “tech crisis” era, he still had multiple job offers to choose from when he considered switching jobs.

And yet, every single time he joins a new project, he feels like a complete idiot.

Everybody else seems productive. People are delivering tickets. Writing code. Moving confidently through the project. Meanwhile, he sits there staring at the codebase wondering:

What exactly is happening here?
What are we even building?
Why does this work like this?
Why are we implementing it this way and not differently?

And then he starts asking questions.

Usually, it turns out nobody really knows what they’re doing, why they’re doing it, or whether they’re even solving the right problem in the first place.

It reminds me of that old joke about lumberjacks cutting down a forest. Eventually, the team leader climbs the tallest tree, looks around, and screams:

“Guys! We’re cutting down the wrong forest!”

And the workers below shout back:

“Who cares? We’re making great progress!”

And honestly, no LLM will save us here. Especially if we never even ask the right questions.

Others Lie About Knowing How To Do Something

This is basically an extension of the previous problem.

A less experienced developer picks up a task and confidently says:
“Yeah, I know how to do this.”

Unfortunately, what they often mean is:
“I hope I’ll somehow figure it out.” 😅

In reality, they may not know how to solve the problem, which tools to use, what architecture makes sense... or even what prompt to write to get useful help from a coding agent.

But they’re afraid to ask.

Because how will they look in front of the team? What will the manager think? The tech lead?

Best-case scenario: they eventually ask questions… just way too late.

Worst-case scenario: they never ask at all and deliver something completely wrong. Which often isn’t even caught properly because…

Someone Else Is Lying About Having Time

Now we’re entering senior and leadership territory 😅

The motivations differ. Some people build their self-worth around being “the reliable one.” Others are terrified of losing status, influence, or even their job.

So they keep taking on more:

the hardest tasks,
endless meetings,
refinements,
estimations,
discussions with support,
discussions with business,
code reviews,
architecture decisions,
documentation.

And let’s be honest. Something eventually has to break.

Human beings are not made of steel. Nobody can operate at 100% forever.

So what happens?
People start half-listening during calls. Code reviews become rushed. Documentation quietly dies in a corner somewhere.

But they still refuse to admit — either to others or to themselves — that they’re simply overloaded.

Some Developers Lie About How Long Things Will Take

I see this constantly with more advanced juniors and mids.

They throw around hilariously optimistic estimates with absolute confidence.

And sure — if they could work uninterrupted for eight straight hours, the application contained no legacy code, edge cases didn’t exist, and other humans never interacted with the system… then maybe the estimate would actually be correct 😄

Then sprint review arrives, and suddenly everybody is shocked that the team didn’t deliver everything.

But this is not the only problem with estimations.

I once worked with an especially funny senior developer.

He treated estimations like sacred truth. He would aggressively defend his numbers during planning sessions, insisting that this specific task was definitely extremely complicated. The rest of the team usually suspected it wasn’t that bad, but eventually we’d surrender just to end the discussion.

And then — at least three separate times — he personally picked up the exact task he had massively overestimated… and finished it in about an hour.

Which basically meant the estimation discussion itself took longer than implementing the feature 😅

Did this experience change his behavior?

Absolutely not.

And Some Lie About Knowing Everything Best

These are probably the most dangerous ones.

I avoid people who say things like:

“Use THIS technology and ONLY this technology because everything else is garbage.”

Insert your favorite holy war here:
Angular vs React, Java vs Python, Rust vs literally anything else 😄

I never write like that myself. Even when I publish something titled “I Love Tailwind. Sorry Not Sorry”, I still talk about its downsides and explain where it absolutely doesn’t make sense.

If one day I start claiming some technology is objectively perfect for every possible situation, please leave a comment saying:

“Sylwia, go touch grass immediately.” 😅

Honestly, I’ve always wondered where this sense of absolute certainty comes from.

Because not all of these people are even paid influencers. Some genuinely seem emotionally attached to technological holy wars. Others maybe only know one stack deeply, so everything else automatically feels “bad.”

And while this behavior is very common among tech influencers, you absolutely see it inside companies too.

The problem is that this kind of certainty can seriously damage projects. People stop questioning decisions. Other developers become afraid to speak up. Stakeholders assume “the confident person” must be right simply because they sound convinced.

Best-case scenario: you end up with an annoying developer who knows more about frameworks than the actual business domain.

Worst-case scenario: you end up with a terrible stack choice and spaghetti architecture held together by ego.

People Are Just… People

Of course, I’m not innocent either.

I’ve used many of these lies myself in the past. Maybe I’m older now. Maybe slightly wiser. Or maybe I just recognize these patterns more easily.

But I’m definitely still lying somewhere too. Maybe not to others — maybe to myself.

Because a lot of our problems in software development aren’t really technical problems at all. They’re deeply human problems:

ego,
insecurity,
fear of looking stupid,
fear of admitting mistakes,
fear of saying “I don’t know.”

And honestly, I don’t have some magical solution for this. We’re not going to require three years of therapy from every developer before allowing them into a sprint planning meeting 😄

But I have noticed one thing.

Very often, admitting you don’t know something, openly discussing uncertainty during planning, or simply saying:

“Sorry, I still don’t understand this. Could you explain it one more time?”

doesn’t make people see you as a worse developer.

Quite often, the opposite happens.

Suddenly communication inside the team improves. Other people start asking questions too. Conversations become more honest. Problems get discovered earlier.

Seriously. Try it at least once. You might be surprised 🙂

So… what kinds of developer lies do you see most often in your team?

4 Tiny Mistakes That Secretly Destroy App Performance

Sylwia Laskowska — Thu, 14 May 2026 06:04:15 +0000

Ok, I’m back from my short vacation and returning with some useful content 😄 As you know, from time to time I write posts for you in the style of articles like Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems — which I honestly love writing, and I know you enjoy them too 🙂

Today I want to approach the topic from a slightly different angle. I’m going to show you a few interesting things that might accidentally be making your app much slower, even though they often look completely innocent at first glance. And the best part? Some of them can be fixed surprisingly quickly. Also, these are the kinds of issues Claude Code or Codex probably won’t immediately point out when you ask them “why is my app slow” 😅

Usually, we develop our applications on powerful machines with fast CPUs, plenty of RAM, and fast internet. Unfortunately, real users often live in a completely different reality. Some of them absolutely have modern hardware, but there will always be somebody using an old laptop, a cheap Android phone, weak WiFi, or mobile internet from the depths of hell 😅

And suddenly it turns out your app is painfully slow for 10–30% of users.

And that’s where the war for milliseconds begins 😀

Every example in this article is something I either personally encountered in a real project or heard about from another developer, so these are definitely not hypothetical scenarios. Check whether some of these things are secretly happening in your own application 👀

Meanwhile, I’m slowly preparing for my JSNation conference talk. If you want to support me (or just see me awkwardly talking in my garden 😄), you can give me a like here. And if you want to watch my full talk completely FOR FREE, you can grab a free badge here. HOW COOL IS THAT 😄

But enough self-promotion, let’s get to the point!

1. Custom headers → preflight requests

This is exactly why it’s worth attending conferences. Sometimes you hear about problems there that you would probably never randomly google yourself 😀

One of my colleagues talked about this issue during his presentation. His team was trying to understand why their application felt slow for some users. Naturally, the backend was blamed first. Poor backend, as always 😅

But eventually they noticed something interesting in the network tab: OPTIONS requests appearing before almost every API call. Some of them were taking hundreds of milliseconds.

So what exactly is happening here?

This is related to CORS. Browsers sometimes send an additional OPTIONS request before the actual API call. This is called a preflight request and usually happens for “non-simple” requests — for example when using methods like PUT or DELETE, but also when adding custom headers.

And yes, even a completely innocent GET request can suddenly become two network calls because somebody added X-Feature-Whatever three years ago 😅

In their case, the funniest part was that the custom header wasn’t even used anymore. It was some ancient historical leftover from years earlier. Nobody knew why it existed. Nobody questioned it. It simply survived every refactor like an immortal enterprise relic 😀

If you’re curious, I actually prepared (together with Claude Code 😅) a small repo showing this behavior here:
https://github.com/sylwia-lask/preflight-options

Let's see the screens (please appreciate my high graphic skills!):

GET request without custom header:

GET request with custom header:

And honestly, this kind of thing happens all the time in large projects. Somebody adds a custom header for feature flags, debugging, localization, analytics, or “temporary” metadata… and then the header survives for the next four years.

Of course, sometimes custom headers are completely justified. But if you only use them for frontend-only logic, there are often better alternatives like query params, cookies, local state, or configuration endpoints fetched once during startup.

Individually, one extra request may not look catastrophic. But if your app performs dozens of calls during startup, especially on slower mobile connections, this suddenly becomes very noticeable.

2. Code splitting that does absolutely nothing

Sometimes the problem isn’t the network itself but the gigantic JavaScript bundle we load during startup. And this is usually the moment where everybody says:

“But how? We’re already doing code splitting! We use lazy loading everywhere!”

Yeah… about that 😄

I once audited an Angular application that looked very well structured at first glance. It had modules everywhere, lazy loading, proper architecture, all the “best practices.”

And yet the application loaded painfully slowly.

Fortunately, we have tools like webpack-bundle-analyzer, source-map-explorer, rollup-plugin-visualizer, or @next/bundle-analyzer that allow us to see what’s actually happening inside our bundles.

And what did we discover?

Yes, the application was split into modules…

…except each module was like 2 KB 😅

Because almost everything important lived inside one gigantic shared module that was imported absolutely everywhere, meaning most of the application still ended up inside the main bundle anyway 😀

Congratulations, your app is now split into 400 beautifully separated files that all load at startup.

This is also not the only weird case I’ve seen. I’ve already encountered situations where the app technically “lazy loaded” modules while still downloading almost the entire application every single time 😄

For example, something like this looks perfectly fine:

{
  path: 'admin',
  loadChildren: () =>
    import('./admin/admin.module').then(m => m.AdminModule)
}

Looks clean. Looks modern. Looks optimized.

Until you discover that AdminModule imports a massive shared module containing half the application 😅

So yeah — just because you use import() or lazy modules does not automatically mean your bundles are healthy. Always check what is actually being downloaded by the browser.

3. Unnecessary runtime dependencies

This is another extremely common problem, especially in projects where nobody really controls what npm packages people install 😅

In my current project, importing a new dependency is practically treated like a sacred ritual that requires approval from the wisest architects of the kingdom (which basically means me and two or three coworkers 😀). But in many projects, people install libraries completely thoughtlessly.

And then suddenly your application contains:

three analytics SDKs,
two date libraries,
all Moment.js locales,
the entire Lodash package because somebody needed one utility function,
Firebase imported globally,
three icon packs,
and some “tiny lightweight helper package” that quietly imports half the internet 😀

I once saw an application loading three different date libraries at the same time. The funniest part? The app barely even handled dates 😅 Apparently every developer simply had their own preferred religion.

Another classic example is importing Lodash like this:

import _ from 'lodash';

instead of:

import debounce from 'lodash/debounce';

The difference may look small, but over time these things accumulate a lot. Especially in enterprise applications that grow for years.

And unfortunately, tree shaking is not magic 😅

4. Huge background images

This one sounds almost too obvious, right?

Everybody already knows giant images are bad.

…except people still keep shipping giant images 😄

Recently, during the WeAreDevelopers podcast, we discussed which government websites loaded the fastest. Surprisingly, the UK completely dominated everybody else. Why? I’ll probably write a separate article about this later, but generally speaking, the site was just extremely simple. Very little visual noise, lots of informational text, simple layout, SSR, minimal unnecessary assets.

The second fastest was the US government website.

It followed almost exactly the same principles… except it loaded a fancy large image during startup 😅

And suddenly the large contentful paint became noticeably worse.

The funny thing about large background images is that they often look harmless on developer hardware with fast internet. But on slower devices they can absolutely destroy perceived performance.

Fortunately, there are many ways to improve this: use AVIF or WebP, compress aggressively, avoid massive hero images above the fold, lazy load non-critical visuals, and preload only truly critical assets.

And honestly?

Sometimes the fastest image is simply… no image 😀

Final thought

Application optimization is obviously an endless topic, and this article only scratches the surface. But I think one of the most important things to understand is that performance problems are often death by a thousand cuts.

One unnecessary header.

One oversized dependency.

One “temporary” shared module.

One background image nobody questioned.

Individually, none of these things look catastrophic. Together, they create an application that feels sluggish — especially on older devices or slower mobile networks.

And the really scary part?

Most of these decisions looked perfectly reasonable when they were originally introduced 😅

I Love Tailwind. Sorry Not Sorry

Sylwia Laskowska — Mon, 04 May 2026 08:54:09 +0000

I’m going on a short vacation this week, so this post is coming out a bit earlier than usual. I actually had a different, more “useful” topic in mind — something educational, something responsible. But then I came across this fascinating article: I don’t like Tailwind. Sorry not sorry written by @freshcaffeine , and I couldn’t get it out of my head.

So I decided to write a response instead.
Useful content will have to wait 😄

I actually agree with many of the points in the original article — especially around learning fundamentals. I just have a different perspective shaped by a different kind of work.

Let me start with a small disclaimer: I’ve written a lot — and I mean a lot — of handcrafted CSS in my life. Entire design systems. In fact, I got my first job in IT mostly thanks to my CSS skills, because my programming skills at the time were… let’s say “a work in progress” 😉

There was even a period when I made extra money building simple websites for clients. People literally paid me for delivering clean, aesthetic CSS.

So in theory, I should be the first person to defend handcrafted CSS and criticize Tailwind for polluting HTML.

And yet… I’m not.

Despite all its flaws, I love Tailwind. Deeply, sincerely, and yes — unapologetically.
Because it gives us something incredibly valuable in real-world development: speed and predictability.

Pumpkin pie: homemade or store-bought?

The author of the original article uses a pumpkin pie analogy. Handcrafted CSS is like baking a pie from scratch — roasting the pumpkin, making the dough, carefully preparing everything with love. Tailwind, on the other hand, is like using pre-made ingredients. You open a can, use ready-made crust, assemble everything quickly. Sure, it’s still a pie, but not quite like the one your grandma would make.

It’s a nice analogy. It really is.

The problem is — most businesses are not running artisan bakeries.
They’re running factories.
And those factories aren’t even in the pie business.

In reality, business rarely needs a handcrafted pie. Honestly, it often doesn’t even need a “semi-handmade” one. What it really wants is mass production: something that’s sweet enough, looks good enough, doesn’t cause stomachache, and can be delivered fast. If you can add a small decorative touch on top to make it feel slightly more unique — great. But even that is optional.

And there’s no point being offended by this. We can absolutely build beautiful, handcrafted CSS when we want to. But most of the time, businesses choose speed — because they are selling a product, not CSS.

I’m not building a piece of art.
I’m building software that five teams won’t break next week.

Repetition isn’t always a bug

One of the arguments against Tailwind is that everything starts to look the same. And honestly — that’s true.

But here’s the thing: very often, that’s exactly what the client wants.

Back when I was building websites for clients, the happiest ones were those who got three templates to choose from and a bit of customization on top. They didn’t want a masterpiece. They wanted something clean, modern, and effective — something that sells.

Tailwind is often simply good enough for that.

And in many cases, good enough delivered fast beats perfect delivered late.

“Messy HTML”

Yes — if you just throw classes around randomly, your HTML will look messy.

But let’s be honest: if we’re “craft-oriented developers,” we can organize our components properly, right? In real projects, that long Tailwind class list usually lives inside a component anyway. You don’t copy-paste that everywhere.

Also:

HTML is “noisy”? Sure.
But at least the rules are right next to what they affect.

I’ve seen plenty of “beautiful” CSS codebases where styling logic was scattered across multiple files, overridden in unexpected places, and impossible to trace without jumping through five layers of abstraction. I’ll take explicit over “hidden magic” any day.

Junior developers and “not learning CSS”

I actually agree with one part: Tailwind doesn’t replace learning CSS. I even wrote about that in my article: Is Learning CSS a Waste of Time in 2026?

But the argument that Tailwind is somehow “hurting juniors” always makes me smile a bit.

On one hand, we have mass layoffs in tech and endless discussions about AI replacing developers. On the other, we worry that juniors might not learn CSS because things are… too easy?

Let’s be real for a second.

“Junior” doesn’t mean “child.” These are adults. If someone wants to grow as a frontend developer, learning CSS is part of the job. It’s not some hidden, mystical knowledge. And we don’t need to choose our entire tech stack based on making things harder just so people are forced to learn.

Also — I’ve seen plenty of experienced developers who still struggle with CSS after years in the industry. At that point, I’d honestly rather have them use Tailwind and ship something consistent than fight yet another specificity war.

Tailwind doesn’t create bad developers.
Lack of fundamentals does.

About “craft”

There’s this idea that writing CSS is a form of craftsmanship — something closer to art, something deeply satisfying.

And yes, it can be.

But the last few years — especially with the rise of LLMs — have made it pretty clear where our “craft” actually sits in the bigger picture. In most business applications, CSS is not art. It’s not painting. It’s not sculpture.

It’s closer to baking pumpkin pies at scale.

There will always be places where handcrafted work matters — just like there are bakeries selling beautiful, artisanal cakes. But if you’re selling paper clips and organizing a corporate event, you’re probably not baking everything from scratch. You’re ordering something decent that gets the job done.

And that’s fine.

Why I actually like Tailwind

Let’s be clear — Tailwind is not perfect. It has trade-offs.

But it solves very real problems.

It gives you:

speed — you don’t context-switch between files every 10 seconds
predictability — no guessing what some class name means
consistency — especially across large teams
simple selectors — which are often easier for browsers to process than deeply nested CSS
less dead code — thanks to modern build setups

And most importantly:

It removes ambiguity.

The real problem in large codebases isn’t that CSS isn’t “beautiful” enough.
It’s that it becomes inconsistent, fragile, and slow to evolve.

I’ve never seen a project fail because CSS wasn’t handcrafted enough.
I’ve seen plenty fail because things were inconsistent and took forever to build.

When handcrafted CSS still makes sense

I don’t think Tailwind (or something similar) should replace handcrafted CSS everywhere.

There are cases where writing CSS by hand is not just useful — it’s the better choice.

Design systems and shared UI foundations — where you need full control and long-term consistency
Highly custom or experimental UI — where utility classes start to fight you instead of helping
Performance-critical interfaces — where you want precise control over what gets shipped
Learning and understanding the fundamentals — because at some point, abstractions always leak

Final thoughts

Tailwind isn’t about replacing CSS.
It’s about making frontend development survivable at scale.

And no — this post is not sponsored by Tailwind. (But if someone from Tailwind happens to read this… feel free to reach out 😄)

And what do you guys think? Are you Team Tailwind or more into 'craft' CSS? Or maybe something in between?

Thanks for reading! If you enjoyed this post, I'd love to have you follow me here on LinkedIn.

Is Software Development Just a Side Quest? A Jira Story

Sylwia Laskowska — Thu, 30 Apr 2026 06:01:20 +0000

How much time did you spend this week moving tickets in Jira (or other tracking tool) instead of actually coding?

I sometimes have this feeling that my main job is not development anymore — it’s just moving things between columns.

I always say that a software developer, by nature, is lazy. That’s why we became developers in the first place — to automate everything. So maybe expecting us to not only do our actual work, but also carefully maintain every single detail in Jira… is a bit optimistic.

Quick “what’s up with me” section. My recent article
Most Apps are Slower Than They Need To Be
ended up going way beyond DEV — different newsletters, and it even got me invited to a podcast at WeAreDevelopers 🎤 First podcast in my life. Chaos, tangents… pretty much 100% me 😅

And here’s a fun part: the technical article that opened those doors had almost 6x fewer views than this one:
You're a Real Software Developer Only If... Well, turns out we all enjoy a good laugh more than GPU acceleration demos. Can’t argue with reality 😄

Anyway, back to the topic.

I’m a senior developer. Not officially a tech lead in my current company, but in practice I do a lot of that work, next to coding. Coordinating developers' work, answering questions, helping unblock people. And it’s not just the team — there are stakeholders, testers, other teams.

And the app? It’s a government system. So if something breaks, it’s not “oh no, someone couldn’t watch a show” (haha yes, I'm refering to @adamthedeveloper and his famous You're Not Building Netflix post 😁). The consequences can be very real.

After a day like that, the last thing I feel like doing is carefully updating every field in Jira.

Don’t get me wrong — I actually like having a tracking tool. I can’t imagine working without one, especially in a bigger team. Tasks need to exist somewhere, priorities need to be visible, things shouldn’t disappear into Slack threads.

I also create tickets myself all the time, or ask for them to be created. I want things tracked. I want a history. I want clarity.

But for me, a ticket should have three states: todo, in progress, done.

Everything else is… negotiable.

Stories? Epics? Fine. If it helps someone manage the process, I can live with that.

But then come the extra fields. The additional statuses. The “just one more thing” because it will make the report nicer. Because the burn-down chart will look better. Because someone somewhere wants a cleaner dashboard.

And slowly, without really noticing, we turn Jira into something that requires more mental effort than the actual development.

We’re basically the boiling frog at this point. One more field. One more status. One more small tweak. Until suddenly nobody really knows what goes where anymore, what needs to be updated, and why.

And then, of course, developers get blamed for “not keeping Jira up to date”.

At some point it starts feeling like development itself is just a side quest. If we didn’t have to deal with code at all, imagine how perfect our Jira boards could be. Beautiful burn-down charts. Perfectly filled tickets. Absolute harmony 😄

The funny thing is — the best developers I know are often the ones who engage with this the least. Not because they don’t care, but because their focus is somewhere else. On solving real problems.

I’m still managing it somehow. But I definitely feel the friction.

So I’m curious — is it just me?

Do you also feel this kind of frustration sometimes? Or did you actually manage to find a system that works without turning Jira into a full-time job?

If AI Existed in 2011, Would We Still Have the Modern Web?

Sylwia Laskowska — Wed, 22 Apr 2026 08:04:46 +0000

Imagine it’s 2011. The web is mostly server-rendered PHP templates, maybe a bit of jQuery if you’re feeling fancy, or sometimes no JavaScript at all. Interactivity is limited, everything is a request-response loop, and the idea of complex client-side apps isn’t really mainstream yet. It works, it’s predictable, and honestly… nobody is panicking 😄

Now imagine that into this world, suddenly, we drop modern AI. Not some early experimental models, but something close to what we have today — LLMs, coding agents, tools that generate entire features from prompts. Codex, Claude Code, all that magic. The kind of tools that can scaffold half your app before you even finish your coffee ☕

Quick side note before I continue, because I’m way too excited not to mention this 😄 I’ll be speaking at JSNation 2026, which still feels a bit surreal. It’s one of those conferences where all the big JavaScript minds show up… and apparently also me 😉

Don’t worry though — I won’t bring shame to the DEV community 😅 I’m bringing my talk “Rewrite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks,” which I’ve already tested on stage. If you’re curious, you'll be able to watch it here: https://gitnation.com/badges/jsnation-2026/sylwia_laskowska_154511. And honestly, even if you’re not a frontend dev but you like my articles, you’ll probably enjoy it anyway — it’s basically a “spoken article” 😄

Also, to celebrate, I bought a non-alcoholic beer and somehow woke up feeling like I had a huge hangover. So yes, new achievement unlocked.

So back to the thought experiment. What actually happens next? Do we accelerate into the modern web faster, because suddenly everyone has a superpowered assistant? Or do we get something much less exciting — a world where AI keeps reinforcing what already works and we never quite feel the need to move beyond it?

Because here’s the uncomfortable question: what if AI doesn’t accelerate progress as much as we think… but instead quietly stabilizes it? 👀

AI Is Brilliant — As Long As You Stay on Known Ground

I’m not an AI expert, and I’m not going to pretend I am. I use LLMs daily, I know what RAG is, I understand inference, matrix multiplication, sampling — enough to work with it comfortably. But I never really thought about AI in terms of shaping the direction of technology, not just speeding it up.

That changed when I started working more with WebAssembly and WebGPU. And something became obvious pretty quickly.

LLMs are extremely good at things like Rust, standard frontend work, typical patterns — anything with lots of existing examples. You ask for a simple feature, like downloading an image, and you get clean, idiomatic code almost instantly. It honestly feels like cheating 😄

But the moment you move into newer territory, like WebGPU and WGSL shaders, things start to break down. Mistakes become frequent, assumptions are off, APIs get mixed up. You stop trusting the output and go back to manual coding, debugging everything yourself like it’s 2010 again.

And it’s not because AI is “bad.” It’s because it simply hasn’t seen enough of it. WGSL has only been around since roughly 2021. Compared to decades of web dev patterns, that’s basically nothing.

AI Optimizes for What Exists

This is where the whole thing flips a bit. We like to think AI helps us write better code and make smarter decisions. But in practice, it mostly guides us toward what is most common, most represented, most reinforced by data.

It doesn’t think like a senior engineer. It doesn’t evaluate trade-offs or long-term consequences. It pattern-matches.

That’s why it will often default to React on the frontend — not because it’s always the best choice, but because it’s everywhere. Angular or Vue might be a better fit in some cases, but AI doesn’t “prefer” them. It just hasn’t seen them as much.

If you’re experienced, you catch this and adjust. But if you’re tired, under pressure, or just want to get things done (so… most of us most of the time 😅), you go with what it gives you. It works, it compiles, ship it.

And that’s the subtle shift: AI isn’t just helping you code — it’s quietly influencing how we all code.

From Exploration to Convenience

Before AI, web development was rarely about comfort. It was about pain 😄

PHP templates worked — until they didn’t. We needed interactivity, so we started hacking things with JavaScript. Then jQuery appeared to manage the chaos. Then SPAs happened, because managing state on the client became unavoidable. Frameworks evolved, patterns evolved, everything kept moving forward.

There was always friction. And that friction forced people to think, experiment, and sometimes try things that weren’t yet mainstream.

Now imagine removing most of that friction. You can get a working solution almost instantly, without digging too deep. And when that happens, something subtle shifts. You stop asking “is this the best way?” and start asking “does this already work?”

And once that mindset kicks in, exploration slowly starts to disappear.

Cognitive Miser Meets AI

There’s also a very human factor here. We’re what psychologists call “cognitive misers,” which basically means we avoid unnecessary thinking whenever possible. If there’s an easier path, we take it.

AI is the ultimate easy path — which is exactly why it’s so powerful 😄

But it also creates a feedback loop. AI suggests common solutions, developers implement them, those solutions become even more common, and AI becomes even more confident in suggesting them again.

Breaking out of that loop requires effort. And effort is exactly what we’re trying to avoid when using AI in the first place.

Back to 2011

So let’s go back to that original scenario. You’re a developer in 2011, building a web app. You have access to a powerful AI assistant trained on everything that existed at the time: PHP templates, early JavaScript, server-side rendering patterns.

You ask it how to build a feature, and it gives you a clean, working solution — in PHP. It’s fast, it’s familiar, and it solves your problem.

Would you really push for a completely new paradigm, like client-side apps? Would you experiment with something that doesn’t yet exist, when the current approach already works and is fully supported by your tools?

Or would you just… ship? 😄

If enough people choose to just ship, something interesting happens. Not a dramatic collapse — just a quiet lack of movement.

And suddenly, the future doesn’t get built as quickly as it could have.

The Real Risk

I don’t think AI will replace developers. That’s the obvious discussion, and honestly, the less interesting one.

The more interesting possibility is that AI makes us extremely efficient at continuing in the same direction we’re already going. Not because it’s wrong, but because it’s shaped by the past and optimized around it.

And if we’re not careful, we might start optimizing everything — our tools, our workflows, even our decisions — around what already exists, instead of pushing toward what doesn’t yet.

A Different Perspective

On the other hand… when it comes to innovation, things are accelerating like crazy. New ideas are moving faster than ever. What used to take years now happens in months.

But innovation has always been driven by a relatively small group — the ones exploring new tools and pushing boundaries.

The rest of us?

We sit down every day and work with what’s already there. Stable, supported, well-documented. The kind of stack AI understands really well.

So yes — innovation is speeding up. But at the same time, AI might be making it easier than ever for everyone else to stay exactly where they are.

And that’s exactly why I hope I’m wrong.

So now I’m really curious — what do you think?

If AI had existed in 2011, would we have built the modern web faster… or would we still be comfortably sitting in index.php? 😄

If you made it this far, maybe consider giving me a like or even a follow on
LinkedIn 🙂

I’ll admit — I’m definitely not a LinkedIn master 😄 My reach there isn’t amazing (I usually just post links to my articles, often with a delay xD). But I think I might have an idea for some shorter-form content there…

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://dev.to/sylwia-lask/will-webassembly-kill-javascript-lets-find-out-live-demo-43ln
WebGPU → https://dev.to/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://dev.to/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. 🚀

DEV Community: Sylwia Laskowska

How Are Developers Actually Using AI At Work?

AI Above Everything

From Excitement to Cost Optimization

And Finally, My Own Story

Every Developer Is Lying About Something — And AI Won’t Fix It

Some Developers Lie About Knowing What They’re Doing

Others Lie About Knowing How To Do Something

Someone Else Is Lying About Having Time

Some Developers Lie About How Long Things Will Take

And Some Lie About Knowing Everything Best

People Are Just… People

4 Tiny Mistakes That Secretly Destroy App Performance

1. Custom headers → preflight requests

2. Code splitting that does absolutely nothing

3. Unnecessary runtime dependencies

4. Huge background images

Final thought

I Love Tailwind. Sorry Not Sorry

Pumpkin pie: homemade or store-bought?

Repetition isn’t always a bug

“Messy HTML”

Junior developers and “not learning CSS”

About “craft”

Why I actually like Tailwind

When handcrafted CSS still makes sense

Final thoughts

Is Software Development Just a Side Quest? A Jira Story

If AI Existed in 2011, Would We Still Have the Modern Web?

AI Is Brilliant — As Long As You Stay on Known Ground

AI Optimizes for What Exists

From Exploration to Convenience

Cognitive Miser Meets AI

Back to 2011

The Real Risk

A Different Perspective

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

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`