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
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.
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.
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.