Conclusions

As you can see, each messaging system has pro’s and con’s. Also, each can, and often is, used in tandem with each other. They aren’t always stand alone, and many are used in the same code base. As you better understand the basics of messaging systems, you can more easily make your Object Oriented code bases easier to encapsulate. It also makes it easier when using Design Patterns to have disparate parts of the code talk to each other in a flexible way.

Why Write This and Other Random Notes

For context, the whole reason I wrote this article is I had no idea why Promises were so lauded by JavaScript developers. I also had no clue what Streams were and if they were valuable or not. Coming from Flash and Flex, Events worked just fine as a core messaging system for years. There were a few who used Signals, and a few pumped strangeness across the global, and not well known loaderInfo.sharedEvents.

Many articles online explained what Promises and Streams were, but none explained why they mattered, nor why I should use them over some other system. WHY AM I DOING THIS!? The Stream guys are the worst. They use computer science terminology that’s extremely obtuse & unapproachable, and they assume these words plastered by themselves is enough to justify their usage. “The Ancients used Stargates, or course we’re supposed to use them as well”.

Before writing this, I didn’t realize CustomEvent’s only worked with DOM elements. Polymer’s done a good job at this via their fire method, no doubt, but… wow. Talk about having it rough. Those poor JS devs.

I also didn’t realize JQuery, to solve the above, gave them callbacks for async programming, and basically introduced the concept of Promises to the JS world. I was in my spoiled world of events that worked in visual components or in data components. What I didn’t realize was that when it came to orchestration, the JQuery crowd actually had a much easier time of it. Once you have more than 2 async events, you start having to hunt through the code to mentally map what function fires what event and what function handles that. When you start chaining those things… good luck. With Promises, it’s all centralized, making the code much easier to read. AS3 is basically like TypeScript or Dart; and thus we were all willing to have more verbose code because of strong typing’s value. Anything that can help make it less more verbose, like Promises, would of been a god send in some of the larger enterprise code bases I’ve been thrust into fixing.

Sadly, Flash Player garbage collector worked extremely differently post Flash Player 8, so things like local variables can’t just magically “exist” like they do in JavaScript. This was so deeply ingrained, it made it quite hard for me to “get” why Promises actually work, and how to clean them up.

I was also confused why Angular’s $q differed so much from the official Q. I then realized they wrote their own version of it. Some of the more important features, however, of long stack traces would of made many people’s lives easier. The biggest frustration I’ve had learning the ins and outs of Promises this year was completely useless stack traces. As as spoiled Flex developer, I’ve watched Chrome in the past 3 years insanely improve it’s runtime errors and stack traces. None of which seems to make working with nested Promises that much easier when the developers use anonymous functions everywhere. This has completely changed the way I code Promises in JavaScript if not using a Promise library (most of my work is Angular’s $q so when creating Promise chains, I avoid anon functions like t3h plague if I can, and try/catch throw like a mofo).

After doing a lot of orchestration in larger code bases from a data perspective, Promises really started to make sense once I started doing the same work in JavaScript. Remember, this was before Node, and all Factory / data orchestration had to be done on the client WITHOUT something like Cocoa’s CoreData. Once you put Node into the picture, this gets a TON easier. No matter how complicated the Java/.NET developers make your life, you can get yourself the 1 API call you need, with no parsing, in about 2 hours. That. Is. Hot. Shit.

Now, I still don’t get Streams on the client beyond gaming, or an improved event system for component frameworks (like Polymer or Angular UI). I’m attempting to recreate Final Fantasy 6’s battle system as a research exercise. In doing so, I’ve played with various Stream facets in Dart as well as Frappe (which works more like Bacon/RX).

Although research is still on going, for client side, Streams are way easier to deal with than Events, GUI or not. It took me 3 months to get comfortable, but once I got it, there’s basically no going back to Events if it I can help it. I’m not sure how to resolve that for Polymer as I’m a huge fan of the project, want to use it, but I’ve already lived through the world of Events and am over it. One of these days I need to hack into it and see if there’s an easier way to convert “fire” and it’s ilk to Streams vs. just using the common adapters on top. Implementing pause and cancel is where the real work would be.

It’d be nice of application frameworks would implement these, such as Angular UI. A few hours playing with Polymer’s ObservableList and you’ll be hooked. Array’s are too low level for creating truly dynamic application UI controls.

That said, in the data layer, especially when Node comes into play to support your front end REST API, I don’t have many disparate async events. The value for Streams beyond the GUI layer doesn’t seem helpful, and smaller promise chains work fine.

In Node, however, the complete opposite. If I had Node back in my Flex consulting days, things would have been much simpler. Waiting weeks, sometimes never, getting the API’s to be simpler, moved a ton of technical debt on the client side to compensate for this, with large Facade layers over the data. Orchestrating many different API’s, often from different servers with different request and response formats is ripe for Streams to make them easier to work with. Even better is that Node is in a language I already know: JavaScript. I can use the same libraries in the same build stack on the same CI server.

And yet, even here I struggle to convince others. My guess is they just haven’t spent 6 months like I have playing with Streams and Promises simply to write a blog post.

I will say the need for a Stream spec is pretty clear. It makes all the Promise libraries immediately understandable in how they work. You have the exact opposite problem with Streams. Sadly, I don’t think Streams will catch on as hard as Promises do. Promises solve such a core problem in ajax and only have a small native footprint to code whereas Streams require a TON of things.

First off, most browsers, even nightlies, barely scratch the surface of what RX/Bacon/Dart have for functional array methods. We’ve seen how long it takes browser vendors to acknowledge their value and add them in natively hence why lodash or underscore still reign supreme in most peoples tool belts.

Second, they rely a common expectation of how Streams work and the consensus, especially on cold vs. hot, and Observables vs. Properties, just ain’t there either yet. Until that mess settles down, the libraries will be the go-to places to embrace Streams. Well, except in Dart where they are in there out of the box. It’s still unclear to me in Polymer where Events end and Streams begin. Need more time to play.

One small note, I used a variety of text editors to write this post over the past 6 months. After about 4 pages, even if the most recent version of WordPress with the improved single page scrolling, it’s still brutal and version control is confusing. I tried Mou, my current favorite Markdown editor, but after about 10 pages performance quickly went down. I gave a few random text editors for the Mac a try and finally settled on Scrivener. It’s not safe with my HTML tags as it keeps upper casing b and pre tags, and breaks hyperlinks with it’s weird double-quote choice, but I’m sure it’s a setting I don’t know yet. Either way, at nearly 20,000 words, ZERO performance problems. Faster to boot up and use compared to Word for Mac. Props to Cliff Hall for the recommendation.

Special Thanks

Thanks to Joel Hooks, Paul Taylor, Dan Schultz, and the Dart community for answering my questions.

Art:

• Ao2 40th day: Antennas
• grad lvl

<< Part 6 – Streams

Streams

Streams are merely Array’s that emit change events through a callback when items are added to it.

That’s it.

People try to make them sound magical, complicated, or like some core savior technique of programming life. They’re not. They’ve been around long before me in networking code. They’re how Github visualizes different branches. They’re just Arrays that emit change events to a callback you can filter before you get the event. You don’t even have to use events; you could just use any value you want. Most implementations also play nice with Promises.

Streams are like Events, except you can use Array methods on them BEFORE the event is given to the callback handler, and listeners can pause further events from being emitted. They take the asynchronous flattening abilities of Promises, the filtering abilities of functional Arrays (think all those Array methods on Underscore), and the 1 to many broadcast abilities of Events. They have a flattening power of their own once you start merging streams together. When used with Promises, you can work around the race conditions much like you do for Events.

As a side note, Node’s current version of Streams at the time of this writing is actually based on EventEmitter.

For example, you’ll use a command to get the weather in JSON:

String url = 'http://api.openweathermap.org/data/2.5/weather?q=Richmond,VA&units=imperial';
EventStream links = new EventStream(HttpRequest.request(url, responseType: 'json').asStream());
links.listen((data)
{
	print(data.response);
});

In Dart using Frappe, you use listen to hear about when streams fire events. Here’s RxJS doing the same thing:

function getWeather()
{
    return $.get('http://api.openweathermap.org/data/2.5/weather?q=Richmond,VA&units=imperial')
    .promise();
}
var currentWeather = distinct.flatMapLatest(getWeather);
currentWeather.subscribe(function(data)
{
   	console.log(data);
});

And in Bacon.js, another rad, and less intimidating, JavaScript Stream library:

function getWeather()
{
    var promise = $.get('http://api.openweathermap.org/data/2.5/weather?q=Richmond,VA&units=imperial')
    .promise();
    return Bacon.fromPromise(promise);
}
getWeather().onValue(function(data)
{
	console.log(data);
});

Like addEventListener, you pass in a callback to fire when they happen. Like events, listen will pass in the parameter the Stream emits. While events have the convention to pass events as the single and only parameter, many who are used to smaller promises, or putting streaming code on top of existing promise code, more primitive values along with multiple values may be common, and that’s ok. JavaScript will work.

Strongly Typed Streams

Dart however will give you compile warnings if you don’t match the types. If you don’t use strong-typing and expect a certain type, you’ll get a runtime exception.

For example, this is good:

StreamController controller = new StreamController();
EventStream nameChanges = new EventStream(controller.stream);
nameChanges.listen((String someName)
{
	print("someName: $someName");
});
controller.add("Jesse");

This will give you a compiler warning:

StreamController controller = new StreamController();
EventStream nameChanges = new EventStream(controller.stream);
nameChanges.listen((int someName)
{
	print("someName: $someName");
});
controller.add("Jesse");

And this will compile just fine, yet blow up at runtime:

StreamController controller = new StreamController();
EventStream nameChanges = new EventStream(controller.stream);
nameChanges.listen((someName)
{
	int oldAge = 70 + someName;
	print("oldAge: $oldAge");
});
controller.add("Jesse");
//	Exception: Uncaught Error: type 'String' is not a subtype of type 'num' of 'other'.
//    Stack Trace:
//    #0      int.+ (dart:core-patch/integers.dart:15)

