A New Concurrency Primitive
No code is more concurrent than code that does not run and then runs all at once, suddenly.
In these modern times, it seems everyone is catching the concurrency bug. At EmberConf 2017, everyone and their elderly friend from down the street named John was talking about ember-concurrency. There were at least 10 talks that were mostly or only about the add-on wunderkind. Furthermore, articles by the author of the add-on have been declaring ember-concurrency as the magic bullet to solve problems you didn’t even know you had. Even Twitter was alight with admiration for this hot new craze.
ember-concurrency is good
Before ember-concurrency, I had to think about things like how to handle failure gracefully and what to do about retrying asynchronous work. I would think about all those things. And then not do them. Because programming is hard and I already spent so much time getting the happy path to work. If the user experienced a network error, that was just their fault for not plugging directly into the Ethernet port outside of Amazon’s data center, like I do. I thought that I shouldn’t have to adapt my applications to workaround every common failure case. But I was wrong. Very wrong. Bad Max.
ember-concurrency really saved my bacon. Literally. I used it in the app for my newly-announced startup BaconSaver, which allowed me to launch several requests to grocery APIs, searching for the best bacon prices. Managing all that asynchronous work would have been impossible without ember-concurrency. But it’s still too complex. I have think about concurrency strategies. Should I drop or keepLatest? And then, it has to run code. Ugh. It’s 2017, people. We pretend servers don’t exist now.
But…
I have a Computer Science-related undergraduate degree from an average-ranked public university, so I know what concurrency means. (But I won’t tell you.) Because I definitely know what it means, I am qualified to say that concurrency (and therefore ember-concurrency, a special kind of concurrency) could be a lot better in Ember.
As someone who knows what concurrency means, I can tell you that having to run code drastically reduces concurrency, probably. Luckily, I have a solution. I’m announcing in this blog post ember-procrastination. ember-procrastination improves the concurrency story of our Ember apps by optimizing when code gets run.
Did you know?
Did you know that almost no language implements procrastination primitives? Of course, Java offers a ProcrastinationFactory, .NET has System.Enterprise.ProcrastinationServices and Haskell has that powerful Procrastinate monad. However, to date no one has ever implemented anything like this for Ember or JavaScript. Sad.
How to use Ember-Procrastination?
ember-procrastination introduces a new concurrency primitive called a someday . A someday is a lot like a task from ember-concurrency, but has the special property that it will only schedule and do work when prompted several times. This means that only work the user truly wants done will get completed. But be careful: if you ask too much, it may get mad and cancel work already in-progress. Such truly concurrent code can be finicky.
ember-procrastination also leverages the best in lazy code loading technology to ensure that we don’t execute expensive operations until the last possible moment. To do this, ember-procrastination uses an advanced Just-In-Time (JIT) feature present in modern JavaScript: the beforeunload event. When ember-procrastination detects this event, all code that has been previously prompted to run that has not yet been run will run, ensuring that all work is completed. And it all happens concurrently. Amazing.
You can try it today.yarn add --dev ember-procrastination to your project.
Seize The Future, Someday
This revolutionary add-on puts the control back into your user’s hands. Technology does too much for them already anyway. Give your users a chance to go outside and experience nature. Before it all starts on fire.
