Not 100% sure I know what you're asking. But, I get the sense you're at a point where event-driven programming doesn't feel "real" enough -- or like you're at the mercy of someone else's event system. Or like your application isn't really "doing" anything. Or like it's just a bunch of disparate methods that you're feeding another application.

So. Suppose a user-facing application creates and environment and waits for stuff to happen, which is what most applications do. There are two ways to receive those "happenings."

Periodically poll for evidence that something has happened.

Pros:

• You can respond to happenings that aren't "events" in someone else's event-model.
• The application is not interrupted when it's in the middle of something important. ^{(Not generally relevant concern in JavaScript, because events are queued until the pipe is clear.)}
• The application retains more precise control over what's running; it has the flexibility to completely ignore input, only check for input every N cycles or seconds, etc.
• It may give you a [mistaken] sense of satisfaction that you're writing more real, more thorough code. You're not relying on some silly, mysterious event system. You're doing all the work, dammit!

Cons:

• Application is iteratively checking for event flags, often needlessly.

• CPU usage is high and potentially running inefficiently due to frequent context switches, increasing likelihood of thrashing.

• You likely end up writing and event-system and event-driven code anyway ...

  while (true) { var flags; if (flags = checkMouseFlags()) { doMouseInput(flags); } if (flags = checkKeyboardFlags()) { doKeyBoardInput(flags); } }

  function doMouseInput() { // stop lying to yourself. this is an event. }

  function doKeyboardInput() { // this is also an event. }

Let the host invoke the code when something happens.

Pros:

• It's an extension of what happens at lower levels. Unless you're building the hardware, you're ultimately writing event handlers: The CPU is sleeping. It's woken up when something happens. The CPU interrupts the OS to say, "hey, something happened." The OS determines that Chrome should receive the event. The OS invokes Chrome's event-handler. Chrome sets some flags and stuff and invokes your event handlers.
• You're not needlessly hogging CPU cycles and introducing context switches.
• No need to (re)write and event-system [under the mistaken notion that it's not an event-system].
• More reflective of reality, easier to wrap your head around, and easier maintain (once you embrace the model) (Even though you probably don't stop background thinking when you're in a conversation, you also don't "poll" for input. Input from your ears interrupts your thought-process and your respondToStupidRemark handler is triggered.)

Cons:

• Puts you at the mercy of someone else's event-system.
• Small chance you'll have to do some perverse looking stuff or poll for "events" anyway to respond to things that aren't "events" in your host's event-system.
• Weird sense that your application isn't doing anything ...
• ... Or maybe a weird sense that it's not even an application; just a bunch of tangentially related event-handlers.

Notable: In other languages, and with the advent of worker processes in JavaScript, it's not an either-or paradigm. You can have a background process butchering the CPU and use the existing event-system to do as much or as little with each event as you like.