3 ms·

If it's any consolation, I also dislike promises, though I don't know that much about them. I feel they don't solve the problem they set out to solve, "callback

If it's any consolation, I also dislike promises, though I don't know that much about them. I feel they don't solve the problem they set out to solve, "callback hell" or cleanly interleaving async and sync code together, and I don't find their syntax aesthetic. I feel JSONP, message passing and state machines are cleaner. I'm unsure why many love promises, and was surprised by the level of what I'm only comfortable describing as "standards fever" over the emergent promises spec. I also think arrows are cool. Ah, that was refreshing. Thanks you for having the courage to buck the promises trend, which contributed to inspiring me to speak my mind as well! :) BTW -- your karma is enormous. What's with that?

joepie91_ 12y ago
Perhaps this clarifies the possibilities of promises a bit? https://coderwall.com/p/ehzcuq/concurrency-in-js-is-easy-with-promises https://coderwall.com/p/ehzcuq/concurrency-in-js-is-easy-wit...
- humanarity 12y ago
  It's a good overview. I'm thinking about it now :) Examples 3 and 4 are very neat. And they do make sense as a way to have a pipeline operate on a range of values which may or may not have resolved yet. They promise consistency regardless of the "readyState" of the resource. And the syntax could even be shortened with property getters to something like: pipe.read(x).split.map(upper).join.write(y) Which is okay. There's still something I dislike about them. I really just like the pattern where everything is a separate service, which send messages to each other. You can have message queues, and all services can operate simultaneously, and distribute them across wherever, you can hot-swap them, they're totally de-coupled, parameter formats aren't limited to Node-style callbacks. And each service can be "programmed" with a state machine, so everything is totally declarative, and totally expressive. Throw in complex event processing and you can do anything. I just really like SoA, and think if you're going to bother trying to create a solution for the "async opportunity" you may as well do the most awesome one possible. I think I mostly get what promises do and how they're useful -- I don't get why I'd use them over just JSONP and callbacks for something where I'm not trying to create such an epic solution. Fundamentally tho I think one major reason contributing to my choice to not use promises is maybe I'm comfortable with the ambiguity of a value that a value hasn't resolved yet, I don't need to pretend there's something there when it isn't!! :) Or maybe I just have "trust issues", and I don't trust promises in general, no matter what language you say 'em in! :) Yeah, that's probably a reason contributing, too -- I like SoA because everything takes care of its own stuff. No need to promise, just do!!
modarts 12y ago
OP is James Long, a really well known + awesome and insightful writer and thinker on topics mainly around JS.
woah 12y ago
I agree. I feel that we're kind of forced to use them at this stage, with new browser APIs etc, but they don't actually seem to make code any less verbose or more maintainable.

joepie91_ 12y ago

Perhaps this clarifies the possibilities of promises a bit? https://coderwall.com/p/ehzcuq/concurrency-in-js-is-easy-with-promises https://coderwall.com/p/ehzcuq/concurrency-in-js-is-easy-wit...

humanarity 12y ago
It's a good overview. I'm thinking about it now :) Examples 3 and 4 are very neat. And they do make sense as a way to have a pipeline operate on a range of values which may or may not have resolved yet. They promise consistency regardless of the "readyState" of the resource. And the syntax could even be shortened with property getters to something like: pipe.read(x).split.map(upper).join.write(y) Which is okay. There's still something I dislike about them. I really just like the pattern where everything is a separate service, which send messages to each other. You can have message queues, and all services can operate simultaneously, and distribute them across wherever, you can hot-swap them, they're totally de-coupled, parameter formats aren't limited to Node-style callbacks. And each service can be "programmed" with a state machine, so everything is totally declarative, and totally expressive. Throw in complex event processing and you can do anything. I just really like SoA, and think if you're going to bother trying to create a solution for the "async opportunity" you may as well do the most awesome one possible. I think I mostly get what promises do and how they're useful -- I don't get why I'd use them over just JSONP and callbacks for something where I'm not trying to create such an epic solution. Fundamentally tho I think one major reason contributing to my choice to not use promises is maybe I'm comfortable with the ambiguity of a value that a value hasn't resolved yet, I don't need to pretend there's something there when it isn't!! :) Or maybe I just have "trust issues", and I don't trust promises in general, no matter what language you say 'em in! :) Yeah, that's probably a reason contributing, too -- I like SoA because everything takes care of its own stuff. No need to promise, just do!!

modarts 12y ago

OP is James Long, a really well known + awesome and insightful writer and thinker on topics mainly around JS.

woah 12y ago

I agree. I feel that we're kind of forced to use them at this stage, with new browser APIs etc, but they don't actually seem to make code any less verbose or more maintainable.