DEV Community: Marie Berezhna

🕵️‍♂️ The Shadow DOM: Power Tool or Pain in the Ass? 🕵️‍♂️

Marie Berezhna — Wed, 28 May 2025 07:00:00 +0000

The Shadow DOM is like the secret room in a house — it’s hidden, self-contained, and not everyone knows how to use it.

On one hand, it’s a magical tool for building components that are encapsulated from the rest of your app. On the other hand, it can make you question your life choices when things go wrong.

Let’s break it down, shall we?

💡 What is the Shadow DOM

The Shadow DOM is a part of the Web Components spec that lets you create encapsulated DOM for your elements. Essentially, you can create a "mini DOM" inside a parent element, and it won’t mess with the global styles or scripts.

For example:

<custom-element>
  <div>Hello, World!</div>
</custom-element>

Inside your <custom-element>, you can create a Shadow DOM like so:

class CustomElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({mode: 'open'});
    shadow.innerHTML = '<style> div { color: blue; }</style><div>Shadow DOM Content</div>';
  }
}
customElements.define('custom-element', CustomElement);

Now, the content inside <custom-element> is completely isolated from the rest of the page’s styles and scripts.

⚡ Power Tool: Benefits of the Shadow DOM

Style Encapsulation:

Styles in the Shadow DOM don’t leak into the global styles, and global styles don’t leak into the Shadow DOM. Perfect for building reusable components without worrying about clashing styles.
DOM Encapsulation:

The Shadow DOM makes sure that the inner structure of your component is hidden and protected. You can access it only via the custom element API. No one outside of your component can easily mess with it.
Web Components:

Shadow DOM is a crucial part of Web Components, allowing for custom elements that can be reused anywhere - in vanilla HTML, frameworks, or even in different apps.
Cleaner Code:

With encapsulation, you can break down complex UIs into isolated chunks, making your codebase cleaner and easier to maintain.

😵 Pain in the Ass: The Challenges of the Shadow DOM

Not All Browsers Are Equal:

Though modern browsers mostly support it, older browsers (looking at you, IE) don’t. If you need compatibility, you're stuck with polyfills, which can add extra weight.
Access Control:

With encapsulation comes separation. You can't easily access styles or DOM elements from the outside, which can be a pain if you need to modify or manipulate them. You need to rely on the public API you’ve defined for your component, or it’s hands off.
JavaScript Bloat:

Web Components can feel a bit heavy for smaller projects. If you’re building a small app, creating custom elements and adding Shadow DOM may feel like overkill.
Debugging Nightmares:

The encapsulation means that debugging styles and DOM can get tricky. If you’re trying to figure out why an element is not behaving like you want, it might be buried in a shadow tree somewhere and harder to inspect.
Event Handling:

Events in the Shadow DOM don’t propagate in the same way as in the regular DOM. You'll need to use event retargeting or listen for events in specific ways, which can add complexity.

💭 So… Should You Use It?

Use the Shadow DOM if:
- You’re building a reusable component that needs to be encapsulated and self-contained.
- You want styling isolation so that global styles don’t mess with your component.
- You’re working with Web Components or building a design system.
Avoid the Shadow DOM if:
- You’re building a small project where you don’t need the complexity.
- You’re facing browser compatibility issues and can’t polyfill.
- You want to access the internals of a component from outside or have tight control over events and styles.

🔑 Conclusion

The Shadow DOM is one of those tools that can supercharge your web development by providing isolation and cleaner components - but only if you’re ready to handle the trade-offs. If used correctly, it can lead to highly maintainable, reusable, and scalable components. If misused, it can lead to confusion, frustrating debugging, and unnecessary complexity.

At the end of the day, it’s all about knowing when to use the Shadow DOM and when to leave it on the shelf.

Import Maps: Why Nobody Talks About Them (But Maybe Should)

Marie Berezhna — Wed, 21 May 2025 06:50:00 +0000

You know what sucks?

Bundling.

Install react → ends up in node_modules/, goes through Vite/Rollup/webpack, gets transpiled, hashed, minified… just so you can write:


import React from 'react';

But what if you didn’t need a bundler at all?

🧩 What Are Import Maps?

Import Maps are a native browser feature (yep, no polyfill needed in modern Chromium) that let you map bare module specifiers to real URLs — directly in the browser.

Here’s the magic:

<script type="importmap">
{
  "imports": {
    "react": "https://esm.sh/react@18",
    "react-dom": "https://esm.sh/react-dom@18"
  }
}
</script>

Now, in your <script type="module">, you can write:

import React from "react";

And the browser knows where to get it, no bundler, no build step, no CDN script tags.

🚀 Why It’s Cool

No build step: Instant dev workflow
No node_modules/: Zero install, zero bloat
Works with CDNs like Skypack, ESM.sh, JSPM
Great for micro frontends, prototypes, and fast loading islands

😬 So… Why Isn’t Everyone Using This?

Not supported in all browsers yet

→ Mostly just Chromium for now. Firefox is dragging. Safari? Radio silence.

(You can polyfill it, but it kills the whole “zero tooling” idea.)
Tooling momentum is too big

