17 posts tagged with "frontend"

If you've ever worked with React and server-side rendering (SSR), you've almost certainly written this:

const [mounted, setMounted] = useState(false);

useEffect(() => {
  setMounted(true);
}, []);

if (!mounted) return null;

Or this other version, which looks simpler and is worse:

if (typeof window === 'undefined') return null;

Both exist for the same reason: some components simply have nothing to show on the server. They depend on localStorage, on the user's time zone, on the screen size, on a library that touches window. And React never had an official way to say "this one, browser only".

React 19.3, released on September 9, 2026, changed that. Meet browser().

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.