Instead of relying on direct calls between components, event-driven systems communicate through events – messages that signal that something has happened.

JavaScript, with its inherently asynchronous nature and built-in event loop, is a natural fit for this paradigm. From browser interactions to backend microservices, event-based communication enables flexibility, performance, and maintainability across the entire stack.

This handbook explores how event-driven architectures work, how they can be implemented in JavaScript (both in Node.js and in the browser), and why they are foundational to building modern distributed applications.

Prerequisites: What you should already know

• JavaScript fundamentals (ES6+): modules, classes, closures, this

• Asynchronous JS: callbacks, Promises, async/await, and the event loop

• Node.js basics

Table of Contents

• 1. Introduction

  • What Is an Event-Driven Architecture?

  • Why JavaScript Naturally Fits This Paradigm

  • Event-Driven vs. Request-Driven Architectures

  • When It Makes Sense to Use an Event-Driven Architecture

  • When It Might Not Be the Right Choice

  • Typical Business Use Cases

• 2. Fundamentals of the Event Model in JavaScript

  • The Event Loop, Task Queue, and Call Stack

  • EventEmitter and the Pub/Sub Pattern

  • EventTarget, CustomEvent, and Browser Events

  • Putting It All Together

• 3. Publisher–Subscriber (Pub/Sub) Pattern

  • Concept and Advantages of Decoupling

  • Basic Implementation in Plain JavaScript

  • Limitations and When to Use a Library

  • Summary

• 4. Implementations in Node.js

  • How to Use the Native events Module

  • Real Example: Event-Oriented Microservice

  • Error Handling and Backpressure

  • How to Build an Event Bus Across Services

  • Summary

• 5. Event-Driven Microservices Architecture

  • Asynchronous Communication via Message Brokers

  • Example: Order → Inventory → Notification Flow

  • Designing Event Contracts (Event Schemas)

  • When to Use an Event-Driven Microservice Architecture

  • Summary

• 6. Frontend Applications and Events

  • Custom Events in the Browser

  • Event Communication in Modern Frameworks

  • Real-Time Architectures: WebSockets and Server-Sent Events

  • Summary

• 7. Event Sourcing and CQRS (Command Query Responsibility Segregation)

  • Event Sourcing: The Core Idea

  • Example: Reconstructing State from Events

  • CQRS: Command Query Responsibility Segregation

  • Difference Between Event Sourcing and Pub/Sub

  • When to Use Event Sourcing and CQRS

  • Summary

• 8. Benefits and Challenges

  • Benefits of EDA

  • Challenges of EDA

  • Summary

• 9. Real-World Use Cases

  • 1. Financial and Banking Systems

  • 2. E-commerce Platforms

  • 3. IoT and Sensor Networks

  • 4. Real-Time Analytics and Monitoring

  • 5. Social Networks and Messaging Apps

  • 6. Workflow Automation and Orchestration

  • Summary

• 10. Best Practices and Conclusions

  • 1. Version and Validate Events

  • 2. Design for Idempotency

  • 3. Keep Events Meaningful and Self-Contained

  • 4. Implement Robust Error Handling and Dead-Letter Queues

  • 5. Ensure Observability and Traceability

  • 6. Use Patterns for Reliability

  • 7. Choose the Right Broker for the Job

  • 8. Balance Event-Driven and Request-Driven Approaches

  • 9. Educate and Align the Team

  • 10. Start Small, Then Evolve

• Conclusion

1. Introduction

Software systems are becoming increasingly distributed, asynchronous, and complex. Traditional request–response architectures – where one component directly calls another and waits for a reply – often create tight coupling and limit scalability.

In contrast, event-driven architectures (EDA) embrace asynchrony by letting components communicate through events (messages that represent a change or an occurrence in the system). When an event happens (for example, “Order Created”), other parts of the system that care about that event can react to it independently, without knowing who triggered it or when.

This simple shift from commands to events has profound implications for scalability, resilience, and system design. It allows applications to evolve as loosely coupled collections of independent components that listen for and emit events, rather than monolithic blocks of code that depend directly on each other.

What Is an Event-Driven Architecture?

An event-driven architecture is a software design pattern where the flow of the program is determined by events. An event can be any significant change in state, like a user action, a message from another system, a sensor reading, or even an internal trigger like a database update.

In this model:

• Producers (also called emitters or publishers) generate and broadcast events.

• Consumers (or listeners or subscribers) react to those events asynchronously.

Unlike traditional request-driven systems, producers and consumers don’t directly call each other. Instead, they communicate through a mediator (like an event bus, queue, or topic), achieving loose coupling and higher flexibility.

Why JavaScript Naturally Fits This Paradigm

JavaScript was built around an event-driven model from its very beginning. In the browser, every user interaction – clicks, scrolls, network responses – is handled through events. The event loop, callback queue, and non-blocking I/O make JavaScript particularly well-suited for systems where many things happen concurrently.

In Node.js, this model extends to the backend. The EventEmitter API, asynchronous I/O, and the single-threaded event loop allow developers to write scalable services that handle thousands of concurrent connections efficiently. This makes JavaScript a natural language for implementing and experimenting with event-driven systems across the full stack, from the UI to distributed microservices.

Event-Driven vs. Request-Driven Architectures

Here’s a quick summary of the main features and differences:

Event-driven systems tend to perform better in environments that require real-time updates, asynchronous workflows, or high concurrency, such as financial transaction systems, IoT platforms, and analytics pipelines.

But adopting an Event-Driven Architecture is not a universal solution. It introduces its own complexities and is best suited to problems where loose coupling, scalability, and reactivity are primary goals.

When It Makes Sense to Use an Event-Driven Architecture

• Asynchronous or real-time requirements: When the system needs to react to changes instantly (for example, new data, user interactions, or external triggers).

• High scalability and resilience: When services must handle variable workloads independently, without blocking or waiting for each other.

• Microservices or distributed systems: When independent services must communicate without strong dependencies or shared state.

• Extensibility and flexibility: When you expect the system to evolve over time, adding new consumers without modifying existing producers.

• Data streaming or continuous processing: When the system processes streams of events (for example, telemetry, logs, or payments) rather than discrete requests.

When It Might Not Be the Right Choice

• Simple, synchronous applications: For small systems where interactions are linear (for example, a CRUD API or a small monolith), introducing an event bus may be unnecessary overhead.

• Strong consistency requirements; When the system must maintain a strict order of operations or immediate transactional integrity, asynchronous event flows can complicate data coherence.

• Limited observability or operational tooling: Debugging distributed events is harder – tracing and replaying events requires good logging and monitoring infrastructure.

• Team inexperience: If the development team is not familiar with asynchronous systems, event versioning, or message brokers, the cognitive load may outweigh the benefits.

Typical Business Use Cases

1. E-commerce platforms: Events like OrderPlaced, PaymentProcessed, ItemShipped trigger workflows across inventory, billing, and logistics services.

2. Financial and banking systems: Real-time updates of transactions, fraud detection, and asynchronous settlement processing.

3. IoT and telemetry processing: Devices emit data continuously. The backend aggregates, filters, and reacts to these events asynchronously.

4. Streaming analytics and monitoring: Continuous event ingestion from applications or sensors to update dashboards and trigger alerts.

5. Social networks and messaging apps: Notifications, chat updates, and activity feeds naturally map to event streams that multiple consumers can subscribe to.

6. Workflow orchestration systems: Each step in a process (for example, document signed, email sent, approval granted) triggers subsequent actions automatically.

Event-driven architectures change the way we think about program flow. Instead of pulling data or waiting for responses, components react to what’s happening in the system.

By leveraging JavaScript’s asynchronous foundations, like the event loop, promises, and non-blocking I/O, developers can build architectures that are more responsive, resilient, and scalable than traditional request-driven designs.

In the next section, we’ll dive deeper into how JavaScript’s event model works, exploring the event loop, the task queue, and the key mechanisms (like EventEmitter) that make this paradigm possible.

2. Fundamentals of the Event Model in JavaScript

JavaScript is inherently event-driven. From its earliest days in the browser to its modern incarnation on the server with Node.js, the language has been designed to handle asynchronous operations gracefully through events – signals that something has happened.

Understanding how this works under the hood is essential before applying event-driven principles to large systems.

The Event Loop, Task Queue, and Call Stack

At the heart of JavaScript’s concurrency model lies the event loop, a mechanism that enables asynchronous, non-blocking behavior in a single-threaded environment.

Let’s break it down:

1. Call Stack: This is where JavaScript executes code line by line. Each function call creates a new frame on the stack.

2. Task Queue (or Callback Queue): When asynchronous operations finish (like a setTimeout or a network request), their callbacks are queued here for later execution.

3. Event Loop: Constantly checks if the call stack is empty. When it is, the loop dequeues a task and pushes it onto the stack to execute.

This cycle repeats indefinitely – hence the term “event loop.”

console.log("A");

setTimeout(() => {
  console.log("B");
}, 0);

console.log("C");

// Output:
// A
// C
// B

Even though the timeout is 0, the callback runs after the synchronous code because it’s queued in the task queue and executed only when the call stack is clear.

This model allows JavaScript to remain responsive and non-blocking, even while performing I/O operations or waiting for user input.

EventEmitter and the Pub/Sub Pattern

Node.js exposes its event-driven core through the EventEmitter class – one of its most fundamental building blocks.

An EventEmitter lets objects emit events and subscribe to them. This mechanism forms the foundation for countless Node.js APIs, from HTTP servers to file streams.

Here’s a simple example:

const EventEmitter = require('events');
const emitter = new EventEmitter();

// Subscriber (listener)
emitter.on('dataReceived', (data) => {
  console.log(`Data received: ${data}`);
});

// Publisher (emitter)
emitter.emit('dataReceived', 'User profile loaded');

Output:

Data received: User profile loaded

Each event has:

• A name (string or symbol)

• A set of listeners (functions) that react to it

This is the classic Publisher–Subscriber pattern (Pub/Sub): components publish events, while others subscribe to react – without direct references to each other.

EventTarget, CustomEvent, and Browser Events

In the browser, the same concept exists through the EventTarget API. Every DOM element can listen for or dispatch events.

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

button.addEventListener('click', () => {
  console.log('Button clicked!');
});

We can also create custom events to simulate our own event-driven behavior:

const userEvent = new CustomEvent('userLoggedIn', {
  detail: { name: 'Alice' }
});

document.addEventListener('userLoggedIn', (e) => {
  console.log(`Welcome, ${e.detail.name}!`);
});

document.dispatchEvent(userEvent);

Output:

Welcome, Alice!

This lightweight mechanism allows front-end applications to coordinate behavior across components without tight coupling.

Putting It All Together

Whether in the browser or Node.js, JavaScript’s asynchronous runtime and event-driven APIs form a natural foundation for building reactive, modular, and scalable systems.

In Node.js, nearly everything is an event emitter – HTTP requests, streams, process signals, and even errors. In the browser, events are how users and systems interact through clicks, network responses, and state changes.

This unified model across client and server is what makes JavaScript uniquely powerful for implementing end-to-end event-driven architectures.

In the next section, we’ll explore the Pub/Sub pattern in depth: we’ll understand its advantages, pitfalls, and how to implement it cleanly in plain JavaScript before scaling up to distributed systems.

3. Publisher–Subscriber (Pub/Sub) Pattern

The Publisher–Subscriber pattern, often abbreviated as Pub/Sub, is one of the most common and powerful foundations of event-driven systems. It defines how components can communicate asynchronously without knowing each other directly – a principle known as loose coupling.

In a Pub/Sub model:

• Publishers (or emitters) broadcast events.

• Subscribers (or listeners) register interest in those events.

• A broker (or event bus) acts as a mediator between the two.

This separation allows systems to evolve and scale independently: new subscribers can be added without changing the publishers, and vice versa.

Concept and Advantages of Decoupling

In traditional architectures, one component often depends directly on another:

function processOrder(order) {
  sendInvoice(order);
  notifyWarehouse(order);
}

Here, processOrder is tightly coupled to the functions it calls. If we later need to send a shipping confirmation or trigger analytics, we must modify processOrder again. This violates the Open/Closed Principle (open for extension, closed for modification).

In a Pub/Sub model, the same logic becomes event-driven:

const EventEmitter = require('events');
const bus = new EventEmitter();

bus.on('order:created', sendInvoice);
bus.on('order:created', notifyWarehouse);

bus.emit('order:created', { id: 42, items: 3 });

Now, processOrder doesn’t need to know who’s listening. It simply emits an event (order:created), and any number of subscribers can react to it – even ones that didn’t exist when the code was written.

Advantages:

• ✅ Loose coupling between components

• ⚙️ Easier extensibility: add new behaviors by adding listeners

• 🚀 Parallel evolution: teams can work on producers and consumers independently

• 🧩 Greater testability: events can be simulated in isolation

Basic Implementation in Plain JavaScript

While Node.js provides a ready-to-use EventEmitter, you can easily build a minimal event bus in plain JavaScript. This helps illustrate the underlying logic:

function createEventBus() {
  const listeners = {};

  return {
    subscribe(event, callback) {
      if (!listeners[event]) listeners[event] = [];
      listeners[event].push(callback);
    },
    publish(event, data) {
      (listeners[event] || []).forEach((callback) => callback(data));
    },
    unsubscribe(event, callback) {
      listeners[event] = (listeners[event] || []).filter((cb) => cb !== callback);
    }
  };
}

// Example usage
const bus = createEventBus();

function onUserRegistered(user) {
  console.log(`Welcome, ${user.name}!`);
}

bus.subscribe('user:registered', onUserRegistered);
bus.publish('user:registered', { name: 'Alice' });
bus.unsubscribe('user:registered', onUserRegistered);

This simple implementation already captures the essence of Pub/Sub:

• You can subscribe to an event.

• You can publish events with data.

• You can unsubscribe dynamically.

Limitations and When to Use a Library

While the above implementation works for small-scale use, real-world systems often require:

• Wildcard or hierarchical event names (for example, order.* or user.created)

• Asynchronous delivery (with message queues or brokers)

• Error handling and retries

• Event persistence or replay

• Cross-process or distributed communication

In those cases, using a dedicated library or broker is more appropriate.

Popular options include Node.js’s built-in EventEmitter for in-process events, RxJS for reactive programming and stream composition, and message brokers like RabbitMQ, Kafka, or Redis Streams for distributed, scalable architectures

Each of these tools extends the Pub/Sub model to handle larger scale, fault tolerance, and observability – essential features in modern distributed systems.

Summary

The Publisher–Subscriber pattern is the backbone of event-driven design. It transforms direct, synchronous function calls into indirect, asynchronous communications, allowing systems to evolve gracefully and handle change without friction.

In JavaScript, this pattern is everywhere – from browser DOM events to Node.js streams and microservice architectures.

In the next section, we’ll dive deeper into practical implementations in Node.js, exploring how the events module powers many of the platform’s most important features and how it can be extended to build robust, event-oriented systems.

4. Implementations in Node.js

Node.js was designed from the ground up around the event-driven paradigm. Its single-threaded, non-blocking I/O model allows it to handle thousands of concurrent operations efficiently – not by running code in parallel, but by reacting to events as they occur.

At the heart of this model lies the events module, which exposes the EventEmitter class used throughout Node’s core APIs, from HTTP servers to file streams.

How to Use the Native events Module

The EventEmitter class provides a standard way to emit and listen for events within a Node.js process.
It’s a lightweight yet powerful abstraction for asynchronous communication between components.

Let’s look at a simple example:

const EventEmitter = require('events');
const emitter = new EventEmitter();

// Register an event listener
emitter.on('user:login', (user) => {
  console.log(`User logged in: ${user.name}`);
});

// Emit the event
emitter.emit('user:login', { name: 'Alice' });

Output:

User logged in: Alice

Each EventEmitter instance maintains an internal map of event names to listener functions. Listeners can be added using .on() or .once() (for one-time execution), and events are triggered asynchronously with .emit().

Real Example: Event-Oriented Microservice

To see this in action, imagine a simplified order-processing microservice:

const EventEmitter = require('events');
const bus = new EventEmitter();

function createOrder(order) {
  console.log(`Order created: ${order.id}`);
  bus.emit('order:created', order);
}

function sendInvoice(order) {
  console.log(`Invoice sent for order ${order.id}`);
}

function updateInventory(order) {
  console.log(`Inventory updated for order ${order.id}`);
}

// Subscribe listeners
bus.on('order:created', sendInvoice);
bus.on('order:created', updateInventory);

// Simulate an order
createOrder({ id: 123, items: ['Book', 'Pen'] });

Output:

Order created: 123
Invoice sent for order 123
Inventory updated for order 123

Here, the microservice emits an order:created event whenever a new order is placed. Multiple listeners (invoice and inventory handlers) react independently – a miniature event-driven architecture in a single process.

This approach scales naturally as the system grows. New behaviors, like sending notifications or analytics tracking, can be added by simply subscribing new listeners.

Error Handling and Backpressure

In event-driven systems, error management is crucial because unhandled exceptions inside event listeners can crash the entire Node.js process.

To prevent this, Node provides built-in mechanisms:

1. Error events: You can emit and handle errors explicitly.

    const EventEmitter = require('events');
    const emitter = new EventEmitter();
   
    emitter.on('error', (err) => {
      console.error('An error occurred:', err.message);
    });
   
    emitter.emit('error', new Error('Database connection failed'));
   

   If an 'error' event is emitted without at least one listener, Node.js will throw it as an uncaught exception and terminate the process.