→ Everyone already uses Vite, webpack, etc. Import Maps don’t fit the current “npm install + dev server” mindset.
No ecosystem support

→ Most tutorials, libraries, and docs assume you're bundling. Period.

✅ When Should You Use It?

Import Maps shine when you want:

No build tools at all
To prototype quickly
To ship something truly small
To combine multiple micro-apps without a monolith

They’re especially useful with:

Web components
Vanilla JS apps
Islands architecture setups (Astro, Marko, etc.)
JAMstack sites that want dynamic bits without bundling

🧠 Final Thought

Import Maps don’t want to replace your build system.

They’re just saying: "Hey... you might not need one."

They're not mainstream (yet), but they offer a glimpse at a simpler frontend world — one where browsers do more and you ship less.

Worth keeping an eye on.

Client-Side Rendering is Boring Now. What’s Next?

Marie Berezhna — Wed, 14 May 2025 07:40:00 +0000

For years, client-side rendering (CSR) was the cool kid on the block. Angular, React, Vue - they all made CSR the default way to build "modern" web apps. Push your logic to the browser. Fetch your data with fetch(). Sprinkle in some loading states. Boom: single-page app.

But here's the thing: CSR isn't exciting anymore. It's become... standard. Predictable. Even boring.

So, what's next?

CSR Fatigue: We've Seen This Movie Before

Let's be honest: CSR was fun until it wasn't.

Slow first loads?
Flashing spinners everywhere?
SEO hell unless you bolt on SSR later?

Developers got tired of hacking around the same limitations. You'd ship 300KB of JavaScript just to say "Hello, user." You needed hydration, suspense, skeleton UIs - just to mimic server behavior we used to get for free.

Enter: Server-Side is Cool Again

The pendulum swung back. Frameworks started saying, "What if we just... rendered stuff on the server again?" Next.js popularized SSR and hybrid routes. Remix pushed data loading to the edge. Astro said, "No JS unless you ask nicely."

Now we have server components in React, and the frontend world is buzzing again.

Why? Because they simplify everything. No hydration. No client data fetching. Just clean, direct HTML from the server.

Edge Rendering and the CDN Awakening

Forget your origin server. What if your logic runs at the edge, milliseconds from the user?

Cloudflare Workers
Vercel Edge Functions
Deno Deploy

This isn't just ops porn - it's about delivering dynamic content with near-static performance. It's fast, distributed, and ready for personalization without compromising Time to First Byte (TTFB).

The edge is becoming the real backend for modern apps.

Partial Hydration and the Rise of the Island

Instead of rendering your whole app in JS, why not just hydrate the interactive bits?

Astro, Qwik, and Marko are leading the islands architecture renaissance. The concept is simple: most of your page is static. Only hydrate what's interactive. No more bloated bundles. No more rehydrating a giant React tree for a navbar and a button.

It's surgical. Efficient. And way less painful for users.

The Future: Less JavaScript, More Focus

We're done throwing JavaScript at everything like it's glitter. The future is about shipping less:

Less JS to the client
Less logic in the wrong place
Less architecture just to render a blog

Instead, we're building smarter: using the right tool for each piece, rendering closer to the user, leaning into the edge, and thinking in HTML again.

CSR isn't dead - it's just not the only trick in the bag anymore. And honestly? That's a good thing.

Should You Quit Tech? A Reality Check for Burnt Out Devs

Marie Berezhna — Wed, 07 May 2025 07:30:00 +0000

Let’s not sugarcoat it - tech is brutal right now.

The layoffs haven’t stopped. Projects are being killed mid-sprint. Startups are ghosting job offers. People are working more for less and wondering, “Why the hell am I still doing this?”

If you're burnt out, jaded, or secretly Googling “alternative careers for software developers”, you're not alone. But the real question is: should you actually quit tech?

Let’s break it down.

🧠 Burnout Isn’t Always About the Work

Sometimes it’s not coding that’s the problem - it’s everything around it.

Toxic team dynamics? Yeah, that’ll drain your soul faster than any bug in production.
Endless meetings? Welcome to death by calendar.
Poor leadership? Say goodbye to motivation.
Zero impact work? Even a great paycheck feels empty when you're just moving tickets around.

Ask yourself: are you tired of tech, or tired of this job?

📉 The Market Sucks. No Lie.

Let’s be honest: it’s rough out there.

Big Tech is shrinking.
Startups are either frozen or folding.
Junior devs are being told to “build a portfolio” while mid-senior folks are fighting for scraps.

But this is a cycle. The dot-com bubble burst. The 2008 crash happened. And tech came back each time - leaner, yes, but also wiser.

This industry isn’t going away. It's just shedding a layer of excess.

🔁 Staying Doesn’t Mean Staying the Same

You don’t have to quit tech to change your life.

You can:

Switch stacks (maybe you hate frontend but love automation).
Change roles (dev → devrel, QA → PM, engineer → educator).
Go indie (start freelancing, consulting, or shipping your own thing).
Work part-time (yes, that’s allowed).

Sometimes staying in tech just means staying on your terms.

🚪 Okay, But What If You Do Want Out?

That’s valid too. There’s no shame in saying, “I’m done.”

