On Thursday, March 14, 2013, Glenn Maynard wrote: > On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> The entire reason for most async (all?) APIs is thus irrelevant in a >> > Worker, and it may be a good idea to provide sync versions, or do >> something else that negates the annoyance of dealing with async code. >> > > I agree, except that async APIs are also useful and relevant in workers. > Sometimes you want synchronous code and sometimes you want asynchronous > code, depending on what you're doing. > > > On Thu, Mar 14, 2013 at 9:19 PM, Alex Russell > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> My *first* approach to this annoyance would be to start adding some async >> primitives to the platform that don't suck so hard; e.g., Futures/Promises. >> Saying that you should do something does not imply that doubling up on API >> surface area for a corner-case is the right solution. > > > "Futures" are nothing but a different async API. They're in no way > comparable to synchronous code. >
I didn't imply they were. But addressing the pain point of asynchronous code that's hard to use doesn't imply that the only answer is a synchronous version. This is not a particularly hard or subtle point. > But, as I said, it's true that a second synchronous interface isn't > necessarily the best solution for complex APIs like IndexedDB. At least in > this particular case, if we have a synchronous messaging API I might call > the synchronous IDB interface unnecessary. > > -- > Glenn Maynard > >
