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

One option that will probably never happen: Stop making jank-inducing API's
available on the main thread.  Do them all as synchronous APIs only, and
available only to workers.

Your APIs stay simple, and you don't have to make double the surface area.
 Building a library that marshals sync APIs to the main thread over async
MessagePorts is tractable, and may the best implementation win.  With
enough standardization across APIs you may even be able to make a
generalized broker.


Rob.


On Thu, Mar 14, 2013 at 6:58 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell <slightlyoff@google.com>
> > 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.
>
> > (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
>
>