2. Backpressure management: In streaming scenarios, producers can emit data faster than consumers can handle.

   Node.js Streams solve this through backpressure, where consumers signal when they are ready for more data.

    const fs = require('fs');
    const readable = fs.createReadStream('large-file.txt');
    const writable = fs.createWriteStream('copy.txt');
   
    readable.pipe(writable); // Automatically manages flow control
   

   Under the hood, streams use event-based coordination (data, drain, end) to ensure stability even under heavy load.

How to Build an Event Bus Across Services

While EventEmitter works within a single process, real-world architectures often span multiple microservices or containers. In such cases, an external message broker (like RabbitMQ, Kafka, or Redis Streams) acts as a distributed event bus.

Each service becomes either:

• a producer (publishing events), or

• a consumer (subscribing and reacting).

Node.js integrates seamlessly with these systems using community libraries:

• amqplib for RabbitMQ

• kafkajs for Apache Kafka

• redis for Redis Pub/Sub

Example (simplified with Redis):

const { createClient } = require('redis');
const publisher = createClient();
const subscriber = createClient();

await publisher.connect();
await subscriber.connect();

subscriber.subscribe('user:created', (message) => {
  console.log(`New user event received: ${message}`);
});

await publisher.publish('user:created', JSON.stringify({ id: 1, name: 'Alice' }));

This pattern allows cross-service communication without tight coupling. Each service reacts to events asynchronously, whether it’s hosted locally or across a cluster.

Summary

The Node.js EventEmitter encapsulates the essence of event-driven design at the process level: lightweight, decoupled, and asynchronous. Combined with external message brokers, it becomes a powerful tool for building scalable, distributed event-driven systems.

Through events, Node.js applications can handle multiple concurrent workflows efficiently, maintain clear separation of concerns, and grow organically as the system evolves.

In the next section, we’ll extend this idea beyond a single application. We’ll explore Event-Driven Microservices Architecture, where multiple independent services communicate entirely through asynchronous event flows.

5. Event-Driven Microservices Architecture

As applications grow, a single event bus inside one process is no longer enough. When your system consists of multiple independently deployed services – each owning its own data and responsibilities – the Event-Driven Architecture becomes a natural fit for enabling asynchronous, decoupled communication.

In an event-driven microservice ecosystem, services don’t call each other directly through HTTP or RPC.
Instead, they publish and consume events through a message broker – a central medium that handles delivery, queuing, and persistence of messages between services.

Asynchronous Communication via Message Brokers

In a request-driven microservice system, one service directly invokes another via REST or gRPC:

Order Service  →  Inventory Service  →  Notification Service

Each call is synchronous, meaning the caller waits for a response. This creates coupling and potential cascading failures if one service is down or slow.

In an event-driven model, communication happens asynchronously through events:

Order Service  →  [Event Bus]  →  Inventory Service, Notification Service

The event bus becomes the backbone of the system. Each service publishes events and subscribes to those it needs, without knowing who will consume them.

This brings several advantages:

• ⚙️ Loose coupling: services don’t depend on each other’s availability

• 📈 Scalability: new consumers can subscribe without changing existing code

• 🔁 Resilience: temporary outages are absorbed by the broker’s queues

• 🧩 Extensibility: new workflows can be added just by listening to existing events

Example: Order → Inventory → Notification Flow

Let’s consider a practical scenario in an e-commerce platform:

1. Order Service publishes an order:created event when a user places an order.

2. Inventory Service subscribes to order:created and decrements stock.

3. Notification Service also subscribes to order:created and sends a confirmation email.

          ┌──────────────────────┐
          │   Order Service      │
          │ emits "order:created"│
          └──────────┬───────────┘
                     │
          ┌──────────▼───────────┐
          │     Event Bus        │
          │ (Kafka, RabbitMQ...) │
          └──────┬───────────────┘
      ┌──────────┴───────────┐   ┌────────────────────┐
      │ Inventory Service    │   │ Notification Service│
      │ updates stock        │   │ sends email         │
      └──────────────────────┘   └────────────────────┘

Node.js example (simplified with Redis):

// order-service.js
const { createClient } = require('redis');
const publisher = createClient();
await publisher.connect();

async function createOrder(order) {
  console.log(`Order created: ${order.id}`);
  await publisher.publish('order:created', JSON.stringify(order));
}

createOrder({ id: 42, items: ['Book', 'Pen'] });

// inventory-service.js
const { createClient } = require('redis');
const subscriber = createClient();
await subscriber.connect();

await subscriber.subscribe('order:created', (message) => {
  const order = JSON.parse(message);
  console.log(`Updating inventory for order ${order.id}`);
});

// notification-service.js
const { createClient } = require('redis');
const subscriber = createClient();
await subscriber.connect();

await subscriber.subscribe('order:created', (message) => {
  const order = JSON.parse(message);
  console.log(`Sending confirmation email for order ${order.id}`);
});

Each service is now independent. They communicate only through events, not direct calls.

Designing Event Contracts (Event Schemas)

In a distributed system, events are contracts – they define what information producers share and consumers rely on. Defining and maintaining these contracts carefully is crucial to avoid breaking downstream consumers.

A good event should:

• Contain enough context for consumers to act independently

• Use a versioned schema to evolve safely over time

• Include metadata like eventId, timestamp, and source

Example event schema (JSON):

{
  "event": "order:created",
  "version": 1,
  "timestamp": "2025-10-29T18:45:00Z",
  "data": {
    "orderId": 42,
    "userId": 123,
    "items": [
      { "sku": "BOOK-001", "quantity": 2 },
      { "sku": "PEN-003", "quantity": 1 }
    ],
    "total": 39.90
  }
}

Best practices:

• Use namespaced event types (order:created, payment:failed)

• Include a version number (v1, v2) to avoid schema drift

• Store events in a central registry (for example, JSON Schema repository)

• Log all events for auditing and debugging

When to Use an Event-Driven Microservice Architecture

Event-driven microservices are especially valuable when:

• Systems require real-time updates (for example, notifications, analytics)

• Components must operate independently and asynchronously

• The platform needs to scale horizontally across services

• New capabilities should be added without touching existing code

But this architecture also brings challenges:

• Harder to trace flows across multiple asynchronous hops

• Requires observability tools (logs, traces, metrics) to debug issues

• Event ordering and exact-once delivery can be complex

• Increased operational overhead from managing brokers and message queues

Summary

Event-driven microservices take the principles of the Pub/Sub pattern and scale them across distributed systems. By communicating exclusively through asynchronous events, services become autonomous, resilient, and extensible. This is ideal for modern cloud architectures and high-throughput applications.

In the next section, we’ll shift our focus to the front end and explore how event-driven principles power reactivity in browsers and frameworks like React and Vue, and how technologies like WebSockets and Server-Sent Events enable real-time user experiences.

6. Frontend Applications and Events

While backend systems use event-driven architectures to coordinate between services, frontend applications have relied on event-based programming since JavaScript’s creation. And again, every user interaction is handled through events.

Understanding how events flow in the browser, and how modern frameworks like React and Vue build upon this model, is key to creating responsive, decoupled, and real-time user interfaces.

Custom Events in the Browser

In vanilla JavaScript, every DOM element can emit and listen to events through the EventTarget API.
This mechanism is the foundation of how browsers handle user interaction and component communication.

Example – Basic Event Handling:

<button id="subscribeBtn">Subscribe</button>
<script>
  const btn = document.getElementById('subscribeBtn');
  btn.addEventListener('click', () => {
    console.log('User subscribed!');
  });
</script>

Here, the button acts as an event emitter. When the click event occurs, the listener function reacts. This is a simple example of publish-subscribe behavior within the DOM.

You can also define custom events to allow decoupled communication between components:

const userEvent = new CustomEvent('user:registered', {
  detail: { name: 'Alice', email: 'alice@example.com' }
});

// Listen for the event
document.addEventListener('user:registered', (e) => {
  console.log(`Welcome ${e.detail.name}!`);
});

// Dispatch it
document.dispatchEvent(userEvent);

Output:

Welcome Alice!

This approach allows different parts of the UI to react to user actions or system changes without directly calling each other.

Event Communication in Modern Frameworks

Modern JavaScript frameworks like React, Vue, and Angular abstract the native event system, but the core idea remains the same: components react to events.

React Example

React’s synthetic event system wraps the browser’s native events, providing a unified interface across browsers.

function NewsletterSignup() {
  function handleSubmit(e) {
    e.preventDefault();
    console.log('Newsletter form submitted!');
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="email" placeholder="Your email" />
      <button type="submit">Subscribe</button>
    </form>
  );
}

Behind the scenes, React uses an event delegation model: it attaches a single listener at the root and dispatches events down the component tree efficiently.

For cross-component communication, React developers often use:

• Context or state managers (like Redux, Zustand, or Recoil)

• Event emitter utilities (like mitt or nanoevents)

• Custom hooks for modular event handling

Example using a lightweight emitter (mitt):

import mitt from 'mitt';

export const bus = mitt();

Then anywhere in your app:

// Component A
bus.emit('theme:changed', 'dark');

// Component B
bus.on('theme:changed', (theme) => {
  console.log(`Theme updated to ${theme}`);
});

This simple event bus decouples components that don’t share a direct parent-child relationship.

Vue Example

Vue provides a native event system for child-to-parent communication and also supports global event buses.

<template>
  <button @click="notify">Notify Parent</button>
</template>

<script>
export default {
  methods: {
    notify() {
      this.$emit('user-registered', { name: 'Alice' });
    }
  }
};
</script>

The parent component can listen for user-registered and react accordingly. Vue 3 also supports custom event buses via external libraries like mitt, enabling component-to-component events without tight coupling.

Real-Time Architectures: WebSockets and Server-Sent Events

In modern web applications, the event-driven model extends beyond the client, connecting the front end and back end in real-time.

WebSockets

WebSockets provide a full-duplex channel between the browser and the server. This means both sides can send events at any time, enabling instant updates without polling.

Example:

const socket = new WebSocket('wss://example.com/socket');

socket.addEventListener('open', () => {
  console.log('Connected to server');
  socket.send(JSON.stringify({ event: 'user:joined', name: 'Alice' }));
});

socket.addEventListener('message', (msg) => {
  const data = JSON.parse(msg.data);
  console.log('New event from server:', data);
});

Use cases:

• Real-time chat applications

• Live dashboards

• Online multiplayer games

Server-Sent Events (SSE)

SSE is a simpler alternative when you only need one-way communication – from server to client – using standard HTTP connections.

const source = new EventSource('/events');

source.addEventListener('update', (e) => {
  const data = JSON.parse(e.data);
  console.log('Received update:', data);
});

SSE is ideal for live notifications, monitoring dashboards, and continuous data feeds.

Summary

The frontend world has always been event-driven – from DOM interactions to modern component frameworks and real-time connections.

By treating the UI as a system that reacts to events rather than polling for changes, we build interfaces that are more responsive, more modular, and easier to extend and integrate with event-driven back ends.

Whether you use CustomEvent, mitt, WebSockets, or SSE, the principle is the same: emit events, listen for changes, and let your app respond asynchronously.

In the next section, we’ll explore how these same principles extend into Event Sourcing and CQRS (Command Query Responsibility Segregation) – advanced architectural patterns that persist and reconstruct system state entirely through events.

7. Event Sourcing and CQRS (Command Query Responsibility Segregation)

Up to this point, we’ve explored events as transient messages that trigger behavior – signals passed between components or services. But in more advanced architectures, events can also become the source of truth for the system’s state itself.

This is where Event Sourcing and CQRS come into play.

These patterns are fundamental in systems that require auditability, replayability, and scalable state reconstruction, such as banking platforms, e-commerce systems, and workflow engines.

Event Sourcing: The Core Idea

In traditional architectures, a system stores only the current state: for example, a database row representing the latest balance of a user’s account.

In Event Sourcing, the system instead stores a series of events that led to that state. Each event represents a historical change, such as AccountCreated, FundsDeposited, or FundsWithdrawn.

When you need the current state, you don’t query a static record – you replay all relevant events in sequence.

Traditional Model:

Event-Sourced Model:

To calculate the balance, you replay the events:

0 + 300 + 200 = $500

This approach provides:

• 🧾 Full audit history: every state change is recorded

• 🔁 Replayability: rebuild state after crashes or schema changes

• 🧩 Temporal queries: know what the system looked like at any point in time

Example: Reconstructing State from Events

Let’s illustrate with a simple JavaScript implementation.

const events = [
  { type: 'AccountCreated', data: { id: 1, owner: 'Alice' } },
  { type: 'FundsDeposited', data: { id: 1, amount: 300 } },
  { type: 'FundsDeposited', data: { id: 1, amount: 200 } },
  { type: 'FundsWithdrawn', data: { id: 1, amount: 100 } }
];

function rebuildAccount(events) {
  let balance = 0;

  for (const event of events) {
    switch (event.type) {
      case 'FundsDeposited':
        balance += event.data.amount;
        break;
      case 'FundsWithdrawn':
        balance -= event.data.amount;
        break;
    }
  }

  return balance;
}

console.log('Current balance:', rebuildAccount(events)); // 400

Here, we never stored a static “balance” field. Instead, we reconstructed it from the sequence of past events – the same way a ledger works in accounting.

This technique is powerful for debugging, auditing, or migrating systems: you can replay all events in a new environment to rebuild state exactly as it was.

CQRS: Command Query Responsibility Segregation

CQRS (Command Query Responsibility Segregation) is a complementary pattern often used with Event Sourcing.
It separates the model for writing data (commands) from the model for reading data (queries).

• Commands modify system state by producing events (OrderPlaced, PaymentProcessed).

• Queries read data optimized for retrieval (for example, a denormalized “view” of orders).

This separation improves scalability and performance because the read and write sides can evolve independently – even use different databases.

Simplified diagram:

[User Action]
      │
      ▼
 ┌────────────┐
 │ Command API│  --->  emits --->  [Event Store]
 └────────────┘                      │
                                    ▼
                        ┌────────────────────┐
                        │  Read Model / View │
                        │ (e.g., MongoDB)    │
                        └────────────────────┘

Example (conceptual):

function placeOrder(order) {
  // Write model
  eventStore.push({ type: 'OrderPlaced', data: order });
}

function getOrdersView() {
  // Read model
  return eventStore
    .filter((e) => e.type === 'OrderPlaced')
    .map((e) => e.data);
}

Here, the event store acts as the single source of truth, while query views can be rebuilt or optimized as needed.

Difference Between Event Sourcing and Pub/Sub

It’s common to confuse Event Sourcing with simple event-driven messaging, but they solve different problems:

You can – and often should – use both together: an event-sourced service emits domain events to notify other systems.

When to Use Event Sourcing and CQRS

Use when:

• You need a complete audit trail or historical reconstruction.

• The business domain is complex and event-driven by nature (finance, logistics, IoT).

• The system requires high resilience and state recoverability.

Avoid when:

• You’re building a small, CRUD-oriented app with limited complexity.

• You don’t need event replay or full history, as it adds storage and operational overhead.

• Your team lacks experience managing distributed consistency and event evolution.

Summary

Event Sourcing and CQRS extend event-driven design to the data layer. Instead of only reacting to events, your system persists them and uses them as the foundation for rebuilding, auditing, and scaling.

This approach transforms your architecture from a static data store into a living timeline, where every change is captured as part of an ongoing story of the system’s behavior.

In the next section, we’ll analyze the benefits and challenges of event-driven architectures. We’ll explore why they scale so effectively, but also why debugging and observability can be tricky in large distributed environments.

8. Benefits and Challenges

Event-driven architectures offer remarkable scalability, resilience, and flexibility, qualities that make them a cornerstone of modern distributed systems. But these benefits come with trade-offs: debugging becomes more complex, data consistency is harder to guarantee, and operational visibility requires specialized tooling.

In this section, we’ll examine both sides — why EDAs are so powerful and what challenges teams face when implementing them.

Benefits of EDA

1. Scalability and Responsiveness

Event-driven systems naturally handle high concurrency. Because components react to events asynchronously, they can process workloads in parallel without blocking one another.

For example, in a retail platform:

• The Order Service publishes an event.

• The Inventory, Billing, and Notification services consume it concurrently.

This decoupling allows systems to scale horizontally, adding new consumers or instances without affecting existing ones.

Also, when combined with brokers like Kafka or RabbitMQ, EDAs can handle massive throughput while maintaining order and reliability.

2. Loose Coupling and Extensibility

In a traditional system, integrating new functionality often requires editing existing components. In an event-driven system, new consumers simply subscribe to existing events.

For instance, adding a new Analytics Service that listens for order:created events requires:

• No changes to the Order Service

• No disruption to other consumers

• No coordination between teams

This makes event-driven systems extensible by design, which is invaluable for large organizations with multiple teams or evolving business logic.

3. Resilience and Fault Isolation

Since communication is asynchronous, if one service fails, others can continue working. Events are buffered in the broker and delivered later.

This prevents cascading failures typical of tightly coupled, request-response systems. For example, if the Notification Service is down, orders can still be processed, and notifications will be sent once it recovers.

Many brokers also provide durable queues and retries, ensuring no event is lost even under heavy load or downtime.

4. Real-Time and Reactive Experiences

Event-driven systems power real-time applications, from chat apps and IoT platforms to fraud detection systems and live analytics dashboards.

Because events represent changes as they happen, they enable instant updates, alerts, and responsive UIs. When combined with technologies like WebSockets, Server-Sent Events, or GraphQL Subscriptions, the same model extends seamlessly to the frontend.

5. Auditability and Traceability

When paired with Event Sourcing, EDAs provide a complete audit trail of everything that has happened in the system. This is crucial for domains like finance, healthcare, or logistics, where compliance and historical accuracy are mandatory.

Challenges of EDA

1. Debugging and Tracing

