DEV Community: Mía Salazar

From Zero to Hero in TypeScript

Mía Salazar — Sat, 20 Jun 2026 08:55:48 +0000

TypeScript has become the go-to language for writing scalable, safer JavaScript in large applications. With its powerful static typing and developer tooling, it allows you to catch bugs earlier and write more expressive code.

This guide walks you through the journey, starting from the very basics and gradually moving toward intermediate and advanced TypeScript concepts.

What is TypeScript?

TypeScript is a superset of JavaScript that adds static typing. It compiles down to plain JavaScript, but offers better tooling, type safety, and developer confidence.

The Basics: Understanding the Type System

The basic types of Typescript are:

number: whole and floating numbers
boolean:true or false values
string: text values
symbol: globally unique identifier.
bigint: whole numbers allowing larger negative and positive numbers than the standard number type.

Type Annotations

let name: string = "Alice";
let age: number = 30;
let isOnline: boolean = true;

Any
any disables type checking and allows all types.

let name: any = true;
name = "Taylor"; 
Math.round(name);

Arrays and Objects

let fruits: string[] = ["apple", "banana"];

let user: { name: string; age: number } = {
  name: "Bob",
  age: 25
};

Functions

function greet(name: string): string {
  return `Hello, ${name}`;
}

void
void indicates that a function doesn't return any value.

function someFunction(): void {
  console.log('This is an article');
}

Intermediate Features: Making Your Types Smarter

Type Aliases and Interfaces
Interfaces and type aliases are similar, but interfaces are generally used for objects and support declaration merging.

type User = {
  id: number;
  username: string;
};

interface Product {
  id: number;
  title: string;
  price: number;
}

Optional and Readonly Properties

interface Config {
  url: string;
  timeout?: number; // optional
  readonly port: number;
}

Enum

enum Direction {
  Up,
  Down,
  Left,
  Right
}

Tuples
A tuple is an array with a pre-defined types and length.

let tuple: [string, boolean, number];
tuple = ['hello", true, 22];

Literal Types & Narrowing
Literal types allow you to specify the exact value a variable can hold.

function handleEvent(event: "click" | "scroll") {}

Union and Intersection Types
Union types let a variable be one of several types, while intersection types combine multiple types into one that must satisfy all of them.

type UserState = { status: "success" | "error" | "loading" };
type WithTimestamp = { timestamp: number };

type LogEntry = UserState & WithTimestamp; 
// Ahora LogEntry tiene tanto 'status' como 'timestamp'

Advanced & Practical Techniques

Generics
Generics allow you to write reusable code with type flexibility

function identity<T>(value: T): T {
  return value;
}

const num = identity<number>(42);
const str = identity("hello");

Utility Types
TypeScript provides built-in utilities like

type Partial<T>       // Makes all properties optional
type Pick<T, K>       // Picks a subset of properties
type Record<K, T>     // Builds object types from keys and values
type Exclude<T, U>    // Removes a type from a union

Discriminated Unions
Useful for handling different types with shared structure

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; size: number };

Type Guards

function isString(value: unknown): value is string {
  return typeof value === "string";
}

Casting with as
as informs the compiler to treat a variable as a specific type, without altering the actual runtime object.

type User = {
  name: string;
  age: number;
};

const data = {
  name: "Alice",
  age: 30,
  role: "admin"
};

const user = data as User;

Tips & Best Practices

Prefer type for aliases and primitives, and interface for object shapes and components.
Don’t overuse any, it defeats the purpose of TypeScript.
Use unknown instead of any when input type is truly uncertain.
Let the compiler infer where possible, but annotate for clarity in APIs.

Conclusion

TypeScript offers a powerful type system on top of JavaScript that makes your codebase safer, clearer, and more maintainable. By starting with the basics and gradually adopting more advanced features like generics, utility types, and type guards, you’ll gain confidence in architecting scalable front-end and back-end solutions.

Accesibilidad y neurodivergencia: no todo el mundo navega igual

Mía Salazar — Sun, 07 Jun 2026 17:47:40 +0000

Fuentes y referencias de la charla

Después de la charla que di para la Commit Conf titulada "Accesibilidad y neurodivergencia: no todo el mundo navega igual", varias personas me pidieron las referencias y artículos que utilicé para preparar la sesión sobre accesibilidad y neurodivergencia.

Aquí dejo una recopilación de estudios, artículos, guías y recursos que me ayudaron a construir la charla. He añadido una pequeña explicación de cada uno por si alguien quiere profundizar en un tema concreto.

Neurodivergencia y diversidad cognitiva

https://imk.global/que-es-la-neurodivergencia-esto-es-lo-que-necesitas-saber/
Introducción sencilla al concepto de neurodivergencia y cómo afecta a la vida cotidiana.
https://thendalliance.org/what-is-neurodiversity/
Explica la neurodiversidad desde una perspectiva social y de inclusión.
https://www.ags-psicologosmadrid.com/ansiedad/neurodivergencia-que-es-tipos-causas-e-impacto-en-la-vida-cotidiana/
Un resumen bastante completo sobre tipos de neurodivergencia y su impacto diario.
https://neuroqueer.com/neurodiversity-terms-and-definitions/
Glosario muy útil para entender terminología relacionada con neurodiversidad.
https://viqu.co.uk/news/neurodiversity-in-tech/
Reflexiona sobre cómo la industria tecnológica se adapta (o no) a personas neurodivergentes.
https://www.techtalentcharter.co.uk/wp-content/uploads/diversity-in-tech-report-2024.pdf
Informe sobre diversidad en tecnología y representación neurodivergente.

Autismo, TDAH y procesamiento sensorial

https://www.cdc.gov/autism/data-research/index.html
Datos y estadísticas oficiales sobre autismo.
https://riseupforautism.com/es/blog/autism-obsessions
Explica intereses intensos y patrones comunes en personas autistas.
https://autism.org/auditory-processing-asd/
Relación entre autismo y dificultades de procesamiento auditivo.
https://add.org/adhd-and-auditory-processing/
Cómo el TDAH puede afectar al procesamiento de sonidos e instrucciones.
https://add.org/sensory-overload-adhd/
Introducción a la sobrecarga sensorial en personas con TDAH.
https://www.getinflow.io/post/accident-prone-clumsy-adhd-cause
Habla sobre torpeza motora y coordinación en personas con TDAH.
https://gam-medical.es/el-stimming-para-regular-el-tdah/
Explica el stimming como mecanismo de regulación emocional y sensorial.
https://www.autismparentingmagazine.com/is-it-oversharing-or-autism/?srsltid=AfmBOoqBQ0GZ95kXhfzsUeNroWYSSAM00KYv7WPT5u4I-r_ksNU3pHqa
Analiza por qué algunas personas autistas pueden compartir información de forma diferente.
https://www.understood.org/es-mx/articles/adhd-and-oversharing-what-you-need-to-know
Relaciona impulsividad y oversharing en personas con TDAH.
https://blog.dyslexia.com/auditory-processing-disorientation/
Conexión entre dislexia y dificultades de procesamiento auditivo.
https://www.calmclinic.com/anxiety/symptoms/hypersensitivity-to-sound
Cómo la ansiedad puede aumentar la sensibilidad al sonido.