#inb4HaxeDoesntHaveThisProblem

The strong-typing helps both while coding, when you start merging/piping streams or using Composition. It also helps in helping the compiler create faster JavaScript at runtime. This helps when writing Dart for the client or for the server (just like JavaScript in the client and Node).

Streams Being ‘Done’ vs. Infinite

If you map your mind to Streams firing multiple times like an event, they are immediately familiar. Here’s Bacon creating an event stream (a Stream of Events, usually from something that spits out events from addEventListener type deal):

$('#someButton').asEventStream('click').subscribe(function(mouseEvent)
{
	console.log("mouseEvent:", mouseEvent);
});

“JQuery, find me this button hidden in the DOM soup, create a Stream from it’s click addEventListener, and let my anonymous function know about events as they are added in the Stream, kthxbai!”

Since Events work very similarly to Streams, most Streaming libraries have these kinds of converters to quickly make them work like Streams, yet retain the original Event interface. Lowers the barrier of entry.

Filtering

As previously mentioned unlike Events, you can filter them BEFORE you’re subscribe/listen function is fired. For example, when designing a game, I only want to know about events where a particular character is ready so I can redraw the UI:

initiativeStream.where((InitiativeEvent event)
{
	return event.type == InitiativeEvent.CHARACTER_READY;
})
.listen((event)
{
	print("character ready: ${event.character}");
});

You’ll notice I’m treating the initiativeStream here as an Array, using a where function. If you’re not familiar with uber functional Array stuff, check out Underscore’s definition of where or try your hand at the low-level implementations tutorial to understand why you even need or would want this stuff.

What if I didn’t have filtering abilities? You’d write crap like this:

initiativeStream.
.listen((event)
{
	if(event.type == InitiativeEvent.CHARACTER_READY)
	{
		print("character ready: ${event.character}");
	}
});

Bottom line, every time an initiative event is fired, only let me know about the ready events. Cool. However, anyone who has played RPG games know’s there is one issue with the above; I’ll hear about the Monster events as well. Again, without functional Array methods:

initiativeStream.
.listen((event)
{
	if(event.character is Player)
	{
		if(event.type == InitiativeEvent.CHARACTER_READY)
		{
			print("character ready: ${event.character}");
		}
	}
});

Machete don’t write nested ifs.

With functional Arrays, you can filter on filters. We’ll ensure it’s the correct event type, only from Players, and convert it so we get the player out since that’s all we care about:

initiativeStream.where((InitiativeEvent event)
{
	return event.type == InitiativeEvent.CHARACTER_READY;
})
.where((InitiativeEvent event)
{
	return event.character is Player;
})
.map((InitiativeEvent event)
{
	return event.character;
})
.listen((Player player)
{
	print("player is ready: ${character}");
});

Good stuff. Remember, though, like events, that listen callback will get called multiple times if more things come into the stream. The docs for the various libraries and runtimes are confusing in that many methods will go “when the stream is done”. Done is a strange word because if you never un-listen, is it REALLY done? The whole chain above will get executed if 5 seconds later when another IntiativeEvent is pumped through the system. In implementations like Dart’s, they actually can emit a ‘done’ type of event if you wish to know. However, for UI Streams like the Bacon one I gave above, it’s never really done because the user could click anytime they want.

Merging and Piping Streams

Many systems use Streams to link a series of inputs and outputs together with very little code. The most common are string operations on the command line in many Unix systems.

$ ps aux | grep conky | grep -v grep | awk '{print $2}' | xargs kill

To read that in Jesse Engrish, “List my running processes, throw that list to a search program called grep, and look for ‘conky’ within it, exclude all the lines that don’t match, use a program called awk to snag out the process ID (called a PID) I need from the string, and throw that PID at xargs kill which will stop the process from running. Notice in this case the pipe is literally a pipe vs. a “Stream.pipe()” function. You can imagine what happens if someone starts changing ‘conky’ and keeps re-running ps aux… continuously streaming pipes in hot action, sucka!

It should be noted that Node already has a way to pipe streams together which is more performant and shorter to write:

var errorsFromClient = getErrorPostStream();
var errorLogFile = fs.createWriteStream('error.log');
errorsFromClient.pipe(errorLogFile);

You’ll often “pipe” the data from one command to the next, whether manually doing it like I showed, or using the platform/libraries built in pipe command.

Streams can also indicate a “series of events”. As previously mentioned, Node.js uses streams much in this fashion using EventEmitters. They’re basically Events that have start, progress, and stopping points and are called Streams (api in flux at time of this writing).

Finally, Streams can be merged. One use case is when you’re building an orchestration on the Node server to have 4 API calls be 1 to make the client side code easier to write and not have to worry about authentication & parsing details. Another use case is flattening all the Events on a client that cause the same thing to happen.

For example, you know how when building a login form, either clicking the “Login” button will submit the form as well as hitting enter while within the password field? You can merge Streams to make that easier to read. Here’s a Bacon example:

var loginButton = $("#loginButton").asEventStream("click");
var loginField = $("#passwordField").asEventStream("click");
var loginStream = loginButton.merge(loginField);
loginStream.onValue(function()
{
	$.post('server.com/login');
});

The same technique can be used server-side or client side to flatten orchestrations when making many REST API calls. This example first loads the client’s location using a geoIP service (uses the server vs. navigator.geolocation) to identify the user’s latitude and longitude, ensures it’s not called more than every half a second, parses the result into a Point object, loads the weather passing in the latitude and longitude, and ensures the result isn’t the same as last time, else it ignores it:

GetLocation locationService = new GetLocation();
EventStream getWeatherFromGeoIP = new EventStream(locationService.asStream())
.debounce(new Duration(milliseconds: 500))
.map((HttpRequest request)
{
	return new Point(request.response.lat, request.response.lon);
})
.asyncMap((Point point)
{
	return getWeather(point.x, point.y);
})
.distinct();
getWeatherFromGeoIP.listen((num weather)
{
	print("It is $weather degrees.");
});

new Timer(new Duration(minutes: 1), ()
{
	locationService.getLocation();
});

If you didn’t catch it, check out line #10 (getWeather method) where the Stream supports asynchronous filters as well, specifically Promises. This is also an option where you can use Composition vs. Merging of Streams.

Here’s another example with a less linear approach where you can see different streams emitting events at different times, in this case, Monsters and Players attacking each other. One is controlled by AI, the other controlled by the user:

EventStream monsterAttacks = new EventStream(new StreamController().stream);
EventStream playerAttacks = new EventStream(new StreamController().stream);
EventStream attacks = monsterAttacks.merge(playerAttacks);
attacks.listen((AttackResult result)
{
	textDropper.addTextDrop(result.attackTarget, result.hitValue);
});

In the case of chat applications which will do a request/response in the background, but a real-time socket when you have the application active, like on your phone with HipChat. Two different application modes, your data comes out the same:

EventStream ajaxStream = new EventStream(new StreamController().stream);
EventStream socketStream = new EventStream(new StreamController().stream);
EventStream messages = ChatMessage.merge(socketStream);
messages.listen((ChatMessage message)
{
	querySelector("#chatField").text = message.text;
});

Note On Observables

While not always mentioned in some Stream API’s, an Observable is often included when describing Stream API’s. All they’re referring to is the Observer pattern applied over an Array, like a Collection. When you do an arrayInstance.push(), there are no change events. No one else knows that the Array changed unless you use a CustomEvent or pub sub to inform others that it changed. Thus, many use the Observer pattern to wrap Array’s to create Collections; similar API, except you know what changed, where, and how. Backbone’s Model and Collection classes are perfect examples of this.

Streams, however, represent the data coming into their Array IN ORDER, even when merged streams. This is why all the cray cray Functional Array stuff works on top, no matter how many Streams you use. Now, your listen function may fire only 1 time because your Array/Stream only has 1 data item. As that data “changes” however, you’ll get more events. Hence why they call it an Observable; somewhere deep in the API is the Observer pattern watching a piece of data, usually passed by ref if possible to emulate Promise state encapsulation.

You’ll also sometimes see Properties. These are sometimes like Observables depending on the library. Other times they’re like Promises that cache data.

Be aware of the context of Observable. This is one of the reasons Streams are so hard to grok because people often cite Observable in many different ways without defining what the hell it actually is. For example, the RX family calls Streams:

RxJS = Observables + Operators + Schedulers.

Except it’s not. That quote form the docs is actually talking about RX, not Streams. You could be easily fooled (I was) to think using a Stream library called RX would be defined as Observers, Operators, and Schedulers.

Streams ARE an Observable. Like the Observer pattern: “This thing changed, let the world know.” When you change a Stream, it lets the world know. You use functional Array methods to “operate” on that data. Operators == Functional Array Methods. And putting Schedulers there makes it sound like Streams are one third made up of these scheduler things. Except their not. It’s 1 plugin out of the 11 RX has… and that’s only for some advanced unit testing/functional testing mojo. Most of us ain’t going to use that.

If you think of a Stream as an Array that emits events when it changes, and thus is an Observer, you’ll get it. The 2 diverging extremes are “the Observable’s current value”, I.e. The latest value in the Stream. The other end of the spectrum is what I call them as; the Stream is just an Array of values, and you get them in order; so the Array’s an Observable. They’re both not technically correct because some Streaming libraries give you insane ballz control over Observables. Some like Frappe even go the Property route.

This is why specs exist after the innovation love has died down and developers have self-loathing when their toys start to get annoying.

Cold vs. Hot

When they start speaking really advanced about “cold vs. Hot”, don’t sweat it. All this means is something is Cold when it doesn’t dispatch events until someone listens. In a cold stream, if I click the mouse 50 times on a Hot button Stream, none of those Events are actually dispatched on the Stream until someone calls listen/subscribe. If it was a hot stream, she’d act like Events; the Stream would emit the events even if no one is listening.

