Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Thursday, March 14, 2013, Tab Atkins Jr. wrote:

> On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard <glenn@zewt.org<javascript:;>>
> wrote:
> > On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell <slightlyoff@google.com<javascript:;>
> >
> > wrote:
> >> I don't understand why that's true. Workers have a message-oriented API
> >> that's inherently async. They can get back to their caller "whenevs".
> What's
> >> the motivator for needing this?
> >
> > Being able to write synchronous code is one of the basic uses for
> Workers in
> > the first place.  Synchronously creating streams is useful in the same
> way
> > that other synchronous APIs are useful, such as FileReaderSync.
> >
> > That doesn't necessarily mean having a synchronous API for a complex
> > interface like this is the ideal approach (there are other ways to do
> it),
> > but that's the end goal.
>
> Yes, this seems to be missing the point of Workers entirely.  If all
> you have are async apis, you don't need Workers in the first place, as
> you can just use them in the main thread without jank.  Workers exist
> explicitly to allow you to do expensive synchronous stuff without
> janking the main thread.  (Often, the expensive synchronous stuff will
> just be a bunch of calculations, so you don't have to explicitly break
> it up into setTimeout-able chunks.)
>
> 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.
>

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.


> > (FYI, the messaging in Workers isn't inherently async; it just happens to
> > only have an async interface.  There's been discussion about adding a
> > synchronous interface to messaging.)
>
> Specifically, this was for workers to be able to synchronously wait
> for messages from their sub-workers.  Again, the whole point for async
> worker messaging is to prevent the main thread from janking, which is
> irrelevant inside of a worker.
>
> ~TJ
>