Ansiedad, depresión y salud mental

https://www.who.int/es/news-room/fact-sheets/detail/anxiety-disorders
Datos oficiales de la OMS sobre trastornos de ansiedad.
https://www.mayoclinic.org/es/diseases-conditions/anxiety/symptoms-causes/syc-20350961
Síntomas y causas frecuentes de ansiedad.
https://www.who.int/es/news-room/fact-sheets/detail/depression
Información general y cifras sobre depresión.
https://www.webmd.com/depression/depression-physical-effects-brain
Explica cómo la depresión puede afectar al cerebro y al cuerpo.
https://www.cliffordtaylormd.com/the-benefits-of-psychiatric-care/signs-and-symptoms-of-major-depression/
Señales comunes asociadas a la depresión mayor.
https://www.calmclinic.com/anxiety/symptoms/extreme-clumsiness
Relación entre ansiedad, estrés y coordinación motora.

Dislexia, discalculia y comprensión

https://www.researchgate.net/publication/321807876_La_discalculia_un_reto_para_la_ensenanza_de_la_matematica_Discalculia_a_challenge_in_teaching_mathematics
Investigación sobre discalculia y aprendizaje matemático.
https://www.spldhub.com/post/dyscalculia-and-money-supporting-practical-maths-skills
Cómo la discalculia afecta a tareas cotidianas relacionadas con números y dinero.
https://uxdesign.cc/software-accessibility-for-users-with-dyslexia-a506698af4d6
Buenas prácticas de UX para personas con dislexia.
https://dyslexiascotland.org.uk/contrasting-advice-what-colours-are-best-for-accessibility/#:~:text=Accessible%20text%20contrast&text=In%20fact%2C%20The%20British%20Dyslexia,%2C%20such%20as%20cream-black.
Explica por qué algunos contrastes funcionan mejor para personas con dislexia.

Diseño accesible y experiencia de usuario

https://leedsautismaim.org.uk/resources/guide-to-making-information-accessible-for-neurodivergent-people/
Guía práctica para crear contenido accesible para personas neurodivergentes.
https://mikebifulco.com/posts/dont-center-paragraph-text
Explica por qué centrar párrafos dificulta la lectura.
https://www.easy-read-online.co.uk/post/accessible-information-for-neurodiverse-people
Consejos para simplificar contenido e información compleja.
https://thecontentlab.ie/how-to-make-your-website-accessible-for-neurodivergent-people/
Recomendaciones para diseñar webs más inclusivas cognitivamente.
https://www.continualengine.com/blog/neurodiversity-and-digital-accessibility/
Relación entre accesibilidad digital y neurodiversidad.
https://www.wypartnership.co.uk/application/files/3716/4735/6437/making-information-accessible-for-neurodivergent-people-final-v2-20.04.21.pdf
Documento muy completo sobre comunicación accesible.
https://www.ronins.co.uk/hub/accessible-design-for-neurodiversity/
Casos y recomendaciones de diseño accesible para neurodiversidad.
https://heynova.io/blog/2023-10-designing-for-people-with-adhd/
Ideas prácticas para diseñar pensando en personas con TDAH.
https://dwpdigital.blog.gov.uk/2022/06/30/designing-accessible-services-dont-exclude-the-neurodiverse/
Cómo evitar excluir a personas neurodivergentes en servicios digitales.
https://theweco.com/it-accessibility-living-with-autism/
Reflexión sobre accesibilidad digital desde la experiencia autista.
https://stephaniewalter.design/blog/neurodiversity-and-ux-essential-resources-for-cognitive-accessibility/
Recopilación excelente de recursos sobre accesibilidad cognitiva.
https://uxdesign.cc/inclusive-design-guide-7-principles-of-designing-for-the-autistic-community-1e6dcd4bae85
Principios de diseño inclusivo enfocados en la comunidad autista.
https://uxdesign.cc/software-accessibility-for-users-with-attention-deficit-disorder-adhd-f32226e6037c
Cómo adaptar interfaces para personas con déficit de atención.

WCAG y estándares de accesibilidad

https://www.w3.org/WAI/WCAG21/Understanding/unusual-words.html
Importancia de explicar términos poco comunes.
https://www.w3.org/WAI/WCAG21/Understanding/abbreviations.html
Por qué las abreviaturas pueden dificultar la comprensión.
https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions
Recomendaciones sobre animaciones y movimiento.
https://readabilityguidelines.co.uk/grammar-points/capital-letters/
Cómo el abuso de mayúsculas afecta a la legibilidad.

Colores, percepción y sobrecarga sensorial

https://joyrealtoys.com/blogs/news/how-do-different-colors-affect-sensory-overload-in-autistic-children?srsltid=AfmBOoqQloUVtF4EAFpZ8j6VOFLYQkUiVcQtNeriXxx5CzewCCGICIRL
Relación entre color y sobrecarga sensorial.
https://mintops.ca/2024/10/21/the-importance-of-color-in-a-clinic-and-the-impact-it-has-on-patient-anxiety/
Cómo el color puede influir en ansiedad y percepción emocional.
https://www.elimparcial.com/locurioso/2025/10/23/cuales-son-los-colores-que-usan-las-personas-ansiosas-segun-los-expertos/
Artículo divulgativo sobre colores y estados emocionales.

Tourette, dispraxia y coordinación

https://tourette.org/about-tourette/overview/
Introducción al síndrome de Tourette y sus características.
https://disabilitytogether.org.uk/information-and-resources/tourette-syndrome/
Impacto cotidiano y social del Tourette.
https://www.salud.mapfre.es/salud-familiar/ninos/enfermedades-del-nino/dispraxia-realizar-ciertas-tareas-resulta-dificil/
Explicación sencilla sobre dispraxia y coordinación motora.
https://escolasalut.sjdhospitalbarcelona.org/es/consejos-salud/deporte/nino-patoso-algunos-ninos-muestran-mas-torpeza-otros
Habla sobre torpeza motriz y desarrollo infantil.

Estudios académicos y papers

https://www.sciencedirect.com/science/article/pii/S014976342100049X
Revisión científica relacionada con neurodesarrollo y procesamiento cognitivo.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4873188/
Investigación sobre accesibilidad cognitiva y procesamiento de información.
https://pmc.ncbi.nlm.nih.gov/articles/PMC11745029/
Estudio reciente sobre neurodivergencia y experiencia digital.
https://www.frontiersin.org/journals/psychiatry/articles/10.3389/fpsyt.2022.837424/full
Investigación sobre salud mental y neurodivergencia.
https://pmc.ncbi.nlm.nih.gov/articles/PMC3620841
Estudio relacionado con percepción sensorial y atención.
https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2025.1499390/full
Investigación reciente sobre experiencia cognitiva y comportamiento.
https://pmc.ncbi.nlm.nih.gov/articles/PMC12145479/
Paper reciente relacionado con accesibilidad y neurodiversidad.

Recursos visuales y ejemplos