Another example is reading text from a file. You won’t start receiving events for it until someone says, “Yo, read the this text file, and lemme know each line of text read as an event”. On demand type stuff like ajax calls, reading serialized data from window.localeStorage, querying a Model/Collection for the first time, etc.

Hot is the opposite, and works like Events; they’re fired whether anyone’s listening or not. This is for things that are happening whether you’re there or not. If you’re listener is late to the party, he’ll start getting new events from that point forward. If I click the mouse 50 times on a button Stream, and you only add a listen/subscribe callback after 25th has fired, you’ll only get 25 Events. Same as if you did 25 mouse clicks, then domElement.addEventListener(“click”, mouseCallback), then clicked 25 more times.

Dart streams are hot by default, whereas RX ones are cold unless you explicitly make it hot.

Stream Pros

The core goal with Streams is to reduce the amount of code you have to write, centralize the event handling, and filter the events all with Promise support. They do this by embracing functional Array filter methods, improving upon the Events API, support of Promises, with the ability to merge & pipe streams together.

Promises deal with 1 event, not many. Although you can chain and/or bubble the event forward, it’s still 1 specific event that starts each part of the chain. Streams deal with many events with many listeners.

Promises usually are a 1 time affair. With their caching, while you can restart the sequence with many Promises in a chain and it’s a lot faster, it’s still the same piece of data. Streams on the other hand represent new data each time an event occurs by default unless combined with Promises or Observables/Properties. For cold observables, this helps solve the Event race condition problem by using the fact Streams will not usually post events until someone has subscribed/listened. In the case of many, you can utilize Promises to help.

Most Event mechanisms are synchronous whereas Streams can support asynchronous operations as well, yet like Promises, be written in a synchronous way. While not 100% solving race conditions, it helps. Some API’s such as Dart’s provide options allowing the Stream to be synchronous or asynchronous. Event emitters can’t be paused by default, where in some Stream implementations, its assumed those who are listening to the streams can pause them. This means any consumer, anywhere, can pause the stream without having knowledge of what Stream their pausing, whether that Stream is merged or via Composition. Since you can get multiple instances, you can have multiple people with varying levels of control. With great power comes great responsibility. Those who use Streams are now responsible for managing this subscription. This is an additional instance that you must store and later destroy. Here’s an RX example:

var stream = getAStream();
var subscription = stream
  .subscribe(
    function (hotness) {
      console.log('Droppin it: ' + hotness);
    });
subscription.dispose();

Events make this simpler by just forcing everyone to get the emitter instance, and just manager the listeners directly from the emitter. Except in larger code bases, finding this instance isn’t so simple. Some frameworks in more dynamic languages will offload the listeners secretly through the Decorator pattern onto those who call addEventListener so that garbage collection can more easily deal with the references.

For larger applications, flattening the complexity with Streams is very similar to flattening a complex architecture through Composition and Facades. The difference with Streams is a common API to do so for both consumption of Events as well as the abilities to wire Streams together. In heavy GUI applications in Flash/Flex, we’d do this with Events, or some other messaging system like Signals.

They also scale better than Events in larger systems. As Stream / pub sub / Event systems grow, you start to run into the cognitive load challenge of keep track of all the different Event types and who dispatches them in your head including the data and types of data they contain. The difference with Streams is you have the ability to query both the data/Events you’re getting and operate on that data, all from a higher level structure. Using CSS classes and a DOM query syntax allows a more flexible UI. You can change & refactor things under the surface API, and the surface API still works. Streams are the same way. No matter what you modify, move around underneath, you can still have flexible queries up top to ensure your data is in the format you need when it arrives. For game developers this may seem like something horrible; deeply nested, disparate structures IN SUPPORT OF allowing disparate parts to flexibly talk to each other.

For applications developers on a deadline with ever changing API’s across different domains, however, different story. You can quickly see how “querying” your data and composing it into something more useful from smaller parts, all in synchronous looking code that has a small line count, sounds hot.

To be clear; this isn’t a panacea; a large code base still has a heavy cognitive load. Streams just help. Helping is good.

For unit testing purposes, it’s slightly easier in some cold Streams to write unit tests specifically because many Streams will not dispatch events until the 1st listener is subscribed. Some of this behavior is predictable in some API’s, thus you can write better tests to ensure the listener actually received and reacted on the API regardless of what transformations it and the data composing went through. This all continues to work regardless of how many Streams you merge.

Stream Cons

There is no spec right now. As such, they are quite confusing to learn. This also inadvertently makes them quite intimidating. Unless you have a game development, animation, or networking hardware background, visualizing how streams scale in larger systems can be quite hard. Bottom line, the lack of a spec means a lack of consensus on how these things are implemented. That’s really the only valid con for Streams, right now. Everything below is just nitpicking.

Streams also assume you already have good experience with Functional Array programming, and can answer why you’d use a map, where, and zip on the same Array… yet applied to Events. Wait, what? If you don’t, it can be hard to extricate what is part of a Stream, and what’s part of the library. You have to “get” why lodash/underscore are awesome libraries first before you can see how they can “improve” events.

Many also assume you already are comfortable with Promises. Many developers are comfortable with Promises, but still create nested Promise chains vs. flattening them. Most Streaming libraries embrace Promises to make dealing with asynchronous code in a multitude of events easier. This can be a real mind-bender. It takes time to get used to coding this way. If your teammates don’t, they’ll get mad when they need you debug the code if they’re not up to speed yet.

Managing, or rather, choosing NOT to manage Stream subscriptions can get you into trouble memory wise. Most Promises you see on the web don’t really show how to clean them up. Most Stream examples are the same way. Just be sure you realize their writing pseudo code to get the point across and assume you will do your due diligence by disposing of your subscriptions.

Lastly is the merge/pipe mania. Many will use Stream features simply because they a Stream features. New, fresh, shiny, hot. Once they get bored, they’re just another way of doing events or async Promises. Be wary of people who want to merge/pipe all the things. If they go all Katamari Damacy with Streams attempting to eat and consume MVC, you know they’ve jumped the shark. That said, I encourage you to do this in your spare time off of project/client work. The various libraries approach things differently so it’s neat to learn those differences.

<< Part 5 – Promise Deferred | Part 7 – Conclusions >>

Promise and Deferred (or Futures and Completers)

