16 posts tagged with "frontend"

Every front-end project using Vitest reaches this question at some point: environment: 'jsdom' or environment: 'happy-dom'?

The answer you usually find is "happy-dom is 2 to 4 times faster". I went looking for where that number comes from and, in most articles, it has no code, no methodology and no versions. So I decided to measure it.

I built a suite with 240 React component tests and ran it in both environments, under different Vitest configurations, several times. I also checked 20 browser APIs and behaviors in both to see what each one actually implements. The result has a surprise: Vitest's configuration matters more than the choice of library.

Every JavaScript developer has a story with Date. The report that showed the previous day. The due date that jumped from January 31 to March 3. The birth date that changed when the user was in another time zone. The 300KB moment installed just to add a month.

Date was created in 1995, in a few days, copied from java.util.Date. Java itself deprecated most of that API shortly afterwards. JavaScript kept it for 30 years.

That's over. In March 2026 Temporal reached Stage 4 at TC39 and became part of ECMAScript 2026. It already runs without flags in Chrome, Edge, Firefox and Node 26.

This article is about what actually got better. With real, running examples, side by side with new Date().

If you follow the React ecosystem closely, you've probably tripped over this announcement this week. Dominic Gannaway launched Octane, described as "the React programming model, compiled". It's the declared successor to Inferno, the framework Gannaway himself built back in 2016 with the same performance pitch.

It's worth pausing to understand two things. First, what it actually does technically. Second, and more important for anyone making stack decisions, what its arrival says about where React is heading.

Anyone who has spent hours chasing an undefined in the middle of a bundle or a strange behavior only in production knows how an unresolved import chain can become a headache. One of the frequent culprits is the circular import: module A imports B, B imports C, and somewhere in the chain someone imports A again — closing a cycle.

It's wonderful — the build works, the project runs locally, but when you try to deploy, it breaks! \o/

I've seen this in small projects and in large ones; the only difference is the size of the problem you'll face. You can spot the headache with Madge and it's a lifesaver!

To lock up TypeScript, a circular import is a treat.

Many people ask me how to organize their studies in technology. There's no single path, but it's possible to think in learning levels that provide clarity and direction.

I've put together a list of items to make studying easier, going from the basics to advanced.

Many people still associate the term frontend only with the visual appearance of a website or application — colors, buttons, layouts.

That famous phrase "it's just a button." But they don't understand what's behind that simple button that triggers multiple actions in the user interface and, in most cases, in other systems via API, for example.

Front-end development is frequently misunderstood. Many people still limit its definition to the purely visual layer — "just put a button there" or "just need to change that color." This misconception underestimates the complexity and impact that architectural decisions have on modern web development.

And with the rise of Vibe Coding, this view can be amplified. Frontend is just HTML and Backend is a bunch of CRUDs.

Those who work with development know that's not how it works. A simple system built in 1 hour that scales? Good luck.