https://github.com/UKHomeOffice/posters/blob/master/accessibility/dos-donts/posters_en-UK/svg/anxiety.svg
Ejemplo visual de buenas prácticas de accesibilidad relacionadas con ansiedad.
https://www.youtube.com/watch?v=cBBl3zaheYI
Vídeo divulgativo útil para entender accesibilidad cognitiva y experiencia neurodivergente.

Preparar esta charla me recordó algo importante: la accesibilidad no consiste únicamente en cumplir una checklist. Consiste en entender que cada persona procesa, siente y navega de forma diferente.

Diseñar para la diversidad cognitiva no beneficia solo a personas neurodivergentes. Hace que los productos sean más claros, más humanos y mejores para todo el mundo.

Server-Side Rendering vs Client-Side Rendering: What Developers Should Know

Mía Salazar — Mon, 01 Jun 2026 09:50:41 +0000

As the web has evolved, so have the strategies for rendering content in browsers. Two of the most widely used approaches today are Server-Side Rendering (SSR) and Client-Side Rendering (CSR). Each has its strengths and trade-offs, and understanding when to use one over the other is key to building fast, scalable, and user-friendly applications.

This article explores the key differences, benefits, and common use cases of SSR and CSR, with practical examples.

What is Client-Side Rendering (CSR)?

Client-Side Rendering means that the browser downloads a minimal HTML shell and renders the content using JavaScript. Most of the work, fetching data, templating, and updating the DOM, happens in the user's browser after the page loads.

Benefits

Rich interactivity: Ideal for dynamic single-page applications (SPAs).
Fast navigation after initial load: Once loaded, switching between views is instantaneous.
Great for app-like experiences: Think dashboards, SaaS tools, or email clients.

Drawbacks

Slower initial page load: The user sees a blank screen until JavaScript loads and executes.
SEO challenges: Search engines may struggle to index dynamic content, unless SSR or prerendering is used.
Poor performance on slow devices: All rendering logic happens in the browser.

What is Server-Side Rendering (SSR)?

Server-Side Rendering generates the full HTML on the server for each request. When a user visits a page, the server fetches the data, compiles the HTML, and sends it to the browser, which then hydrates the app into an interactive component.

Benefits of SSR:

Fast time-to-first-byte (TTFB): HTML is ready and shows up immediately.
Better SEO: Search engines receive fully rendered pages.
Good for public-facing content: Blogs, marketing sites, e-commerce pages.

Drawbacks

Increased server load: Every page request triggers rendering logic.
Longer time to interactivity: HTML loads quickly, but hydration takes extra time.
Requires server infrastructure: Cannot be purely deployed as static files.

When to Use SSR vs CSR?

Choosing between Server-Side Rendering (SSR) and Client-Side Rendering (CSR) isn’t always straightforward. The decision should be guided by several key factors: SEO requirements, load performance, content dynamism, and the user experience you're trying to build.

Below is a deeper dive into scenarios where one might be preferable over the other.

Use SSR when:

You need excellent SEO and fast initial rendering
SSR is ideal for websites where content must be indexed by search engines or previewed accurately on social platforms. For instance, blogs, news sites, product pages, or landing pages all benefit from pre-rendered HTML, which bots and crawlers can read instantly.

You want better performance on low-powered devices
Since the HTML is pre-rendered, SSR reduces the burden on the client’s browser. This is particularly useful for users on older mobile devices or slower connections.

Time to First Paint (TTFP) matters
If you're targeting users with slow networks and you want content to appear fast (even before JavaScript has hydrated the page), SSR gives you a meaningful performance advantage.

Use CSR when:

Your app requires heavy user interaction post-load
CSR is great for Single Page Applications (SPAs), where the user stays on one page and interacts frequently (e.g., filtering data, submitting forms, navigating within the app). Once loaded, CSR apps can be incredibly fast and responsive.

Your content is highly personalised or session-based
If almost every user sees different data (e.g., based on login, preferences, roles), it often makes sense to use CSR. Fetching data on the client allows full control over what’s displayed without needing server logic to differentiate every request.

Your site doesn’t need search engine indexing
Admin dashboards, internal tools, and private platforms don’t usually need SEO. CSR reduces complexity by keeping rendering logic on the client side.

You want to offload server responsibility
With CSR, the server mainly delivers static assets (JS, HTML, CSS). This architecture scales easily via CDNs and serverless environments with minimal infrastructure.

Conclusions

Choosing between Server-Side Rendering (SSR) and Client-Side Rendering (CSR) depends on your application's goals and the expectations of your users. SSR is ideal for content-heavy sites where fast initial load, SEO, and visibility across devices and search engines are vital. By serving fully rendered HTML from the server, it improves indexing, speeds up first paint, and reduces the load on client devices.

CSR, on the other hand, is best suited for dynamic, interactive web applications such as dashboards, user portals, or tools that rely heavily on client-side state and behaviour. It enables richer, more responsive interfaces after the initial load and supports personalised content without extra server complexity.

Ultimately, the decision isn't about which is better, but about which best fits the structure, purpose, and performance priorities of your project.

Cross-Browser Considerations for Front-End Development

Mía Salazar — Wed, 22 Apr 2026 12:31:22 +0000

Building a website that works only in your development browser is like hosting a party and only giving the address to one friend. Users will arrive using Chrome, Firefox, Edge, Safari, Opera, and a variety of mobile browsers, each powered by different rendering engines and each with its own quirks. While the modern web is far more standardised than a decade ago, browser differences remain a challenge.

The goal isn’t to make the site pixel-perfect in every environment, but to ensure it is usable, functional, and accessible everywhere.

Understand Rendering Engine Differences

Every browser relies on a rendering engine to process HTML, CSS, and JavaScript and turn it into what you see on screen.

Chrome & Edge (Chromium-based) → Blink
Firefox → Gecko
Safari → WebKit

These engines follow web standards but can interpret specifications slightly differently.

For instance, form controls and native input widgets can look drastically different between Blink and Gecko, which can break a carefully designed UI if not tested.

Stick to Standards-Compliant HTML and CSS

Browsers are surprisingly forgiving of sloppy markup, but that forgiveness is inconsistent. One may “guess” your intention and display correctly, while another may break the layout.

<!-- Invalid HTML (missing closing tag) -->
<p>This is a paragraph
<p>This is another paragraph</p>

Chrome might auto-close the first <p> correctly. Firefox could nest them incorrectly, causing spacing issues. To reduce the risk of unpredictable browser behaviour you can:

Validate your code with the W3C Validator.
Use semantic tags (, , ) for better rendering and accessibility.
Avoid deprecated tags and attributes.

Check CSS Feature Support Before Using

The pace of CSS innovation is fast. Features like subgrid, :has(), and container queries are powerful but not universally supported.

To prevent these situations, you can use Can I Use before adding cutting-edge features, and you should always provide a fallback style.

For example, using :has may not always be effective.

.card:has(img) {
  border: 2px solid green;
}

However, using a less elegant way of styling elements is universal.

.card img {
  border: 2px solid green;
}

Manage JavaScript Compatibility Carefully