We’ve glossed over asynchronous coding up to this point. Many from languages which have reasonable event API’s (ActionScript) to extremely nice ones (C#), it may not at first look like a problem, or even appear to be an edge case. Coming from ActionScript, it took me years to get comfortable, and understand why, Promises were helpful. Also, many in those languages either create, or have facilities that help create, orchestration code to help mitigate common asynchronous coding issues.

But first, why asynchronous code? Synchronous code in GUI’s is challenging for 2 reasons.

The first is most UI runtimes have the code execution and drawing in the same thread. The Elastic Racetrack metaphor is often used to explain how this works. This means we have an our code doing calculations and handling user events (like clicks) done at the same time as the code that draws and redraws things to the screen. At first this seems reasonable given how fast computers are. However, as code complexity grows inline with sophisticated UI such as dynamic graphs, hardware accelerated animation, and complicated redrawing of multiple DOM elements for text and graphics in the browser… It’s a lot to do in a few milliseconds so the user doesn’t notice. That, and this all assumes the code has no orchestration to optimize this redraw part of the track, and the data processing part of the track such as invalidation strategies, also known as deferred rendering.

Second is network or I/O (input output) calls. For example, I want to show some text on this page; I know you’re German speaking based on the browser string, so I make a network request to my CMS (content management system) to get the German content. This may take a second or many seconds. In the synchronous or “blocking” world, the code would stop executing at that point and wait for that request to the server to spit back the text we need. The user’s mouse would work, but no clicks, drags, touches, double-clicks, rollovers, touch indicators, keyboard usage would function, nor would the user be able to see the UI visually update; the app looks like it’s broken. Even if it had a loading icon, it’d be paused. The UI is “locked” or “blocked”.

Cool, so things that require us to go outside of JavaScript for data like the server or the local disk/database, we’ll just make those asynchronous, which the Browser developers have done for us. The same holds true for server development platforms like Node and gaming ones like Corona and Unity. Other blocking languages like Google’s Go don’t have this issue/feature.

This, however, creates 2 new problems specifically how to write code that “waits” for things and how to chain these scenarios without making the code unreadable or hard to follow.

Callbacks are the first way. We’ve seen for simple code, they are the fastest, easiest, and most flexible way to do that. “Whenever you’re done, homey, call me”. Below is how JQuery does asynchronous loading of data from t3h interwebz:

$.ajax({
  url: "http://jessewarden.com",
  success: function(data)
  {
  	console.log("loaded data:", data);
  }
});

“Load data from here, and call this function when it worked, passing me the data as the 1st parameter, kthxbai.”

Events were another attempt to do that for multiple people who wish to know about some async event. You can utilize the same API, and your code looks the same, and the key here is that it works the exact same whether synchronous or asynchronous. The pseudo code below shows synchronous click code with asynchronous image loading code. Notice how the API looks and works the same, yet the first callback function fires immediately when you click in the same call stack, whereas the 2nd fires after some random amount of time, never in the same execution stack.

function onClick(event)
{
   console.log("clicked");
}
button.addEventListener("click", onClick);

function onImageLoaded(event)
{
   console.log("image loaded");
}
image.addEventListener("onload", onImageLoaded);

That’s all well and good until you start utilize class composition; meaning you utilize many objects that have events or callbacks in a parent class. One convention is to register all the event listeners up top, and then define the event handlers below, in the order they were added. If the event handlers utilize functions, well, you just either put them nearby and make finding the functions in order no longer work, or put them below the callbacks and force those reading/debugging to jump around your class.

For the sake of the reader, I’ll keep the below brief, but tripling the lines of code below it is something I commonly see:

define(["jquery",
		"Underscore",
		"com.company.project.views.InventoryView",
		"com.company.project.views.ScheduleView",
		"com.company.project.views.ProfilePopUp",
		"com.company.project.events.EventBus",
		"com.company.project.utils.InventoryUtils"], 
		function($,
					_,
					InventoryView, 
					ScheduleView, 
					ProfilePopUp,
					EventBus,
					InventoryUtils)
{
	var SomeClass = function()
	{
		init: function()
		{
			// TODO: use _.bindAll
			_.bind(this.onClick, this);
			_.bind(this.onInventory, this);
			_.bind(this.onScheduleTask, this);
			_.bind(this.onToggleProfile, this);
			_.bind(this.onToggleEditProfile, this);

			$("#SubmitButton").click(this.onClick);
			$("#InventoryButton").click(this.onInventory);
			$("#ScheduleTask").click(this.onScheduleTask);
			$("#ToggleProfile").click(this.onToggleProfile);
			$("#ModalProfileEditForm").click(this.onToggleEditProfile);
		},

		onClick: function()
		{

		},

		onInventory: function()
		{

		},

		onScheduleTask: function()
		{

		},

		onToggleProfile: function()
		{


		},

		onToggleEditProfile: function()
		{

		},

		someHelperMethodReferencedRandomlyAbove: function()
		{

		}
	};
	return SomeClass;

});

It looks nice at first, but then becomes a long class you have to constantly scroll up and down through. It gets worse as those event handlers and methods either grow in size, number, or have comments attached to them. You’ll notice the above is using UI events; this can be deceiving if some of those callbacks are actually listening to global pub sub messages. It gets confusion which functions are responding to global events and which are responding to local UI ones. Your unit tests also start to get pretty long as well. Languages which handle scope like CoffeeScript and TypeScript can help a little, but you still end up with the same problem: lot’s of code that’s hard to pin down to localized functionality; i.e. “all the stuff this class does about this one thing is right here” vs. spread out all over the place.

Now, remember, there are those of us from other languages/platforms where this was the norm and considered ok (even if you didn’t have a deadline). Worse, anonymous functions in some languages needed to be scoped to SOMETHING else the garbage collector would eat them leading to less terse code capabilities without a language change (i.e. Lambdaâ€s in t3h newer Java). JavaScript and Lua’s friendless to lamda/anonymous functions in terms of the Garbage Collector not eating them in Mark and Sweep phases means they are a common way to reduce code length in larger code bases at a tiny cost to function creation time (anonymous functions vs. class member / Object.prototype ones).

Where async code really starts to break down is with data orchestration and animation: 2 common asynchronous operations central in UI development. Additionally, we have no idea if any of those events already happened before the class executed. The UI events that are user gestures (the user clicked on something), we don’t care, but the model or other UI asset changes, we do. This is why you’ll often see those event handlers called at the bottom of the init to “set the class up in case she’s late to the data party”.

Jake Archibald has a great, and often used example, that wonderfully illustrates how the above provides a false sense of security, specifically around loading of an image. I’ll copy that example here verbatim:

var img1 = document.querySelector('.img-1');

function loaded() {
  // woo yey image loaded
}

if (img1.complete) {
  loaded();
}
else {
  img1.addEventListener('load', loaded);
}

img1.addEventListener('error', function() {
  // argh everything's broken
});

2 important points in this example.

First, we burden the consumer, the developer using the class that emits events, to check if it already fired, and if so, manually fire her event assuming the event handler accepts a function call without an event parameter; JavaScript does, CoffeeScript(?), TypeScript, and Dart you have to specifically mark those functions to have the events as optional parameters.

Second, my SomeClass example above doesn’t have any error handling at all. In most apps, at best, they log errors with little to no user experience thought given around those scenarios. That said, very rarely do any of them react to errors that happened before their instantiated for the user (ie a graph is shown, but the data that was supposed to be loaded before it was shown failed to load). No one wants to spend time creating user experiences around a broken server, but it’s important. Pitching clients to spend a lot of their application development budget on designing user experiences around things breaking seems counterintuitive to quality software craftsmanship. Thus, this is often left to developers who have little time for such concerns, hence why error handling is often such a horrible experience in many applications. It’s not their responsibility, its the Designer(s). Catch 22, sucka!

When you take into account both events already happening before you’ve arrived on the scene as well as errors, you can see how the code above gets much more verbose, and complicated to follow.

One common work around at least in MVC applications, is to allow View classes to be extremely friendly to null values in the Models. That way, if the data isn’t loaded let, they can show either a loading or something to the user while it loads or fails, otherwise they can immediately draw the model when they’re shown. The thinking goes “someone else will handle orchestrating everything in the correct order later” and even “somehow allow this to be easily refactored”. This can work if your Models aren’t that complicated, but still makes the code quite verbose.

The second place the SomeClass example starts to break down is when you have multiple asynchronous events that depend on each other.

var userView = {
	userModel: null,
	imageTag: null,
	showAvatar: function()
	{
		var imageURL = userModel.avatarURL;
		imageLoader.get(imageURL, function(bitmapData)
		{
			imageTag.showBitmapData(bitmapData);
		});
	}
};

You’ll notice in the above simple JavaScript View, if both the model data for the user is not yet loaded from the server AND the HTML and CSS needed to display the image which also needs to be loaded, the View won’t work. 2 options here: either check for null and do nothing assuming “you didn’t load the data for me idiot, I’m not showing anything, but will be nice to you and not throw errors” or put the burden on the developer using the View to get both of those things ready ahead of time.

Many MVC and web application tutorials out there assume you have good REST services that give you only the data you need, and you only need to make 1 call for the entire app or per section the user see’s with a good set of data caching code behind it. Backbone is notoriously seductive in this respect regarding who it’s Models are built around this with no guidance given to those who aren’t actually hitting REST services.

If you’re a JavaScript client developer, and you have a bad ass Node developer who has your back and y’all can communicate often as requirements change… you have it quite well, my friend.

This is simply not how enterprise applications work in the real world, although I’m seeing this change once .NET/Java business tier developers realize their jobs aren’t in jeopardy because of Node. You’re often building atop of .NET or Java backends that are several years old, many of which were in support of page based web sites or desktop applications long before you got involved. Getting the back-end team to refactor this for the best user experience takes an act of God, especially if you’re one of hundreds of applications that consume their services.

Unless you got Node into the mix, you’ll be making many calls, often multiple times, before a particular View/Screen can be shown to the user… in addition to your other data orchestration duties. Sometimes you’re lucky if you abstract these multiple calls away into a single class that dispatches 1 event. If you’re not, you usually have the two common problems: multiple classes that only have pieces of the data you need that continually needs refreshing or lots of data on the client you have to parse, such as the case in dashboards and graphing applications. This isn’t just ajax calls we’re talking about either; this could be JavaScript code running on the client that that needs to run long running parsing code that may or may not include an ajax call, image and other media assets, and various multiple authentication calls from a variety of servers.

For example, many financial applications often pull data from a variety of back-end data sources to show on 1 screen. Whether these are different sub-domains, or a single REST/SOAP/RPC server, they could still all work slightly differently and take varying amount of times to respond. Sometimes you have to call them in a certain order since each successive call gives you a token/id/session cookie needed for the following call for the actual data, some of which you can’t cache because the nonce tokens (prove you’re a user who’s logged in) can expire quickly for financial data.

Let’s show an example where you first need to get some user info that needs to be obtained to snag the user’s current token (which changes often) so you can then get info on a particular financial transaction (something the user bought) which is then used to charting data related to it’s id + type (which the server has conveniently stashed a bunch of huge JSON files on a Heroku friendly CDN somewhere so you can parse on the client to show charts).

However, that last call has a TON of data, so you’re using a polyfill (a library that allows you to use future HTML5 functionality, today) that supports WebWorkers (threads in JavaScript) so you can parse the data safely and attempt save to LocalStorage to avoid the slow latter part of the process again if the user views a particular transaction again later. I’ve also had cases where the type dictates which type of data we have, thus requiring another parsing call and a basic fork in the path of how you parse the code. I’ve also left out the fun parts of debugging unknowingly neutered ArrayBuffers… but lets keep it simple (lulz).

Quite a mouthful yet common in the screwed up world of Enterprise Software.

var currentClientToken = null;
var clientID = null;
var transactionID = null;
var graphWorker = null;
var done = false;

function getCompleted()
{
	return this.done;
}

function getClientToken(clientID, transactionID)
{
	this.done = false;
	this.clientID = clientID;
	this.transactionID = transactionID;
   $.get("/getClientInfo", clientID, this.onGetClientTokenSuccess, this.onGetClientTokenError);
}

function triggerGenericError(error)
{
	EventBus.trigger("GetChartingInfo:error", error);
}

function onGetClientTokenError(error)
{
	this.done = true;
	this.triggerGenericError(error);
}

function onGetClientTokenSuccess(data)
{
	try
	{
		var clientVO = ClientFactory.get(data);
		this.currentClientToken = clientVO.token;
		$.get("/getTransactionInfo", 
			{token: this.currentClientToken, transactionID: this.transactionID}, 
			this.onGetTransactionInfoSuccess, this.onGetTransactionInfoError);
	}
	catch(err)
	{
		this.triggerGenericError(err);
	}
}

function onGetTransactionInfoError(error)
{
	this.triggerGenericError(error);
}

function onGetTransactionInfoSuccess(info)
{
	try
	{
		var transactionVO = TransactionFactory.get(info);
		var currentTransactionURL = "https://sub.company.com/project/graphingcdn/" + transactionVO.id + "/?clientID=" + this.currentClientToken;
		$.get(currentTransactionURL, this.onGraphDataSuccess, this.onGraphDataError);
	}
	catch(err)
	{
		this.triggerGenericError(err);
	}
}

function onGraphDataError(error)
{
	this.triggerGenericError(error);
}

function getGraphWorker()
{
	if(this.graphWorker == null)
	{
		this.graphWorker = new Worker("GraphFactory.js");
		this.graphWorker.onmessage = function(event)
		{
			this.onGraphDataParsed(event.data);
		};
	}
	return this.graphWorker;
}

function onGraphDataSuccess(graphData)
{
	getGraphWorker().postMessage(graphData);
}

function onGraphDataParsed(graphVO)
{
	if(graphVO != null)
	{
		this.done = true;
		EventBus.trigger("GetChartingInfo:success", graphVO);
	}
	else
	{
		// parsing failed
		EventBus.trigger("GetChartingInfo:error", error);
	}
}

… to recap our problems, we now have:

1. lots of code
2. you have to scroll to find where an event is handled
3. finding event handlers for events registered within event handlers makes it even harder to follow
4. using if statements to handle potential race conditions
5. burden to ensure sequence can only start once with ability to stop it at any point
6. forced to remove event listeners to help garbage collection
7. code not fully shielded from uncaught exceptions
8. burden of error handling can make API unwieldy

WAT DO!?

Science has shown that less code equals better software. Through 1 study at least.

Enter the Promise (known as Futures in Dart). They are a way to make asynchronous code look and feel like synchronous code.

Our “use” of the above is turned into 8 lines of code (6 if you cuddle, but Machete don’t cuddle):

getGraphData().then(function()
{
	EventBus.trigger("GetChartingInfo:success", graphVO);
},
function(error)
{
	EventBus.trigger("GetChartingInfo:error", error);
});

Now, using Underscore and some refactoring using your module system of choice, you could refactor the above to be similar without Promises:

EventBus.on("GetChartingInfo:success", function(graphVO)
{
	drawIt(graphVO);
});
EventBus.on("GetChartingInfo:error", function(error))
{
	console.error("GetChartingInfo:error:", error);
});
getGraphData();