Unlike synchronous systems, where a stack trace shows the full call path, event-driven systems are non-linear. An event may pass through multiple services, queues, and transformations before triggering an outcome.

This makes it difficult to answer questions like:

“Why did this event trigger twice?”
“Where did this data originate?”
“Which services consumed this message?”

To mitigate this, teams rely on distributed tracing tools such as:

• OpenTelemetry

• Jaeger

• Zipkin

• AWS X-Ray

• Kafka UI / Conduktor (for message inspection)

Embedding trace IDs in event metadata is a best practice that allows cross-service correlation of events.

2. Data Consistency

Because events are asynchronous, maintaining strict transactional consistency is challenging. For example, when an OrderPlaced event triggers multiple actions, those actions may complete at different times – or even fail independently.

To manage this, developers often use:

• Idempotent event handlers (safe to re-run)

• Outbox pattern (ensuring events are emitted only after successful database commits)

• Saga pattern (for distributed transactions and compensating actions)

These patterns add robustness but also increase system complexity.

3. Message Duplication and Ordering

In distributed systems, you must assume:

• Events may arrive twice (due to retries)

• Events may arrive out of order

Because of this, consumers need to be designed for idempotency and order independence. Many event stores or brokers (like Kafka) provide partitioning and offsets to preserve partial ordering, but global order is rarely guaranteed.

4. Operational Complexity

While adding a message broker improves decoupling, it also introduces new infrastructure to manage:

• Brokers and topics

• Retention policies

• Consumer groups

• Dead-letter queues (for failed messages)

Monitoring and maintaining these systems requires DevOps expertise and mature observability practices.

5. Team and Mental Model Shift

Event-driven systems require developers to think differently:

• Systems become reactive, not procedural.

• Data flows are eventual, not immediate.

• Debugging requires system-wide visibility, not local inspection.

For teams used to request-response logic, this transition can be difficult, requiring training, discipline, and careful design reviews.

Summary

Event-driven architectures offer:

• ⚙️ Scalability

• 🧩 Extensibility

• 🔁 Resilience

• ⚡ Real-time capabilities

But they demand:

• 🧠 Rethinking data flow

• 🔍 Better observability

• 🧰 Advanced tooling

When implemented carefully, EDAs unlock new levels of system flexibility and business agility, but success depends on balancing their power with strong governance, well-defined event contracts, and team alignment.

In the next section, we’ll look at real-world use cases, examining how leading industries like fintech, e-commerce, and IoT leverage event-driven architectures to achieve scale, responsiveness, and reliability.

9. Real-World Use Cases

Event-driven architectures are not just theoretical patterns. They power many of the systems we use every day. From instant payments to social networks, EDAs provide the backbone for handling real-time data, asynchronous workflows, and massive scalability.

Below are some of the most common and impactful use cases across different industries.

1. Financial and Banking Systems

Financial institutions rely heavily on asynchronous, reliable event flows to process millions of operations safely and in real time.

Typical Events

• TransactionInitiated

• FundsDeposited

• PaymentProcessed

• FraudAlertTriggered

How It Works

When a user initiates a payment:

1. The Payment Service emits a PaymentInitiated event.

2. The Fraud Detection Service subscribes to it, analyzing risk in parallel.

3. The Ledger Service records the transaction asynchronously.

4. The Notification Service sends confirmations.

Each component operates independently, and failures or slow responses in one don’t block others.

Benefits

• Real-time fraud detection

• Parallel transaction processing

• Clear audit trail for compliance (with Event Sourcing)

Example: Modern payment systems (like Revolut, Stripe, and PayPal) use event-driven microservices to orchestrate transactions securely and at scale.

2. E-commerce Platforms

E-commerce systems are naturally event-driven. Every customer action generates events that ripple across subsystems.

Typical Events

• OrderCreated

• ItemAddedToCart

• InventoryUpdated

• ShipmentDispatched

Event Flow Example

When a user places an order:

1. The Order Service emits OrderCreated.

2. Inventory Service reserves stock.

3. Billing Service processes the payment.

4. Shipping Service schedules delivery.

5. Analytics Service records metrics.

Each step occurs asynchronously, allowing thousands of orders to be processed concurrently.

Benefits

• High scalability during peak sales (for example, Black Friday)

• Fault isolation between modules

• Easy integration of new services (for example, loyalty or recommendation engines)

Example: Amazon and Shopify both use event-based pipelines for order management, tracking, and analytics.

3. IoT and Sensor Networks

In IoT ecosystems, thousands or millions of devices constantly emit data. Event-driven architectures are essential for ingesting, processing, and reacting to these streams efficiently.

Typical Events

• TemperatureMeasured

• DeviceConnected

• MotionDetected

• BatteryLow

Event Flow Example

1. Devices publish sensor data to a message broker (like MQTT, Kafka, or AWS IoT Core).

2. The Processing Service filters and enriches data.

3. Alert Services emit notifications if thresholds are crossed.

4. Analytics Pipelines store aggregated data for insights.

Benefits

• Real-time monitoring

• Predictive maintenance (based on event patterns)

• Scalable ingestion from thousands of sources

Example: Smart cities and connected vehicles use event-driven systems to react to sensor data in milliseconds, adjusting traffic lights, tracking fleets, or monitoring energy grids.

4. Real-Time Analytics and Monitoring

Modern analytics systems depend on stream processing, continuously ingesting and analyzing events to derive insights instantly.

Typical Events

• PageViewed

• UserLoggedIn

• MetricUpdated

Event Flow Example

1. Applications emit user interaction events to a message queue.

2. A Stream Processor (like Apache Flink or Kafka Streams) aggregates events in real time.

3. Dashboards and alerting systems consume processed results via WebSockets or APIs.

Benefits

• Live metrics and dashboards

• Early anomaly detection

• Continuous feedback loops for ML models

Example: Netflix uses event-driven data pipelines (built on Kafka) to monitor playback quality and deliver adaptive streaming experiences in real time.

5. Social Networks and Messaging Apps

Social platforms are fundamentally event-driven systems. Every post, like, message, or comment is an event that triggers updates across multiple systems.

Typical Events

• PostCreated

• MessageSent

• UserMentioned

• NotificationDelivered

Event Flow Example

When a user sends a message:

1. The Chat Service emits MessageSent.

2. The Notification Service alerts the recipient.

3. The Search Index Service updates conversations.

4. The Analytics Service logs engagement metrics.

Benefits

• Instant notifications and updates

• Asynchronous scalability across millions of users

• Modular and evolvable product features

Example: Slack, WhatsApp, and Facebook Messenger rely on distributed event buses to coordinate billions of message and presence events per day.

6. Workflow Automation and Orchestration

Workflow systems such as document approvals, CI/CD pipelines, or business processes are often built around events.

Typical Events

• TaskCreated

• TaskCompleted

• ApprovalGranted

• PipelineDeployed

How It Works

Each action in a workflow triggers the next step through events, allowing flexible orchestration without hardcoding dependencies. This makes it easy to reconfigure or extend workflows dynamically.

Example: GitHub Actions and Zapier use event-driven models to execute workflows automatically based on triggers (for example, a commit, file upload, or webhook).

Summary

Event-driven architectures power some of the most demanding digital systems in existence. Across industries, they provide:

• ⚙️ Scalable infrastructure for handling massive event streams

• ⏱ Real-time responsiveness to user and system actions

• 🧩 Modularity and evolution as systems grow by subscribing to new events

Whether in fintech, IoT, e-commerce, or analytics, EDAs have proven to be a flexible, future-proof foundation for building systems that react intelligently to change.

In the final section, we’ll synthesize the lessons learned, summarizing best practices, common pitfalls, and key takeaways for adopting event-driven architectures successfully in modern JavaScript ecosystems.

10. Best Practices and Conclusions

Event-driven architectures offer a flexible, scalable, and future-proof foundation for modern software systems. But their power comes with complexity: events are easy to emit but hard to manage at scale without discipline and consistency.

This final section distills practical best practices for designing and operating event-driven systems effectively, followed by a summary reflection on when and how to adopt this architecture.

1. Version and Validate Events

Events evolve over time as your system grows. Adding or changing fields can break consumers if versions aren’t managed carefully.

Best practices:

• Use explicit versioning in event names or schemas (for example, order:created.v2).

• Validate event payloads using JSON Schema or tools like ajv or Zod.

• Maintain a central event catalog or schema registry shared by all services.

This ensures backward compatibility and reduces surprises when consumers update at different times.

2. Design for Idempotency

In distributed systems, duplicate messages are inevitable – retries, network hiccups, or failovers can cause events to be processed multiple times.

Make consumers idempotent, meaning they can handle the same event repeatedly without unintended side effects.

For example:

if (!processedEvents.has(event.id)) {
  process(event);
  processedEvents.add(event.id);
}

Always include a unique event ID and check for duplicates before applying changes.

3. Keep Events Meaningful and Self-Contained

Each event should represent a domain-level change, not just a technical signal. Avoid overly generic messages like "update" or "dataChanged", as they make debugging and evolution difficult.

Good events:

• Describe what happened (not what to do).

• Include enough context for consumers to act independently.

• Avoid exposing internal database models directly.

Example:

{
  "event": "user:email:updated",
  "data": { "userId": 123, "oldEmail": "a@x.com", "newEmail": "b@x.com" }
}

This provides clear, business-oriented semantics.

4. Implement Robust Error Handling and Dead-Letter Queues

Not every event will be processed successfully. Network failures, schema mismatches, or transient service outages are inevitable.

Mitigation strategies:

• Use retry policies with exponential backoff.

• Send failed messages to a dead-letter queue (DLQ) for inspection.

• Build alerting and monitoring on DLQ metrics to detect recurring issues.

This ensures resilience and prevents message loss.

5. Ensure Observability and Traceability

Debugging asynchronous flows requires visibility. Embed tracing and correlation data into your events:

{
  "event": "payment:processed",
  "eventId": "9b7f...c0",
  "traceId": "c74d...d9",
  "timestamp": "2025-11-03T13:45:00Z"
}

Integrate with tools like:

• OpenTelemetry for distributed tracing

• Jaeger or Zipkin for visualization

• Kafka UI, Redpanda Console, or Conduktor for message inspection

This allows you to reconstruct event lifecycles across services, which is critical for debugging, compliance, and performance tuning.

6. Use Patterns for Reliability

Certain design patterns make large-scale event-driven systems more reliable:

Applying these patterns reduces race conditions and improves data consistency.

7. Choose the Right Broker for the Job

Different brokers serve different use cases:

Your choice depends on throughput, durability, and delivery guarantees.

8. Balance Event-Driven and Request-Driven Approaches

Event-driven systems excel in asynchronous workflows, but not everything should be event-driven.

Use synchronous APIs for immediate, transactional actions (for example, authentication, user profile lookup). And use events for background or decoupled processes (for example, analytics, notifications, async updates).

Combining both models yields the best balance of responsiveness and reliability.

9. Educate and Align the Team

Architecture is as much about people as it is about technology. Ensure developers share a common understanding of event naming conventions, schema versioning policies, error handling and retry rules, and ownership of producer and consumer responsibilities.

Without alignment, even the best tools lead to inconsistent, brittle systems.

10. Start Small, Then Evolve

You don’t need Kafka clusters or event sourcing to begin. Start small:

• Use Node.js EventEmitter or a simple in-memory bus for decoupling modules.

• Gradually evolve toward distributed brokers as complexity increases.

The key is incremental adoption – building understanding before scaling infrastructure.

Conclusion

Event-driven architectures fundamentally change how we design software. By focusing on what happens rather than what to do next, systems become more adaptable, reactive, and aligned with real-world processes.

In JavaScript – a language born from events – this paradigm feels especially natural. From browser interactions to Node.js microservices, event-driven thinking unifies the frontend and backend under a single principle: react to change.

When used wisely, EDA is not just a design pattern – it’s an architectural mindset that empowers systems to evolve continuously, communicate fluidly, and stay resilient in the face of complexity.

This article covers how to set up event handlers and proceeds to more elegant techniques for event management. You'll learn how to create events in React components, pass arguments to the handlers, and prevent default behaviors.

We'll also cover common event handling patterns and best practices to ensure your applications are performant and easy to maintain.

Basic Principles of Event Handling in React

Event handling in React is guided by a few basic principles that align with its component-based architecture. These principles include:

• Synthetic event system
• Naming conventions
• Passing event handlers as props
• Inline function and component methods

React uses a synthetic event system that ensures events behave consistently across different browsers. This wraps the native event system in browsers, providing a unified API regardless of the browser in which React is run.

Naming conventions revolve around a set of consistent naming that developers use for identifying events and the handler functions at a glance. Every event uses a camelCase naming convention, and the handler function they run is prefixed with "handle", followed by the event name. For example, an onClick event running a handleClick function.

Event handlers are the functions that run when the event is fired. They're usually defined before the render, just above the return statement. On many occasions, they are also passed as props to components. This aligns with React component-based architecture, allowing event logic to be embedded within the components using them.

In React components, events typically run inline functions or standalone functions within the component when fired. With this, you can utilize hooks like useState for state and useCallback for memoizing handler functions. This helps manage state changes and optimize performance.

How to Create Event Handlers in React Components

Creating an event in React starts with attaching the event name to the element that will fire it, with the handler function referenced in it:

<button onClick={handleClick}>
  Click me
</button>

What follows is to define that handler function, because it's the function that will run when the event is triggered:

const handleClick = () => {
   alert('You clicked me');
};

This is the full code that has been imported into the page.jsx file of a Next.js starter:

'use client';

const Counter = () => {
 const handleClick = () => {
   alert('You clicked me!');
 };

 return (
   <div className="p-10 flex items-center">
     <button
       onClick={handleClick}
       className="bg-green-400 px-4 py-2 rounded mx-auto"
     >
       Click me
     </button>
   </div>
 );
};

export default Counter;

And here's what shows in the browser when the button is clicked:

Next.js application displaying alert window

You can also trigger the event without a separate function. You can do this by defining the function to run as an anonymous function inside the event:

<button onClick={() => alert('You clicked me!')}>
  Click me
</button>

If you want to update the component state based on an event, you might need the useState hook. Here's an example that shows that using a simple counter application:

'use client';

import { useState } from 'react';

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

 return (
   <div className="flex items-center justify-center space-x-8 p-10">
     <button
       onClick={() => setCount(count - 1)}
       className="bg-red-500 hover:bg-red-600 text-white font-bold px-4 py-2 rounded "
     >
       Decrement
     </button>
     <p className="text-4xl font-semibold text-gray-800">{count}</p>
     <button
       onClick={() => setCount(count + 1)}
       className="bg-green-500 hover:bg-green-600 text-white font-bold px-4 py-2 rounded "
     >
       Increment
     </button>
   </div>
 );
};

export default Counter;

Counter App in Next.js (Animated GIF)

onChange and onSubmt are other popular events in React. onChange is used on input elements and onSubmit is used on a form element.

Here's an example of an onChange event:

'use client';

import { useState } from 'react';

const MyInput = () => {
 const [inputValue, setInputValue] = useState('');

 const handleChange = (e) => {
   setInputValue(e.target.value);
 };

 return (
   <div>
     <input
       type="text"
       value={inputValue}
       onChange={handleChange}
       className="border border-green-400 p-2 rounded shadow"
       placeholder="Type something..."
     />
     <p className="mt-4 text-green-400">You typed: {inputValue}</p>
   </div>
 );
};

export default MyInput;

Handling input changes in React

We'll look at an example of an onSubmit event in the section on how to prevent the default browser behavior when submitting a form.

Other examples of events include keyboard events like onKeyDown, onKeyPress, and onKeyUp, mouse events like onMouseUp, onMouseDown, onMouseEnter onDrag, and more. Any popular event in JavaScript is available in React. The only difference is that events are written in camelCase in React.

How to Pass Arguments to Event Handlers

Passing arguments to event handlers in React is a common requirement when you need to perform actions on specific data associated with an event. For example, deleting or editing a resource.

To do this, the handler function needs to take in a parameter:

const handleClick = (item) => {
   console.log('Button click for:', item);
 };

You then pass an argument corresponding to that parameter into the anonymous function of the event:

<button onClick={() => handleClick(item)}>Click Me</button>

Here's an example handling task deletion in a TaskManager component:

'use client';

import { useState } from 'react';

const TaskManager = () => {
 const [tasks, setTasks] = useState([
   { id: 1, text: 'Read an article' },
   { id: 2, text: 'Read a book' },
   { id: 3, text: 'Write an article' },
   { id: 4, text: 'Code' },
 ]);

 // Function takes a a taskId parameter
 const deleteTask = (taskId) => {
   setTasks((currentTasks) =>
     currentTasks.filter((task) => task.id !== taskId)
   );
   console.log('Deleted task with ID:', taskId);
 };

 return (
   <div className="p-5 max-w-md mx-auto bg-gray-100 rounded-lg shadow">
     <ul className="list-none space-y-2">
       {tasks.map((task) => (
         <li
           key={task.id}
           className="flex justify-between items-center bg-white p-3 rounded shadow-sm"
         >
           {task.text}
           <button
             // onClick event takes a task.id argument to account for the taskId parameter of the function
             onClick={() => deleteTask(task.id)}
             className="bg-red-500 hover:bg-red-700 text-white font-bold py-1 px-3 rounded"
           >
             Delete
           </button>
         </li>
       ))}
     </ul>
   </div>
 );
};


export default TaskManager;

Item delete is a great example of parametrized event handler

Common Event Handling Patterns in React

Event handling patterns refer to the techniques for handling user interactions within React components.

These patterns include but aren't limited to:

• Binding event handlers with useCallback to memoize the handler
• Event handlers with parameters (you've seen this in the section on how to pass arguments to event handlers)
• Conditional event handling
• Event delegation
• Event bubbling
• Optimized handling for lists
• Inline arrow functions (anonymous functions that you pass into event handlers)

Here's an example using useCallback to prevent creating a new function on every render:

'use client';

import { useCallback } from 'react';

function HandlerComponent() {
 const handleClick = useCallback(() => {
   console.log('Button clicked');
 }, []);

 return (
   <button onClick={handleClick}>
     Click Me
   </button>
 );
}

export default HandlerComponent;

And here's an example of conditional event handling:

'use client';

import { useState } from 'react';

function CheckLogin() {
 const [isLoggedIn, setLoggedIn] = useState(false);

 const toggleLogin = () => {
   setLoggedIn(!isLoggedIn);
 };

 const handleLogin = () => {
   if (isLoggedIn) {
     console.log('User is logged in');
   } else {
     console.log('User is logged out');
   }
 };

 return (
   <div>
     <h2 className="text-3xl text-center mb-4">
       {isLoggedIn ? 'User is logged in' : 'User is not logged in'}
     </h2>
     <button
       onClick={handleLogin}
       className="bg-green-400 hover:bg-green-500 px-2 py-3 rounded mr-3"
     >
       Check Login
     </button>
     <button
       onClick={toggleLogin}
       className="bg-green-400 hover:bg-green-500 px-2 py-3 rounded"
     >
       {isLoggedIn ? 'Log Out' : 'Log In'}
     </button>
   </div>
 );
}

export default CheckLogin;

Next.js app checks if user is logged-in

How to Prevent the Default Browser Behavior in Event Handlers

Default browser behavior is the automatic actions the browser performs when a specific event is fired. In event handling, the most common default browser behavior is that it refreshes when a form is submitted.

To prevent the browser from refreshing when a form is submitted, or prevent any other default behavior, pass the event parameter into the function handling the onSubmit event, then use that event to call a preventDefault function.

const handleSubmit = (event) => {
 // prevent the default behavior
 event.preventDefault();
};

return (
 // reference the function in onSubmit
 <form onSubmit={handleSubmit}>
   <input
     type="text"
     value={inputValue}
     onChange={handleInputChange}
     placeholder="Enter something..."
   />
   <button type="submit">Submit</button>
 </form>
);

Best Practices for Efficient Event Handling in React

Here are the most important rules for event handling in React:

Avoid Using Anonymous Arrow Functions Inside Events

It looks convenient to use arrow functions directly in events, like onClick={() => console.log('button clicked')}). The downside to this is that it can lead to performance issues because a new function is created on every render.

Always define the handler function to run when the event is fired outside the render method to avoid those performance issues.

Memoize Events with useCallback hook

For components that re-render often, memoizing the handlers in it with the useCallback hook can prevent unnecessary re-renders. This is useful when passing events as props to child components that might re-render unnecessarily.

Use Event Delegation

For multiple similar elements, like items in a list, consider using event delegation. Attach a single event listener to the parent element and use the event target to handle user interaction with child elements. This reduces the number of event listeners and can improve performance.

Prevent Default Behavior Where Necessary

Use event.preventDefault() in your event handlers when you need to stop the browser from performing default actions, like submitting a form. However, you should use this method prudently to avoid blocking browser behaviors unnecessarily.

Clean Up Event Listeners

If you set up your event listeners in useEffect, always return a cleanup function to remove the event listener. Otherwise, it'll cause memory leaks.

Test Event Handlers

Make sure your event handlers are covered in your unit and integration tests. Testing frameworks like Jest combined with React Testing Library can help verify that your event handlers are functioning as expected.

Conclusion

In this article, you learned the fundamentals of event handling in React, focusing on how to use the React synthetic event system to create events in React web apps.

We explored defining event handlers, passing arguments, and preventing default browser behaviors to enhance user experiences.

In addition, you learned about the benefits of using useCallback to optimize event handlers for efficient performance under various user interactions.

With these insights, you should be able to implement event handling in your projects, so you can improve both functionality and user engagement.

Bring your React skills to the next level

Would you like to learn more about event handling or other React concepts? Then join my React course on Udemy. I will show you how to become a better React developer by building a 2048 Game. Building games make learning more fun and enjoyable.

So join now and start your journey to mastering React!

Throughout this guide, we will explore the DOM's hierarchical tree structure, essential properties, and methods for accessing and modifying nodes. We'll also dive into event handling and various techniques for efficient DOM manipulation.

By the end of this guide, you should be able to confidently manipulate the DOM to meet the demands of your web development projects.

Prerequisites:

While this guide is designed to be beginner-friendly and accessible to anyone, having a basic understanding of JavaScript fundamentals will greatly enhance your ability to grasp the practical concepts covered.

Also, familiarity with HTML and CSS is a plus and will help you comprehend and apply the material we cover.

If you're new to JavaScript, consider familiarizing yourself with variables, data types, functions, loops, and basic DOM manipulation techniques before diving into this tutorial. This foundational knowledge will ensure a smoother learning experience as we explore more advanced topics related to the Document Object Model (DOM).

Table of Contents

1. What is the Browser Object Model (BOM)?
2. What is the Document Object Model (DOM)?
3. DOM Tree Structure
   – Types of Nodes in the DOM Tree
   – Node Relationships
4. How to Work with DOM Elements
   – Traversing the DOM
   – Methods for Querying DOM Elements
   – Specialized Selectors (Matches, Closest, Contains)
   – How to Inspect DOM Elements
   – Table Navigation in the DOM
5. How to Modify DOM Elements
   – How to Manipulate Element Content and Visibility
   – How to Modify Element Attributes
   – HTML Insertion Methods
   – How to Manipulate Classes with JavaScript
6. Event Handling in the DOM
   – Common Types of Events
   – Event Handlers
   – Event Propagation
   – Event Bubbling
   – Event Delegation
7. Conclusion

What is the Browser Object Model (BOM)?

The Browser Object Model is like a set of tools provided by the browser itself. It's not part of the official DOM specification, but it's specific to web browsers. As a result, the objects and methods available in the BOM may vary between different browsers.

The BOM provides JavaScript access to browser-specific things like the browser's history, location, and browser window itself.

Window Object

The window Object serves as a global object in the browser, representing the browser window and is the top-level object in JavaScript when we're working in a web browser. You can access it by typing window in the browser console:

console.log(window); // prints the Window object

Since, it's global, you can access it from anywhere and use it to access other global objects such as the console and the alert function.

The window object is a key part of the BOM and provides access to many browser-related things. For example, window.location.href gives you the URL of the current web page.

Functions like alert(), prompt(), and confirm() are also part of the BOM, allowing you to interact with users through pop-up dialogs.

What is the Document Object Model (DOM)?

The Document Object Model (DOM) is a programming interface for web documents. It represents the structure of a web page, allowing interaction with its elements using programming languages like JavaScript.

The DOM contains the document object, which represents the DOM structure of the current web page and has properties and methods that allow you to manipulate the DOM.

You can access the document object by typing document in the browser console:

console.log(document); // prints the DOM object

You use document object to access and manipulate different parts of the HTML document. Elements within the DOM can be accessed using properties and methods of this object.

Examples include accessing the body or title element, retrieving HTML content (innerHTML), accessing text content (innerText) and changing styles.

// Accessing the document's title
console.log(document.title);

// Changing the document's title
document.title = "changed Title";

// Accessing the document's body 
console.log(document.body);

// Changing background color of body element using inline CSS
document.body.style.backgroundColor = "red";

You can use the DOM to interact with web pages dynamically. This allows JavaScript to access, modify, and manipulate the content, structure, and style of a web document in response to user actions or other events.

Let's illustrate the concept of DOM manipulation with a simple example:

<html>
  <body>
    <div id="container">
      <p id="message">Hello, World!</p>
      <button id="changeText">Change Text</button>
    </div>

    <script>
      // we select the paragraph element by its ID
      let messageElement = document.getElementById("message");

      // let's add event listener to button element using ID
      document
        .getElementById("changeText")
        .addEventListener("click", function () {
          // this  will change the text content of the paragraph element
          messageElement.textContent = "Text Changed!";
        });
    </script>
  </body>
</html>

In this example, we have an HTML document with a <div> container containing a <p> element and a <button> element.

Using JavaScript, we can select the <p> element by its ID and attach an event listener to the <button> element. When the button is clicked, the text content of the paragraph element is changed dynamically.

DOM Tree Structure

The DOM represents the layout of HTML and XML documents as a tree-like structure, resembling the hierarchical arrangement of elements on a web page. In this tree, each node represents a part of the document, such as HTML elements, attributes, and text.

The top-level node in the tree is called the document node, which represents the entire HTML document. From there, it branches out to include all elements and their relationships within the document. Here's a visual representation of that:

DOM Tree of Objects

Types of Nodes in the DOM Tree

There are two main types of nodes in the DOM:

1. Element Nodes: Represent HTML elements such as <div>, <h1>, <p>, <span>, and so on. These nodes make up the backbone of the DOM tree and form the structure of the HTML document.
2. Text Nodes: Represent text content within HTML elements. Text always serves as the last child (leaf node) of an element node and cannot contain any child nodes.

In HTML, whitespace such as spaces, tabs, and line breaks are considered part of the text content within HTML elements and are represented as text nodes.

Linebreak is 1st child node, div (Blue) is 2nd, linebreak again 3rd

We can see all the nodes here including non-element ones (like text nodes or comment nodes)

We also have:

• Attribute Nodes: Represent attributes of HTML elements, for example id, class, src, href, and so on.
• Comment Nodes: Nodes representing comments within the HTML markup.

To access and manipulate DOM elements, we can "walk" through the tree structure using JavaScript. For instance:

• document.head: Selects the <head> element of the current HTML document.
• document.body: Selects the <body> element of the current HTML document.
• document.documentElement: Selects the root element of the DOM tree, that is <html>.

Once we access an element, we can modify its attributes or properties accordingly. For example, we can alter the background color of the <body> element to red by executing document.body.style.backgroundColor = "red" in the console.

We can see the body color has changed to "red"

Node Relationships

Nodes in the DOM tree have parent-child relationships, which form the hierarchical structure of the tree. A child is an element that directly resides within another element (the parent).

<div id="container">
    <p>Hello, World!</p>
    <button>Click Me</button>
</div>

In the DOM tree, sibling elements are arranged linearly. The element to the right of the current element is called the next sibling, while the element to the left is called the previous sibling.

In the above example, the <p> element (previous sibling of ) and the <button> element (next sibling of

) are sibling nodes as they share the same parent. They are both children nodes of the <div> element with the ID "container". So the <div> element serves as the parent node of both the <p> and <button> elements.

Elements positioned above a given element in the DOM tree hierarchy are called ancestors. In the given code, the <html> element acts as the ancestor of the <body>, <h1>, and <p> elements, and they are descendants of the <html> element.

How to Work with DOM Elements

Now, let's dive into accessing nodes in the DOM using various properties and methods.

Traversing the DOM:

When working with the Document Object Model (DOM), it's important to understand the distinction between element nodes (HTML elements) and non-element nodes (like text nodes, comments, and so on). Certain properties and methods specifically deal with either element nodes or all types of nodes, including non-element nodes.

NodeList vs. HTMLCollection: Different properties return different collections of nodes. NodeList contains all types of nodes, while HTMLCollection specifically holds element nodes. Understanding this distinction is crucial for interpreting the results.

Properties for All Nodes (Including Non-element Nodes): These properties return nodes of all types, including element nodes, text nodes, and comment nodes.

childNodes returns a NodeList containing all child nodes and the parentNode property returns the parent node of the specified node. For example:

// Access the first child of the body node
console.log(document.body.childNodes[0]);


// parentnode; the parent of a <p> element within a <div> would be the <div> itself.
let p = document.querySelector('p'); // Select the <p> element
console.log(p.parentNode); // Output: <div> element (parent of p);

Spaces between tags and line returns in HTML code are considered text nodes by the browser. So, the actual first child node might not be what you expect.

firstChild/lastChild: Returns the first/last child node, again including all types.

document.body.firstChild; // Outputs: First child node (likely a linebreak(text node))
document.body.lastChild; // Outputs: Last child node (likely a script tag)

So we can say the following:

element.childNodes[0] === element.firstChild;
element.childNodes[element.childNodes.length - 1] === element.lastChild;

nextSibling/previousSibling: returns the next sibling/previous sibling node, including all of them.

Element specific properties or Element only navigation: These properties provide a convenient way to access only element nodes, excluding text nodes and comments.

children returns a live HTMLCollection of direct child elements, and the parentElement property returns the parent element node of the specified node.

In the below screenshot, you can see the difference between childNodes and children:

Here, Linebreak (text node) will be considered 1st child node of body element, whereas div.color (Blue) will be considered the 1st child.

For instance, let's say we have this code:

// childnode
console.log(document.body.childNodes);

// children
console.log(document.body.children);

// childnode
NodeList(19) [text, div.color, text, div.color, text, comment, text, div.color, text, div.color, text, div.color, text, script, text, comment, text, script, text]


// children
HTMLCollection(7) [div.color, div.color, div.color, div.color, div.color, script, script]

and, if we refresh the page, the output gets:

NodeList(14) [text, div.color, text, div.color, text, comment, text, div.color, text, div.color, text, div.color, text, script]
HTMLCollection(6) [div.color, div.color, div.color, div.color, div.color, script]

Initially, the NodeList contains 19 nodes. These nodes consist of text nodes, div elements with the class "color", a comment node, and script elements. The HTMLCollection contains 7 elements, which are the div elements with the class "color" and script elements.

When the page is refreshed, some elements or nodes are removed or modified dynamically through JavaScript or other means, leading to the observed changes in the DOM structure.

firstElementChild/lastElementChild returns the first/last child, excluding non-element nodes.

// Both will exclude text nodes and comment nodes.
document.body.firstElementChild; // Outputs: <div class="color">
document.body.lastElementChild; // Outputs: <script src="script.js">

Key Points:

• Choose the right property based on whether you need to target all nodes or specifically element nodes.
• Remember that properties like firstChild and previousSibling might return element and non-element nodes, while their element-specific counterparts (firstElementChild and previousElementSibling) focus only on elements.

Methods for Querying DOM Elements:

JavaScript provides several methods for accessing elements in the DOM:

• getElementById: This method retrieves an element by its unique ID attribute.

let element = document.getElementById("myElement");

• getElementsByClassName: This method returns a collection of elements with the specified class name.

let elements = document.getElementsByClassName("myClass");

• getElementsByTagName: This method returns a list of collection of elements with the specified tag name.

let elements = document.getElementsByTagName("div");

• querySelector: This method retrieves the first element that matches a specified CSS selector.

let element = document.querySelector("cssSelector");

• querySelectorAll: This method retrieves all elements that match a CSS selector.

let elements = document.querySelectorAll("cssSelector");

You might be wondering how querySelector differs from querySelectorAll.

Well, querySelector returns the first element within the document that matches the specified selector. On the other hand, querySelectorAll returns a static NodeList representing a list of the document's elements that match the specified group of selectors.

When you're using querySelectorAll, you receive a NodeList, which is similar to an array but not exactly the same. You cannot directly manupulate all elements like appling styles to all elements within a NodeList using methods like style.backgroundColor = 'red'. So we use a forEach loop. For example:

console.log(document.querySelectorAll(".box"));

document.querySelectorAll('.box').forEach(element => {
    // Within the forEach loop, we access each element and set its background color to green.
    element.style.backgroundColor = "green";
});

Let's see what's going on in this code:

• In the first line, we directly change the background color of the element with the class 'box' using querySelector.
• In the second line, we use querySelectorAll to select all elements with the class 'box' and log the NodeList to the console.
• In third line, since querySelectorAll returns a NodeList, we need to iterate through each element in the NodeList in order to apply the background color to each element separately.
• so basically, we can say querySelector is equivalent to querySelectorAll('section')[0].

Alright, one last method to consider:

• getElementsByName: This method returns a list of collection of elements with the specified name attribute.

let items = document.getElementsByName('some-name-attribute');
console.log(items);

These methods are important to understand because they are used in various situations.

For example, when we want to select all the div elements in the document, we can use the querySelectorAll method or the getElementsByTagName method. Both methods will return the same result, but querySelectorAll is more flexible because it can select elements that match any CSS selector. getElementsByTagName can only select elements that have the same tag name.

Matches, Closest, and Contains:

When you're working with JavaScript and dealing with web pages, you often need to find specific parts of the page or do things with them. Three methods you might use are matches(), closest(), and contains().

matches() checks if an element matches a certain style rule. For example, if you have a button and you want to see if it has a class of "active", you could use button.matches('.active'). It will return true if the button has that class, and false if it doesn't.

const button = document.querySelector('button');
if (button.matches('.active')) {
  console.log('The button is active');
} else {
  console.log('The button is not active');
}

If you have an element and you want to find its nearest parent with a certain class, you can use **closest()** like this: element.closest('.classname').

For instance, if you have a link inside a list item and you want to find the nearest list item, you could do link.closest('li').

const link = document.querySelector('a');
const listItem = link.closest('li');
console.log(listItem); // This will give you the nearest list item

And contains() checks if one element is inside another. For example, if you have a div and a paragraph inside it, you could check if the div contains the paragraph with div.contains(paragraph). It will return true if the paragraph is inside the div, and false if it's not.

const div = document.querySelector('div');
const paragraph = document.querySelector('p');
if (div.contains(paragraph)) {
  console.log('The div contains a paragraph');
} else {
  console.log('The div does not contain any paragraph');
}