As Javascript evolves rapidly, not all features are immediately supported across browsers. For instance, syntax introduced in recent ECMAScript versions (such as optional chaining, nullish coalescing, or private class fields) may work flawlessly in the latest versions of Chrome or Edge, but can cause silent failures or syntax errors in older versions of Firefox or mobile browsers that haven’t updated.

More critically, browser APIs, such as ResizeObserver, IntersectionObserver, or navigator.clipboard, may behave inconsistently or not exist at all. Writing robust front-end code requires the habit of checking for the presence of an API before using it.

Prepare for Browser-Specific Bugs

Even when your code is technically correct and standards-compliant, browser-specific bugs and inconsistencies can still derail your layout or behaviour. This can be especially frustrating when something that works perfectly in one browser looks broken or behaves unexpectedly in another.

These issues often stem from differences in how the rendering engines interpret the standards, partial implementations of specifications, or simply long-standing bugs that have yet to be fixed.

For example, flexbox gap doesn't work in older versions of Firefox.

.container {
  display: flex;
  gap: 16px;
}

So, if you need your app to work smoothly in older versions of Firefox, it's better not to use it.

.container > * {
  margin-right: 16px;
}
.container > *:last-child {
  margin-right: 0;
}

Cross-Platform Testing

Testing is where all cross-browser efforts come together. It’s not enough to assume that your site works everywhere because it functions well in your main development browser.

Users interact with the web on a vast range of devices: desktop computers, tablets, smartphones, smart TVs, and more. Each comes with its own OS-level quirks, hardware limitations, and browser-specific behaviour.

For example, Chrome on Android and Chrome on desktop do not behave identically. Safari on iOS has its own rendering engine (WebKit) that behaves differently than Safari on macOS. Edge on Windows may support APIs that its Android counterpart does not. Only by testing in these different environments can you catch layout shifts, unresponsive components, or missing UI elements.

Accessibility Across Browsers

While accessibility is defined by standards, its real-world behaviour varies across browsers and assistive technologies. A feature that works perfectly in Chrome with a screen reader like NVDA may behave differently in Safari with VoiceOver, or even fail silently in Firefox. For this reason, accessibility must be tested across multiple browser–screen reader combinations, not assumed from a single environment.

One key area where this shows is in how browsers handle dynamic content updates with ARIA live regions. These are often used to announce changes to users without moving focus, such as loading messages or form feedback.

Conclusions

Cross-browser development remains a nuanced and evolving challenge, even in 2025. Despite increasing standardisation, differences in rendering engines, partial implementations of features, and inconsistent API support continue to impact how users experience your website.

Building for the modern web means accepting that not all browsers behave identically, but they must all behave acceptably.

How to Improve Performance in React Applications

Mía Salazar — Fri, 27 Mar 2026 12:22:38 +0000

Optimizing performance in React applications is essential to create smooth, fast, and responsive user experiences. React’s flexibility and component-based architecture allow developers to implement various strategies to enhance performance.

In this article, we’ll explore key techniques such as dynamic imports, list virtualization, and others to help you boost your app’s speed.

Dynamic Imports: Code Splitting for Faster Load Times

One of the most effective performance optimizations in React is code splitting, which allows you to load JavaScript files only when needed. This can drastically reduce the initial load time, especially for large applications. React’s dynamic imports enable you to load components and modules on demand, which means users only download the code they need.

With dynamic imports, you can split your application into smaller chunks and only load parts of the app when required. For example, you might load a component for a specific route only when the user navigates to it, rather than including it in the initial bundle.

By implementing dynamic imports, you improve your app’s initial loading time and reduce the amount of unnecessary code loaded upfront.

import React, { Suspense } from 'react';

const LazyLoadedComponent = React.lazy(() => import('./LazyLoadedComponent'));

function App() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <LazyLoadedComponent />
      </Suspense>
    </div>
  );
}

List Virtualization: Rendering Only What’s Visible

In applications that display large lists of data, rendering every single item at once can be a performance bottleneck. List virtualization solves this problem by only rendering the items visible on the screen at any given time, drastically reducing the number of DOM elements.

Libraries like react-window help implement list virtualization by rendering a small subset of items based on the visible area, improving rendering speed and reducing memory usage.

Memoize Expensive Calculations with useMemo

If you perform heavy calculations or transformations (like sorting, filtering, or mapping large arrays), memoize the result with useMemo so it's only recalculated when the inputs change.

const sortedList = useMemo(() => {
  return items.sort((a, b) => a.name.localeCompare(b.name));
}, [items]);

This avoids unnecessary recalculations on every render.

Preload Critical Resources

Use <link rel="preload"> or tools like React Helmet to preload fonts, critical images, or even API data you know the user will need immediately. This can significantly reduce LCP and improve perceived performance.

Smart Data Fetching with React Query

Managing server state efficiently is key to performance. Instead of manually fetching and storing data in state variables, libraries like React Query handle caching, background refetching, and request deduplication out of the box.

React Query can:

Cache requests and avoid redundant fetches.
Refetch data in the background without blocking the UI.
Handle loading, error, and success states automatically.

Optimize Images and Assets

Large or unoptimized images are one of the most common causes of slow-loading apps. To avoid this:

Use modern formats like WebP or AVIF
Compress images before loading
Use lazy loading (<img loading="lazy" />) for below-the-fold images
Leverage responsive images with srcSet for different screen sizes

<picture>
  <source media="(min-width:768px)" srcset="flowers-tablet.jpg">
  <img src="ppizza.jpg" alt="Pozza" style="width:auto;">
</picture>

Keep Components Small and Focused

Smaller components are easier to optimize, understand, and reuse. If a component does too many things, it’s more likely to re-render often. Split logic-heavy components into smaller children where only relevant parts update.

Analyze and Monitor with Performance Tools

Lighthouse (via Chrome DevTools or CI)
Web Vitals extension
React Profiler
Sentry/Datadog for performance monitoring

Measure, benchmark, and monitor performance to track regressions over time.

Use useEffect and useCallback Wisely

React’s useEffect and useCallback hooks are powerful, but they can easily become sources of performance issues if not used thoughtfully.

With useEffect, it's important to limit side effects to what’s necessary and avoid including unstable dependencies (like inline functions or objects) unless absolutely required. This reduces the risk of unnecessary re-renders or even infinite loops. Also, always clean up subscriptions or event listeners inside effects to prevent memory leaks.

On the other hand, useCallback helps memoize functions so they retain a stable reference between renders, useful when passing callbacks to memoized child components or when including functions as dependencies in useEffect. However, overusing useCallback can clutter your code and offer little benefit if the function isn’t passed as a prop or used in dependency arrays.

In short, use useEffect to manage external interactions and side effects with minimal, clear logic, and reserve useCallback for stabilizing functions that really need it. Used wisely, these hooks help you keep your components performant and predictable.

Conclusions

Performance optimization in React is not just about writing faster code. It's about making thoughtful architectural choices, leveraging the right tools, and reducing unnecessary work for the browser.

Focus on rendering only what’s needed, when it’s needed, and keep an eye on the network, re-renders, and the structure of your components. With these strategies in place, you’ll create React apps that are not only functional but delightfully fast.