9 (7c) lines vs. 8 (6c); not bad. However, not apples to apples either. They do completely different things and the Event way doesn’t guarantee the same order in the same stack like Promises do. Subtle, but painful for n00bs to debug when they don’t know what’s going on. Heck, it’s painful for me!

The promise way only has 1 callback. The Events have multiple potential ones.

The events must be registered as listeners first before the call to getGraphData happens. If the events are not registered before getGraphData is called, you do not get the data. While getGraphData may internally cache the data, you must call it again after your listeners are registered to get this data. For smaller applications, this is easy; for larger ones, this is more challenging. It also puts a burden on those types of classes to make a caching decision sooner to make an easier API to consume.

The Promise does not care if you call it before the value(s) internally have been fetched from the server yet or not; you can call it anytime and get the same result. There is never a race condition problem using Promises as opposed to Events.

Also, by default, most Promises assume you’re caching in RAM by default based on the last return value if you follow the Promise/A spec.

API wise, it should be noted that the Event by default allows multiple responders to hear about a success or failure, whereas the Promise is only executed with 1 callback. This is neither good nor bad, just something be aware of when comparing the callback nature of Promises compared to Events.

A minor point, but the events now have a message chosen. You now need a way to track that message. If you just use a magic string, fine, but for large applications you tend to use some form of enumeration or constant class to help both management, strong-typing & code hinting for IDE’s that support it, and to ease the developer’s need to View all possible messages in a central place without a grep. Now a decision must be made; where do these enumerations go? In the class dispatching as statics/constants? Is it 1 class that supplies all global pub sub events for the entire application? Each has their pro’s and con’s, but both include more code, cognitive overhead, and crap for you to deal with.

Lastly, most Promises & promise libraries will execute on the next tick whereas most event, pub sub, and streaming libraries do not. Yes, you can add a setTimeout(func, 0), but that’s a hack on top of an API most assume works, and codes their API as, synchronously. There are a variety of use cases that aren’t described very well so I’ll cover that below regarding expecting order of execution to work, whether in synch or async code. This is why many pub sub libraries have extra error handling on removing listeners because if it’s in the middle of a dispatch, you can accidentally prevent others from getting the message.

Now, Jake’s article covers all you need to know about how Promises work, and Q’s documentation is pretty legit as well to help you create Promises as well as work with libraries that aren’t Promises out of the box.

Done Yet?

Promises, whether ES6 or Q, store the state of whether the Promise is done or not internally. You don’t have write code to do that; it’s part of them implementing the state machine part of the Promises/A spec. The Event option, however, has to allow the “done” boolean to be managed amongst the many callbacks.

This internal state management has a positive effect on sub-sequent calls with the same data, specifically getClientToken, getTransactionInfo, loading of the transaction JSON data, and receiving the parsed data from the WebWorker. For Promises, they’ll simple cache the data and re-deliver it usually immediately in the next tick (next time the stack is unwound then wound).

In the Event abstraction, you’ll have to do that yourself. In both cases, you’ll have to utilize whatever local storage option you wish to use (cookies, local storage, app cache, etc), but this functionality of locked data is built into Promises; you don’t have to code it, it’s built in + expected behavior. This includes multiple calls that could utilize multiple Promises internally. In our case, that’s about 4 Promises that each has the built-in ability to store data if it hasn’t changed.

You can also refactor asynchronous code that is not a Promise to be a Promise. That is one way developers have attempted to solve the above problems.

Solving Lots of Code

Promises are made part of async API’s. As such, instead of first registering for an event before calling something that will trigger it, you instead just call the method and the Promise is the returned value. That’s 2 lines of code to 1. Like callbacks.

This has larger ramifications, though, down the line when you’re async call is part of a series of async call allowing them to be chained as well as put into groups where they all must complete before another operation can succeed. This further cuts down on needing to define event handlers.

Scroll to Find Code

No more scrolling, it’s defined inline. The call and the responses are all next to each other.

Nested Event Handler Registration

This problem isn’t solved immediately with Promises. You can get into situations where people do not return Promises from async code, and they end up doing work in the success handlers. Through refactoring you can flatten these deeply nested chains. Thomas Burleson has a great example where he shows both.

Handling Race Conditions

Part of the spec for Promises is to solve this issue. Promises will automatically call their success or error method if the event has already occurred. This, again, reduces the amount of code you need to write when consuming async services. Additionally, it adds flexibility to call them in any order, at any time you need to; no need for orchestration/setup code to ensure everything is “ready for the data events that will fire and YOU NEED TO BE THERE FOR”. You instead react. This is part of where the “reactive” part comes in Functional Reactive Programming.

Finally, Promises have an internal state machine convention that they only ever complete once; so you don’t have to worry about your error or success methods firing more than once. They are not like events in this aspect which are known to fire many times.

This is one of the main problems that Events and Pub Sub run into when the application starts to grow in size and developers.

Aborting Sequence

Promises do not solve the abort sequence; i.e. you cannot easily start a long async Promise or chain of Promises once they’ve started. De-reffing the parent in hopes the child will get garbage collected isn’t sure fire, and adding API’s to a Promise based class is a more prudent option, although, more work in the case of many Promises through Composition.

More advanced Promise API’s such as Dart’s StreamController and RX.js’ Backpressure have the API’s you need to wrap Promises with the ability to stop async sequences, or even pause the events being emitted from the emitter. However, both incur a completely different paradigm of programming so it’s not as simple as “oh, I’ll just use this awesome library/x-compiler…”. We’ll get into that in the Streams section.

No More Cleanup Code

Promises, if they’re values are non-global and the chains are local to the function block, will get eaten by garbage collection if you de-reference them.

From a memory standpoint, this can be a blessing or a curse. Promises are ensured to only execute one time, and cache the value each additional call assuming the inputs don’t change, all while retaining the same code execution order. However, they basically act like a getter; they cache the data they are referencing as a form of Observers, albeit with 1 listener to start. Note, the Observer pattern is different than what stream API’s refer to regarding Observables. People will use the word “observable” to either refer to something that emits change events like the Observer design pattern, or a watchable property/stream in something like RX.js/Bacon.js. For large data sets, images, etc. you may not wish to leave this stuff laying around in RAM.

Check out this post (plus the comments full of lulz) from Drew Crawford talking about how brazenly just caching all data in Promises isn’t always a good idea.

Shielded From Exceptions

In the native implementations, Promises are built around the concept of success and failure. This includes built-in support for if an exception is thrown in a constructor it calls the error callback. Additionally, you can interpret successful responses from the server as a mistake and cause an error condition safely.

That said, the burden of good error handling is still on the developer in case an error does bubble up through a deep Promise chain, you want a good idea of where it came from. The same goes for good synchronous error handling through tried and true try/catch blocks within more complex Promise operations. Looking through the stack trace to work your way back down is still required in some cases which, again, can be mitigated with an effective logging solution. Theoretically yield used within a Generator function could help mitigate some of the error hunting as well.

Also, take note some Promise libraries take the positive initiative to allow you to get stack traces that are… you know… actually useful in debugging such as Q (check out longStackSupport = true) and Bluebird’s longStackTraces. these types of debugging features are NOT in Angular’s version of $q, and it’s Promise API. Do the hard work of being proactive yourself with good try/catch error messages and logging.

Also note, many Promise libraries will allow you to apply multiple catches to differentiate between the various types of async errors which is a wonderful practice you should endeavor to do.

Next Tick

Some Promise libraries will make a big deal about “nextTick”. The reason is most people when writing synchronous code expect the same order of execution no matter how many times the code is run. While Promises aren’t technically synchronous code, you write it as such.

For example, we all expect the function below to print out 1, 2, 3 no matter how many times it’s called:

function dreamMachine()
{
	console.log("1");
	console.log("2");
	console.log("3");
}

We also expect the function below to print out 1, 3, 2 no matter how many times it’s called:

function dreamMachine()
{
	console.log("1");
	Q.fcall(somePromise).then(function()
	{
		console.log("2");
	});
	console.log("3");
}

This is one feature Promises have above simple Pub Sub because your callbacks are fired in the same order regardless of how long the response takes, and if the data is cached or not.

