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: