On Sat, 9 Aug 2014, Alan deLespinasse wrote:
Thanks. Apparently I did a lousy job of searching for previous discussions.
I just found this later, longer thread:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
syntax (async/await keywords [2]) that looks
like sync syntax, but acts asynchronously. This should eliminate the need
for web devs for blocking message passing primitives for workers.
Syntax sugar around async is not a replacement for synchronous APIs.
I have yet to find a use case
wrote:
This topic is on people minds [1]. My understanding of where
we're at is that ECMAScript 7 will bring syntax
(async/await keywords [2]) that looks like sync syntax, but
acts asynchronously. This should eliminate the need for web
devs for blocking message
Le 12/08/2014 02:11, Brendan Eich a écrit :
David Bruant wrote:
Le 09/08/2014 16:22, Brian Kardell a écrit :
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
There is still a case for blocking primitives for projects that
compile from other
David Bruant wrote:
Le 12/08/2014 02:11, Brendan Eich a écrit :
David Bruant wrote:
Le 09/08/2014 16:22, Brian Kardell a écrit :
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
There is still a case for blocking primitives for projects that
One thing that I haven't seen anyone explicitly state on this thread, in
response to David's points, is that the semantics are observably and crucially
different between
fs.readFileSync(file.txt);
console.log(read it!);
and
await fs.readFile(file.txt);
console.log(read it!);
Le 12/08/2014 19:44, Domenic Denicola a écrit :
Realizing the difference between these is important background to realizing why
async + sugar cannot replace synchronous code. (Apologies if this was stating
the obvious...)
Is replacing sync APIs a goal? It sure isn't mine.
My point is that
Le 12/08/2014 19:36, Brendan Eich a écrit :
David Bruant wrote:
Le 12/08/2014 02:11, Brendan Eich a écrit :
David Bruant wrote:
Le 09/08/2014 16:22, Brian Kardell a écrit :
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
There is still a case for
David Bruant wrote:
That's not what I had understood. So both types of APIs (sync and
async) will be available to workers for say, IndexedDB?
If that's the case, I have no problem with it and we can stop the
discussion.
What I remembered of the state of the consensus was that given sync
APIs
Le 12/08/2014 20:51, Brendan Eich a écrit :
David Bruant wrote:
That's not what I had understood. So both types of APIs (sync and
async) will be available to workers for say, IndexedDB?
If that's the case, I have no problem with it and we can stop the
discussion.
What I remembered of the state
David Bruant wrote:
I proposed exposing both here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html
You didn't reply, but we now have a good argument thanks to your point
On 12/08/14 15:25, Brendan Eich wrote:
David Bruant wrote:
I proposed exposing both here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html
You didn't reply, but we now
On Tue, Aug 12, 2014 at 9:21 AM, David Bruant bruan...@gmail.com wrote:
With C, Java and all, we already know where adding blocking I/O primitives
leads to. Admittedly maybe dogma trying to learn from history.
You still seem to be confusing the issue that I explained earlier. There's
nothing
On Tue, Aug 12, 2014 at 3:54 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Aug 12, 2014 at 9:21 AM, David Bruant bruan...@gmail.com wrote:
With C, Java and all, we already know where adding blocking I/O
primitives leads to. Admittedly maybe dogma trying to learn from history.
You still
for web devs for blocking message passing primitives for workers.
Syntax sugar around async is not a replacement for synchronous APIs.
I personally hope it won't happen as it would be a step backwards.
Blocking communication (cross-thread/process/computer) was a mistake. We
need a culture
]) that looks like sync syntax, but acts asynchronously. This
should eliminate the need for web devs for blocking message
passing primitives for workers.
Syntax sugar around async is not a replacement for synchronous APIs.
I have yet to find a use case for hand-written code that requires sync
Le 09/08/2014 16:22, Brian Kardell a écrit :
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
There is still a case for blocking primitives for projects that
compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3].
I'm glad to be
David Bruant wrote:
Le 09/08/2014 16:22, Brian Kardell a écrit :
On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
There is still a case for blocking primitives for projects that
compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3].
syntax (async/await keywords [2]) that looks
like sync syntax, but acts asynchronously. This should eliminate the need
for web devs for blocking message passing primitives for workers.
Syntax sugar around async is not a replacement for synchronous APIs.
I have yet to find a use case for hand
Thanks. Apparently I did a lousy job of searching for previous discussions.
I just found this later, longer thread:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
(same thread, different year, so
at is
that ECMAScript 7 will bring syntax (async/await keywords [2]) that
looks like sync syntax, but acts asynchronously. This should eliminate
the need for web devs for blocking message passing primitives for workers.
There is still a case for blocking primitives for projects that compile
from other
.
This topic is on people minds [1]. My understanding of where we're at is
that ECMAScript 7 will bring syntax (async/await keywords [2]) that looks
like sync syntax, but acts asynchronously. This should eliminate the need
for web devs for blocking message passing primitives for workers.
There is still
I would find it extremely useful to have a function available to a Worker
that would block and wait for a message from another Worker or from the
main thread. For example, instead of:
onmessage = function(event) {
// Do some work
// Save all state for next time
};
I'd like to have something
On Fri, Aug 8, 2014 at 12:49 PM, Alan deLespinasse adelespina...@gmail.com
wrote:
I would find it extremely useful to have a function available to a Worker
that would block and wait for a message from another Worker or from the
main thread. For example, instead of:
onmessage =
24 matches
Mail list logo