Tech isn’t sacred. If it’s draining you, if the values don’t match, if you're no longer curious - walk away. You can always come back. The skills you’ve built aren’t wasted; they’re portable.

Tech doesn’t define your worth. You do.

🧭 Reality Check: So... Should You Quit?

Here’s a quick gut check:

Ask Yourself	If You Answer Yes...
Am I miserable every day, even on chill projects?	It might be time to move on.
Do I feel stuck and unseen in my current role?	Try switching teams or companies first.
Am I still curious about tech, but just tired?	You're burnt out, not broken. Rest, then reassess.
Is my life outside of work suffering?	That’s a sign to change something now.
Am I staying only because of the money?	Dangerous long-term. Explore your options.

🧩 Final Thought

You’re allowed to quit. You’re allowed to stay. You’re allowed to take a break without explaining yourself to anyone.

Tech will survive without you. But you? You’ve only got one brain, one body, one life. Take care of it first.

🛠️ Ditching Frameworks: How Far Can You Get with Just the Platform?

Marie Berezhna — Wed, 30 Apr 2025 07:05:00 +0000

Frontend frameworks are great - until they’re not.

React, Vue, Svelte, Solid... they’re powerful, but also heavy, complex, and full of abstraction. What if you just said “no” to all of it?

What if you went framework-free?

🧪 What Is "the Platform"?

When people say “just use the platform,” they mean:

HTML
CSS
JavaScript (vanilla, not bundler-fried)
Web APIs like fetch(), FormData, URLSearchParams, localStorage, etc.
Native browser features like <dialog>, <details>, and <form> (yes, it still works)

It’s everything your browser gives you out of the box. And spoiler: it's a lot more than you think.

💡 What Can You Actually Build?

Surprisingly... a lot.

Static sites? Easy. Just use HTML + CSS.
Blogs? Markdown + a build script. No need for a JS runtime.
Forms? Native HTML + progressive enhancement.
APIs? Call them with fetch(), render with innerHTML.
Stateful UIs? EventListener, dataset, classList.toggle(). That’s it.

Unless you’re building a single-page app with dynamic routing, real-time updates, and client-side caching, you might not need a framework.

🧨 Why Bother?

Because:

Your bundle size drops to zero.
No dependencies = no supply chain drama.
No framework = no updates, no breaking changes.
It’s fast. Stupid fast.
You relearn how the web actually works.

The platform is getting better all the time. Modern HTML is not your grandpa’s <table>-ridden nightmare. Native forms, popovers, animations, and even transitions are finally decent.

🧱 Where It Starts to Hurt

Let’s be real, going raw has its limits:

No routing.
No component model (unless you write your own or use Web Components).
State management? Manual.
DX? Brutal. You’ll miss hot reloading, error overlays, dev tools.

For anything complex or long-lived, you’ll start reinventing wheels fast. That’s when a micro-library or lightweight tool makes sense (think: htmx, Alpine.js, Lit, Petite Vue, etc).

✅ So… How Far Can You Really Get?

Pretty damn far - if you design around the platform, not against it.

The sweet spot:

Content-heavy pages
Forms and interactions
Small apps that don’t justify React

You’ll write less, ship less, debug less, and load way faster.

Frameworks are tools. Not laws of nature. Sometimes the best dev experience… is just the browser.

Are Web Components Making a Comeback?

Marie Berezhna — Wed, 23 Apr 2025 07:45:00 +0000

Sort of - but don't call it a comeback just yet. Web Components are definitely on the rise again, but they're still not the go-to solution for most developers. That said, they're quietly powering some big things behind the scenes.

What Are Web Components?

They're built-in browser features that let you make your own HTML elements. No frameworks. Just standard APIs:

Custom Elements - your own HTML tags like
Shadow DOM - scoped styles and structure so your component doesn't leak or get messed with
HTML Templates - chunks of HTML you can reuse and render when needed

Why Are People Talking About Them Again?

✅ Browsers Finally Got Their Act TogetherNo more polyfills or hacks. Web Components now work out-of-the-box on all major browsers, including Safari (yes, even Safari).
✅ Everyone's Tired of Framework WhiplashReact today, Svelte tomorrow, Solid next week? Some devs just want stable, long-term tools that don't change every 6 months. Web Components offer that.
✅ Framework-Agnostic FTWUse them in React, Vue, Angular, plain HTML - whatever. That makes them perfect for design systems or teams working with multiple stacks.
✅ Tools Are Making Life EasierWriting raw Web Components kinda sucks. But tools like Lit, Stencil, and SkateJS smooth the rough edges, so you don't have to fight the browser API.

Why Most Devs Still Ignore Them

The syntax without a library is ugly
Ecosystem is smaller compared to React or Vue
Learning curve for concepts like Shadow DOM
Less community support and fewer prebuilt components

Should You Use Web Components?

Go for it if:

You're building a design system or UI library that needs to work everywhere
You want future-proof, native tech
You like modular, encapsulated components

Maybe skip if:

Your team is already deep in a React/Vue ecosystem
You need rapid prototyping with lots of off-the-shelf components

Bottom Line

Web Components aren't the hot new thing - but they're solid, native, and finally practical. They're carving out a niche in real projects, especially where portability and long-term stability matter.

