Want to work with us? Contact us below, and let’s start collaborating!

FoolBlogger

HTML Button Onclick: HTML onclick vs JavaScript addEventListener for Button Events

Use addEventListener() for most button clicks. Use HTML onclick only for quick demos, tiny tests, or simple pages you will not grow later. The addEventListener() method has been widely supported in browsers for years, and MDN lists it as “widely available” since July 2015 [source: MDN].

TLDR: HTML onclick is fast to write, but it mixes HTML and JavaScript. addEventListener() keeps your code cleaner and lets you attach many actions to one button. For example, if a checkout page has 8 buttons and 3 developers, using addEventListener() can prevent messy inline code from turning into a bug hunt. Pick onclick for a toy project; pick addEventListener() for real work.

What is an HTML button click?

A button click is a small event with big energy.

You press a button. The browser says, “Hey, something happened.” Then your code reacts.

Maybe it opens a menu. Maybe it submits a form. Maybe it changes the text from Buy now to Too late, your cat bought it.

There are three common ways to handle button clicks:

  • Inline HTML onclick
  • JavaScript onclick property
  • JavaScript addEventListener()

They all work. They do not all age well.

Option 1: Inline HTML onclick

This is the classic “just make it work” style.

<button onclick="sayHello()">Click me</button>

<script>
function sayHello() {
  alert("Hello!");
}
</script>

It is simple. You can see the click action right on the button. That feels nice at first.

But then your page grows.

Now you have 20 buttons. Each one has code stuffed into the HTML. Some call functions. Some run tiny scripts directly. One has a typo. Another was copied from a tutorial written during the dinosaur era.

Honestly, it feels like finding gum under a desk.

When inline onclick is okay

  • A quick demo
  • A beginner lesson
  • A single test file
  • A throwaway prototype

When inline onclick gets annoying

  • You want clean HTML
  • You have many buttons
  • You use shared JavaScript files
  • You work with a team
  • You need more than one click action

Inline onclick is like taping a note to your fridge. Fine for one note. Bad for running a restaurant.

Option 2: JavaScript onclick property

This keeps the click code out of your HTML.

<button id="helloBtn">Click me</button>

<script>
const button = document.getElementById("helloBtn");

button.onclick = function () {
  alert("Hello!");
};
</script>

This is cleaner than inline onclick. The HTML stays neat. The JavaScript handles behavior.

Nice.

But there is a weird little trap.

The onclick property can hold only one handler at a time. If you assign another one, it replaces the old one.

button.onclick = function () {
  console.log("First action");
};

button.onclick = function () {
  console.log("Second action");
};

Only Second action runs. The first one is gone. Poof.

It drives me crazy that this can fail so quietly. No siren. No flashing light. Just missing behavior.

Option 3: addEventListener()

This is the grown-up way.

<button id="buyBtn">Buy now</button>

<script>
const button = document.getElementById("buyBtn");

button.addEventListener("click", function () {
  alert("Added to cart!");
});
</script>

addEventListener() says:

“When this button gets clicked, run this function.”

That is clear. It is flexible. It plays nicely with larger projects.

You can add more than one click action too.

button.addEventListener("click", function () {
  console.log("Track analytics");
});

button.addEventListener("click", function () {
  console.log("Open cart");
});

Both actions run. Nobody gets kicked out.

Quick comparison

Method Best for Main issue
Inline onclick Small demos Mixes HTML and JavaScript
JS onclick Simple scripts Only one handler at a time
addEventListener() Most real projects Slightly more typing

Why addEventListener usually wins

addEventListener() keeps your HTML clean.

Your button can stay boring. Boring is good here.

<button id="saveBtn">Save</button>

Then your JavaScript can do the action.

const saveBtn = document.getElementById("saveBtn");

saveBtn.addEventListener("click", saveProfile);

function saveProfile() {
  console.log("Profile saved");
}

This makes your code easier to scan. The button is the button. The script is the script.

That split helps when you need to fix bugs. It also helps when someone else opens your code after lunch and asks, “Who wrote this soup?”

A mini real-life scenario

Say you run a small pizza order page.

You have buttons for:

  • Add pepperoni
  • Add mushrooms
  • Remove olives
  • Apply coupon
  • Place order

With inline onclick, your HTML starts to look crowded.

<button onclick="addTopping('pepperoni')">Pepperoni</button>
<button onclick="addTopping('mushrooms')">Mushrooms</button>

That is okay for two buttons. But with 15 toppings, it gets old fast.

With addEventListener(), you can group your logic in JavaScript. You can reuse functions. You can loop over buttons. Less clutter. Fewer tiny mistakes.

Expect to waste time on silly typos if every button has its own inline spell. One missing quote can steal 10 minutes. Rude.

What about the event object?

Button events can send useful details to your function.

button.addEventListener("click", function (event) {
  console.log(event.target.textContent);
});

The event object tells you what was clicked. It can stop a form submit. It can help with keyboard clicks. It can tell you where the event came from.

This is very handy.

For example:

formButton.addEventListener("click", function (event) {
  event.preventDefault();
  console.log("Form did not submit yet");
});

Now your code can check the form first. No wild form sprinting across the internet.

Can you remove a listener?

Yes. This is another win for addEventListener().

function showMessage() {
  console.log("Clicked!");
}

button.addEventListener("click", showMessage);
button.removeEventListener("click", showMessage);

This works because the function has a name. If you use an anonymous function, removal gets harder.

So this is good:

button.addEventListener("click", showMessage);

This is less helpful if you plan to remove it later:

button.addEventListener("click", function () {
  console.log("Clicked!");
});

Common beginner mistakes

  • Calling the function too early: Use sayHello, not sayHello(), with addEventListener().
  • Running code before the button exists: Put your script after the HTML, or use DOMContentLoaded.
  • Using the same ID twice: IDs should be unique.
  • Forgetting quotes in inline onclick: This breaks stuff in sneaky ways.

Here is the wrong way:

button.addEventListener("click", sayHello());

That runs sayHello() right away. The button did not even get a chance. Poor button.

Here is the right way:

button.addEventListener("click", sayHello);

So which one should you use?

Use inline onclick when you are learning or making a tiny demo.

Use JavaScript onclick when the script is very small and you know you need only one action.

Use addEventListener() for normal websites, apps, forms, menus, carts, dashboards, and anything that might grow.

The best default is simple:

Keep HTML for structure. Keep JavaScript for behavior. Use addEventListener() for button events.

Your future self will thank you. Maybe not out loud. But still.