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

On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell <slightlyoff@google.com>wrote:

>
>
> On Thursday, March 14, 2013, Tab Atkins Jr. 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.
>
>
I wouldn't say that.  Async code will eventually be scheduled to execute on
the UI thread, which can cause contention with other tasks that must run on
that same UI thread.  Using a worker thread to perform (async) XHR requests
and JSON decoding while the UI thread focused on other rendering tasks was
one of the methods we (Sencha) used to increase News Feed performance for
Fastbook.  I agree with a lot of what you're saying re: workers, but I
don't agree that they wouldn't be needed if all we had were async apis.


>  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.
>

+1.  Libraries cover that fairly well; albeit I think we all would enjoy
such things to be first-class citizens of the platform.  I've seen some
good looking implementations and some decent control flow libraries.  I use
https://github.com/caolan/async a lot in node projects.


> Saying that you should do something does not imply that doubling up on API
> surface area for a corner-case is the right solution.
>

I agree.  It may have seemed like a good and simple idea at first - well
intentioned for sure - but upon reflection we have to admit it's sloppy, a
greater surface area to maintain, and the antithesis of DRY.  It's not what
I personally would expect from a modern, quality JS api, and I'm probably
not the only web dev to share that feeling.  At the risk of making a
blanketed statement using anecdotal evidence, I would claim that
overindulgence from modern libraries in existence today has raised the
expectations of web devs in how the web platform architects new apis.


>
>> > (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
>>
>