Those who get mad about it are the ones who want faster code, typically server-side Node developers. The nextTick is often at a minimum a setTimeout(runTheThenFunction(), 0). This’ll significantly warp benchmarks that make the code look slow whereas in reality the code isn’t actually using CPU.

However, it IS a problem in that the code still takes more time and can significantly increase unit test suite test runner time. There are various Promise/A+ spec compliant libraries that will give you a flag to turn this off. This is for developers who know exactly why you’ll get 1, 2, 3 in some situations above. If you don’t know why that can happen, leave the setting off, heh!

Be aware, Node.js has a more efficient nextTick with configuration options.

Another use case is asynchronous initialization. Some objects/classes have significant amounts of asynchronous setup they have to do. You want an opportunity to be aware of some of these operations, say the loading of images in gaming Sprites, or using a server-side logging that has JSON file based configuration values is must load and parse before being used. Incidentally, this makes writing invalidation routines on top of existing GUI code a big easier.

Finally, in the case of networking operations, you don’t always want to impose knowledge of order of operations on the user. Instead, let them set and call things in any order, and let the class figure out the true order on the nextTick/frame.

For example, imagine if JQuery’s ajax didn’t have object initialization as it’s API. Instead of:

$.ajax({
  url: "http://jessewarden.com",
  success: function(data)
  {
  	console.log("loaded data:", data);
  }
});

It’d be:

var operation = $.ajax();
operation.url = "http://jessewarden.com";
operation.dataType = "html";
operation.type = "GET";
operation.success = function(data)
{
	console.log("loaded data:", data);
};
operation.load();

You not only have to learn an API, but the order in which the methods are called just to make a simple GET call? What if even more code later continues to modify, or even overwrite the operation’s parameters?

Using nextTick, calling order doesn’t matter. Internally, the actual XHR call won’t be made until the next frame anyway, so the ajax operation can handle setting everything up in the order it needs. This follows OOP encapsulation principles, and makes life easy on the developer.

Promise Pros

Promises significantly reduce the amount of code you have to write for asynchronous operations where you’d traditionally use callbacks or events.

They also localize it vs. spreading it out like events and callbacks are want to do. Just be sure you practice flattening some Promise chains so you don’t end up with the opposite problem of Promise chain hell vs. callback hell.

They also make chaining multiple asynchronous operations together much easier to read and debug.

They help reduce race conditions when the Promise already has a cached value, and merely calls the callback immediately. For low memory items, this also has the side benefit of caching data in memory for expedited calls later on, especially for those classes/Views initialized later in the application lifecycle. They also make writing asynchronous libraries easier on the consumers because they can call their setup calls in any order knowing the actual resolving of them will occur on the next frame.

Finally, you can write your code and not have to care something is synchronous or asynchronous; it looks and is written in a synchronous way.

Promise Cons

For those who are new to Promises, as I mentioned, they end up creating callback hell using Promises. Rather than creating their own operations that return Promises, they instead merely use Promises and continue to nest them. Again, check out Thomas Burlesson’s great example where he shows how you flatten deeply nested Promise chains. Once you practice, you can quickly flatten these trees as you create them. Eventually you’ll start writing methods that return Promises by default making your life easier. Like once you memorize a for loop’s syntax, you never think about it again.

For low memory situations on mobile, you could get in trouble when caching the data in Promises. While you’re supposed to follow the Promise/A spec and ensure Promise’s fullfilled state stays true and never changes the data, care must be taken to ensure you aren’t keeping these around unnecessarily, especially on mobile devices. This isn’t necessarely indicative of Promises, rather caching in general, which is a commonly hard programming problem. They are just brought up since most Promises handling async operations are often around data, your want to cache it.

Caching isn’t straightforward either. Some libraries help in this regard, but basic programming for by value vs. by reference apply. When getting values you’re basically assuming the developer doesn’t change them if they’re by ref. Cloning has performance impacts as well for deeply nested objects. Following the Promise/A spec with regards to not changing the value is often based on convention and isn’t always easily enforced. Don’t get me started on the insanity of sharing ArrayBuffers across WebWorkers; shiz is magic death.

<< Part 4 – Publish Subscribe | Part 6 – Streams >>

Publish Subscribe

Callbacks help objects/classes talk to each other in a less coupled way. Events for many to listen and react. However, for objects that deal with data or business logic, you need a way for them to globally communicate through some sort of event or message bus. Various libraries have sprung up in languages that do not have this natively available, or if the native API doesn’t fit the developer(s) need.

Enter publish subscribe.

Now, pub sub is actually a pretty high level term that pretty much encompasses this entire article.

Callbacks and Promises have a subscribe method, and they publish a method when they execute a callback. However, we’re referring to the ability to publish to multiple subscribers.

Events have a subscribe method via addEventListener, and a publish method via dispatchEvent. However, at least in the case of JavaScript, we’re referring to the same abilities WITHOUT the need for anything graphical involved.

A pub sub system COULD be made from a Stream, but I wanted to cover the implementations I’ve seen so you get an understanding why they not callbacks, events, promises, nor streams.

Pub sub IS the ability to:

• be 1 instance that can broadcast to many listeners
• have no need for anything GUI related
• just be a class/object instance

Pub Sub Examples

Backbone’s Events class is the first example most in the JavaScript community refer to. You can either create an instance and pass this instance around via Require.js as a global telephone. Some get lazy (or are in a hurry or don’t know any better) and shove on window, or forget they can just use the Backbone object. Either way, here’s a manually created global one below:

var EventBus = {};
_.extend(EventBus, Backbone.Events);
window.EventBus = EventBus;

Now, any object or class, anywhere in the world, GUI or data, can go:

EventBus.trigger("onSomeEvent", 1, 2, {firstName: "Action", lastName: "Jackson"});

… and anyone and their mom can listen for it, anywhere via:

EventBus.on("onSomeEvent", function(event)
{
	console.log("Who's the MAN?!: " + event.firstName + " " + event.lastName);
});

Instead of caring about the context (or where and how) a message is sent, you just… get the message.

The same concept applies to Runtime in Corona SDK:

Runtime:dispatchEvent({name="boxDragged", x=event.x, y=event.y, phase=phase})

And the View/Controller class that will visually update the object. She listens

function controller:init(view)
	self.view = view
	Runtime:addEventListener("boxDragged", self)
	self.originalX = self.view.x
	self.originalY = self.view.y
end

function controller:boxDragged(event)
	self.view.x = event.x + 20
	self.view.y = event.y + 20
	local phase = event.phase
	if phase == "ended" or phase == "cancelled" then
		self.view.x = self.originalX
		self.view.y = self.originalY
	end
end

Notice Backbone’s is a custom implementation whereas Corona’s is a native implementation, built into the platform.

Angular’s uses a hybrid approach of event using their Dependency Injection system where anyone can reference the top node to hear all events bubbled (emitted) up:

// listen for it
angular.module("com.company.project.inventory", 
[
	"com.company.project.utils"
])
// shows and hides children UI panels
.controller("UIPanelsController", function($rootScope)
{
	$scope.inventoryShowing = false;

	$scope.onToggleInventory = function()
	{
		$scope.inventoryShowing != $scope.inventoryShowing;

		// 

	};
	$rootScope.on("toggleInventory", $scope.onToggleInventory);
});

// use it
angular.module("com.company.project.gameControls", 
[
	"com.company.project.utils"
])
.controller("GameControlsController", function($scope)
{ 
	// angular template be all like 
	// <button ng-click='onToggleInventory()'>Show Inventory</button>
	$scope.onToggleInventory = function()
	{
		$scope.$emit("toggleInventory");
	};
});

You send whatever you want. You can send wherever you want; doesn’t matter if within a button click handler, a deeply nested list, or somewhere in the bowels of your ajax code parsing whack JSON from a middle tier.

This simplicity and flexibility made Underscore and others of its ilk a lot more popular than the verbose Event system. Easier to learn, easier to integrate anywhere, and easier to read. You can still use events for UI related concerns to keep the bubbling and cancelable functionality, but for everything else in Application (what your app does) and Business logic (what back-end your app talks to and how), you can simply use a pub sub library. This is why they’re popular amongst MVC frameworks.

While Underscore doesn’t cover all the cool pub sub libraries out there, it’s the most approachable and gives you enough to be uber effective in understanding one basic approach to pub sub.

Pub Sub Pros

At their core, any “thing” in pub sub can publish a message. Any “thing” can subscribe to that message. A message can be whatever you want. They’re flexible, easy to grasp, and reasonably easy to debug if their dispatch function isn’t overly verbose.

Callbacks only support 1, but pub sub supports many. Pub sub have a more obvious API to subscribe and unsubscribe to messages and to particular messages than callbacks. They don’t expose nested UI parameters in their function signatures like Events do for addEventListener, nor do they care about where they’re dispatched from; if someone is listening for their message, they’ll get it. There is no native functionality to worry about canceling, so that too isn’t thrown in the API of messages where only 1% would actually have their preventDefault called.

Pub Sub Cons

What pub sub lacks that events has, this makes it basically assumed you’ll never use it for UI. Instead, you’ll use it in some form of MVC; whether intentional or not, to communicate UI concerns to higher level classes that DO things when someone clicks a UI element or some class needs to broadcast it has new data if any of those UI controls want to show it.

If for whatever reason you want to stop others from getting events, you can’t unless for some weird reason the API supports removing all currently subscribed listeners from the stack of a subscriber’s current callback execution (which isn’t elementary to support, mind you; many an experienced programmer has created messaging bugs forgetting this common use case). Most Stream API’s have this functionality, either by pausing the broadcaster from the listener at a bare minimum.

You can also get into race conditions where a subscriber subscribes too late and misses one or many messages. This leads to a lot of weird “orchestration” code to ensure all views and controllers are registered for services start loading data that the UI wouldn’t be ready to “handle”. There is no “did I miss any?” functionality unless the API has clever ways to do so. Promises and Stream fix this problem.

