Event-driven programming is a paradigm in which the flow of a program is controlled by events — button clicks, key presses, mouse movements, timer expiry, or network messages — rather than running top-to-bottom through a fixed sequence. Almost every graphical user interface in existence runs on this model.
How does event-driven programming differ from procedural programming?
In procedural programming, the program runs a fixed sequence of instructions from start to finish. The programmer decides the order of execution in advance. If you write a Python script that reads a file, processes it, and prints a result, you can trace exactly which line runs next at every moment.
In event-driven programming, the program sits idle inside an event loop, waiting for something to happen. When a user clicks a button, presses a key, or a timer fires, the runtime places an event on a queue. The event loop picks events off the queue one by one and calls the appropriate event handler — a function you wrote specifically to respond to that event. The program has no predetermined order of execution: it reacts.
| Feature | Procedural | Event-driven |
|---|---|---|
| Execution order | Fixed, top-to-bottom | Determined by user/system events at runtime |
| Control flow | Written explicitly by programmer | Managed by an event loop |
| Idle behaviour | Runs to completion | Waits in loop until an event arrives |
| Typical use | Scripts, algorithms, batch processing | GUIs, games, web apps, real-time systems |
What are events, handlers, and listeners?
Event: Something that happens — a button click, a key press, the arrival of a network packet, a timer reaching zero.
Event handler (or callback): A function that is executed in response to a specific event. The programmer writes this function; the runtime calls it.
Event listener: The mechanism that watches for a particular event and connects it to its handler. In Python's Tkinter:
import tkinter as tk
def on_button_click():
label.config(text="You clicked me!")
root = tk.Tk()
button = tk.Button(root, text="Click", command=on_button_click)
button.pack()
label = tk.Label(root, text="Waiting...")
label.pack()
root.mainloop() # starts the event loop
command=on_button_click registers on_button_click as the event handler for the button's click event. root.mainloop() starts the event loop — the program now waits, responds to events, and continues waiting.
What is the event queue and why does it matter?
Events do not jump straight to their handlers. They enter an event queue — a first-in, first-out data structure. The event loop processes them one at a time, in order of arrival. This guarantees that events are handled predictably even if several fire in rapid succession.
If you click a button five times quickly, five click events queue up. The handler runs five times in order — the event loop ensures no two handlers run simultaneously (in single-threaded environments), preventing data corruption from concurrent access to shared variables.
Where is event-driven programming used?
| Application area | Examples | Events involved |
|---|---|---|
| Desktop GUIs | Tkinter, PyQt, Java Swing | Button clicks, menu selections, window resize |
| Web browsers | HTML + JavaScript | Mouse events, form submissions, page load |
| Games | pygame, Unity | Key presses, collisions, frame timer |
| Operating systems | Windows, macOS, Linux | Mouse/keyboard input, hardware interrupts |
| Embedded systems | Arduino sketches | Sensor triggers, pin state changes |
JavaScript — the language of the web — is almost entirely event-driven. Every addEventListener() call registers a handler; the browser's event loop drives the entire page interaction.
What are the advantages and disadvantages of event-driven programming?
Advantages:
- Programs respond immediately to user input without wasting CPU time polling in loops.
- Code is naturally modular: each handler does one job.
- Well-suited to concurrent, unpredictable inputs (a user may click anything at any time).
Disadvantages:
- The flow of execution is harder to trace — there is no single path through the code to follow.
- Debugging is more challenging because errors may only occur in specific event sequences.
- Deeply nested callbacks (so-called "callback hell") can make code difficult to read and maintain.
Frequently asked questions
Is event-driven programming on the GCSE Computer Science syllabus?
Yes. AQA GCSE Computer Science (8525) and OCR GCSE Computer Science (J277) both list programming paradigms as an examinable topic, including event-driven programming alongside procedural and object-oriented. Students should be able to define the paradigm, describe the role of events and handlers, and compare it with procedural programming.
What is an event loop in simple terms?
An event loop is a continuously running process that checks whether any events are waiting in the event queue. If an event is found, it calls the corresponding handler function, then goes back to waiting. It is the mechanism that keeps a GUI program alive and responsive — without it, the program would simply run to the end and close.
Can Python do event-driven programming?
Yes. Python's Tkinter library uses event-driven programming for GUIs — root.mainloop() starts the event loop. The pygame library provides an event loop for games. Python's asyncio module supports event-driven asynchronous programming for network applications. Any framework that requires you to "register" a function to run when something happens is event-driven.
How do events relate to interrupts?
Events (in software) and interrupts (in hardware) share the same idea — something asynchronous demands attention and triggers a handler. A hardware interrupt is a signal from a device (keyboard, network card, timer chip) that pauses the CPU to run an interrupt service routine. An event in a GUI framework is the software equivalent: the operating system translates the hardware interrupt into an event object, queues it, and the application's event loop calls your handler.
Bring your GUI project or event-driven exercise to Professor Turing at aitutors.me — we will trace the event loop together until the paradigm makes complete sense.