Writing Scalable and Maintainable CSS: BEM, SMACSS and OOCSS

Mía Salazar — Thu, 12 Mar 2026 10:27:09 +0000

Managing CSS at scale is one of the hardest challenges in front-end development. As projects grow, CSS can easily become brittle, hard to maintain, and prone to unintended side effects due to excessive inheritance and uncontrolled specificity.

This article introduces some popular methodologies: BEM, SMACSS, and OOCSS, and explains how they help create scalable, modular CSS architectures with clear naming conventions, low specificity, and better separation of concerns.

The Problem: Cascading and Specificity

CSS was designed to cascade, but uncontrolled cascading often leads to:

Deep selector chains (.header .menu ul li a span { ... })
Overuse of !important
Inheritance leaks causing unintended style changes
Difficulty overriding styles without breaking existing layouts

When stylesheets become difficult to predict or extend, developers start fearing changes. The key is to avoid deeply nested selectors and manage specificity explicitly.

The Solution: Modular CSS Architecture

A modular CSS approach aims to:

Create independent, reusable components
Minimise selector specificity
Clearly separate structure (layout, positioning) from skin (visual appearance)
Use consistent naming conventions
Avoid over-reliance on inheritance

Let’s explore some well-known methodologies that encourage this.

BEM

BEM stands for Block Element Modifier, and it works like this:

Block: the standalone entity (e.g. card)
Element: a part of the block (e.g. card__header)
Modifier: a variant or state (e.g. card--highlighted)

BEM creates predictable class names with low specificity and no dependence on DOM structure or nesting. Besides, the low specificity makes these class names easy to override and compose.

<div class="card card--highlighted">
  <div class="card__header">Title</div>
  <div class="card__content">Content here</div>
</div>

SMACSS

Scalable and Modular Architecture for CSS (SMACSS) categorises CSS rules into five types:

Base: default browser styles (typography, resets).
Layout: large structural areas (grid, header, footer).
Module: reusable components (cards, buttons, forms).
State: UI states (.is-active, .is-hidden).
Theme: visual skins.

SMACSS encourages separation of concerns, promoting reusability and scalability, and it helps organise large codebases logically.

/* layout/_header.scss */
.header { ... }

/* module/_card.scss */
.card { ... }

/* state/_visibility.scss */
.is-hidden { display: none; }

OOCSS

Object-Oriented CSS (OOCSS) promotes splitting styles into:

Structure (object): layout and positioning.
Skin: colours, fonts, shadows, borders.

OOCSS encourages thinking of UI as reusable "objects" that can be extended visually through skins. It creates highly reusable elements, separating layout and appearance.

/* structure */
.box { display: block; padding: 1rem; }

/* skin */
.box--primary { background-color: blue; color: white; }
.box--secondary { background-color: grey; color: black; }

Managing Specificity and Avoiding Excessive Inheritance

All these methodologies share common goals:

Limit specificity: Prefer simple class selectors over IDs or long chains.
Avoid deep nesting: Don’t rely on parent-child structures (.nav .list .item .link), flat selectors are easier to override.
Use consistent naming: BEM-style or SMACSS naming conventions make styles easy to locate and modify.
Separate structure and skin: Keep layout and visual design decoupled.
Use utility classes for global states: e.g. .is-disabled

Conclusion

BEM, SMACSS, and OOCSS are not mutually exclusive: they share complementary principles that help you write predictable, maintainable, and scalable CSS. By embracing flat class-based selectors, separating concerns, and managing specificity, your front-end code will remain robust even as your project grows.

A clear modular architecture with naming conventions not only improves maintainability but also fosters team collaboration and confidence in styling changes.

Multiple header, footer, and h1 Elements: What Is Actually Accessible?

Mía Salazar — Fri, 20 Feb 2026 15:18:07 +0000

Questions about how many header, footer, or h1 elements are allowed in a page are extremely common in web development, and they are often framed as strict accessibility rules. In reality, accessibility is less about counting elements and more about meaning, structure, and relationships.

This article clarifies what is valid, what is accessible, and what actually matters when using header, footer, and h1 elements in a single document.

The Core Principle: Semantics Over Superstition

HTML is not a set of fragile rules that break accessibility when slightly bent. It is a semantic language designed to describe the structure of a document.

The key question is not "how many of these elements am I allowed to use?", but rather "Do these elements accurately describe the structure of the content?".

Multiple `header` Elements

Is it allowed? Yes. You can have multiple header elements in a single document. A header represents introductory content for its nearest sectioning ancestor, such as:

body
main
article
section
nav

Example

<header>
  <h1>Site name</h1>
</header>

<main>
  <article>
    <header>
      <h2>Article title</h2>
    </header>
    <p>Article content…</p>
  </article>
</main>

This structure is both valid HTML and accessible. Each header introduces its own section. Screen readers expose headers as structural landmarks tied to their sections. Multiple headers are not confusing when the hierarchy is clear.

Multiple `footer` Elements

Is it allowed? Also yes. Like header, the footer element is section-scoped. A footer contains information related to its nearest ancestor section, such as:

Author information
Related links
Metadata

Example

<article>
  <p>Post content…</p>
  <footer>
    <p>Written by Alex</p>
  </footer>
</article>

<footer>
  <p>© 2026 Example site</p>
</footer>

Screen readers announce footers as landmarks only when they are top-level. Nested footers are treated as part of their section, which is expected behaviour.

Multiple `h1` Elements

Is it allowed? A really strong yes. HTML5 explicitly allows multiple h1 elements. Each h1 represents the top heading of its sectioning context.

Example

<main>
  <article>
    <h1>Article title</h1>
    <section>
      <h2>Introduction</h2>
    </section>
  </article>

  <article>
    <h1>Another article</h1>
    <section>
      <h2>Overview</h2>
    </section>
  </article>
</main>

The Real Accessibility Question About Headings

The real issue is not the number of h1s, but whether the heading hierarchy makes sense.

A good heading structure involves headings that reflect the content structure, that levels are not skipped arbitrarily, and sections are clearly defined

//Poor Heading Structure

<h1>Main title</h1>
<h4>Subsection</h4>

Skipping levels creates confusion for screen reader users who navigate by headings.

Screen Readers and Navigation

Many assistive technology users navigate pages by headings, landmarks or regions. Proper use of header, footer, and heading levels enables faster navigation, clear mental models of the page and predictable reading order

The problem is not multiplicity: it is misrepresentation.

Practical Guidelines

header and footer elements should be used to introduce or conclude meaningful sections of content, not as generic wrappers. Headings should reflect the real structure of the page rather than visual styling choices, helping users understand how content is organised.

Clarity should always be prioritised over rigid or outdated rules, and heading navigation should be tested with a screen reader to ensure the structure works in practice.

If the structure makes sense to a human, it usually makes sense to assistive technology.

Conclusions

Using multiple header and footer elements in a document is both valid and accessible when they correctly describe their respective sections. Multiple h1 elements are also allowed and often appropriate, particularly in documents composed of distinct articles or regions.

Accessibility does not depend on counting elements, but on providing a clear and logical hierarchy that accurately represents the content.