More importantly, though, you start to get into “message hell” as your application grows. Unlike callbacks which can be solved by flattened Promises, pub sub messaging systems are a global message hell. Everyone sharing the same telephone, like an 80’s sitcom. They can be way worse when under a deadline with lots of code. You’re constantly following the path of a message through various unrelated classes just to update a piece of data or scope. What set out to be a nice way to enforce encapsulation ends up being an unassuming tool that creates confusion and an unwieldy code base to debug. The key is to isolate concerns and treat pub sub as a “global” or “Singleton”. Once it’s viewed in that light, it makes it easier to only use when necessary.

Pub sub aren’t in those ECMA specs, nor natively implemented as new features in the browsers, nor as API’s in the new languages because of the issues mentioned above.

Everyone uses Pub Sub anyway because it’s extremely useful whether in games or applications.

<< Part 3 – Events | Part 5 – Promise and Deferred >>

Events

Events in JavaScript (and EventEmitters in Node.js) allow 1 to many; meaning 1 dude or many people can listen for the same event without the developer having to add more code to the sender.

Events also solve with finality the parameter order problem. There is only ever 1 parameter: The Event. Callbacks, Promises, and Streams can have none, or many. In dynamic languages, you have no compiler help with this. Since most Events are an object of some type, you can add as many slots as you want without changing the interface between sender and receiver. This slightly improves the ability to refactor. In strongly typed languages, the surface API doesn’t change, only the internal consumption which is often opt-in, thus helping keep OOP things OOP. w00t to the w00t. Moot point is moot.

The most common example you see is listening for a mouse click on a button in JavaScript web development, shown in TypeScript:

function clickHandler(mouseEvent:MouseEvent)
{
	console.log("a mouse click:", mouseEvent);
}

myButtonOrDiv.addEventListener(MouseEvent.CLICK, clickHandler);
// or if strong-typing ain't yo thang,
// da first parameter is always a String, cha-ching!
myButtonOrDiv.addEventListener("click", clickHandler);

You setup your handler, which is a function, that runs when the event fires. In this case, when the user clicks the mouse. Sometimes it’s called an “event handler”, other times an “event callback”. Same thing.

Either way, looks like a callback, right? While they are like callbacks, all event handlers, or handlers for short, take an event as the first and only parameter. Every event that fires, whether built in ones like MouseEvents, or custom ones you make and fire yourself, has the same API.

If you want to stop listening for mouse events, you simply remove your listener:

myButtonOrDiv.removeEventListener(MouseEvent.CLICK, clickHandler);
// or without strong-typing
myButtonOrDiv.addEventListener("click", clickHandler);

If you want have many listeners, simply add it.

function clickHandler1(mouseEvent)
{
	console.log("a mouse click in handler 1:", mouseEvent);
}

function clickHandler2(mouseEvent)
{
	console.log("a mouse click in handler 2:", mouseEvent);
}

myButtonOrDiv.addEventListener("click", clickHandler1);
myButtonOrDiv.addEventListener("click", clickHandler2);

Notice how clickHandler2 is a completely different function. If you were to use the same function, it would NOT register an additional event.

function clickHandler1(mouseEvent)
{
	console.log("a mouse click in handler 1:", mouseEvent);
}

function clickHandler2(mouseEvent)
{
	console.log("a mouse click in handler 2:", mouseEvent);
}

myButtonOrDiv.addEventListener("click", clickHandler1);
myButtonOrDiv.addEventListener("click", clickHandler1);
// click on button, results in:
// a mouse click in handler 1: MouseEvent {dataTransfer: null, toElement: div#clickit, fromElement: null, y: 14, x: 45…} 

Note there are SOME Publish Subscribe libraries and API’s out there that support such functionality; i.e. multiple addListener calls to the same function pointer result in multiple event registrations, and thus you’ll need to do as many to un-register them. However, those kind of API’s put a burden on the developer to remember how many they registered, or an obtuse API to query for this number, so it’s assumed the function/object/table pointer are sufficient for a single registration since you only expect that callback to be called once per event. If another dude needs to know about it, he’ll actually be a “true other dude” vs. an additional pointer pointing to the same function.

Custom Events

The power of events in client side JavaScript is your ability to create your own and tap into the API. While many other frameworks have illustrated this concept like Backbone’s Marionette and Angular’s $broadcast and $emit, Polymer is one of the first to embrace the native JavaScript API for the actual CustomEvent part via fire and asyncFire, not to be confused with zee German’s FIIIRRREEEE!!1oneone

The idea of dispatching custom events for many potential listeners to subscribe to is common place and accepted even if the mechanisms for doing so vary between languages and platforms.

Say you’re building a component for form input and you want to dispatch event when everything is done: all inputs, all validations, and all data formatting. While you could listen for the “click” event on the Submit button, you’d still have to either manually re-trigger all the forms validations again (assuming you have a real-time time form validation here), and once complete, THEN you know it’s truly submitted. The 2 problems with that are that you’re making the consumers of the form deal with that, and that’s not very OOP encapsulated of you.

The better strategy is to create a View; a class that handles all of those concerns where they are, lets those who want to use it know: when is the form ready. Your code can do all that form validation, and then at the end, simply:

someDOMNode.dispatchEvent(new CustomEvent("formCompleted"));

And registering for it?

function onFormCompleted(event)
{
	console.log("Form's complete, yo!");
}
someDOMNode.addEventListener("formCompleted", onFormCompleted);

To get multiple listeners, simply go:

someDOMNode = document.createElement('div');
function onFormCompleted(event)
{
	console.log("Form's complete, yo!");
}

function onFormCompleted2(event)
{
	console.log("check it, form's done mah man.");
}

var cow = {
	onFizzOrm: function(e)
	{
		console.log("moo and stuff, form's done and stuff.");
	}
};

someDOMNode.addEventListener("formCompleted", onFormCompleted);
someDOMNode.addEventListener("formCompleted", onFormCompleted2);
someDOMNode.addEventListener("formCompleted", cow.onFizzOrm);
someDOMNode.dispatchEvent(new CustomEvent('formCompleted'));
// Form's complete, yo!
// check it, form's done mah man.
// moo and stuff, form's done and stuff.

You’ll notice I passed an object’s method in the 3rd listener. Again, as long as it’s a function, she’ll work, regardless of where she’s located. #scopeLoversPizzaBeware

Wrappers

Some languages provide Event dispatching as a core mechanism that can be optionally added to DisplayObject tree’s. Sadly ECMAScript requires Document Object Model (called DOM for short) elements. This means you cannot use Event dispatch capabilities in your data layer (code that has nothing to do with View’s, HTML, CSS, div’s, etc). This is often why many frameworks tend to eschew Events for View level concerns, and use their own pub sub library for Controller and Model level concerns. It’s also funny to see Polymer do it like Flex did where you have an http call co-chilling next to a bar chart and they be all like, “Sup dawwwwg, I’m bound to you, and you to me, and we’re separated by just 1 line break… small world, right!?”

Backbone assumes you’ll use JQuery for DOM level concerns and Events, but will use Backbone.Events as a way for Views and Models to talk to each other. Angular actually embraces this DOM lover scenario with emit and broadcast. Polymer embraces the basic event structure of CustomEvents with a wrapper method called fire. Node’s got EventEmitters, but has no event bubbling capabilities ’cause there ain’t no DOM on the server in the API code.

Event Bubbling

If you’ve ever built composite GUI’s, i.e. components that contain components, then you’ll understand the concept of event bubbling pretty quickly. For those familiar with Angular, it’s similar to $scope.$emit.

Considering a UI is built from clickable parts that can contain other clickable parts, no longer is it as simple as “I clicked on this thing here”. When you stack 20 things on top of each other, which one did you really click on? You’d think the one on top, but EACH thing gets its own click event. To be clear, “things” in the HTML world is div, or more specifically Node (not Node.js) and EventTarget mashed together. While people traditionally think of buttons and other controls as the things you click on, nowadays not so much.

Many controls are not easily skinnable, are missing functionality, or work differently across different browsers vs. mobile. Some are even made of ShadowDOM parts. For these reasons divs are often what you click on. These divs can also contain other divs which are effectively components/buttons/controls in their own right.

Click Me
Click Me

Sometimes you just want to know “the user clicked on the Submit button in the form”; whether it’s an actual <button>, a div you’ve decorated, or a series of things inside a ShadowDOM custom web component. Other times you want to know “the user clicked on the form itself”. While still other times you want to know “the user clicked on item 39 of that long list buried deep in the dom sea” or in your custom draggable window “the user clicked on the header bar, not the window contents, thus I should start dragging the window”. That last one is a capture phase, when bubbling goes the opposite way, like tears in the rain.

In my Flash and Flex experience, the use cases for actually using event bubbling are rare. The only ones I’ve used consistently are for lists, when creating draggable containers such as video game UI’s or emulating a windows based interface, or for Supervising Controller frameworks.

Bubbling up items in some form of list or datagrid control so I can write the click event handler in 1 place instead of adding for each item. If I have 100 listen items, I don’t want to add 100 click handlers. Instead, you add 1, and any click that happens within the list is bubbled up to you. The same technique is used for tile based games such as a tower defense or point and click to walk to tile game. You don’t want a click handler for each tile in a hundred to thousand tile grid; you just want 1 and you use the X and Y values to do the math on what tile you clicked on.

For example, lets say you’ve created a dynamic list and want to know what piece of data the user clicked on.

You have to correlate the index number of the list item and use it to access the data in the Array. Now, in a simple world you could do so like this using the event’s target property to identify which of the list items was clicked on:

<ol id="myList"></ol>

<script>
data = ["Uno", "Dos", "Tres"]; 
list = document.getElementById('myList');

function itemClicked(item)
{
	console.log("you clicked on item:", item);
}

data.forEach(function(item)
{
	var listItem = document.createElement("li");
	listItem.innerHTML = item;
	list.appendChild(listItem);
	list.addEventListener("click", function(event)
	{
		itemClicked(item);
		console.log(event);
		event.stopImmediatePropagation();
	});
});
</script></pre>