Not trendy, but definitely useful - and finally getting some well-deserved respect.

What Are Vanilla JS Modules?

Marie Berezhna — Wed, 16 Apr 2025 07:30:00 +0000

Vanilla JS just means plain JavaScript, without any frameworks or libraries like React, Vue, or jQuery. So, when we talk about Vanilla JS modules, we’re talking about using JavaScript's built-in module system, introduced with ES6 (ECMAScript 2015).

Why Use Modules?

Modules help you:

Organize code into reusable, manageable chunks
Avoid polluting the global scope (no more mysterious variable collisions)
Split responsibilities (e.g., one file handles DOM, another handles data)

The Basics

Vanilla JS modules are just .js files where you export and import things.

1. Exporting

You can export functions, variables, classes, etc.

// mathUtils.js
export function add(x, y) {
  return x + y;
}

export const PI = 3.14;

Or export everything at once:

// mathUtils.js
function subtract(x, y) {
  return x - y;
}

function multiply(x, y) {
  return x * y;
}

export { subtract, multiply };

Yu can also have one default export:

// greet.js
export default function greet(name) {
  console.log(`Hello, ${name}!`);
}

2. Importing

Now you bring that module into another file:

// main.js
import { add, PI } from './mathUtils.js';
import greet from './greet.js';

console.log(add(2, 3)); // 5
console.log(PI);        // 3.14
greet('Marie');         // Hello, Marie!

A Few Gotchas

You must run modules through a server (localhost or real server). They won’t work if opened directly via file://
Use the type="module" attribute in your HTML:

<script type="module" src="main.js"></script>

Modules are deferred by default, so they wait for the HTML to load

Why Not Just Use Script Tags?

Because:

Modules help you split code cleanly
Let you import only what you need
Are more scalable for bigger projects

TL;DR

Vanilla JS modules = using the native import/export syntax to structure code. They’re clean, powerful, and don’t require any external tools — just the browser.

Do We Really Need Frameworks for Frontend Development?

Marie Berezhna — Wed, 09 Apr 2025 12:09:12 +0000

Let’s get one thing straight: JavaScript frameworks didn’t fall from the sky as divine gifts. They were born out of real pain - DOM manipulation hell, inconsistent browser behavior, spaghetti code that turned into a monster by the time a project hit version 1.3. So yeah, frameworks solve problems. But the question we should be asking in 2025 is: Do we still need them? Or at least, do we need them this much?

The Case for Frameworks

Let’s start with the obvious: React, Vue, Svelte, Angular - they streamline state management, UI rendering, componentization, routing, and developer experience in general. You get a nice abstraction layer, ecosystem support, and a community big enough to drown in Stack Overflow answers and open source goodies.

Using a framework means faster development, fewer bugs (hopefully), and easier collaboration in teams. Plus, if you hire a new dev, odds are they already know React or Vue. No onboarding nightmare.

But Let’s Be Honest…

Do you really need all that firepower just to build a landing page? Or even a simple dashboard?

Look at modern vanilla JS. Look at how much better native APIs have gotten - querySelector, fetch, Web Components, modules, and even lit-html. CSS has grown up too. We’re not stuck in the jQuery-era anymore. You can build beautiful, dynamic interfaces with just native tools and a bit of structure.

Frameworks also bring bloat. Performance gets hit hard - bundle sizes balloon fast. Then there’s the issue of lock-in. Frameworks evolve, APIs break, and suddenly you’re rewriting half your app because Vue 4 or React 19 changed something fundamental.

The Alternative: Lean and Native

What if you went barebones? Built your app with:

Vanilla JS modules
Web Components (which are finally usable, by the way)
Lightweight libraries (Alpine.js, HTMX, Lit, etc.)
Progressive enhancement instead of full-blown SPA magic

You’d have more control. Less abstraction. Better understanding of your stack. Debugging becomes easier because you don’t have to mentally reverse-engineer some framework’s virtual DOM algorithm.

So… Do We Need Frameworks?

It depends. (Yeah, the classic dev answer.)

Building a large, complex web app with multiple contributors? A framework helps keep the chaos in check.
Building a fast, simple site or something experimental? Skip the framework and enjoy the minimalism.
Want to learn how the web actually works? Ditch the training wheels for a bit.

The point is: we’ve gotten so used to reaching for React without thinking, we’ve forgotten how powerful the native platform has become. Maybe it’s time to pause and ask: Do I need a framework - or am I using one out of habit?

History of JavaScript: The Big Picture

Marie Berezhna — Wed, 26 Mar 2025 13:44:11 +0000

JavaScript is one of the most influential programming languages in the world, playing a crucial role in web development. Its journey from a hastily developed scripting language to the backbone of modern web applications is remarkable. Let’s take a look at the big picture of JavaScript’s history, its evolution, and its impact on the tech world.

The Birth of JavaScript (1995)

In 1995, Brendan Eich, a programmer at Netscape Communications, created JavaScript in just 10 days. Initially called Mocha, then renamed to LiveScript, and finally JavaScript (as a marketing strategy to ride on Java’s popularity), it was designed to make web pages interactive. JavaScript was first introduced in Netscape Navigator 2.0, allowing developers to add simple functionalities such as form validation and animations.