HTML accessibility is ultimately about expressing meaning rather than following myths or arbitrary conventions.

When Does a Component Re-render in React?

Mía Salazar — Sun, 01 Feb 2026 19:53:25 +0000

React's declarative nature and virtual DOM abstraction make it deceptively easy to build complex UIs. However, understanding when and why a component re-renders is essential for performance, especially in larger applications. Re-renders can be cheap, but unnecessary ones add up.

This article explains the most common triggers of component re-renders and offers strategies for controlling them effectively.

What Triggers a Re-render?

When a component’s state changes using useState, React schedules a re-render of that component.

Every call to setCount with a different value will cause the component to re-render.

const [count, setCount] = useState(0);

const increment = () => setCount(count + 1);

Prop Changes

If a component receives new props (i.e., if the parent re-renders and passes new values), the child will also re-render by default.

If someValue changes (even if it’s deeply equal but a new reference), MyComponent will re-render.

<MyComponent data={someValue} />

Context Changes

React Contexts provide a way to share values across the component tree. Any update to a context value will re-render all consuming components.

When theme changes, ChildComponent and all others using useContext(MyContext) re-render.

<MyContext.Provider value={theme}>
  <ChildComponent />
</MyContext.Provider>

Parent Re-renders

Even if a child’s props didn’t change, it can re-render if its parent re-renders unless it’s memoised with React.memo.

React Reconciliation: How React Decides to Re-render

React uses referential equality (===) to compare props and state. If something changes, a new object, array, or primitive, it assumes the UI might need to update.

This is why using immutable patterns is crucial. Mutating objects without changing their reference can lead to bugs or skipped renders.

How to Prevent Unnecessary Re-renders

Use React.memo for Pure Functional Components

Only re-renders if name changes.

const MyComponent = React.memo(({ name }) => {
  console.log("Rendered!");
  return <div>{name}</div>;
});

Use useCallback and useMemo to Stabilise Functions and Values

Without useCallback, the function is recreated on every render and may cause children to re-render unnecessarily.

const handleClick = useCallback(() => {
  // Do something
}, []);

Avoid Inline Objects and Arrays in Props

// Causes re-render
<Component data={{ a: 1 }} />

// Use useMemo
const data = useMemo(() => ({ a: 1 }), []);
<Component data={data} />

Keep State Local Where Possible

Lifting state up or storing too much in global context can lead to unnecessary tree-wide re-renders. Keep state close to where it’s used.

Conclusion

Understanding when React re-renders a component is vital to building performant and predictable interfaces. State, props, context, and parent updates are the primary causes. By embracing immutable patterns and using tools like React.memo, useCallback, and useMemo, you can significantly reduce unnecessary rendering and boost the responsiveness of your application.

Regular Functions vs Arrow Functions in JavaScript

Mía Salazar — Mon, 26 Jan 2026 08:34:50 +0000

JavaScript offers two main ways to declare functions: regular functions and arrow functions. While both can perform the same tasks, they behave differently in key areas, especially regarding this, arguments, and how they’re used in front-end development.

`this` Binding

Regular functions get their own this depending on how they’re called. this changes based on who calls the function.

const button = document.querySelector('#myButton');

button.addEventListener('click', function () {
  console.log(this); // 'this' = the button
});

In this case, this refers to the button that was clicked

Arrow functions don’t have their own this; they inherit it from their surrounding scope. this comes from where the function is written.

This makes arrow functions ideal in situations where you want to keep the context

const button = document.querySelector('#myButton');

button.addEventListener('click', () => {
  console.log(this); // 'this' = window or outer scope
});

Here, this does not refer to the button.

Arguments Object

The arguments object is a built-in feature in regular functions in JavaScript. It contains an array-like list of all the values passed to that function, even if they weren’t defined as parameters.

Regular functions have access to the arguments object, an array-like list of arguments passed to the function.

function showArguments() {
  console.log(arguments);
}

showArguments('Hello', 42, true);
// Output: ['Hello', 42, true] (in modern browsers)

Arrow functions do not have their own arguments. You need to use rest parameters instead (...args).

If you try to use arguments inside an arrow function, it won’t work the way you might expect. If you need to collect arguments in an arrow function, use the rest parameter syntax:

const showArguments = (...args) => {
  console.log(args);
};

showArguments('Hello', 42, true);
// Output: ['Hello', 42, true]

Constructors

Regular functions can be used as constructors with new.

function Person(name) {
  this.name = name;
  this.sayHello = function () {
    console.log(`Hello, I'm ${this.name}`);
  };
}

const user = new Person('Alice');
user.sayHello(); // Hello, I'm Alice

Arrow functions cannot be used that way. They’re not constructors.

const Person = (name) => {
  this.name = name;
  this.sayHello = () => {
    console.log(`Hello, I'm ${this.name}`);
  };
};

const user = new Person('Alice'); // ❌ TypeError: Person is not a constructor

Syntax

Arrow functions are more concise, especially for one-liners or callbacks.

Conclusion

Arrow functions and regular functions both allow you to define reusable blocks of code. However, they serve slightly different purposes in modern JavaScript.

Arrow functions are shorter, cleaner, and automatically bind this and arguments from their surrounding context. This makes them ideal for callbacks, array methods, and React components, where you want predictable scope and no surprises with this.

On the other hand, regular functions are more flexible when you need your function to have its own this, use the built-in arguments object, or act as a constructor with new. They are better suited for event handlers on the DOM, older codebases, or where full control over the function context is required.

Understanding when to use each helps keep your code readable, efficient, and bug-free, especially in front-end development where scope confusion is a common issue.

Human‑Driven vs AI‑Driven IDEs

Mía Salazar — Fri, 09 Jan 2026 09:29:09 +0000

AI‑powered IDEs such as Cursor, VS Code with Copilot, and WebStorm AI Assistant are rapidly becoming part of everyday development. They can autocomplete code, refactor components, generate tests, and explain unfamiliar APIs.

There is, however, a crucial distinction in how these tools are used:

AI‑driven development: the IDE leads, the human reacts.
Human‑driven development: the human leads, the AI assists.

This article explains that distinction, why human‑driven workflows matter for teams, and how to configure AI‑enabled IDEs (with Cursor as a concrete example) to support that approach.

What Do We Mean by AI‑Driven?

An AI-driven workflow is one in which the developer accepts large AI-generated blocks of code with little or no critical review, allows the AI to make decisions about architecture, naming, and patterns, and increasingly relies on the tool to “solve” problems instead of reasoning through them. In this model, the AI effectively leads the development process, while the human mainly reacts to its output.

// Prompt: "Create a responsive navbar in React"

export default function Navbar() {
 return (
  <nav>
   <ul>
    <li>Home</li>
    <li>About</li>
    <li>Contact</li>
   </ul>
  </nav>
 );
}

This code works, but the AI has implicitly made design decisions on behalf of the team, without considering accessibility, responsiveness, design‑system conventions, or state management. These omissions are subtle, but they accumulate quickly in real codebases.

What Is Human‑Driven Development?

Human‑driven development keeps intent, judgement, and responsibility firmly with the developer.