These methods are handy for navigating around your web page and doing different things with its elements.

How to Inspect DOM Elements

Using console.dir(): console.dir() is not a method of the DOM. It's a method provided by the browser's Console API, specifically used for logging JavaScript objects to the console.

If we log an element using console.log(), we see its HTML representation. But with console.dir(), we get an interactive list showing all available attributes and functions for that element.

tagName and nodeName: tagName is a property specific to HTML elements. It returns the tag name of an HTML element in uppercase letters. For example, if you have an HTML element <div>, tagName will return "DIV".

On the other hand, nodeName is a property of DOM nodes that represents the name of the node. For element nodes, it returns the tag name in uppercase. For other types of nodes, it returns a string representing the type of node (for example, "#text" for text nodes, "#comment" for comment nodes).

Discovering a node's type: Each node in the DOM has a nodeType property that indicates its type. It has a numeric value: 1 for elements, 2 for attributes, 3 for text nodes, 8 for comment and 9 for document. Read-only. This property can be used to distinguish between element nodes and text nodes. For example:

const element = document.createElement('div');
console.log(element.nodeType); // Output: 1

Table Navigation in the DOM

Now, let's learn how to navigate a table element and its child nodes using the DOM. Here, instead of manually writing a table, we will use Bootstrap's pre-designed table.

Before diving into table navigation, let's discuss Bootstrap, a popular front-end framework offering pre-designed components and styles for building responsive web pages efficiently.

To integrate Bootstrap into our project, we'll:

1. Copy the pre-designed table from here.
2. Paste it into a container <div> in our HTML.
3. Include Bootstrap's CSS and JS files in our webpage (which you can copy from here).

Here's how our HTML code will look after integration:

<!DOCTYPE html>
<html>
<head>
    <title>Table Navigation</title>
    <link rel="stylesheet" href="styles.css">
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha3/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-KK94CHFLLe+nY2dmCWGMq91rCGa5gtU4mk92HdvYe+M/SXH301p5ILy+dN9+nJOZ" crossorigin="anonymous">
</head>
<body>
   <div class="container">
    <!-- Bootstrap Table -->
    <table class="table">
        <!-- Table Header -->
        <thead>
          <tr>
            <th scope="col">#</th>
            <th scope="col">First</th>
            <th scope="col">Last</th>
            <th scope="col">Handle</th>
          </tr>
        </thead>
        <!-- Table Body -->
        <tbody>
          <tr>
            <th scope="row">1</th>
            <td>Mark</td>
            <td>Otto</td>
            <td>@mdo</td>
          </tr>
          <tr>
            <th scope="row">2</th>
            <td>Jacob</td>
            <td>Thornton</td>
            <td>@fat</td>
          </tr>
          <tr>
            <th scope="row">3</th>
            <td colspan="2">Larry the Bird</td>
            <td>@twitter</td>
          </tr>
        </tbody>
      </table>
   </div>
    <script src="script.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha3/dist/js/bootstrap.bundle.min.js" integrity="sha384-ENjdO4Dr2bkBIFxQpeoTz1HIcje39Wm4jDKdf19U8gI4ddQ3GYNS7NTKfAdVQSZe" crossorigin="anonymous"></script>
</body>
</html>

Table navigation properties:

The table element supports various properties for convenient navigation, such as:

• table.rows: Returns an HTMLCollection of all rows in the table.
• table.caption: Returns the caption element of the table.
• table.tHead: Returns the thead element of the table.
• table.tFoot: Returns the tfoot element of the table.
• table.tBodies: Returns an HTMLCollection of all tbody elements in the table.

Similarly, the tr (table row) element supports properties like:

• tr.cells: Returns an HTMLCollection of all cells in the row.
• tr.sectionRowIndex: Returns the index of the row in the current section (thead, tbody, or tfoot).
• tr.rowIndex: Returns the index of the row in the table.

The td (table cell) element also supports the td.cellIndex property, returning the index of the cell in the row.

For instance, to print all rows in the table:

let t = document.body.firstElementChild.firstElementChild; // Selecting the table
for (let i = 0; i < t.rows.length; i++) {
    let row = t.rows[i];
    console.log(row)
}

To print cells in the first row:

let t = document.body.firstElementChild.firstElementChild; // Selecting the table
let row = t.rows[0]; // Selecting the first row
for (let i = 0; i < row.cells.length; i++) {
    let cell = row.cells[i];
    console.log(cell)
}

How to Modify DOM Elements

Once you have access to DOM elements, you can modify them in various ways using JavaScript.

How to Manipulate Element Content and Visibility

innerHTML and outerHTML

You can use innerHTML to access or change the HTML content inside an element as a string. outerHTML, on the other hand, lets you get or set the HTML content of an element as a string, including the original element itself.

Here's an example:

<body>
    Hello World
    <span>Hey I am span</span>
    <script src="script.js"></script>
</body>

let first = document.getElementsByTagName("span")[0]; // 

// log and change inner HTML
console.log(first.innerHTML); // Output: Hey I am span
first.innerHTML = "Hey I am changed"; // Modify the content of the <span> element

// log and change outer HTML
console.log(first.outerHTML); // Output: <span>Hey I am span</span>
first.outerHTML = "<h1>Hey I am changed</h1>"; // Reload the page to see the change

textContent property

The textContent property allows you to set or retrieve the text content of an element, ignoring any HTML tags within it. It's useful when you want to update the text content of an element without affecting its HTML structure.

console.log(first.textContent); // output: Hey I am span

// change the text content
first.textContent = "Hey I am changed";

innerText property

The innerText property returns only the visible text content of an element, excluding any text within <script> and <style> elements, and accounting for CSS styling that affects visibility. It takes into account CSS styling, such as display: none, visibility: hidden, and so on and returns only the text that is rendered on the screen.

style property

This property provides access to an object for manipulating an element's inline styles (for example, element.style.color = "red").

hidden property

The hidden provides a simple and convenient way to control the visibility of elements in the DOM without directly manipulating their style properties.

document.getElementsByTagName('span')[0].hidden = true;

// When hidden is set to false, the element is visible.

Note that setting an element's hidden property to true only hides it from view, but it still occupies space in the document layout.

How to Modify Element Attributes

The getAttribute() method retrieves the value of a specified attribute of an element, while setAttribute() sets or updates the value of a specified attribute.

hasAttribute() checks whether an element has a specific attribute, returning true or false. The removeAttribute() method removes a specified attribute from an element.

In HTML5, it's possible to define custom attributes for elements. But to prevent potential conflicts with future HTML or JavaScript updates, you should prefix custom attributes with data-. For instance:

<div id="element1" class="sample" data-category="music" data-rating="5">
    This is the first element.
</div>

To access these custom attributes using JavaScript, we can utilize the dataset property. For example:

console.log(element1.dataset);

This will display a DOMStringMap object containing all the custom attributes associated with the "element1" div. Specific custom attributes can also be accessed by their names. For example:

console.log(element1.dataset.category);

// This code would output the value of the "category" custom attribute, which in this case is "music"

HTML Insertion Methods

In HTML, there are several ways to insert new content or modify existing content dynamically using JavaScript. These are known as HTML insertion methods.

Consider the following HTML as our example:

<html>
<head>
</head>
<body>
    <div class="container">
        <div id="first">first element</div>
    </div>
    <script src="script.js"></script>
</body>
</html>

Classic Way to Insert HTML:

A conventional way to insert HTML is by using the innerHTML property. For example, let's say we want to add an h1 element with the text "Hello World" inside the first div. We can do this using the following code:

let a = document.getElementsByTagName('div')[0];
a.innerHTML = '<h1>Hello World</h1>';

We could also append new HTML to the existing HTML inside the div element. For example:

// This will retain the old content and add a new h1 element.
let a = document.getElementsByTagName('div')[0];
a.innerHTML = a.innerHTML + '<h1>Hello World</h1>';

Using createElement to Insert HTML:

Another method involves creating a new element using createElement, setting its content using innerHTML, and subsequently appending it to the target element using appendChild.

Other HTML Insertion Methods:

<!DOCTYPE html>
<html>
<head>
</head>
<body>
I am outside div (start)
<div class="container">
    I am start of this container
        <div id="first">I am first element</div>
    I am end of this container
</div>
I am outside div (end)
    <script src="script.js"></script>
</body>
</html>

Now, let's consider other methods for inserting HTML content dynamically:

let a = document.getElementsByTagName('div')[0];

// Using createElement and appendChild
let div = document.createElement('div');
div.innerHTML = '<h1>Hello World (append)</h1>';
a.appendChild(div);

// Using prepend
let div = document.createElement('div');
div.innerHTML = '<h1>Hello World (prepend)</h1>';
a.prepend(div);

// Using before
let div = document.createElement('div');
div.innerHTML = '<h1>Hello World (before)</h1>';
a.before(div);

// Using after
let div = document.createElement('div');
div.innerHTML = '<h1>Hello World (after)</h1>';
a.after(div);

// Using replaceWith
let div = document.createElement('div');
div.innerHTML = '<h1>Hello World (replaced)</h1>';
a.replaceWith(div);

This code demonstrates different methods for dynamically inserting HTML content into the DOM using JavaScript.

• a.append(div): This method appends the div element as the last child of the a element.
• a.prepend(div): This method adds the div element as the first child of the a element.
• a.before(div): This method adds the div element before the a element.
• a.after(div): This method adds the div element after the a element.
• a.replaceWith(div): This method replaces the a element with the div element.

The insertAdjacentHTML, insertAdjacentElement, and insertAdjacentText Methods

These methods are used to insert content into the DOM at a specified position relative to a given element. They are helpful when you need to dynamically add new elements or text to your webpage.

insertAdjacentHTML:

insertAdjacentHTML allows you to insert a string of HTML at a specified position relative to the element.

The first parameter specifies where the HTML string will be inserted:

• beforebegin: Before the element itself.
• afterbegin: Just inside the element, before its first child.
• beforeend: Just inside the element, after its last child.
• afterend: After the element itself.

Example usage:

let element = document.getElementById('example');
element.insertAdjacentHTML('beforebegin', '<div>New content</div>');

insertAdjacentElement:

It's similar to insertAdjacentHTML, but instead of inserting HTML, you can insert a DOM element.

Example usage:

let element = document.getElementById('example');
let newElement = document.createElement('div');
newElement.textContent = 'New content';
element.insertAdjacentElement('beforebegin', newElement);

insertAdjacentText:

It's similar to insertAdjacentHTML, but instead of inserting HTML, you can insert plain text.

Example usage:

let element = document.getElementById('example');
element.insertAdjacentText('beforebegin', 'New content');

Node Removal:

The remove method removes the element from the DOM.

Example usage:

let element = document.getElementById('example');
element.remove();

These methods allow you to manipulate the DOM dynamically, adding or removing content based on certain conditions or user interactions.

When using insertAdjacentHTML, insertAdjacentElement, or insertAdjacentText, you specify where the new content should be inserted relative to the given element.

When using remove, you simply remove the element from the DOM entirely.

These methods are helpful for dynamically updating the content of your webpage without having to reload the entire page.

How to Manipulate Classes with JavaScript

In HTML, we use classes to group elements and apply styles using CSS. For example, we have a div with an id of "first" in our HTML.

<div id="first">
    <span>Hello, this is text</span>
</div>

We also have CSS styles for classes like "yellow", "red", and "text-dark" to change background color and text color.

.yellow {
    background-color: yellow;
    color: white;
}
.red {
    background-color: red;
    color: white;
}
.text-dark {
    color: black;
}

className: In JavaScript, we can change the class of an element using the className property. For instance, if we want to change the class of the element with the id "first" to "red text-dark", we would do:

// we are applying 2 classes here
first.className = "red text-dark";

If we want to add another class without removing the existing ones, we use the += operator:

first.className += " yellow"; // Adds the class "yellow" without removing existing classes

classList: The classList property allows you to manipulate the classes of an element. We can use methods like add, remove, toggle, and contains to add, remove, toggle, or check the presence of a class.

• classList.remove(): Removes a specific class from the element:

first.classList.remove('text-dark'); // Removes the class "text-dark"

• classList.add(): But wait, it looked better with that class! We can also add it back with:

first.classList.add('text-dark'); // Adds the class "text-dark"

• classList.toggle(): Toggles a class on or off based on its presence:

first.classList.toggle('text-dark'); // Toggles the class "text-dark" (adds if absent, removes if present)

• classList.contains(): Checks if a class is present on the element:

console.log(first.classList.contains('text-dark')); // Returns true if the class "text-dark" is present

Event Handling in the DOM

Events are actions or occurrences that happen in the system you are programming, that the system may need to respond to in some way.

In the context of web development, events (Browser Events) can be user interactions like clicks, mouse movements, key presses, and so on. JavaScript allows you to handle these events and perform actions in response to them.

In HTML, you can directly specify what should happen when an event occurs using attributes like onclick, onmouseover, and so on. For example:

<button onclick="alert('hello')">Click me</button>

While you can write JavaScript directly in HTML attributes, it's always better to keep your HTML clean and handle events in JavaScript code separately. This makes your code easier to read and maintain.

You can do this by selecting elements from the webpage using JavaScript and then attaching an event handler to them. Here's how you might do it:

let container = document.getElementById("container");
container.onclick = function() {
    console.log("Hey, this is logged from the script!");
}

In this code, we select the element with the id "container" using document.getElementById(). Then, we attach a function to the onclick event of that element. This function will be executed whenever the element is clicked.

Common Types of Events:

1. Mouse Events: These events are related to interactions with the mouse.

2. click: When you click on an element.

3. contextmenu: When you right-click on an element.
4. mouseover / mouseout: When the mouse cursor enters or leaves an element.
5. mousedown / mouseup: When you press or release a mouse button over an element.
6. mousemove: When the mouse is moved.

Some Examples of Mouse Events:

// Mouse Button Property Example:

<div onmousedown="console.log('Mouse button:', event.button)">Click me</div>

In this example, the event.button property is used to log which mouse button was pressed.

// Modifier Keys Example:

<div onclick="if(event.ctrlKey) console.log('Ctrl + Click!')">Ctrl + Click Me</div>

This example logs a message when the user clicks the element while holding the Ctrl key.

// Coordinates Example:

<div onmousemove="console.log('clientX:', event.clientX, 'clientY:', event.clientY)">Move your mouse here</div>

This example logs the clientX and clientY coordinates of the mouse pointer as it moves over the element.

// Preventing Selection Example:

<span ondblclick="console.log('Double clicked!')" onmousedown="return false;">Double-click me</span>

In this example, the return false statement in the onmousedown event handler prevents the default selection behavior when the element is double-clicked.

2. Keyboard Events – keydown / keyup: When a key is pressed or released on the keyboard.

Some Examples of Keyboard Events:

<input type="text" onkeydown="console.log('Key pressed!')" onkeyup="console.log('Key released!')">

In this example, the input field triggers events when a key is pressed (keydown) and released (keyup).

// Event Modifiers Example:

<input type="text" onkeydown="if(event.ctrlKey && event.key === 'c') console.log('Ctrl + C pressed!')">

This example logs a message when the user presses the Ctrl key and 'c' key simultaneously in the input field.

// Accessing Key Information Example:

<input type="text" onkeydown="console.log('Key pressed:', event.key)">

This example logs the key that was pressed in the input field.

3. Form Element Events: These events occur when you interact with form elements, like submitting a form, focusing on an input field, and so on.

4. Document Events: These events are related to the document object itself. Example: DOMContentLoaded (when the HTML is fully loaded and the DOM is ready)

5. CSS Events: These events are related to CSS animations. Example: transitionend (When a CSS animation finishes)

Now, let's see an example demonstrating the practical application of event handling and input validation in web development:

<html>
<head>
<title>Input Validation Example</title>
<script>
function checkPhoneNumber(event) {
  const validKeys = ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '+', '(', ')', '-'];
  if (!validKeys.includes(event.key)) {
    event.preventDefault(); // Prevent default action for invalid keys
  }
}
</script>
</head>
<body>
<label for="phone">Enter Phone Number:</label>
<input type="tel" id="phone" onkeydown="checkPhoneNumber(event)">
<p>Only digits, +, (, ), and - are allowed.</p>
</body>
</html>

In this example, we're implementing input validation for a phone number input field. The onkeydown event triggers the checkPhoneNumber function, which checks if the pressed key is valid (digits, plus sign, parentheses, or hyphen). If the key is not valid, the default action (character input) is prevented.

You can explore more about events here.

Event Handlers

To react to these events, we use event handlers. An event handler is simply a function that runs when a specific event occurs. There are different ways to assign event handlers in JavaScript:

1. HTML Attribute: You can set an event handler directly in the HTML code using an attribute like onclick, onmouseover, etc.

<button onclick="alert('Button clicked!')">Click me</button>

2. DOM Property: You can assign a handler using a DOM property like onclick, onmouseover, and so on.

<button id="myButton">Click me</button>
<script>
  document.getElementById("myButton").onclick = function() {
    alert('Button clicked!');
  };
</script>

3. Event Listeners: Event listeners are functions that wait for a specific event to occur and then execute a designated function. This is typically done using the addEventListener method.

addEventListener() and removeEventListener():

These are methods used to assign and remove event handlers, respectively, in JavaScript.

• **addEventListener()** is used to attach an event listener to an element, which listens for a specific event (for example, a click or mouseover). It provides more flexibility, especially when you need to add multiple handlers to the same event.

<button id="myButton">Click me</button>
<script>
  document.getElementById("myButton").addEventListener('click', function() {
    alert('Button clicked!');
  });
</script>

const btn = document.getElementById('btn');