The Standardization (1997)

To ensure consistency across different browsers, JavaScript was submitted to ECMA International for standardization. This led to the creation of ECMAScript (ES), with the first version, ES1, released in 1997. This standardization process ensured that JavaScript would remain a stable and widely adopted technology.

The Browser Wars and jQuery (Early 2000s)

During the late 1990s and early 2000s, browsers like Internet Explorer and Netscape had their own versions of JavaScript, leading to inconsistencies. To address these challenges, developers relied on libraries like jQuery, introduced in 2006, which simplified JavaScript usage and improved cross-browser compatibility.

The Rise of Modern JavaScript (2009 - Present)

JavaScript's major transformation began with ECMAScript 5 (ES5) in 2009, which introduced essential features like strict mode and JSON support.

However, the most significant leap came with ECMAScript 6 (ES6) in 2015, bringing features like let/const, arrow functions, template literals, destructuring, modules, default parameters, promises, and classes, making JavaScript more powerful and developer-friendly.

ES6 revolutionized JavaScript by introducing syntactic sugar and improvements that made code more readable, maintainable, and efficient. The introduction of the import/export module system allowed developers to write modular code, while the spread/rest operators enhanced flexibility in handling function arguments and arrays. Additionally, the adoption of promises and async/await significantly improved asynchronous programming, reducing callback hell.

The rise of front-end frameworks like AngularJS (2010), React (2013), and Vue.js (2014) further cemented JavaScript’s role in modern web applications. Additionally, the introduction of Node.js in 2009 allowed JavaScript to be used for backend development, transforming it into a full-stack language.

JavaScript Today and Beyond

Today, JavaScript powers everything from web applications and mobile apps to server-side development and even AI projects. The ecosystem continues to grow with tools like TypeScript, WebAssembly, and advanced frameworks like Next.js. With continuous improvements and widespread adoption, JavaScript remains an essential part of the digital world.

Conclusion

From a simple scripting language to a fundamental technology shaping the internet, JavaScript’s journey has been extraordinary. Its flexibility, constant evolution, and widespread use ensure that it will remain a cornerstone of web development for years to come.

Next.js Development: Key Differences Between App Router and Pages Router

Marie Berezhna — Tue, 18 Mar 2025 14:21:13 +0000

Next.js has evolved significantly over the years, with the introduction of the App Router in version 13 representing one of its most substantial architectural shifts. Let's explore the key differences between the traditional Pages Router and the newer App Router approaches to help you understand which might be better suited for your projects.

Fundamental Architecture

Pages Router

The Pages Router uses a file-system based routing approach where each file in the /pages directory automatically becomes a route. This has been Next.js's original approach since its inception.

For example, a file at /pages/products/[id].tsx would create a dynamic route that matches paths like /products/1, /products/2, etc. The routing is straightforward and intuitive for developers coming from other frameworks.

App Router

The App Router, introduced in Next.js 13, uses a more complex but powerful /app directory structure. Rather than individual files representing routes, the App Router uses folders to define routes, with special files like page.tsx, layout.tsx, and loading.tsx serving specific purposes within each route segment.

This folder-based approach allows for nested layouts and more granular control over how your application renders and loads.

Component Model

Pages Router

In the Pages Router, components are primarily class or function components that export a default React component. Data fetching methods like getStaticProps, getServerSideProps, and getInitialProps are separate exported functions from the same file:

// pages/products.tsx
import { GetServerSideProps } from 'next';

interface Product {
  id: number;
  name: string;
}

interface ProductsProps {
  products: Product[];
}