You’ll notice on line 17, we create a new anonymous function for each list item. Since it’s created in that context, it retains a unique link to the item that was used to create it. This is nice; whenever it’s clicked on, we know which item it represents, and call itemClicked with it.

The bad? Really dude? A listener for EACH list item? What if you have a hundred or more list items, or the list redraws often? You’ll end up with a ton of listeners, many of which you’ll then later throw away. Dat shiz cray. You’ll make the Garbage Collector work overtime, and potentially get jank on your animations. Also notice we’re turning event bubbling OFF on line 21. I’ll explain that in a bit.

Let’s show how you make event bubbling work for you vs. against you:

data = ["Uno", "Dos", "Tres"]; 
list = document.getElementById('myList');

function onItemClicked(event)
{
	console.log("you clicked on: " + event.target.getAttribute("data-item"));
}
list.addEventListener("click", onItemClicked);

data.forEach(function(item)
{
	var listItem = document.createElement("li");
	listItem.setAttribute("data-item", item);
	listItem.innerHTML = item;
	list.appendChild(listItem);
});

The same technique goes for any DisplayObject based framework where you use many different vector shapes, bitmaps, or whatever to composite together to form an interface. It isn’t always flat.

Not all events bubble by default, but MouseEvents do.

The above is just 1 level deep, but the rabbit hole goes much deeper. The 2nd, less used use case is when you have some sort of View, whether a Backbone or Ember child View, or even an Angular Controller. Much like the List example above, these are actual Views. They could just be a List item with some slightly extended functionality, or perhaps they’re complex Web Components using mad amounts of composition of other Views within them. Higher level Views are delegated with the responsibility of handling application level events such as navigating to other places in the View, basically things that deal with user interactions that don’t affect data.

In Backbone/Ember’s case, you simply dispatch your own events, except you ensure bubbling is true. They’ll wind their way up the DOM so those higher level Views can hear those events. This has the side benefit of not caring if you refactor your Views later because no matter where those child Views are, their message will be received.

// some random child View
dispatchEvent("userClickedOnShowInventory", true);

Note the 2nd parameter; it’s false by default.

Stopping Event Bubbling

You can stop events from bubbling up further by either stopPropagation or stopImmediatePropagation.

These are hard to remember the difference, so here’s a definition of both written by an art major vs. a computer scientist.

Think of stopPropagation as “stop bubbling” and stopImmediatePropagation as “stop everything”. The word “immediate” should help you remember “omg, stop all the bubbling things!”.

The stopPropagation method will stop all event bubbling to any parents of the current element, but if other people have click events registered at your level, they’ll get their event handlers run in the same call stack. The stopImmediatePropgation stops everything after your handler is done executing.

Showing the modified example above, we’ve nested our list in 2 additional container divs, and added additional click handlers to them to see bubbling in action, and see what happens when we stop it. Observe:

<div id='appUpInThisMug'>
	<div id='datContainerThough'>
		<ol id="myList"></ol>
	</div>
</div>

And our updated code:

data = ["Uno", "Dos", "Tres"]; 
list = document.getElementById('myList');

function onItemClicked(event)
{
	console.log("you clicked on: " + event.target.getAttribute("data-item"));
}
list.addEventListener("click", onItemClicked);
data.forEach(function(item)
{
	var listItem = document.createElement("li");
	listItem.setAttribute("data-item", item);
	listItem.innerHTML = item;
	list.appendChild(listItem);
});

function onContainerClicked1(event)
{
	console.log("onContainerClicked1");
}
function onContainerClicked2(event)
{
	console.log("onContainerClicked2");
}
var container = document.getElementById('datContainerThough');
container.addEventListener("click", onContainerClicked1);
container.addEventListener("click", onContainerClicked2);

var app = document.getElementById('appUpInThisMug');
app.addEventListener('click', function(event)
{
	console.log("app clicked 1");	
});

When you click any in the list, you get:

you clicked on: Uno
onContainerClicked1
onContainerClicked2
app clicked 1

Cool, the list item gets his click first, it then bubbles up to the 2 container listeners, and finally to the top at app.

Let’s just stop all bubbling when it gets to the container:

function onContainerClicked1(event)
{
	console.log("onContainerClicked1");
	event.stopPropagation();
}

We now get:

you clicked on: Uno
onContainerClicked1
onContainerClicked

Notice the 2nd container still gets to run, but bubbling beyond that level has been stopped.

If we swap out stopImmediatePropagation:

function onContainerClicked1(event)
{
	console.log("onContainerClicked1");
	event.stopImmediatePropagation();
}

You see only the 1st bubbled event is fired, but his sibling and his parent are not:

you clicked on: Uno
onContainerClicked1

You use stopImmediatePropagation if you want to ensure a bubbled event you know is up there somewhere isn’t fired. This can happen in games. It can also be useful when creating deeply nested Views and you’re manually propagating your own custom events that have more meaning than “click”.

I have no idea why you’d ever use stopPropagation.

Event Cancelling

Another feature of events typically used mostly in UI operations is event cancelling. It’s sometimes used conjunction with event bubbling, but the more common use case is for stopping functionality from happening you don’t want to happen, thus a supported way of opt-ing out.

For example, by default an anchor tag will navigate the browser to whatever URL you’ve put in the href attribute. You can simply stop this behavior by calling preventDefault. This is different in event bubbling in that even if the event bubbles up, whatever native behavior the browser is supposed to do, it now won’t.

Event Pros

You use events when you want to have multiple people hear abeout the same change. Callbacks are 1 to 1, whereas Events are 1 to many.

Events provide flexibility to emitting many different changes from a single object. For example, we can emit both MouseEvents, KeyboardEvents, and FocuseEvents all from the same Button. You can even give fine grain context about the event, such as a mouse up event vs. a mouse down event, or which key was pressed in the keyboard down event. Callbacks can do this as well, but again, only 1 object can hear about it.

Most events we care about in JavaScript web development support this format, as do Flash & Flex, Corona SDK using Lua, and many others. It’s a common way of doing 1 to many message systems.

As you can already see, events prevent the parameter order problem; events are objects so order doesn’t matter.

You’ll notice that the event names are strings. This means you can create your own events with any name you want as long as it doesn’t conflict with built in ones such as “click”, “onfocus”, etc. This makes them flexible and easy to work with, even in strongly-typed languages.

For GUI systems, if you’re dealing with a bunch of lists or nested Views that handle application level events ONLY related to UI concerns, the bubbling can come in handy by reducing how many event listeners you need to create. This also makes handling View level concerns easier through Composition vs. letting a framework deal with it.

For asynchronous operations, finite state machines, or operations that take some random amount of time and may not succeed, events are perfect.

Event Cons

You can’t object pool them in most frameworks. If you are dispatching many different events, each one is a unique object created, usually with an assumed limited lifetime, which has a performance impact both in creation as well as in garbage collection. It’s not noticeable in applications, more so in games.

Events on the client have also fallen out of fashion long ago for a variety of reasons. Yes, we have things “in fashion” in programming. It doesn’t mean those out of fashion are bad, it’s just harder to start a conversation with some people when you talk about the “boring” things.

First reason is JQuery’s rise to fame and it improving upon the events API via it’s own callbacks, not to be confused with the callbacks I’ve described at the top of this article. Keep in mind everything I described too is not the same cross browser. Different versions of IE, older versions of Firefox, etc. are all different. JQuery helped make all of that sane to work with, and developed it’s own conventions.

Events are very div specific whereas JQuery encourages you (vs. make you) think more in selectors, classes, and ID’s. Simple features help the sale, too, like an option to have an event only fire once. The syntax is a lot smaller too.

Second reason is pub sub messaging frameworks started popping up in JavaScript that helped provide a tighter syntax, better cross browser support, and worked in both UI and non-UI code. Basically globally; anywhere in your code. Most pub sub libraries could receive a message regardless if they were defined in UI code or application framework code. Events on the other hand don’t, they get cloned if you manually re-dispatch, and bubbling is strictly tied to the DOM tree. This is why Node.js developed their own EventEmitter.

Third reason is that JQuery helped continue to fuel the Functional Programming momentum that Python and Ruby on Rails helped popularize. This eventually matured to Reactive Programming which cemented things like Promises, Deferred, Observers, and Event Streams into standard (read: “cool and new and I must use it everywhere”) ways of doing GUI programming on the web. Kind of like how wearing Axe body spray makes you cool even if you weren’t before. Yeah.

Examples often cited include “callback hell” where dealing with multiple callbacks from asynchronous events results in a ton of “event registrations up top, handler soup at the bottom”. Worse is when you start nesting these callbacks like out of control if/then statements, and it’s basically hard to read and debug. Utilizing functional programming patterns makes the code easier to read and easier to debug.

Events have this awkward place in Reactive Programming, at least for the front-end, in that they are now merely a potential delivery message, and no longer the way to register and dispatch messages, thus keeping single parameter/result advantage that events have. Languages like Dart still support using both, but discourage their use indirectly by espousing their nice Reactive Programming implementation via Futures (Promises) and Streams.

Those using Streams intentionally avoid the 1 to many support Events have by continually merging streams of complex systems to funnel all events into 1 pipeline, leaving it to the consumer to filter out the events they want. On top of a View layer, this can work fine, but not within a View layer where events still reign supreme.

They aren’t going away in that all browsers support the basic ones for mouse events, touch events, keyboard events, focus, and form events to name a few. Most code nowadays, however, abstracts them away into a less verbose API.

They also survive in other languages that allowed a flattening of UI tree, such as Flash’s EventDispatcher and Corona’s EventListener (which has View and Global versions). This, flattening the UI vs. using event bubbling, is especially important when you bring in OpenGL/3D functionality because you want as little composition as possible, so things like event bubbling constitute a code smell.

<< Part 2 – Callbacks | Part 4 – Publish Subscribe >>