// Example 1: Adding event listeners directly with anonymous functions
btn.addEventListener('click', function(e) {
    console.log("Button clicked!"); // Logs a message when the button is clicked
});

// Example 2: Defining functions separately and then adding event listeners
function greet() {
    console.log("Hello!");
}
function farewell() {
    console.log("Goodbye!");
}
btn.addEventListener('mouseenter', greet); // Greets when the mouse enters the button
btn.addEventListener('mouseleave', farewell); // Says goodbye when the mouse leaves the button

With addEventListener, you can also specify additional options as a third argument. Some common options are:

• once: A boolean value that specifies whether the event listener should be removed after it is invoked once.
• capture: A boolean value that specifies whether the event should be captured during the capturing phase. The capturing phase happens before the bubbling phase.

For example:

btn.addEventListener('click', handleClick, { once: true, capture: true });

This will add a click event listener to the button element that is triggered only once and captures the event during the capturing phase.

• **removeEventListener()** is used to remove a previously attached event listener from an element.

// Example 1

<button id="myButton">Click me</button>
<script>
  function handleClick() {
    alert('Button clicked!');
  }

  document.getElementById("myButton").addEventListener('click', handleClick);
  // Remove the event handler
  document.getElementById("myButton").removeEventListener('click', handleClick);
</script>

// Example 2
// Assume a user preference
const allowGreetings = true;

// Removing event listeners based on user preference
if (!allowGreetings) {
    btn.removeEventListener('mouseenter', greet);
}

Object Handlers: handleEvent

Instead of assigning a function as an event handler, you can also assign an object that has a handleEvent method. When the event occurs, the handleEvent method of the object will be called.

<button id="myButton">Click me</button>
<script>
  let myObject = {
    handleEvent: function(event) {
      alert('Button clicked!');
    }
  };

  document.getElementById("myButton").addEventListener('click', myObject);
</script>

In this example, when the button is clicked, the handleEvent method of myObject is called.

Event Object:

When an event occurs, the browser creates an event object that contains information about the event, such as the type of event, the target element, and any additional data.

This object is passed as an argument to the event handler function which can be accessed within the callback function of an event listener.

element.addEventListener('click', function(event) {
    console.log(event.type); // Output: "click"
    console.log(event.target); // Output: The element that was clicked
     // We can access more properties like event.clientX, event.clientY, etc.
});

Event Propagation:

Events in the DOM can propagate through the DOM tree in two phases: the capturing phase and bubbling phase.

When an event happens on an element, like a click or a key press, the browser needs to decide which elements should be notified about the event.

Event capturing and bubbling describe the order in which elements are notified about the event. Understanding event propagation is important when dealing with nested elements and event delegation.

1. Capturing Phase: In the capturing phase, the event starts from the top of the DOM hierarchy (usually the <html> element) and travels down to the target element. During this phase, event handlers attached with addEventListener and the capture option set to true are triggered. These handlers are executed before the event reaches the target element.
2. Target Phase: Once the event reaches the target element, it enters the target phase. Event handlers attached with addEventListener without the capture option (or with false as the value) are triggered during this phase. Handlers attached in this phase are executed when the event is directly targeting the element.
3. Bubbling Phase: After the target phase, the event bubbles up from the target element to the top of the DOM hierarchy. During this phase, event handlers attached with addEventListener without the capture option (or with false as the value) are triggered again. Handlers attached in this phase are executed as the event travels up from the target element.

Let's look at an example. Consider a <div> nested inside another <div>. If a click event occurs on the inner <div>, the capturing phase starts from the outer <div> and goes down to the inner <div>. Then, the target phase happens on the inner <div>, and finally, the bubbling phase occurs from the inner <div> back up to the outer <div>.

<div id="outerDiv">
  Outer Div
  <div id="innerDiv">Inner Div</div>
</div>

<script>
  const outerDiv = document.getElementById('outerDiv');
  const innerDiv = document.getElementById('innerDiv');

  outerDiv.addEventListener('click', () => console.log('Capturing: Outer Div'), true);
  innerDiv.addEventListener('click', () => console.log('Target: Inner Div'));
  outerDiv.addEventListener('click', () => console.log('Bubbling: Outer Div'));
</script>

Let's understand Bubbling in detail.

Event Bubbling:

Event bubbling is a mechanism in JavaScript where, when an event occurs on an element, such as a click, that event first triggers on the target element and then "bubbles" up through its ancestor elements all the way up to the root of the document (usually <html>). This triggers the same event on each ancestor along the way. Here's an example:

<form onclick="alert('form')">
  FORM
  <div onclick="alert('div')">
    DIV
    <p onclick="alert('p')">P</p>
  </div>
</form>

If you click on the <p> element, the click event will first trigger on the <p> element, then on the <div>, and finally on the <form>. This is because the event bubbles up through each parent element in the DOM hierarchy.

event.target vs. this:

• event.target refers to the element that initiated the event. It remains the same throughout the bubbling process. In the above example, if you click on the <p> element, event.target will be the <p> element.
• this (or event.currentTarget) refers to the current element that the event handler is attached to. In the above example, if the event handler is attached to the <form>, this will be the <form> element.

How to stop event bubbling:

Sometimes, you might want to stop the event from bubbling up further. You can do this using the event.stopPropagation() method. This method stops the event from propagating to parent elements.

<body onclick="alert('the bubbling doesn't reach here')">
  <button onclick="event.stopPropagation()">Click here</button>
</body>

In this example, clicking the button won't trigger the alert on the body element because event.stopPropagation() is called in the button's click event handler.

event.stopImmediatePropagation() is similar to event.stopPropagation(), but also prevents other handlers on the current element from executing.

Event Delegation:

Event delegation is a technique that allows you to handle events more efficiently by attaching a single event listener to a parent element instead of attaching multiple event listeners to individual child elements. This is particularly useful when you have a large number of similar elements that need the same event handling logic.

parentElement.addEventListener('click', function(event) {
    if (event.target.classList.contains('childElement')) {
        // Action to be performed when a child element is clicked
    }
});

<!-- Example: Event delegation -->
<ul id="myList">
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
</ul>

<script>
    // Adding a click event listener to the parent ul element
    document.getElementById("myList").addEventListener("click", function(event) {
        // Checking if the clicked element is an li
        if (event.target.tagName === "LI") {
            // Code to execute when an li is clicked
            console.log("Item clicked:", event.target.textContent);
        }
    });
</script>

This approach reduces the number of event listeners and improves performance.

Conclusion

The DOM, or Document Object Model, is an interface that represents the structure of HTML documents. It serves as the bridge between JavaScript code and the browser, allowing manipulation of HTML elements, styles, attributes, and event handling.

The DOM API provides methods and properties to interact with the DOM tree. Examples include querySelector, addEventListener, createElement, innerHTML, textContent, etc.

Through DOM manipulation, developers can dynamically change various aspects of a web page, including text content, HTML attributes, and the structure of the document itself (for example, inserting, updating, or deleting HTML elements).

JavaScript frameworks and libraries like React often utilize DOM manipulation capabilities to efficiently manage and update user interfaces. This lets developers create complex web applications with interactive and responsive user experiences.

To learn more about the DOM, here are a few resources you can check out:

First of all, I wrote a follow-up article, which you can find here:
Client-Side Form Handling with JavaScript.

You can also read more in the following articles:

• DOM Events Lifecycle and Efficient script Loading
• The JavaScript DOM manipulation handbook
• The MDN web docs
• JavaScript DOM manipulation best practices
• JS DOM manipulation in Spanish - full course

An event refers to an action or occurrence that happens in the system you are programming. The system then notifies you about the event so that you can respond to it in some way if necessary.

In this article, I will focus on events in the context of web browsers. Essentially, an event is an indicator which shows that a certain action has taken place so that you can make an appropriate response.

To illustrate what I am talking about, let's imagine that you are standing at a pedestrian crossing waiting for traffic lights to change so that you can safely cross the road. The event is the change in traffic light which makes you subsequently take an action – which, in this case, is crossing the road.

Similarly in web development, we can take an action whenever an event we have interest in takes place.

Some of the common events you might have come across in web development include:

1. Mouse events

• click

• dblclick

• mousemove

• mouseover

• mousewheel

• mouseout

• contextmenu

• mousedown

• mouseup

2. Touch events

• touchstart

• touchmove

• touchend

• touchcancel

3. Keyboard events

• keydown

• keypress

• keyup

4. Form events

• focus

• blur

• change

• submit

5. Window events

• scroll

• resize

• hashchange

• load

• unload

For a complete list of events and the different categories they fall into, you can check out the MDN documentation. Some of the events listed are standard events in official specifications, while others are events used internally by specific browsers.

What are event handlers?

As mentioned above, we monitor events so that whenever we receive a notification that the event has occurred, the program can take the appropriate action.

This action is often taken in functions called event handlers which are also referred to as event listeners. If an event occurs and the event handler is invoked, we say an event has been registered. This is illustrated in the code below.

If the button with id btn is clicked, the event handler is invoked and an alert with the text "Button has been clicked" is displayed. The onclick property has been assigned to a function which is the event handler. This is one of three ways of adding an event handler to a DOM element.

const button = document.getElementById("btn");
button.onclick = function(){
   alert("Button has been clicked");
}

It is worth pointing out that event handlers are mostly declared as functions, but they can also be objects.

How to assign event handlers

There are multiple ways of attaching event handlers to HTML elements. We'll discuss these methods, along with their pros and cons, below.

Assign an event handler with an HTML attribute

This is the easiest way of attaching an event handler to HTML elements, though it is the least recommended. It involves using an inline HTML event attribute named on<event> whose value is the event handler. For example onclick, onchange, onsubmit and so on.

Take note that it is not uncommon to find HTML event attributes named onClick, onChange or onSubmit because HTML attributes are not case sensitive. Essentially it is syntactically correct to use onclick, onClick or ONCLICK. But it's common practice to leave it in lowercase.

<button onclick = "alert('Hello world!')"> Click Me </button>
<button onclick = "(() => alert('Hello World!'))()"> Click Me Too </button>
<button onclick = "(function(){alert('Hello World!')})()"> And Me </button>

In the above example, JavaScript code has been literally assigned to the HTML event attribute.

Take note of the Immediately Invoked Function Expression (IIFE) format in the last two button elements. Though this appears easy and straightforward, assigning an inline HTML event attribute is inefficient and difficult to maintain.

Assume you have over 20 such buttons in your markup. It would be repetitive to write the same JavaScript code for each button. It is always better to write JavaScript in its own file so that you can easily use the same code for multiple HTML files.

Besides, you cannot have multiple lines of JavaScript code inline. Inline JavaScript code is considered an anti-pattern due to the aforementioned reasons. So try to avoid it unless you are trying out something quick.

Declare an event handler in a script tag

Instead of doing the above, you can also declare the event handler in a script tag and invoke it inline as shown below.

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" href="./index.css" type="text/css" />
    <script>
      function onClickHandler(){
         alert("Hello world!");
       }
    </script> 
  </head>
  <body>
    <div class="wrapper">
       <button onclick = "onClickHandler()"> Click me </button>
    </div>
  </body>
</html>

Notice, though, that simply assigning the function name as a value of the HTML event attribute like onclick = "onClickHandler" will not work. You need to invoke it as shown above, enclosing the invocation in quotes just like the value of any HTML attribute.

Assign an event handler using the DOM property

Instead of using inline HTML event attribute illustrated above, you can also assign the event handler as the value of an event property on the DOM element. This is only possible inside a script tag or in a JavaScript file.

One limitation of this approach is that you cannot have multiple event handlers for the same event. If you have multiple handlers for the same event, as illustrated below, only the last one will be applied. The others will be overwritten.

const button = document.getElementById("btn");
button.onclick = function(){
   alert("Button has been clicked");
}
// Only this is applied
button.onclick = function(){
   console.log("Button has been clicked");
}

If you want to remove the event listener from the onclick event, you can simply re-assign button.onclick to null.

button.onclick = null

How to improve the DOM method of adding event listeners

The above method of adding event listeners is preferable to using inline JavaScript. Still, it has a limitation of restricting an element to have only one event handler for each event.

For example you cannot apply multiple event handlers for a click event on an element.

To remedy this limitation, addEventListener and removeEventListener were introduced. This enables you to add multiple event handlers for the same event on the same element.

const button = document.getElementById('btn');
button.addEventListener('click', () => {
  alert('Hello World');
})
button.addEventListener('click', () => {
  console.log('Hello World');
})

In the code above, an element with id btn is selected and then monitored for a click event by attaching two event handlers. The first event handler will be invoked and an alert message of Hello World pops up. Subsequently Hello World will also be logged in the console.

As you might have noticed from the above examples, the function signature of element.addEventListener is:

element.addEventListener(event, eventHandler, [optional parameter])

Parameters to the addEventListener method

1. event

The first parameter, event (which is a required parameter) is a string that specifies the name of the event. For example "click", "mouseover", "mouseout" and so on.

2. eventHandler

The second parameter, which like the first is also required, is a function which is invoked when the event occurs. An event object is passed as its first parameter. The event object depends on the type of event. For example, a MouseEvent object is passed for a click event.

3. Optional parameter

The third parameter, which is an optional parameter, is an object with the properties:

• once: Its value is a boolean. If true, the listener is removed after it triggers.

• capture: Its value is also a boolean. It sets the phase where it should handle the event, which is either in the bubbling or capturing phase. The default value is false , therefore the event is captured in the bubbling phase. You can read more about it here. For historical reasons, options can also be true or false.

• passive: Its value is also a boolean. If it is true, then the handler will not call preventDefault(). preventDefault() is a method of the event object.

Similarly if you want to stop monitoring the click event, you can use element.removeEventListener. But this only works if the event listener has been registered using element.addEventListener. The function signature is similar to that of element.addEventListener.

element.removeEventListener(event, eventHandler, [options])

For us to use element.removeEventListener to remove an event, the function passed as second argument to element.addEventListener must be a named function when adding the event listener. This ensures that the same function can be passed to element.removeEventListener if we want to remove it.

It is also worth mentioning here that, if you passed the optional arguments to the event handler, then you must also pass the same optional arguments to the removeEventListener.

const button = document.getElementById('btn');
button.removeEventListener('click', clickHandler)

What are event objects?

An event handler has a parameter called event object which holds additional information about the event.

The information stored in the event object depends on the type of event. For example, the event object passed to a click event handler has a property called target which references the element from which the click event originated.

In the example below, if you click the element with id btn, event.target will reference it. All click event handlers are passed an event object with the target property. As already pointed out, different events have event object parameters which store different information.

const button = document.getElementById("btn");
button.addEventListener("click", event => {
  console.log(event.target);
})

The value of this

In an event handler, the value of this is the element on which the event handler is registered. Take note that the element on which the event handler is registered may not necessarily be the same as the element on which the event occurred.

For example in the code below, the event handler is registered on the wrapper. Normally, the value of this is the same as event.currentTarget. If you click the button, the value of this inside onClickHandler is the div not the button because it is the div on which the event handler is registered though the click originated from the button.

This is called event propagation. It is a very important concept which you can read about here if you are interested.

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" href="./index.css" type="text/css" />
    <script>
      function onClickHandler(){
         console.log(this)
         alert("Hello world!");
       }
       const wrapper = document.querySelector(".wrapper");
       wrapper.addEventListener("click", onClickHandler);
    </script> 
  </head>
  <body>
    <div class="wrapper">
       <button> Click me </button>
    </div>
  </body>
</html>

Conclusion

In this article we looked at:

• Browser events and what they are

• Different ways of adding event handlers to DOM elements

• Event object parameters to event handlers

• The value of this in an event handler

Events are actions that happen when a user interacts with the page - like clicking an element, typing in a field, or loading a page.

The browser notifies the system that something has happened, and that it needs to be handled. It gets handled by registering a function, called an event handler, that listens for a particular type of event.

What does it mean to "handle an event"?

To put it in simple terms, consider this - let's assume you are interested in attending Web Development meetup events in your local community.

To do this, you sign-up for a local meetup called "Women Who Code" and subscribe to notifications. This way, anytime a new meetup is scheduled, you get alerted. That is event handling!

The "event" here is a new JS meetup. When a new meetup is posted, the website meetup.com catches this change, thereby "handling" this event. It then notifies you, thus taking an "action" on the event.

In a browser, events are handled similarly. The browser detects a change, and alerts a function (event handler) that is listening to a particular event. These functions then perform the actions as desired.

Let's look at an example of a click event handler:

<div class="buttons">
  <button>Press 1</button>
  <button>Press 2</button>
  <button>Press 3</button>
</div>
const buttonContainer = document.querySelector('.buttons');
console.log('buttonContainer', buttonContainer);

buttonContainer.addEventListener('click', event => {
  console.log(event.target.value)
})

What are the different types of events?

An event can be triggered any time a user interacts with the page. These events could be a user scrolling through the page, clicking on an item, or loading a page.

Here are some common events - onclick dblclick mousedown mouseup mousemove keydown keyup touchmove touchstart touchend onload onfocus onblur onerror onscroll

Different phases of events - capture, target, bubble

When an event moves through the DOM - whether bubbling up or trickling down - it is called event propagation. The event propagates through the DOM tree.

Events happen in two phases: the bubbling phase and the capturing phase.

In capture phase, also called the trickling phase, the event "trickles down" to the element that caused the event.

It starts from the root level element and handler, and then propagates down to the element. The capture phase is completed when the event reaches the target.

In the bubble phase, the event is "bubbled" up to the DOM tree. It is first captured and handled by the innermost handler (the one that is closest to the element on which the event occurred). It then bubbles up (or propagates up) to the higher levels of DOM tree, further up to its parents, and then finally to its root.