export default function Products({ products }: ProductsProps) {
  return (
    <div>
      {products.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
}

export const getServerSideProps: GetServerSideProps<ProductsProps> = async () => {
  const res = await fetch('https://api.example.com/products');
  const products: Product[] = await res.json();

  return {
    props: { products }
  };
}

App Router

The App Router introduces Server Components as the default, allowing components to run on the server with direct access to resources like databases. This eliminates the need for separate data fetching methods:

// app/products/page.tsx
interface Product {
  id: number;
  name: string;
}

async function getProducts(): Promise<Product[]> {
  const res = await fetch('https://api.example.com/products');
  return res.json();
}

export default async function Products() {
  const products = await getProducts();

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
}

Notice how the component itself can be async, and we directly await data inside the component. This represents a fundamental shift in how components work and interact with data.

Data Fetching

Pages Router

The Pages Router uses specific functions exported alongside your components:

getStaticProps: For static generation at build time
getServerSideProps: For server-side rendering on each request
getInitialProps: The older approach for either client or server rendering

These functions run at build time or request time depending on which one you choose, with data passed to your component as props.

// pages/post/[id].tsx
import { GetStaticProps, GetStaticPaths } from 'next';

interface Post {
  id: string;
  title: string;
  content: string;
}

interface PostProps {
  post: Post;
}

export default function Post({ post }: PostProps) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

export const getStaticPaths: GetStaticPaths = async () => {
  const res = await fetch('https://api.example.com/posts');
  const posts: Post[] = await res.json();

  const paths = posts.map(post => ({
    params: { id: post.id.toString() }
  }));

  return { paths, fallback: 'blocking' };
}

export const getStaticProps: GetStaticProps<PostProps> = async ({ params }) => {
  const res = await fetch(`https://api.example.com/posts/${params?.id}`);
  const post: Post = await res.json();

  return {
    props: { post },
    revalidate: 60 // Regenerate page every 60 seconds
  };
}

App Router

The App Router simplifies this model with:

Direct fetch calls within Server Components with built-in caching and revalidation
No need for separate exported functions
More granular control over caching behavior per request

For example:

// app/posts/[id]/page.tsx
interface Post {
  id: string;
  title: string;
  content: string;
}

async function getPost(id: string): Promise<Post> {
  const res = await fetch(`https://api.example.com/posts/${id}`, {
    next: { revalidate: 60 }
  });

  if (!res.ok) {
    throw new Error('Failed to fetch post');
  }

  return res.json();
}

export default async function PostPage({ params }: { params: { id: string } }) {
  const post = await getPost(params.id);

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

// Generate static parameters for common paths
export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then(res =>
    res.json()
  );

  return posts.map((post: Post) => ({
    id: post.id.toString(),
  }));
}

The caching behavior is defined directly with the fetch call, making it more intuitive and reducing the cognitive load of understanding separate data fetching functions.

Layouts and Nested Routes

Pages Router

In the Pages Router, layouts are handled through component composition. You typically create a layout component and wrap your page components with it:

// components/Layout.tsx
import React, { ReactNode } from 'react';

interface LayoutProps {
  children: ReactNode;
}

export default function Layout({ children }: LayoutProps) {
  return (
    <div>
      <header>My Site</header>
      <main>{children}</main>
      <footer>Copyright 2025</footer>
    </div>
  );
}

// pages/about.tsx
import Layout from '../components/Layout';

export default function About() {
  return (
    <Layout>
      <h1>About Us</h1>
      <p>This is the about page</p>
    </Layout>
  );
}

This approach works but requires you to manually include the Layout in every page component.

App Router

The App Router takes a more structured approach with dedicated layout.tsx files that automatically wrap all child routes:

// app/layout.tsx
import { ReactNode } from 'react';

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body>
        <header>My Site</header>
        <main>{children}</main>
        <footer>Copyright 2025</footer>
      </body>
    </html>
  );
}

// app/about/page.tsx
export default function About() {
  return (
    <>
      <h1>About Us</h1>
      <p>This is the about page</p>
    </>
  );
}

Layouts can be nested within folders to create more complex layout hierarchies without needing to manage them manually in each component.

Loading States and Error Handling

Pages Router

Loading states and error handling in the Pages Router typically require manual implementation using React state:

// pages/products.tsx
import { useState, useEffect } from 'react';

interface Product {
  id: number;
  name: string;
}