In a human-driven approach, the AI is treated as a fast typist, a refactoring assistant, and a source of suggestions rather than a decision-maker. The human developer defines what needs to be built and why, while the AI helps with how to implement it, and all generated code is carefully reviewed, understood, and adapted to fit the wider system and context.

interface NavItem {
 label: string;
 href: string;
}

const navItems: NavItem[] = [
 { label: 'Home', href: '/' },
 { label: 'About', href: '/about' },
 { label: 'Contact', href: '/contact' },
];

export function Navbar() {
 return (
  <nav aria-label="Main navigation">
   <ul className="nav-list">
    {navItems.map(item => (
     <li key={item.href}>
      <a href={item.href}>{item.label}</a>
     </li>
    ))}
   </ul>
  </nav>
 );
}

Here, the AI may have helped with typing or mapping logic, but the structure is intentional, accessibility is explicit, and data is separated from presentation

Using Cursor as a Human‑Driven IDE

Using Cursor effectively requires deliberate constraints. Its deep AI integration can easily shift control away from the developer if left unchecked.

A human‑driven setup starts by making intent explicit before invoking AI, through comments, partial implementations, type definitions, or clearly stated constraints. This anchors suggestions in the developer’s reasoning and ensures that the tool responds to existing context rather than introducing unsolicited structure or assumptions.

In practice, Cursor works best when used incrementally. Inline completions and small, reviewable changes encourage understanding and ownership. Conservative configuration helps prevent large, unexamined rewrites. Treated this way, Cursor becomes an accelerator for well‑defined ideas rather than a substitute for architectural thinking or judgement.

Configuration Files for a Human‑Driven Cursor Setup

A key part of keeping Cursor human‑driven is making your preferences explicit in configuration files. This reduces accidental AI overreach and aligns the tool with team standards.

1. Project‑Level Rules (`.cursor/rules.md` or similar)

Use a project‑local rules file to describe how the AI should behave.

# AI Usage Rules

- Do not introduce new libraries without asking
- Prefer existing project patterns over generic best practices
- Optimise for readability over cleverness
- Always respect accessibility (WCAG) concerns
- Never change public APIs unless explicitly requested

This works especially well in teams, as it makes expectations explicit and repeatable.

2. Editor Settings (`settings.json`)

Cursor builds on VS Code, so editor configuration still matters.

{
  "editor.inlineSuggest.enabled": true,
  "editor.suggest.preview": true,
  "editor.acceptSuggestionOnEnter": "off",
  "cursor.ai.autoGenerate": false,
  "cursor.ai.inlineSuggestions": true,
  "cursor.ai.confirmLargeChanges": true
}

These settings bias toward small, intentional interactions rather than wholesale generation.

3. Repository Documentation (`CONTRIBUTING.md`)

Document how AI is expected to be used in the repository.

## AI‑Assisted Development

AI tools may be used for:
- Refactoring
- Test generation
- Documentation improvements

AI tools should not be used for:
- Designing core architecture
- Introducing new patterns without review
- Replacing code reviews

This makes AI usage part of the team’s social contract, not an implicit or ad‑hoc practice

4. Optional: Prompt Templates

Some teams keep prompt snippets in the repo for consistency.

## Refactoring Prompt

Refactor the selected code:
- Keep the public API unchanged
- Do not introduce new dependencies
- Prefer clarity over abstraction
- Explain the changes briefly

This reduces vague prompts and improves output quality.

Human‑Driven Prompting Patterns

Instead of vague prompts like "Build this component", use constrained prompts such as:

"Refactor this function to be more readable, keep the API unchanged"
"Suggest accessibility improvements only, no visual changes"
"Explain this code rather than rewriting it"

One effective pattern is using AI for review, not creation. The AI becomes a second pair of eyes, not the primary author.

// Ask the AI:
// "What edge cases am I missing here?"

function formatPrice(value: number) {
  return `£${value.toFixed(2)}`;
}

Why Human‑Driven Matters in Front‑End

Front‑end code is not just about logic; it directly shapes user experience, accessibility, performance, and visual consistency. Every component encodes product decisions and design intent.

AI models have no real understanding of your users, business goals, regulatory constraints, or design system nuances. When they lead, those concerns are flattened or ignored.

Human‑driven workflows help teams:

Avoid fragmented UI patterns
Preserve long‑term code quality
Reduce hidden technical debt
Improve readability and onboarding
Maintain shared understanding across the codebase

By keeping intent and judgement with developers, teams gain speed without sacrificing coherence.

Conclusion

AI‑enabled IDEs are not inherently good or bad; the real risk lies in ceding intent.

By defining goals clearly, configuring tools conservatively, and treating AI as an assistant rather than an architect, developers can benefit from increased velocity without losing understanding or ownership.

Human‑driven development is not slower: it is deliberate. And in UI‑centric codebases, that deliberation is a feature, not a bug.

Replacing Toasts with Accessible User Feedback Patterns

Mía Salazar — Tue, 18 Nov 2025 18:43:49 +0000

Providing users with timely and meaningful feedback is essential for a usable digital experience. However, one of the most common UI patterns, toast notifications, often introduces serious accessibility barriers. Toasts tend to appear unpredictably, disappear too quickly, lack keyboard accessibility, and are rarely announced properly by assistive technologies.

This article explores why toast notifications often fail to meet WCAG guidelines, and proposes accessible alternatives, complete with example code snippets.

Why Toasts Are Problematic

Toasts typically violate several WCAG 2.2 success criteria

Non-interruptive timing issues: Toasts frequently appear for only a few seconds, preventing some users from perceiving them.
Lack of screen reader announcement: Many toasts are not implemented as live regions, meaning assistive technology users may never know they were there.
Keyboard inaccessibility: If the toast contains actionable elements (e.g., an “Undo” button), users often cannot tab into it before it vanishes.
Unexpected appearance on screen: Toasts that slide into view can cause layout shifts or distract users.

Accessible Alternatives to Toast Notifications

Use Persistent Status Message Regions

Avoid transient pop-ups and instead display status messages in a consistent, easily discoverable location, typically above the main content or directly beside the component that has changed.

This ensures the message:

Is always in a predictable location (WCAG 3.2.3 Consistent Navigation)
Can remain visible until dismissed (WCAG 2.2.1 Timing Adjustable)
Can be announced with aria-live (WCAG 4.1.3 Status Messages)

<div 
  aria-live="polite"
  aria-atomic="true"
  id="status-message">
</div>

Use Inline Feedback Near the Trigger

For actions such as form submissions or toggles, providing feedback next to the interactive element can help users immediately associate the message with the action they performed.

<button id="save-btn">
  Save
</button>
<span 
  id="save-feedback"
  class="visually-hidden"
  aria-live="assertive"
></span>

Use a Non-modal, Dismissible Alert Component

If a notification must stand out, consider an alert component fixed to the top of the page or container. Ensure it:

Stays visible until user dismissal (WCAG 2.2.1 Timing Adjustable)
Is reachable via keyboard (WCAG 2.1.1 Keyboard)
Is properly announced (WCAG 4.1.3 Status Messages)