Her's a trick to help you remember this:

trickle down, bubble up

Here's an infographic from quirksmode that explains this very well:

               / \
---------------| |-----------------
| element1     | |                |
|   -----------| |-----------     |
|   |element2  | |          |     |
|   -------------------------     |
|        Event BUBBLING           |
-----------------------------------

               | |
---------------| |-----------------
| element1     | |                |
|   -----------| |-----------     |
|   |element2  \ /          |     |
|   -------------------------     |
|        Event CAPTURING          |
-----------------------------------

One thing to note is that, whether you register an event handler in either phase, both phases ALWAYS happen. All events bubble by default.

You can register event handlers for either phase, bubbling or capturing, by using the function addEventListener(type, listener, useCapture). If useCapture is set to false, the event handler is in the bubbling phase. Otherwise it's in the capture phase.

The order of the phases of the event depends on the browser.

To check which browser honors capture first, you can try the following code in JSfiddle:

<div id="child-one">
    <h1>
      Child One
    </h1>
  </div>

const childOne = document.getElementById("child-one");

const childOneHandler = () => {
console.log('Captured on child one')
}

const childOneHandlerCatch = () => {
console.log('Captured on child one in capture phase')
}

childOne.addEventListener("click", childOneHandler); 
childOne.addEventListener("click", childOneHandlerCatch, true);

In Firefox, Safari, and Chrome, the output is the following:

How to listen to an event

There are two ways to listen to an event:

1. addEventListener

2. inline events, such as onclick

   ``` //addEventListener document.getElementByTag('a').addEventListener('click', onClickHandler);

//inline using onclick Click me

## Which is better - an inline event or `addEventListener`?

1. `addEventListener` gives you the ability to register unlimited event handlers.
2. `removeEventListener` can also be used to remove event handlers
3. The `useCapture` flag can be used to indicate whether an event needs to be handled in the capture phase or bundled phase.


## Code examples and live-action

You can try out these events in JSFiddle to play around with them. 

```html
<div id="wrapper-div">
  <div id="child-one">
    <h1>
      Child One
    </h1>
  </div>
  <div id="child-two" onclick="childTwoHandler">
    <h1>
      Child Two
    </h1>
  </div>

</div>

const wrapperDiv = document.getElementById("wrapper-div");
const childOne = document.getElementById("child-one");
const childTwo = document.getElementById("child-two");

const childOneHandler = () => {
console.log('Captured on child one')
}

const childTwoHandler = () => {
console.log('Captured on child two')
}

const wrapperDivHandler = () => {
console.log('Captured on wrapper div')
}

const childOneHandlerCatch = () => {
console.log('Captured on child one in capture phase')
}

const childTwoHandlerCatch = () => {
console.log('Captured on child two in capture phase')
}

const wrapperDivHandlerCatch = () => {
console.log('Captured on wrapper div in capture phase')
}


childOne.addEventListener("click", childOneHandler); 
childTwo.addEventListener("click", childTwoHandler); 
wrapperDiv.addEventListener("click", wrapperDivHandler); 

childOne.addEventListener("click", childOneHandlerCatch, true); 
childTwo.addEventListener("click", childTwoHandlerCatch, true); 
wrapperDiv.addEventListener("click", wrapperDivHandlerCatch, true);

TL;DR

Event phases are capture (DOM -> target), bubble (target-> DOM) and target. Events can be listened for by using addEventListener or inline methods such as onclick.

    addEventListener can add multiple events, whereas with onclick this cannot be done.
    onclick can be added as an HTML attribute, whereas an addEventListener can only be added within <script> elements.
    addEventListener can take a third argument which can stop the event propagation.

Futher reading

https://www.quirksmode.org/js/events_order.html https://jsfiddle.net/r2bc6axg/ https://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick https://www.w3.org/wiki/HTML/Attributes/_Global#Event-handler_Attributes

To keep up with more short tutorials like this, sign up for my newsletter or follow me on Twitter

There are two native functions in the JavaScript library used to accomplish these tasks: setTimeout() and setInterval().

setTimeout

setTimeout() is used to delay the execution of the passed function by a specified amount of time.

There are two parameters that you pass to setTimeout(): the function you want to call, and the amount of time in milliseconds to delay the execution of the function.

Remember that there are 1000 milliseconds (ms) in a 1 second, so 5000 ms is equal to 5 seconds.

setTimeout() will execute the function from the first argument one time after the specified time has elapsed.

Example:

let timeoutID;

function delayTimer() {
  timeoutID = setTimeout(delayedFunction, 3000);
}

function delayedFunction() {
  alert(“Three seconds have elapsed.”);
}

When the delayTimer function is called it will run setTimeout. After 3 seconds (3000 ms) pass, it will execute delayedFunction which will send an alert.

setInterval

Use setInterval() to specify a function to repeat with a time delay between executions.

Again, two parameters are passed to setInterval(): the function you want to call, and the amount of time in milliseconds to delay each call of the function .

setInterval() will continue to execute until it is cleared.

Example:

let intervalID;

function repeatEverySecond() {
  intervalID = setInterval(sendMessage, 1000);
}

function sendMessage() {
  console.log(“One second elapsed.”);
}

When your code calls the function repeatEverySecond it will run setInterval. setInterval will run the function sendMessage every second (1000 ms).

clearTimeout and clearInterval

There are also corresponding native functions to stop the timing events: clearTimeout() and clearInterval().

You may have noticed that each timer function above is saved to a variable. When either the setTimeout or setInterval function runs, it is assigned a number which is saved to this variable. Note that JavaScript does this all in the background.

This generated number is unique for each instance of timers. This assigned number is also how timers are identified when you want to stop them. For this reason, you must always set your timer to a variable.

For clarity of your code, you should always match clearTimeout() to setTimeout() and clearInterval() to setInterval().

To stop a timer, call the corresponding clear function and pass it the timer ID variable that matches the timer you wish to stop. The syntax for clearInterval() and clearTimeout() are the same.

Example:

let timeoutID;

function delayTimer() {
  timeoutID = setTimeout(delayedFunction, 3000);
}

function delayedFunction() {
  alert(“Three seconds have elapsed.”);
}

function clearAlert() {
  clearTimeout(timeoutID);
}

Every time you make a change to the application state, you record the change as an event.
You can replay the events since the beginning of the recording, up to a certain time. Then you've recreated the state of the application at that time.

That's what Event Sourcing is about. It's like you can time travel to the past. I find it fascinating.

Event sourcing provides an audit trail when you need to meet regulatory requirements. It can help with debugging. And you can even explore alternate realities: what would have happened if...

I recently saw a great talk by Jakub Pilimon and Kenny Bastani about event sourcing.

The talk is a 1 hour session of life coding. The two speakers start with a simple application that is not event sourced. Then they refactor it to use events.

They end up wiring the application up with Apache Kafka. I will skip that part in this article and focus on the conceptual part of event sourcing instead.

A recap of the talk

As a user of a Credit Card management application, you can:

• Assign a limit to the credit card
• Withdraw money
• Repay money

For each of these commands, there is a method in the CreditCard class.
Here's the original code of the assignLimit method:

public void assignLimit(BigDecimal amount) { 
  if(limitAlreadyAssigned()) {  
    throw new IllegalStateException(); 
  }
  this.initialLimit = amount; 
}

Here's the withdraw method:

    public void withdraw(BigDecimal amount) {
        if(notEnoughMoneyToWithdraw(amount)) {
            throw new IllegalStateException();
        }
        if(tooManyWithdrawalsInCycle()) {
            throw new IllegalStateException();
        }
        this.usedLimit = usedLimit.add(amount);
        withdrawals++;
    }

The repay method is similiar.

Remember that for event sourcing, you need to record an event
any time the application changes its state?
So the speakers extract each state change to its own method in the CreditCard class.

Here's the refactored withdraw method:

   public void withdraw(BigDecimal amount) {
        if(notEnoughMoneyToWithdraw(amount)) {
            throw new IllegalStateException();
        }
        if(tooManyWithdrawalsInCycle()) {
            throw new IllegalStateException();
        }
        cardWithdrawn(new CardWithdrawn(uuid, amount, Instant.now()));
    }

    private CreditCard cardWithdrawn(CardWithdrawn event) {
        this.usedLimit = usedLimit.add(event.getAmount());
        withdrawals++;
        pendingEvents.add(event);
        return this;
    }

An instance of CardWithdrawn represents the event that a user has successfully withdrawn money. After the state has changed, the event is added to the list of pending events.

You call the save method of the CreditCardRepository class to flush the pending events to the event stream. Event listeners may handle the events then.

Apart from the payload, each event has its own unique identifier and timestamp. So you can sequence and replay the events later.
To replay the events for a specific credit card, the repository calls the recreateFrom method of the CreditCard class, passing in the id of the card and the events stored for it:

    public static CreditCard recreateFrom(UUID uuid, List<DomainEvent> events) {
        return ofAll(events).foldLeft(new CreditCard(uuid), CreditCard::handle);
    }

    private CreditCard handle(DomainEvent event) {
        return Match(event).of(
                Case($(Predicates.instanceOf(LimitAssigned.class)), this::limitAssigned),
                Case($(Predicates.instanceOf(CardWithdrawn.class)), this::cardWithdrawn),
                Case($(Predicates.instanceOf(CardRepaid.class)), this::cardRepaid),
                Case($(Predicates.instanceOf(CycleClosed.class)), this::cycleWasClosed)
        );
    }

This code uses the vavr.io library to call the handle method for each event. The handle method dispatches the event object to the appropriate method.
For example: for each LimitAssigned event, the handle method calls the limitAssigned method with the event as parameter.

Simplifying the application

I used the requirements as code library for simplifying the code. First, I put all of the event classes and the handling methods in a model. Like this:

this.eventHandlingModel = 
        Model.builder()
           .on(LimitAssigned.class).system(this::limitAssigned)
           .on(CardWithdrawn.class).system(this::cardWithdrawn)
           .on(CardRepaid.class).system(this::cardRepaid)
           .on(CycleClosed.class).system(this::cycleWasClosed)
       .build();

I had to change the return type of the handling methods (e.g. limitAssigned) to void. Apart from that, the conversion from vavr.io was straight forward.

Then, I created a runner and started it for the model:

this.modelRunner = new ModelRunner();
modelRunner.run(eventHandlingModel);

After that, I changed the recreateFrom and handle methods to this:

public static CreditCard recreateFrom(UUID uuid, List<DomainEvent> events) {
    CreditCard creditCard = new CreditCard(uuid);
    events.forEach(ev -> creditCard.handle(ev));
    return creditCard;
}

private void handle(DomainEvent event) {
    modelRunner.reactTo(event);
}

At that point, I could get rid of the dependency to vavr.io.
Transition complete. Now I could get some more simplifying done.

I revisited the withdraw method:

public void withdraw(BigDecimal amount) {
    if(notEnoughMoneyToWithdraw(amount)) {
        throw new IllegalStateException();
    }
    if(tooManyWithdrawalsInCycle()) {
        throw new IllegalStateException();
    }
    cardWithdrawn(new CardWithdrawn(uuid, amount, Instant.now()));
}

The check tooManyWithdrawalsInCycle() didn't depend on the data of the event. It only depended on the state of the CreditCard.
State checks like this can be represented in the model as conditions.

After I moved all state checks for all methods to the model, it looked like this:

this.eventHandlingModel = 
  Model.builder()
    .condition(this::limitNotAssigned)
        .on(LimitAssigned.class).system(this::limitAssigned)
    .condition(this::limitAlreadyAssigned)
        .on(LimitAssigned.class).system(this::throwsException)
    .condition(this::notTooManyWithdrawalsInCycle)
        .on(CardWithdrawn.class).system(this::cardWithdrawn)
    .condition(this::tooManyWithdrawalsInCycle)
        .on(CardWithdrawn.class).system(this::throwsException)
    .on(CardRepaid.class).system(this::cardRepaid)
    .on(CycleClosed.class).system(this::cycleWasClosed)
.build();

For this to work, I needed to replace the direct calls to methods that change the state with the handle method. After that, the assignLimit and withdraw methods looked like this:

public void assignLimit(BigDecimal amount) { 
    handle(new LimitAssigned(uuid, amount, Instant.now()));
}

private void limitAssigned(LimitAssigned event) {
    this.initialLimit = event.getAmount(); 
    pendingEvents.add(event);
}

public void withdraw(BigDecimal amount) {
    if(notEnoughMoneyToWithdraw(amount)) {
        throw new IllegalStateException();
    }
    handle(new CardWithdrawn(uuid, amount, Instant.now()));
}

private void cardWithdrawn(CardWithdrawn event) {
    this.usedLimit = usedLimit.add(event.getAmount());
    withdrawals++;
    pendingEvents.add(event);
}

As you can see, most of the conditional logic has moved out of the methods into the model. This makes the methods easier to understand.

One thing that bothered me is that you must not forget to add the event to the pending events. Every time. Or your code won't work.

Requirements as code allows you to control how the system handles the events. So I extracted pendingEvents.add(event) from the methods as well:

modelRunner.handleWith(this::addingPendingEvents);
...

public void addingPendingEvents(StepToBeRun stepToBeRun) {
    stepToBeRun.run();
    DomainEvent domainEvent = (DomainEvent) stepToBeRun.getEvent().get();
    pendingEvents.add(domainEvent);
}

I could have gone further and extract the validation logic as well.
But I leave that as a thought exercise to you, dear reader.

What's the point?

What I tried to achieve is a clear separation of concerns:

• The state dependent execution of methods is defined in the model
• The data validation and state changes are in the implementations of the methods
• The events are automatically added to the pending events. In general: the infrastructure code is clearly separated from the business logic.

Simplifying an example that is already very simple is good for explaining.
But that's not the point I want to make.

The point is: having such a clear separation of concerns pays out in practice.
Especially, if you work with multiple teams. On complicated problems.

Separation of concerns helps with changing different parts of code at a different pace. You have simple rules where to find something. The code is easier to understand. And it's easier to isolate units for testing purposes.

Conclusion

I hope you enjoyed my article. Please give me feedback.

Have you been working on event sourcing applications?
What were your experiences like?
Can you relate to what I wrote in this article?

I also want to invite you to look at my library that I used throughout the article. I would be thrilled if you try it out in practice, and tell me what you think.

This article was first published on dev.to

Hey meetup facilitators, friends, and future leaders! Do you want more people to show up to your tech event? Or at least the same number of people? Here are some ideas to try! These tips are based on observations of Boston’s meetup culture and my experience running a group focused on Ember.js (a front-end framework).

1. Don’t just ask for new speakers — create them

While Boston Ember is pretty steady, I’ve seen other meetups struggle to find speakers. As a facilitator, it’s my responsibility to curate a variety of talks, both by topic and experience level. To achieve that, I wanted to help bring in new speakers. I needed an enormous amount of cajoling to give my first tech talk, and I can’t cajole attendees at scale, so what can be done?

First, make an event of it! Find an experienced speaker who will answer public speaking questions. You could also assemble a panel. Check out the results of our attempt here, as presented by Stephen Vance. The audience was 100% captivated.

He asked the attendees which category of information they were most interested in:

• choosing topics
• preparation
• delivery
• follow on (handling audience questions)
• remote presenting.

Then, based on audience vote for the focus, Stephen took Q&A for the most popular categories.

Second, follow up. Set aside a slot for a new speaker. Advertise it that way. Many potential speakers may believe that they need to be “experts” or that someone else is more worthy. Help them overcome imposter syndrome by extending an invitation.

2. Avoid lengthy product pitch talks

Product pitches kill tech meetups. If you don’t take steps to cultivate new speakers, your only volunteers may be people who have something to sell. Your devs will get bored of sales pitches, and they’ll stop showing up.

Here’s the litmus test for whether it’s a product pitch. Ask the potential presenter,”What will the audience take away from the talk? What will you teach them?” If it’s teaching about a business use case, the company, the industry and so on, offer them a spot for a lightning talk, ten minutes or less.

I was a salesperson before I became a developer, and I can empathize with the product pitch speakers. But be firm. You owe it to your attendees. If the speaker shares more than a product pitch, you can invite them to speak again for a longer time slot.

3. Run a raffle at the end

Every month, I go to She Geeks Out, an amazing event run by some women who are real pros at community engagement. Every month, they do a raffle at the end of the evening, and the energy it brings to the room is incredible. People stay until the end, they cheer each other on, and no speaker is ever confronted with “So, I guess that’s it for questions. Bye, have a good night.” Instead, it’s “Who’s ready to win tonight!?!? It’s raffle time.”

At the end of the day, our animal brains love the chance to win a prize.

So, I tried this out for one of our special events, using some Ember swag. Because I’m a nerd, I printed out some Ember API methods and wrote a script to select them at random. Even the people who were already wearing some swag were intent on winning.

You don’t have to spend a ton of money either to add some magic to your event. Think of it as the cost of pizza for just one more attendee. Buy $40 of clearance stuff from ThinkGeek and you’re good to go for the year.

4. Be in cahoots with other meetups

In 2017, the Boston tech meetup scene suffered some serious blows. Many popular groups went poof, and seemingly the number of venues willing to host tanked. To form a support network, some local meetup organizers created Boston JavaScript. It is a Slack organization where local groups could share and grow together. Then, they invited every group and their organizers to join.

It’s important for developers to consider tools outside their wheelhouse. We all have a lot to learn from each other! The shared space enables us to share event announcements and collaborate.

I also reached out to some people in my Ember network to ask for advice. I spoke with other local members, past leaders, and facilitators in other states. They shared ideas I had never seen in action before.

5. Every month, take action to build sustainability