export default function Products() {
  const [products, setProducts] = useState<Product[]>([]);
  const [loading, setLoading] = useState<boolean>(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    fetch('/api/products')
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch');
        return res.json();
      })
      .then((data: Product[]) => {
        setProducts(data);
        setLoading(false);
      })
      .catch(err => {
        setError(err);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
}

App Router

The App Router introduces specialized files for loading states (loading.tsx) and error handling (error.tsx):

// app/products/loading.tsx
export default function Loading() {
  return <div>Loading products...</div>;
}

// app/products/error.tsx
'use client';

import { useEffect } from 'react';

interface ErrorComponentProps {
  error: Error;
  reset: () => void;
}

export default function Error({ error, reset }: ErrorComponentProps) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error(error);
  }, [error]);

  return (
    <div>
      <h2>Something went wrong loading products!</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

// app/products/page.tsx
interface Product {
  id: number;
  name: string;
}

async function getProducts(): Promise<Product[]> {
  const res = await fetch('https://api.example.com/products');
  if (!res.ok) throw new Error('Failed to fetch products');
  return res.json();
}

export default async function Products() {
  const products = await getProducts();

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
}

This approach automatically renders the loading state while the page loads and the error component if an error occurs, without needing to handle those states in every component.

Route Handlers (API Routes)

Pages Router

In the Pages Router, API routes are defined in the /pages/api directory:

// pages/api/products.ts
import type { NextApiRequest, NextApiResponse } from 'next';

interface Product {
  id: number;
  name: string;
}

export default function handler(
  req: NextApiRequest,
  res: NextApiResponse<Product[] | { message: string }>
) {
  if (req.method === 'GET') {
    const products: Product[] = [
      { id: 1, name: 'Product 1' },
      { id: 2, name: 'Product 2' }
    ];
    res.status(200).json(products);
  } else {
    res.status(405).json({ message: 'Method Not Allowed' });
  }
}

App Router

The App Router moves API routes to a route.ts file using a more modern approach:

// app/api/products/route.ts
import { NextResponse } from 'next/server';

interface Product {
  id: number;
  name: string;
}

export async function GET() {
  const products: Product[] = [
    { id: 1, name: 'Product 1' },
    { id: 2, name: 'Product 2' }
  ];

  return NextResponse.json(products);
}

export async function POST(request: Request) {
  const body: Product = await request.json();

  // Process the data
  console.log('Received product:', body);

  return NextResponse.json(
    { message: 'Product created', product: body },
    { status: 201 }
  );
}

This approach uses the standard Web Response API rather than the Express-like request/response model, making it more aligned with web standards.

Client-Side Navigation

Pages Router

The Pages Router uses <Link> components for client-side navigation, but requires manually prefetching routes:

// components/Navigation.tsx
import Link from 'next/link';

export default function Navigation() {
  return (
    <nav>
      <Link href="/" prefetch={true}>Home</Link>
      <Link href="/about" prefetch={false}>About</Link>
    </nav>
  );
}

App Router

The App Router still uses the <Link> component but handles prefetching more intelligently by default:

// app/components/Navigation.tsx
import Link from 'next/link';

export default function Navigation() {
  return (
    <nav>
      <Link href="/">Home</Link>
      <Link href="/about">About</Link>
    </nav>
  );
}

Prefetching happens automatically for links in the viewport, optimizing for performance without requiring explicit configuration.

Server vs. Client Components

Pages Router

All components in the Pages Router are client components by default, meaning they run on both the server (for initial render) and the client (for interactions and updates).

App Router

The App Router introduces a distinction between Server Components (default) and Client Components (opt-in):

// app/server-component/page.tsx
// This is a Server Component (default)
interface DataType {
  title: string;
}

export default async function ServerComponent() {
  const data = await fetch('https://api.example.com/data');
  const result: DataType = await data.json();

  return <div>{result.title}</div>;
}

// app/components/counter.tsx
// This is a Client Component (opt-in)
'use client';

import { useState } from 'react';

export default function ClientComponent() {
  const [count, setCount] = useState<number>(0);

  return (
    <button
      onClick={() => setCount(count + 1)}
      className="px-4 py-2 bg-blue-500 text-white rounded"
    >
      Count: {count}
    </button>
  );
}

This distinction allows for more optimized rendering and better performance by keeping as much as possible on the server.

Conclusion

The shift from Pages Router to App Router represents Next.js's evolution toward a more structured, performance-focused framework. While the Pages Router offers simplicity and familiarity, the App Router provides more powerful features like nested layouts, server components, and simplified data fetching.

Next.js Router Comparison Table

Feature	Pages Router	App Router
Directory Structure	`/pages` directory with each file representing a route	`/app` directory with folders defining routes and special files (`page.tsx`, `layout.tsx`, etc.)
Component Model	Client components by default	Server components by default, client components opt-in with `'use client'` directive
Data Fetching	Separate functions (`getStaticProps`, `getServerSideProps`)	Direct `fetch` calls with built-in caching inside components
Layouts	Manual composition through component wrapping	Automatic through `layout.tsx` files with nested inheritance
Loading States	Manual implementation with React state	Automatic with `loading.tsx` files
Error Handling	Manual try-catch blocks	Automatic with `error.tsx` files
API Routes	`/pages/api` with `req`/`res` pattern	`/app/api` with HTTP method exports (`GET`, `POST`)
Route Handlers	Express-like pattern with `req`/`res`	Web standard Response API
Client Navigation	Manual prefetching configuration	Intelligent automatic prefetching
TypeScript Support	Built-in, but requires manual type annotations	Built-in with better type inference for routes
Performance	Good, but requires manual optimization	Better by default due to server components
Parallel Routes	Not supported	Supported via folder naming convention
Intercepting Routes	Not supported	Supported via special naming convention
Metadata	Requires manual `<Head>` component	Built-in `metadata` object or `generateMetadata` function
Streaming	Limited support	First-class support with streaming SSR
Coexistence	Can exist alongside App Router	Can exist alongside Pages Router

For new projects, the App Router is generally recommended as it represents the future direction of Next.js. For existing projects, migration can be gradual as both routers can coexist in the same application.

The App Router offers several advantages:

Better performance through automatic optimizations
More intuitive API design aligned with modern web standards
Reduced boilerplate code for common patterns
Enhanced TypeScript support with better type inference
Improved developer experience with more granular control

However, the Pages Router still has its place, especially for:

Existing projects where migration costs may be significant
Simpler applications that don't need the advanced features
Developers more comfortable with the traditional React patterns
Projects using libraries that haven't been updated for Server Components

Understanding these key differences will help you make informed decisions about which approach to use for your Next.js applications and how to best leverage the framework's capabilities.

Separation of Concerns: A Fundamental Principle in Software Development

Marie Berezhna — Tue, 11 Mar 2025 13:31:06 +0000

Introduction

In software development, complexity is a constant challenge. As systems grow, maintaining, scaling, and debugging them becomes increasingly difficult. The Separation of Concerns (SoC) principle is a powerful approach that helps developers manage this complexity by dividing software into distinct, independent parts, each responsible for a specific aspect of the system. This article explores SoC, its benefits, practical implementations, and how it enhances software design.

What is Separation of Concerns?

Separation of Concerns is a design principle that advocates for breaking a software system into distinct sections, where each section handles a separate concern. A concern refers to a specific functionality or responsibility within a system, such as data management, user interface, or business logic.

By isolating different concerns, developers can work on individual components without affecting others, leading to more maintainable and scalable software.

Benefits of Separation of Concerns

Improved Maintainability – Changes to one part of the system do not ripple through unrelated areas, making updates and debugging easier.
Better Code Reusability – Components designed for a specific concern can be reused across different parts of an application or even in different projects.
Enhanced Readability and Organization – Structuring code around concerns makes it easier to understand and navigate.
Scalability and Flexibility – With well-separated concerns, individual components can be modified, replaced, or scaled independently.

Real-World Applications of SoC

1. Model-View-Controller (MVC) Architecture

MVC is a classic example of SoC in action:

Model: Handles data and business logic.
View: Manages the presentation and UI.
Controller: Acts as an intermediary, processing user input and updating the Model or View accordingly.

By separating these three concerns, developers can modify UI elements without affecting data logic and vice versa.

2. Layered Architecture in Web Applications

Most web applications follow a multi-layered architecture, such as:

Presentation Layer: Handles the UI and user interaction.
Business Logic Layer: Processes application rules and data handling.
Data Access Layer: Communicates with the database.

Each layer is responsible for a specific concern, making the system modular and easier to manage.

3. Microservices Architecture

In microservices, each service is designed to handle a single concern, such as authentication, payments, or notifications. This approach allows teams to develop, deploy, and scale services independently, fostering flexibility and efficiency.

Best Practices for Implementing SoC

Use modular design: Break software into independent modules with clear boundaries.
Follow design patterns: Patterns like MVC, Repository Pattern, and Dependency Injection promote SoC.
Leverage frameworks and tools: Many modern frameworks enforce SoC principles, such as Angular (with components and services) or Spring Boot (with layered architecture).
Document concerns clearly: Maintain clear documentation and architectural diagrams to ensure a shared understanding of different concerns in a system.

Conclusion

Separation of Concerns is a foundational principle in software development that leads to cleaner, more scalable, and maintainable code. Whether using architectural patterns like MVC, layered designs, or microservices, applying SoC improves software quality and efficiency. By keeping concerns well-defined and isolated, developers can build robust and adaptable systems, ready to meet future demands with ease.

Understanding JSX in React: History, Features, and Examples

Marie Berezhna — Wed, 05 Mar 2025 20:16:29 +0000

Introduction

JSX (JavaScript XML) is a syntax extension for JavaScript used in React to describe the UI structure in a way that resembles HTML. It simplifies writing and understanding React components by allowing developers to write declarative UI code inside JavaScript.

History of JSX

JSX was introduced with React by Facebook in 2013 as a way to simplify UI development. Before JSX, React components were created using the React.createElement function, which was cumbersome and less readable. JSX emerged as a solution to provide a more intuitive way to describe UI components while still leveraging JavaScript's power.

Early React without JSX

Before JSX, React components looked like this:

const element = React.createElement('h1', null, 'Hello, world!');
ReactDOM.render(element, document.getElementById('root'));

While functional, this approach was not very readable for complex UI structures.

Introduction of JSX

With JSX, the same component can be written as:

const element = <h1>Hello, world!</h1>;
ReactDOM.render(element, document.getElementById('root'));

This makes the code more readable and intuitive, especially for developers familiar with HTML.

How JSX Works

JSX is not understood by browsers directly. It gets compiled by Babel into regular JavaScript before execution. For example, the JSX code:

const element = <h1>Hello, world!</h1>;

is transformed into:

const element = React.createElement("h1", null, "Hello, world!");

This means JSX is just syntactic sugar for React.createElement calls, making it easier to write and maintain UI code.

Key Features of JSX

1. Embedding JavaScript Expressions

JSX allows embedding JavaScript expressions inside curly braces {}.

const name = "Marie";
const greeting = <h1>Hello, {name}!</h1>;

2. Using Components

JSX allows you to use custom React components like HTML elements.

function Greeting() {
  return <h1>Welcome to React!</h1>;
}
const element = <Greeting />;

3. Adding Attributes

JSX attributes follow camelCase naming conventions.

const image = <img src="image.jpg" alt="Sample Image" />;

4. Conditional Rendering

JSX allows conditions using ternary operators.

const isLoggedIn = true;
const message = <h1>{isLoggedIn ? "Welcome back!" : "Please sign in"}</h1>;

5. Handling Events

JSX allows event handlers similar to regular HTML but in camelCase.

function handleClick() {
  alert("Button clicked!");
}
const button = <button onClick={handleClick}>Click Me</button>;

6. Lists and Keys

JSX allows rendering lists dynamically using map.

const items = ['Apple', 'Banana', 'Cherry'];
const list = (
  <ul>
    {items.map((item, index) => <li key={index}>{item}</li>)}
  </ul>
);

Why Use JSX?

Improves Readability: Writing UI in JSX is more intuitive than using React.createElement.
Prevents XSS Attacks: JSX escapes expressions by default, preventing security vulnerabilities.
Better Developer Experience: Helps developers quickly visualize UI structure.

Conclusion

JSX is a core part of React that enhances the way developers create UI components. While it looks like HTML, it is actually JavaScript that gets transformed before execution. Understanding JSX is essential for building React applications efficiently.