<div
  id="alert"
  class="alert"
  role="alert"
  tabindex="-1"
  hidden
>
  <p id="alert-text"></p>
  <button aria-label="Dismiss alert" id="alert-dismiss">×</button>
</div>

Keep Animations Minimal and Optional

Some users may experience distraction or discomfort from motion. It is recommended to avoid unnecessary motion unless essential to functionality (WCAG 2.3.3 – Animation from Interactions) and respect the user’s “prefers-reduced-motion”.

@media (prefers-reduced-motion: reduce) {
  .alert {
    transition: none;
  }
}

Conclusion

Toasts may be familiar and visually appealing, but they often create accessibility barriers. By using persistent status areas, inline messages, or properly implemented alert components, designers and developers can ensure all users, including those with assistive technologies, can perceive, understand, and respond to important feedback.

Replacing toasts with more accessible patterns not only improves compliance with WCAG but also leads to clearer, more reliable communication across your interface.

Why Skipping Frontend Tests Always Backfires

Mía Salazar — Wed, 22 Oct 2025 07:05:38 +0000

Every team has that one person, or two, who insists that “frontend tests are a waste of time.”

They might say E2E tests are flaky, or that QA already does the job. But deep down, skipping tests isn’t a bold time-saving move; it’s a long-term productivity trap.

Here’s how to win the argument (and save your project from endless regressions).

Why Testing Matters, even on the Frontend

1.Tests catch regressions before your users do

Frontend changes are deceptively simple. You tweak a component or update an API call, and suddenly the login form stops working.

Having automated tests for critical flows (login, checkout...) ensures that your app’s core functionality never silently breaks. Without tests, the real testers are your users, and they’re the worst kind of testers.

2.They actually save time

Fixing a bug found in production takes exponentially more time than catching it during development. Manual QA can’t rerun every scenario on every release, but a test suite can, in seconds.

So while writing tests feels slow upfront, it pays off every sprint.

3.They make refactoring safe

When your codebase grows, refactors are inevitable. Without tests, developers fear touching anything. With tests, you can confidently restructure, optimize, or modernize your code, knowing that your safety net will catch regressions instantly.

4.They force better code design

Writing testable code means separating responsibilities and avoiding hidden side effects. Tests naturally lead to cleaner, more modular, and easier-to-understand components.

In the long run, this reduces onboarding time for new developers and increases overall code health.

5.You don’t need 100% coverage

Nobody’s asking for full-blown test coverage. Start small: Cover only the key integration flows.

Common Objections, and How to Defeat Them

"Tests are too fragile": Badly written tests can be unstable, but using modern tools, and using them well, makes them reliable and maintainable.
"We don’t have time": Skipping tests saves time only in the short term. Bugs found later cost far more to fix and slow development over time.
"QA already checks that": QA should focus on exploratory and edge-case testing, not on repeating the same core flows every release.
"Our app changes too often": Frequent changes increase the risk of regressions. Well-structured tests provide confidence and prevent hidden breakages.
"Tests slow us down": Full E2E coverage can be slow, but a balanced strategy, focusing E2E on key user flows and using faster integration or unit tests elsewhere, keeps feedback loops quick and efficient.

Why End-to-End tests alone aren’t enough

E2E tests are fantastic, they simulate real user behavior and verify that everything works together. But relying only on E2E tests is like checking if your car drives without ever opening the hood.

Here’s why that’s risky:

E2E tests are heavy and slow: They take longer to run and are more brittle because they depend on the full stack being up and stable.
When they fail, it’s hard to know why: A single failing E2E might mean a backend bug, a frontend change... Debugging takes longer than if you had smaller, faster integration or unit tests.
You lose granularity: Without lower-level tests, you can’t easily isolate where a bug originates.
They don’t scale well: Large teams need fast feedback loops. Having only E2E tests means waiting minutes (or hours) for CI runs instead of seconds for unit tests.

Conclussions

Convincing someone to write tests isn’t about dogma: it’s about pragmatism. It’s insurance against chaos. Start small, show quick wins, and let the results speak for themselves. Before long, your once-skeptical teammate will be willing to create more tests.

DEV Community: Mía Salazar

From Zero to Hero in TypeScript

What is TypeScript?

The Basics: Understanding the Type System

Intermediate Features: Making Your Types Smarter

Advanced & Practical Techniques

Tips & Best Practices

Conclusion

Accesibilidad y neurodivergencia: no todo el mundo navega igual

Fuentes y referencias de la charla

Neurodivergencia y diversidad cognitiva

Autismo, TDAH y procesamiento sensorial

Ansiedad, depresión y salud mental

Dislexia, discalculia y comprensión

Diseño accesible y experiencia de usuario

WCAG y estándares de accesibilidad

Colores, percepción y sobrecarga sensorial

Tourette, dispraxia y coordinación

Estudios académicos y papers

Recursos visuales y ejemplos

Server-Side Rendering vs Client-Side Rendering: What Developers Should Know

What is Client-Side Rendering (CSR)?

Benefits

Drawbacks

What is Server-Side Rendering (SSR)?

Benefits of SSR:

Drawbacks

When to Use SSR vs CSR?

Use SSR when:

Use CSR when:

Conclusions

Cross-Browser Considerations for Front-End Development

Understand Rendering Engine Differences

Stick to Standards-Compliant HTML and CSS

Check CSS Feature Support Before Using

Manage JavaScript Compatibility Carefully

Prepare for Browser-Specific Bugs

Cross-Platform Testing

Accessibility Across Browsers

Conclusions

How to Improve Performance in React Applications

Dynamic Imports: Code Splitting for Faster Load Times

List Virtualization: Rendering Only What’s Visible

Memoize Expensive Calculations with useMemo

Preload Critical Resources

Smart Data Fetching with React Query

Optimize Images and Assets

Keep Components Small and Focused

Analyze and Monitor with Performance Tools

Use useEffect and useCallback Wisely

Conclusions

Writing Scalable and Maintainable CSS: BEM, SMACSS and OOCSS

The Problem: Cascading and Specificity

The Solution: Modular CSS Architecture

BEM

SMACSS

OOCSS

Managing Specificity and Avoiding Excessive Inheritance

Conclusion

Multiple header, footer, and h1 Elements: What Is Actually Accessible?

The Core Principle: Semantics Over Superstition

Multiple header Elements

Example

Multiple footer Elements

Example

Multiple h1 Elements

Example

The Real Accessibility Question About Headings

Screen Readers and Navigation

Practical Guidelines

Conclusions

When Does a Component Re-render in React?

What Triggers a Re-render?

Prop Changes

Context Changes

Parent Re-renders

React Reconciliation: How React Decides to Re-render

How to Prevent Unnecessary Re-renders

Use React.memo for Pure Functional Components

Use useCallback and useMemo to Stabilise Functions and Values

Multiple `header` Elements

Multiple `footer` Elements

Multiple `h1` Elements

`this` Binding

1. Project‑Level Rules (`.cursor/rules.md` or similar)

2. Editor Settings (`settings.json`)

3. Repository Documentation (`CONTRIBUTING.md`)