So what killed the Boston meetups in 2017? My guess is that the organizers needed a break, which is natural, but no one else was ready to take over.

It’s important to take steps today to prepare for when you and your partners will inevitably be moving on to something else. Don’t wait until that time hits.

I’m still exploring this myself, but here’s what I’ve gathered from other meetup leaders:

• Ask for help, even when you don’t need it. Your helpers will become the future leaders.
• Form a coalition. I recently heard of a meetup run by 6 people. It is very stable.
• Suggest many ways to help. Social media, livestream, and event advertising are all good ways for people to pitch in. Volunteers don’t need to be comfortable in front of a crowd.
• Let go of some control. Share responsibilities with your co-facilitators. Accept that they will do things differently than you would.
• Rotate the emcee, at least for certain sections of the event. People besides you need practice before they’d ever agree to be a copilot or take over facilitation.
• Get the attendees involved as participants. Ask them to be speakers and ask them for feedback. Have a session where people can propose topics they’re interested in hearing about. If people show up and leave without contributing, you may become the only one who cares enough to put in the work. Make it everyone’s baby.

In closing…

When I first stepped up to help run a meetup, I was terribly worried. I was afraid that no one would show up, that I wouldn’t be able to find venues/sponsors, that people would stop coming… that I wasn’t good enough. I got on the phone with the facilitator of the NYC Ember.js, Luke Melia, and I asked him a thousand anxiety-fueled questions.

He said something like this:

Before I answer any of these questions, I want to make one point. You are going to have so much fun! Running a meetup is an incredibly valuable experience. You will learn so much.

He was right.

Jen Weber builds apps for science at BioBright. She’s a contributor to Ember.js, a front end framework that comes with “batteries included” for better developer experience and productivity. She works to transform tech into an industry that welcomes new people.

In dealing with a flurry of recent emails regarding compensating speakers for events, I realized that more people should be aware of how speaker compensation is handled, particularly if you want to organize an event.

That being said, it’s a rather touchy topic so I’ll try to tread lightly. And I’ll mainly be talking about typical non-corporate software conferences. I also speak at private/corporate events across Europe and the US and they’re a different ball game.

_Me after giving a talk in Lisbon, Portugal. The cocky air was probably unintentional. [Photo by Rafael Garcia-Suarez](https://www.flickr.com/photos/rgarciasuarez74/3794820418" rel="noopener" target="blank" title=")

The Different Types of Speakers

At a conference, attendees fall into several groups, but I’ll just cover regular and invited (guest) speakers.

A regular speaker is typically someone’s who’s submitted a talk for a conference and gotten it accepted. While the compensation varies, the only standard is a waiving of the attendance fee. Other forms of compensation may be a speaker’s dinner, “speaker only” swag, or other perks such as the professional photographer work you see at OSCON.

A regular speaker might have pitched a tutorial and those people often get part (or all) of the tutorial money and might have their travel and hotel covered. This bit seems more “hit or miss” depending on the conference. That being said, my company’s training courses are typically in a corporate environment and I don’t have much to say about conference training.

Then you have the invited, or “guest” speakers. These are the speakers that a conference uses to promote themselves. Not only does the conference offer a wide array of interesting topics and a chance to network with other people in your field, strong guest speakers such as Charles Stross are a powerful draw. Or if you’ve ever seen Damian Conway speak, you know why people want to go see him. I’ve also been fortunate enough to be featured as a keynote speaker at conferences.

Guest Speakers

As mentioned, I’m often invited to speak at conferences, such as giving the Day 1 Keynote at a conference in Bulgaria. I certainly don’t claim to have the appeal of Damian Conway or Charles Stross (though with a rating of 5 out of 5 stars for my last US OSCON talk, I’m not too shabby), but nonetheless I have given a number of keynotes, or have been invited to just be a “special guest.” When you’re invited to a conference, that’s when things change a bit.

If I go to all of the events I’m invited to, I’d hardly see my family and my business would suffer; I can’t attend every event I’m invited to. Rachel Nabors, on a recent podcast where she discussed how speaking can help or hurt your business, stated that she loses on average $3,000 for every conference she attends. I find that’s actually on the low side if you count all the prep time for a great talk and how many days I’ll be away (my travel’s particularly painful as I live in a small town on the southwest coast of France with no airport).

As for myself, I often speak at Perl events and in the previously mentioned email thread, someone claimed that, with a couple of exceptions, invited speakers to non-corporate software conferences do not receive compensation for these events. This is a misunderstanding. Invited speakers to said events often do not receive speaking fees.

Top public speakers can earn very good money, but for these conferences, not so much. And just to be crystal clear: I have never asked for a speaking fee for a Perl event. The Perl community has given me a lot and I try to give back in return. It also helps that I’ve a lot of friends there. If a Perl event wants to offer me a speaking fee and I think it won’t hurt them, I’ll accept, but I have never made that a precondition of my speaking.

When I speak at other conferences/events, I decide on a case-by-case basis. For a quick pep talk or a new take on a talk I’ve previously given, it’s pretty easy. If I’m asked to write something tailored for a given event, that changes the whole game plan.

People who don’t do public speaking often don’t get how labor intensive it is. If I’m giving a talk on strategic agile business practices, designing OO systems, or database design, or even “how to move to a foreign country,” there’s a huge amount of research involved and if I don’t get it right, the audience will eat me alive. And after I get it right, I have to make it both interesting and fun. Oh, and fit it into whatever time slot is available. That’s hard work, even if I’m only giving a motivational talk.

However, as previously mentioned, short of me deciding I want to make a full time living as a public speaker, there are only so many events I can afford to attend before I start hurting my business (and as mentioned, this isn’t just about lost income). That’s why when I am invited to a conference, I ask for travel and accommodation to offset the costs. And when I say “accommodation”, I’m happy to kip in someone’s spare bedroom. I am well aware that many conferences are run on shoestring budgets and I have no desire to break them.

Instead, I view these events as marketing and for whatever costs I incur, my company budgets them as such. The benefit of marketing outweighs the cost of the conference itself, so long as one’s careful about the conferences attended.

Some Advice for Conference Organizers

A smart conference will arrange the speaker’s flight and hotel themselves rather than leave it up to the speaker. Yes, it’s more work for you to arrange all of this in advance, but there are a handful of speakers who have hurt conferences with 4 star hotels and business class flights whose costs the conference wasn’t expecting to cover.

The speaker may not even have realized they were causing a problem, but nonetheless, it does happen and can make the difference in whether or not the conference can cover all of their debts. For private events, we’ve pretty much stopped billing flight and hotel separately (unless asked) because so many businesses have also been bitten by this.

It’s also interesting to note the number of requests for new talks. For new talks, we don’t just slap together a slide deck at the last minute. We spend a huge amount of time writing the material, practicing it, working on our timing, cutting slides, writing new slides, cursing when we realize we have to cut our favorite joke, and so on. Watch my Agile Companies Go POP talk in Kiev and you’ll get a sense of how much work is involved.

Even if the speaker has already given a talk, no talk is ever given twice: we react to our audience, we update our material and we stress different points in our presentation. Even if the talk has been posted online, few people watch those all the way to the end. So if you invite us but you can’t afford to pay us, that’s often OK, but be aware that getting a brand-spanking new talk out of it is a bonus.

In Summary

For most conferences, the majority of speakers only get the conference fee waived and maybe some special swag. For smaller, non-profit conferences, guest speakers are often not paid, but their travel and accommodation expenses are usually covered. For larger conferences and corporate events, guest speakers often receive a speaking fee and the amount varies from event to event, and from speaker to speaker.

Smaller conferences usually only offer speaking fees to a handful of luminaries because that’s all the conference can typically afford. People giving tutorials often get part of the tutorial fees as compensation (OSCON offers a paltry $500 honorarium).

Some well-known personalities at these conferences do not charge speaking fees, but some are in such high demand that they need said fees to offset losses from their main business.

This is an update from a popular LinkedIn post.

Curtis “Ovid” Poe is a regular guest speaker at public and private events in Europe and the US. If you’d like him to speak at an event, please sent an inquiry to info at allaroundtheworld dot fr.

Conferences are a great way to make friends and learn from experts. You can even try your hand at presenting on a topic.

Here are some JavaScript conferences to look forward to in 2017.

NodeConf Budapest: January 19–20 in Budapest, Hungary

NodeConf Budapest is a one-day, single-track conference with a laser focus on what people need to know about Node.js. There’s also a special NodeSchool event the day before.

Agent Conference: January 20–21 in Dornbirn, Austria

AgentConf is the first alpine conference about JavaScript and software engineering. Experts and core contributors will come to showcase their work in ReactJS, ReactNative, Node, and more.

Script’17: January 27 in Linz, Austria

Script’17 is a one-day event focused on JavaScript.

Developer Week: February 13–15 in San Francisco, California

This is the first time that DeveloperWeek will feature a JavaScript conference. It’s 3-days of workshops and industry talks about JavaScript.

React London: March 28 in London, UK

Red Badger is launching a new conference focused on React in London for 2017 called React London 2017.

EmberConf: March 28–29 in Portland, Oregon

EmberConf features sessions, activities, and good times with the Ember Core Team and community members from around the world.

Render: March 30–31 in Oxford, UK

Render Conf is a 2-day conference for front-end developers. It’s the successor to jQuery UK, returning to Oxford for its second year in 2017. It’s a single-track conference.

SmashingConf: April 4–5 in San Francisco, California

SmashingConf features focuses on UX and front end development.

ng-conf: April 5–7 in Salt Lake City, Utah

ng-conf is the world’s original Angular Conference.

React Amsterdam: April 21 in Amsterdam, The Netherlands

React Amsterdam is a full day two-track conference on all things React.

Active Ingredients: April 28 in San Francisco, California

Active Ingredients 2017 is the world’s first conference that is focusing on JAMstack. Spend a day learning from some of the most prominent people in web development.

JSConf EU: May 6–7 in Berlin, Germany

JSConf EU is the labor-of-love conference for the JavaScript community in Europe.

JSDay Italy: May 10–11 in Verona, Italy

From the organizers of the phpDay, JSDay is the first international conference on JavaScript in Italy.

React Europe: May 18–19 in Paris, France

ReactEurope will explore new ways to use tools like React.js, React Native, GraphQL, Relay, Universal apps, Webpack, inline CSS, and more.

Front-Trends, May 24–26, Warsaw, Poland

Front-Trends focuses on front-end development.

ng-cruise: May 29-June 2 in Miami, Florida

The first Angular cruise conference. The cruise departs from Miami and heads to the Bahamas.

Fluent: June 19–22 in San Jose, California

O’Reilly Fluent will focus on the web development and more.

VueConf: June 21–23 in WROCŁAW, POLAND

VueConf is the first Official Vue.js Conference in the world.

AngularCamp: July in Barcelona, Spain

AngularCamp Conference is a one-day, single track conference with amazing talks by internationally renowned community speakers.

Frontend Conference: August 31-September 1 in Zurich, Switzerland

The Frontend Conference in Zurich is Switzerland’s conference on front-end and UX techniques.

NordicJS: September 7–8 in Stockholm, Sweden

Nordic.js is a two-day JavaScript conference.

AngularConnect: November 7–8 in London, UK

AngularConnect is a 2-day, multi-track conference with a variety of Angular expercts, including the core Angular team at Google.

HalfStack 2017: Nov 17 in London, UK

HalfStack is a one-day, single track JavaScript conference that actually takes place in a pub.

Recently, I’ve had a few opportunities to attend and speak at amazing conferences on JavaScript Security. You can read about my experiences and follow me on Twitter.

Not once, but twice, our college became a part of an International community of highly productive and engaging people. The most recent installment took place on last Saturday, May 21st, 2016. From Lisbon to Lahore, from Belgrade to Bengaluru, from Berlin to Bainbridge, we all came together on a single day to celebrate a Global event, a fun event of teaching, learning & hacking together the concepts of JavaScript / NodeJS. Divided by borders, united by JavaScript! Yes, I’m talking about NodeSchool International Day!

A brief history of NodeSchool

On a fine day, a few people from a little upcoming community of daring open source hackers decided to challenge the world with the powers of a language that others dismissed as “too slow”, “a toy language”, and “web only”. They came together to build what would be a simple “workshopper” module, called stream-adventure.

What’s a workshopper? It’s a simple framework displaying a set of challenges to be completed right in your terminal, and has a test runner incorporated within it to test your code solutions.

javascripting Workshopper

These guys then went on to create the initial workshopper modules, such as javascripting and learnyounode, which consisted of beginner level JS and NodeJS problems. They thought, “Well, this is fun. We should have an event focused on these things!”

Soon, ideas came pouring in, which became modules in the NodeJS ecosystem (npm). Participants created repositories and set up websites. And in late 2013, the first official NodeSchool event was underway in Silicon Valley.

The community started to grow, and local chapters sprang up all over the world. By May 2016, there were more than 165 worldwide city-based chapters, which have hosted more than 500 events so far!

NodeSchool Upcoming and Past Events

Node Comes to Kolkata

In July of last year, I hit upon the idea of hosting a NodeSchool event in my city. Tech-wise, Kolkata is a laid back city with few meetups or hackathons to speak of. Most of the cool events are either in Bangalore or Hyderabad. We have an IT Park — known here as Sector V — which was a promised utopia of budding startups and big companies alike. But let’s just say that it hasn’t flourished as much as those of other metropolitan areas in India.

There are tech companies here, but most are service based. There isn’t much of a product or startup footprint. Undergraduates and graduates in my city miss out on the most important medium for networking and skill learning just because of the current landscape. And thus, they resort to joining service-based IT behemoths, which just treat them as a disposable resource.

Sector V, Kolkata, India

With only a short time to set everything up, I reached out to a NodeSchool core team member, Adam Brady, and asked him to guide me. I had three priorities for the event:

• Create awareness in my city and my college
• Train college students and help them shape up with new technologies
• Put our college to the global map

All NodeSchool Chapters are city based. This meant that, technically speaking, I had to host NodeSchool Kolkata. But due to time and space constraints, I had a better idea. Why not setup a smaller college-level chapter instead? After talking it over with Adam, he agreed to my proposal, and hence the NodeSchool IEM Kolkata Chapter was born on August 2015.

We had our inaugural workshop on August 31st, 2015, with 25 participants. Together, we coded together on mainly beginner NodeSchool modules using JavaScript and Git.

As far as new beginnings go, it exceeded my expectations, to say the least! The attendees went home with a little hands-on knowledge, some freebie stickers, and a lot more confidence! IEM Kolkata was added to the world map, and Max Odgen (principle founder of NodeSchool) commented on our pics!

NodeSchool Workshop in IEM Kolkata on 31st August, 2015

As the Second Law of Thermodynamics predicts, post workshop, the interest disappeared to a minimum. But that didn’t deter me from my goal. I found a few long-term interested people, and started a little newsletter among them. We kept in touch, and shared important links, resources, and tutorials among ourselves.

Fast forward to May 2016. NodeSchool International Day was just right around the corner, and planning started barely one week before it! Himanshu Kashyap, a final-year student, helped me out this time by publicizing the event, handling back-end tasks, and mentoring. We sent out invitations, cached the workshop software so we could use it offline, configured our website, and enrolled in the International Day Chapter. We were get-set-go for the event! We even got the Indian School of Ethical Hacking — a startup founded by our alumnus Kirit Sankar Gupta — to sponsor the event!

Nature worked against us this time. Heavy rains throughout the city prevented half the people who had already registered for the event from showing up. Still we went ahead, with the true spirit of Nodeschool International Day, and started the proceedings with the Bengaluru and Osaka teams.

Last time we had some hiccups setting everything up, but this time since the workshops were already cached in my system (local-npm), and installations were a breeze.

By lunchtime, everyone had completed the basic javascripting module, and was hungry for more! After lunch, we proceeded with Git, Github, and NodeJS basics with the git-it and learnyounode module. We also had a live Appear.in chat with Ian Crowther, London Chapter host, as well as the Tokyo and Berlin Chapters! At the end of the day, we distributed stickers and coasters, and then popped by Bisk Farm for a round of snacks and drinks.

I eventually plan to merge our chapter with a bigger NodeSchool Kolkata chapter once we get enough interested people. It takes time to develop interest and awareness in our city, but we should all strive for it nonetheless.

According to The Guardian, India will have over 1 million people turning 18 every month for the next two to three years! That is a huge load for our society to bear at once. Also, our country is facing an acute shortage of skilled engineers, and 80% of the current crop of engineers are considered unemployable by some studies. Why? Causes range from mediocre engineering colleges, low quality classroom education, less opportunity, and most importantly, less networking.

Not all is bad about my city, though. We are experiencing a slow influx of city-based startups, thanks to some cool entrepreneurs, such as Sumeet Chawla, who founded JustStickers.in, where we buy cool stickers and coasters for our events. His love for this city dragged him away from Bangalore, and he brought back his experience and immediately put it to use. We need more entrepreneurs like him to build innovative products and in turn help our city inch toward becoming a more technology-friendly place.

Stickers and Coasters from JustStickers at our Nodeschool Event, May 2016

Members of NodeSchool and Free Code Camp communities have something much more important than raw expertise. They have heart, a desire to network, and an eagerness to help others. This drives up the competency level of each and every participant.

Collaboration is the key to success. We hope to build a better tech community in our city by holding regular events like Nodeschool, Free Code Camp, and keep pushing our city toward becoming a more informed, skilled and proactive generation.

Join me in this Quest. For the City of Joy.

Many thanks to Arijit Layek for the awesome edits and constant motivation. If you would like to get in touch, contact me on Gitter. Help us plan a bigger Nodeschool Kolkata event.