Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-04-02 Thread Marc Fawzi
Boom!

http://pixelscommander.com/en/web-applications-performance/render-html-css-in-webgl-to-get-highest-performance-possibl/

This looks pretty amazing.

On Sat, Feb 14, 2015 at 4:01 PM, Brendan Eich bren...@secure.meer.net
wrote:

 Hang on a sec before going off to a private or single-vendor thread
 because you think I sent you packing on topics that are of interest (as
 opposed to Thread-Safe DOM).

 I'm sorry I missed Travis's mail in my Inbox, but I see it now in the
 archives. The topics listed at the link he cites *are* interesting to many
 folks here, even if public-webapps may not always be the best list:

 -

 IRC log: http://www.w3.org/2014/10/29-parallel-irc

 See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in
 the 29 October 2014 Anniversary Symposium talks

 We covered three main potential areas for parallelism:

 1. Find additional isolated areas of the web platform to enable
 parallelism. We noted Canvas Contexts that can migrate to workers to enable
 parallelism. Initial thoughts around UIWorkers are brewing for handling
 scrolling effects. Audio Workers are already being developed with specific
 real-time requirements. What additional features can be made faster by
 moving them off to workers?

 2. Shared memory models. This seems to require an investment in the
 JavaScript object primitives to enable multiple threaded access to object
 dictionaries that offer robust protections around multi-write scenarios for
 properties.

 3. Isolation boundaries for DOM access. We realized we needed to find an
 appropriate place to provide isolation such that DOM accesses could be
 assigned to a parallelizable JS engine. Based on discussion it sounded
 like element sub-trees wouldn't be possible to isolate, but that documents
 might be. Iframes of different origins may already be parallelized in some
 browsers.


 -

 Mozilla people have done work in all three areas, collaborating with Intel
 and Google people at least. Ongoing work continues as far as I know. Again,
 some of it may be better done in groups other than public-webapps. I cited
 roc's blog post about custom view scrolling, which seems to fall under
 Travis's (1) above.

 Please don't feel rejected about any of these work items.

 /be



  Marc Fawzi mailto:marc.fa...@gmail.com
 February 13, 2015 at 12:45 PM
 Travis,

 That would be awesome.

 I will go over that link and hopefully have starting points for the
 discussion.

 My day job actually allows me to dedicate time to experimentation (hence
 the ClojureScript stuff), so if you have any private branches of IE with
 latest DOM experiments, I'd be very happy to explore any new potential or
 new efficiency that your ideas may give us! I'm very keen on that, too.

 Off list seems to be best here..

 Thank you Travis. I really appreciate being able to communicate freely
 about ideas.

 Marc


 Boris Zbarsky mailto:bzbar...@mit.edu
 February 11, 2015 at 12:33 PM
 On 2/11/15 3:04 PM, Brendan Eich wrote:

 If you want multi-threaded DOM access, then again based on all that I
 know about the three open source browser engines in the field, I do not
 see any implementor taking the huge bug-risk and opportunity-cost and
 (mainly) performance-regression hit of adding barriers and other
 synchronization devices all over their DOM code. Only the Servo project,
 which is all about safety with maximal hardware parallelism, might get
 to the promised land you seek (even that's not clear yet).


 A good start is defining terms.  What do we mean by multi-threaded DOM
 access?

 If we mean concurrent access to the same DOM objects from both a window
 and a worker, or multiple workers, then I think that's a no-go in Servo as
 well, and not worth trying to design for: it would introduce a lot of spec
 and implementation complexity that I don't think is warranted by the use
 cases I've seen.

 If we mean the much more modest have a DOM implementation available in
 workers then that might be viable.  Even _that_ is pretty hard to do in
 Gecko, at least, because there is various global state (caches of various
 sorts) that the DOM uses that would need to either move into TLS or become
 threadsafe in some form or something...  Again, various specs (mostly DOM
 and HTML) would need to be gone over very carefully to make sure they're
 not making assumptions about the availability of such global shared state.

  We should add lighter-weight workers and immutable data structures


 I should note that even some things that could be immutable might
 involved a shared cache in current implementations (e.g. to speed up
 sequential indexed access into a child list implemented as a linked
 list)...  Obviously that sort of thing can be changed, but your bigger
 point that there is a lot of risk to doing that in existing implementations
 remains.

 -Boris

 Brendan Eich mailto:bren...@secure.meer.net
 February 11, 2015 at 12:04 PM


 Sorry, I was too grumpy -- my apologies.

 I don't see 

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-14 Thread Brendan Eich
Hang on a sec before going off to a private or single-vendor thread 
because you think I sent you packing on topics that are of interest (as 
opposed to Thread-Safe DOM).


I'm sorry I missed Travis's mail in my Inbox, but I see it now in the 
archives. The topics listed at the link he cites *are* interesting to 
many folks here, even if public-webapps may not always be the best list:


-

IRC log: http://www.w3.org/2014/10/29-parallel-irc

See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in 
the 29 October 2014 Anniversary Symposium talks


We covered three main potential areas for parallelism:

1. Find additional isolated areas of the web platform to enable 
parallelism. We noted Canvas Contexts that can migrate to workers to 
enable parallelism. Initial thoughts around UIWorkers are brewing for 
handling scrolling effects. Audio Workers are already being developed 
with specific real-time requirements. What additional features can be 
made faster by moving them off to workers?


2. Shared memory models. This seems to require an investment in the 
JavaScript object primitives to enable multiple threaded access to 
object dictionaries that offer robust protections around multi-write 
scenarios for properties.


3. Isolation boundaries for DOM access. We realized we needed to find an 
appropriate place to provide isolation such that DOM accesses could be 
assigned to a parallelizable JS engine. Based on discussion it sounded 
like element sub-trees wouldn't be possible to isolate, but that 
documents might be. Iframes of different origins may already be 
parallelized in some browsers.



-

Mozilla people have done work in all three areas, collaborating with 
Intel and Google people at least. Ongoing work continues as far as I 
know. Again, some of it may be better done in groups other than 
public-webapps. I cited roc's blog post about custom view scrolling, 
which seems to fall under Travis's (1) above.


Please don't feel rejected about any of these work items.

/be




Marc Fawzi mailto:marc.fa...@gmail.com
February 13, 2015 at 12:45 PM
Travis,

That would be awesome.

I will go over that link and hopefully have starting points for the 
discussion.


My day job actually allows me to dedicate time to experimentation 
(hence the ClojureScript stuff), so if you have any private branches 
of IE with latest DOM experiments, I'd be very happy to explore any 
new potential or new efficiency that your ideas may give us! I'm very 
keen on that, too.


Off list seems to be best here..

Thank you Travis. I really appreciate being able to communicate freely 
about ideas.


Marc


Boris Zbarsky mailto:bzbar...@mit.edu
February 11, 2015 at 12:33 PM
On 2/11/15 3:04 PM, Brendan Eich wrote:

If you want multi-threaded DOM access, then again based on all that I
know about the three open source browser engines in the field, I do not
see any implementor taking the huge bug-risk and opportunity-cost and
(mainly) performance-regression hit of adding barriers and other
synchronization devices all over their DOM code. Only the Servo project,
which is all about safety with maximal hardware parallelism, might get
to the promised land you seek (even that's not clear yet).


A good start is defining terms.  What do we mean by multi-threaded 
DOM access?


If we mean concurrent access to the same DOM objects from both a 
window and a worker, or multiple workers, then I think that's a no-go 
in Servo as well, and not worth trying to design for: it would 
introduce a lot of spec and implementation complexity that I don't 
think is warranted by the use cases I've seen.


If we mean the much more modest have a DOM implementation available 
in workers then that might be viable.  Even _that_ is pretty hard to 
do in Gecko, at least, because there is various global state (caches 
of various sorts) that the DOM uses that would need to either move 
into TLS or become threadsafe in some form or something...  Again, 
various specs (mostly DOM and HTML) would need to be gone over very 
carefully to make sure they're not making assumptions about the 
availability of such global shared state.



We should add lighter-weight workers and immutable data structures


I should note that even some things that could be immutable might 
involved a shared cache in current implementations (e.g. to speed up 
sequential indexed access into a child list implemented as a linked 
list)...  Obviously that sort of thing can be changed, but your bigger 
point that there is a lot of risk to doing that in existing 
implementations remains.


-Boris

Brendan Eich mailto:bren...@secure.meer.net
February 11, 2015 at 12:04 PM


Sorry, I was too grumpy -- my apologies.

I don't see much ground for progress in this whole thread or the 
sub-thread you started.


If we're talking about sync XHR, I gave my informed opinion that 
deprecating it is empty talk if actually obsoleting by whichever 
browser takes the first hit inevitably leads to 

RE: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-13 Thread Travis Leithead
Marc,

I'd first mention that I am keenly interested in improving the state-of-the-art 
in DOM (I'm driving the project to update IE's 20-year-old DOM as my day job.) 
I've also done a lot of thinking about thread-safe DOM designs, and would be 
happy to chat with you more in depth about some ideas (perhaps off-list if 
you'd like).

I'd also refer you to a breakout session I held during last TPAC on a similar 
topic [1]. It had lots of interested folks in the room and I thought we had a 
really productive and interesting discussion (most of it captured in the IRC 
notes).

[1] https://www.w3.org/wiki/Improving_Parallelism_Page

-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu] 
Sent: Wednesday, February 11, 2015 12:34 PM
To: public-webapps@w3.org
Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous 
XMLHttpRequest

On 2/11/15 3:04 PM, Brendan Eich wrote:
 If you want multi-threaded DOM access, then again based on all that I 
 know about the three open source browser engines in the field, I do 
 not see any implementor taking the huge bug-risk and opportunity-cost 
 and
 (mainly) performance-regression hit of adding barriers and other 
 synchronization devices all over their DOM code. Only the Servo 
 project, which is all about safety with maximal hardware parallelism, 
 might get to the promised land you seek (even that's not clear yet).

A good start is defining terms.  What do we mean by multi-threaded DOM access?

If we mean concurrent access to the same DOM objects from both a window and a 
worker, or multiple workers, then I think that's a no-go in Servo as well, and 
not worth trying to design for: it would introduce a lot of spec and 
implementation complexity that I don't think is warranted by the use cases I've 
seen.

If we mean the much more modest have a DOM implementation available in 
workers then that might be viable.  Even _that_ is pretty hard to do in Gecko, 
at least, because there is various global state (caches of various sorts) that 
the DOM uses that would need to either move into TLS or become threadsafe in 
some form or something...  Again, various specs (mostly DOM and HTML) would 
need to be gone over very carefully to make sure they're not making assumptions 
about the availability of such global shared state.

 We should add lighter-weight workers and immutable data structures

I should note that even some things that could be immutable might involved a 
shared cache in current implementations (e.g. to speed up sequential indexed 
access into a child list implemented as a linked list)...  Obviously that sort 
of thing can be changed, but your bigger point that there is a lot of risk to 
doing that in existing implementations remains.

-Boris



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-13 Thread Marc Fawzi
Travis,

That would be awesome.

I will go over that link and hopefully have starting points for the
discussion.

My day job actually allows me to dedicate time to experimentation (hence
the ClojureScript stuff), so if you have any private branches of IE with
latest DOM experiments, I'd be very happy to explore any new potential or
new efficiency that your ideas may give us! I'm very keen on that, too.

Off list seems to be best here..

Thank you Travis. I really appreciate being able to communicate freely
about ideas.

Marc

On Fri, Feb 13, 2015 at 11:20 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

 Marc,

 I'd first mention that I am keenly interested in improving the
 state-of-the-art in DOM (I'm driving the project to update IE's 20-year-old
 DOM as my day job.) I've also done a lot of thinking about thread-safe DOM
 designs, and would be happy to chat with you more in depth about some ideas
 (perhaps off-list if you'd like).

 I'd also refer you to a breakout session I held during last TPAC on a
 similar topic [1]. It had lots of interested folks in the room and I
 thought we had a really productive and interesting discussion (most of it
 captured in the IRC notes).

 [1] https://www.w3.org/wiki/Improving_Parallelism_Page

 -Original Message-
 From: Boris Zbarsky [mailto:bzbar...@mit.edu]
 Sent: Wednesday, February 11, 2015 12:34 PM
 To: public-webapps@w3.org
 Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous
 XMLHttpRequest

 On 2/11/15 3:04 PM, Brendan Eich wrote:
  If you want multi-threaded DOM access, then again based on all that I
  know about the three open source browser engines in the field, I do
  not see any implementor taking the huge bug-risk and opportunity-cost
  and
  (mainly) performance-regression hit of adding barriers and other
  synchronization devices all over their DOM code. Only the Servo
  project, which is all about safety with maximal hardware parallelism,
  might get to the promised land you seek (even that's not clear yet).

 A good start is defining terms.  What do we mean by multi-threaded DOM
 access?

 If we mean concurrent access to the same DOM objects from both a window
 and a worker, or multiple workers, then I think that's a no-go in Servo as
 well, and not worth trying to design for: it would introduce a lot of spec
 and implementation complexity that I don't think is warranted by the use
 cases I've seen.

 If we mean the much more modest have a DOM implementation available in
 workers then that might be viable.  Even _that_ is pretty hard to do in
 Gecko, at least, because there is various global state (caches of various
 sorts) that the DOM uses that would need to either move into TLS or become
 threadsafe in some form or something...  Again, various specs (mostly DOM
 and HTML) would need to be gone over very carefully to make sure they're
 not making assumptions about the availability of such global shared state.

  We should add lighter-weight workers and immutable data structures

 I should note that even some things that could be immutable might involved
 a shared cache in current implementations (e.g. to speed up sequential
 indexed access into a child list implemented as a linked list)...
 Obviously that sort of thing can be changed, but your bigger point that
 there is a lot of risk to doing that in existing implementations remains.

 -Boris




Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich

Marc Fawzi wrote:

This guy here is bypassing the DOM and using WebGL for user interfaces

https://github.com/onejs/onejs

He even has a demo, with no event handling other than arrow keys at 
this point, and as the author admits ugly graphics, but with projects 
like React-Canvas (forget the React part, focus on Canvas UIs) and 
attempts like these it looks like the way of the future is to relegate 
the DOM to old boring business apps and throw more creative energy at 
things like WebGL UIToolKit (the idea that guy is pursuing)


I know Rik and keep in touch. OneJS is the kind of over-the-top work 
(not changing the DOM in-situ) that I recommended previously, in 
addition to incremental Web evolution. So once again, I'm not sure we 
disagree, but I am pretty sure your posts are misdirected to this list. 
Philosophizing about backward compatibility painting the Web into 
corners that kill it don't really move anything forward here.


There is a gap to fill with respect to the GPU, which WebGL-based 
toolkits won't bridge. I think Rik would agree that we can't replace the 
web with raw JS+WebGL. Meanwhile, since the first iPhone, the major 
engines have all offloaded parts of their CSS rendering to the GPU 
(ideally with a big shared texture memory, bigger than the display 
viewport), in order to use a separate thread from the main UI event loop 
thread, for 60fps touch response.


Of course the CPUs (multicore + SIMD) need to be used, so we don't want 
to marry a paritcular processing unit, or (worse) one GPU 
microarchitecture. Standards and even languages/toolkits (one.js is 
young) need to mature and abstract enough over hardware variation to be 
worth their weight -- but not so much they collapse like all the big OOP 
skycastles of the Java UI toolkit era have.


The more we can do with incremental standards to expose this OMTC/A 
CPU+GPU-based computation in first class ways on the Web, the less 
anyone will have to make a old wolf or new tiger decision between Web 
and non-Web approaches.


One concrete example: custom view scrolling. See

http://robert.ocallahan.org/2014/07/implementing-scroll-animations-using.html

If we can focus on these sorts of proposals and not thread-safe DOM or 
will-backward-compat-kill-the-Web imponderables, we'll get somewhere 
better, sooner.


/be

P.S. Meanwhile, are we done (for now) with deprecate-sync-XHR angst, and 
no browser actually plans to remove it? Not directed at Marc, rather my 
cc: list browser buddies. :-P




Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread David Rajchenbach-Teller
On 12/02/15 03:45, Marc Fawzi wrote:
 this backward compatibility stuff is making me think that the web is
 built upon the axiom that we will never start over and we must keep
 piling up new features and principles on top of the old ones
 
 this has worked so far, miraculously and not without overhead, but I can
 only assume that it's at the cost of growing complexity in the browser
 codebase. I'm sure you have to manage a ton of code that has to do with
 old features and old ideas...
 
 how long can this be sustained? forever? what is the point in time where
 the business of retaining backward compatibility becomes a huge nightmare?


As a side-note, the original thread is a good illustration of what
happens whenever browser vendors attempt to deprecate features that are
clearly broken by design.

Cheers,
 David

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature


Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Aryeh Gregor
On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote:
 how long can this be sustained? forever? what is the point in time where the
 business of retaining backward compatibility becomes a huge nightmare?

It already is, but there's no way out.  This is true everywhere in
computing.  Look closely at almost any protocol, API, language, etc.
that dates back 20 years or more and has evolved a lot since then, and
you'll see tons of cruft that just causes headaches but can't be
eliminated.  Like the fact that Internet traffic is largely in
1500-byte packets because that's the maximum size you could have on
ancient shared cables without ambiguity in the case of collision.  Or
that e-mail is mostly sent in plaintext, with no authentication of
authorship, because that's what made sense in the 80s (or whatever).
Or how almost all web traffic winds up going over TCP, which performs
horribly on all kinds of modern usage patterns.  For that matter, I'm
typing this with a keyboard layout that was designed well over a
century ago to meet the needs of mechanical typewriters, but it became
standard, so now everyone uses it due to inertia.

This is all horrible, but that's life.



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich

Aryeh Gregor wrote:

This is all horrible, but that's life.


Indeed, nature is nasty. Search for sacculina carcini life cycle for 
but one example. The Web and the Internet are evolving systems with some 
parallels and analogies to biological evolution. See 
http://www.cc.gatech.edu/~dovrolis/ for more on this, if you are 
interested. Nothing like _Sacculina_ yet, luckily!


/be



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich

Brendan Eich wrote:

over-the-top work


Apologies if this overloaded trope is confusing without more context -- 
it could mean wildly excessive, or doing what soldiers in trenches did 
in WWI when the whistle blew (see 
https://www.youtube.com/watch?v=fssPqRWx9U0 :-/), but I meant build on 
top of JS and the DOM (even WebGL requires a bit of DOM for the canvas 
bit).


/be



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Marc Fawzi

Legacy problems

Across the computing industry, we spend enormous amounts of money and
effort on keeping older, legacy systems running. The examples range from
huge and costly to small and merely annoying: planes circle around in
holding patterns burning precious fuel because air traffic control can't
keep up on systems that are less powerful than a smartphone; WiFi networks
don't reach their top speeds because an original 802.11(no letter), 2Mbps
system *could* show up—you never know. So when engineers dream, we dream of
leaving all of yesterday's technology behind and starting from scratch. But
such clean breaks are rarely possible.

For instance, the original 10 megabit Ethernet specification allows for
1500-byte packets. Filling up 10Mbps takes about 830 of those 1500-byte
packets. Then Fast Ethernet came along, which was 100Mbps, but the packet
size remained the same so that 100Mbps ethernet gear could be hooked up to
10Mbps ethernet equipment without compatibility issues. Fast Ethernet needs
8300 packets per second to fill up the pipe. Gigabit Ethernet needs 83,000
and 10 Gigabit Ethernet needs *almost a million packets per second* (well,
830,000).

For each faster Ethernet standard, the switch vendors need to pull out even
more stops to process an increasingly outrageous numbers of packets per
second, running the CAMs that store the forwarding tables at insane speeds
that demand huge amounts of power. The need to connect antique NE2000 cards
meant sticking to 1500 bytes for Fast Ethernet, and then the need to talk
to those rusty Fast Ethernet cards meant sticking to 1500 bytes for Gigabit
Ethernet, and so on. At each point, the next step makes sense, but* the
entire journey ends up looking irrational.*


Source:
http://arstechnica.com/business/2010/09/there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly/


This guy here is bypassing the DOM and using WebGL for user interfaces

https://github.com/onejs/onejs

He even has a demo, with no event handling other than arrow keys at this
point, and as the author admits ugly graphics, but with projects like
React-Canvas (forget the React part, focus on Canvas UIs) and attempts like
these it looks like the way of the future is to relegate the DOM to old
boring business apps and throw more creative energy at things like WebGL
UIToolKit (the idea that guy is pursuing)



On Thu, Feb 12, 2015 at 3:46 AM, Aryeh Gregor a...@aryeh.name wrote:

 On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote:
  how long can this be sustained? forever? what is the point in time where
 the
  business of retaining backward compatibility becomes a huge nightmare?

 It already is, but there's no way out.  This is true everywhere in
 computing.  Look closely at almost any protocol, API, language, etc.
 that dates back 20 years or more and has evolved a lot since then, and
 you'll see tons of cruft that just causes headaches but can't be
 eliminated.  Like the fact that Internet traffic is largely in
 1500-byte packets because that's the maximum size you could have on
 ancient shared cables without ambiguity in the case of collision.  Or
 that e-mail is mostly sent in plaintext, with no authentication of
 authorship, because that's what made sense in the 80s (or whatever).
 Or how almost all web traffic winds up going over TCP, which performs
 horribly on all kinds of modern usage patterns.  For that matter, I'm
 typing this with a keyboard layout that was designed well over a
 century ago to meet the needs of mechanical typewriters, but it became
 standard, so now everyone uses it due to inertia.

 This is all horrible, but that's life.



Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Marc Fawzi

even if the DOM must remain a single-threaded and truly
lock/barrier/fence-free data structure, what you are reaching for is doable
now, with some help from standards bodies. ***But not by vague blather***


You're contradicting yourself within a single two-line paragraph, being
vague in your own statement ... that what I'm reaching for is doable.

I know you know what you're talking about and I know what I'm reaching for
is doable.

What I don't know are the details of how that might be doable. I think a
lot of developers would be interested in that. Not just me. I think you
dropped some hint there but it's no where near a detailed and clear answer,
so again shutting down the discussion because you know more? What the hey!
Mr. Eich. This is a public discussion forum. If it wasn't open to the
public, it would be private. In discussions, vagueness is not the enemy of
the truth, only part of the journey... Relax.

On a more serious basis, please provide us with clarity or point us to
discussions on this topic that might help us understand how to get _to_
there!




On Tue, Feb 10, 2015 at 7:19 PM, Brendan Eich bren...@secure.meer.net
wrote:

 Marc Fawzi wrote:

 I've recently started using something called an atom in ClojureScript and
 it is described as a mutable reference to an immutable value. It holds the
 state for the app and can be safely mutated by multiple components, and
 has an interesting thing called a cursor. It is lock free but synchronous.
 I think I understand it to some degree.


 The win there is the mutations are local to the clients of the atom, but
 the underlying data structure it reflects is immutable. The DOM is not
 immutable and must not be for backward compatibility.

  I don't understand the implementation of the DOM but why couldn't we have
 a representation of it that acted like the atom in clojure and then write
 the diff to the actual DOM.


 Because browsers don't work that way. I wish they did, but they can't
 afford to stop the world, reimplement, optimize (if possible -- they will
 probably see regressions that are both hard to fix, and that hurt them in
 the market), and then restart the world.

  Is that what React does with I virtual DOM? No idea but I wasn't dropping
 words, I was describing what was explained to me about the atom in clojure
 and I saw parallels and possibility of something similar in JS to manage
 the DOM.


 I'm a big React fan. But it can virtualize the DOM using JS objects and do
 diffing/patching, without having to jack up the browsers (all of them; note
 stop the world above), rewrite their DOMs to match, and get them
 optimized and running again.

  With all the brains in this place are you telling me flat out that it is
 impossible to have a version of the DOM (call it virtual or atomic DOM)
 that could be manipulated from web workers?


 I'm not. People are doing this. My explicit point in a previous reply was
 that you don't need public-webapps or browser vendors to agree on doing
 this in full to start, and what you do in JS can inform smaller, easier
 steps in the standards body. One such step would be a way to do sync i/o
 from workers. Clear?

  Also I was mentioning immutable and transient types because they are so
 necessary to performant functional programming, as I understand it.


 Sure, but we're back to motherhood-and-apple-pie rhetoric now.

  Again the clojure atom is lock free and synchronous and is mutable and
 thread safe. Why couldn't something like that act as a layer to hold DOM
 state.


 First, lock-free data structures are not free. They require a memory
 barrier or fence, e.g., cmpxchg on Intel. Study this before endorsing it as
 a free lunch. Competing browsers will not add such overhead to their DOMs
 right now.

 Second, even if the DOM must remain a single-threaded and truly
 lock/barrier/fence-free data structure, what you are reaching for is doable
 now, with some help from standards bodies. But not by vague blather, and
 nothing to do with sync XHR, to get back on topic.

Maybe that's how React's virtual DOM works? I don't know but I find the
 idea behind the atom very intriguing and not sure why it wouldn't be
 applicable to making the DOM thread safe. What do the biggest brains in the
 room think? That's all. A discussion. If people leave the list because of
 it then that's their right but it is a human right to speak ones mind as
 long as the speech is not demeaning or otherwise hurtful.


 I think you're on the wrong list. This isn't the place for vague albeit
 well-intentioned -- but as you allow above, uninformed (I don't know) --
 speculations and hopes.

  I really don't understand the arrogance here.


 Cut it out, or I'll cite your faux-humility as tit-for-tat. We need to be
 serious, well-informed, and concrete here. No speculations based on
 free-lunch (!= lock-free) myths.

 As for sync XHR, I agree with you (I think! I may be misremembering your
 position) that compatibility trumps intentions 

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Brendan Eich

Marc Fawzi wrote:


even if the DOM must remain a single-threaded and truly 
lock/barrier/fence-free data structure, what you are reaching for is 
doable now, with some help from standards bodies. ***But not by vague 
blather***




Sorry, I was too grumpy -- my apologies.

I don't see much ground for progress in this whole thread or the 
sub-thread you started.


If we're talking about sync XHR, I gave my informed opinion that 
deprecating it is empty talk if actually obsoleting by whichever browser 
takes the first hit inevitably leads to market share loss or (before 
that) developers screaming enough to get the CEO's attention. We will 
simply waste a lot of time and energy (we already are) arguing and 
hollering for and against deprecation, without any definite hope of 
obsolescence.


If you want multi-threaded DOM access, then again based on all that I 
know about the three open source browser engines in the field, I do not 
see any implementor taking the huge bug-risk and opportunity-cost and 
(mainly) performance-regression hit of adding barriers and other 
synchronization devices all over their DOM code. Only the Servo project, 
which is all about safety with maximal hardware parallelism, might get 
to the promised land you seek (even that's not clear yet).


Doing over the top JS libraries/toolchains such as React is excellent, 
I support it. But it does not share mutable or immutable state across 
threads. JS is still single-threaded, event loop concurrency with 
mutable state, in its execution model. This execution model was born and 
co-evolved with the DOM 20 years ago (I'm to blame). It can't be changed 
backward-compatibly and no one will break the Web.


We should add lighter-weight workers and immutable data structures and 
other such things, and these are on the Harmony agenda with the JS 
standards body. We might even find race-confined ways to run asm.js code 
on multiple workers with shared memory in an ArrayBuffer -- that's an 
area of active research. But none of these things is anything near to 
what you described in the forked subject line: Thread-Safe DOM.


I'll leave it at this.I invite others from Mozilla, Google, Apple, and 
MS to speak up if they disagree.


/be



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Boris Zbarsky

On 2/11/15 3:04 PM, Brendan Eich wrote:

If you want multi-threaded DOM access, then again based on all that I
know about the three open source browser engines in the field, I do not
see any implementor taking the huge bug-risk and opportunity-cost and
(mainly) performance-regression hit of adding barriers and other
synchronization devices all over their DOM code. Only the Servo project,
which is all about safety with maximal hardware parallelism, might get
to the promised land you seek (even that's not clear yet).


A good start is defining terms.  What do we mean by multi-threaded DOM 
access?


If we mean concurrent access to the same DOM objects from both a window 
and a worker, or multiple workers, then I think that's a no-go in Servo 
as well, and not worth trying to design for: it would introduce a lot of 
spec and implementation complexity that I don't think is warranted by 
the use cases I've seen.


If we mean the much more modest have a DOM implementation available in 
workers then that might be viable.  Even _that_ is pretty hard to do in 
Gecko, at least, because there is various global state (caches of 
various sorts) that the DOM uses that would need to either move into TLS 
or become threadsafe in some form or something...  Again, various specs 
(mostly DOM and HTML) would need to be gone over very carefully to make 
sure they're not making assumptions about the availability of such 
global shared state.



We should add lighter-weight workers and immutable data structures


I should note that even some things that could be immutable might 
involved a shared cache in current implementations (e.g. to speed up 
sequential indexed access into a child list implemented as a linked 
list)...  Obviously that sort of thing can be changed, but your bigger 
point that there is a lot of risk to doing that in existing 
implementations remains.


-Boris



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Boris Zbarsky

On 2/11/15 9:45 PM, Marc Fawzi wrote:

this backward compatibility stuff is making me think that the web is
built upon the axiom that we will never start over and we must keep
piling up new features and principles on top of the old ones


Pretty much, yep.


this has worked so far, miraculously and not without overhead, but I can
only assume that it's at the cost of growing complexity in the browser
codebase.


To some extent, yes.

Browsers have obviously been doing refactoring and simplification as 
they go, but I think it's pretty clear that a minimal viable browser 
today is a lot more complicated than one 10 years ago.



I'm sure you have to manage a ton of code that has to do with
old features and old ideas...


Sometimes.  Sometimes it can just be expressed easily in terms of the 
newer stuff.  And sometimes we do manage to remove things -- I'm seeing 
it happen right now with plugins, which definitely fall in the bucket of 
a ton of annoying-to-maintain code.



how long can this be sustained? forever?


If we're lucky, yes.


what is the point in time where
the business of retaining backward compatibility becomes a huge nightmare?


About 10-15 years ago, really.  We've just gotten pretty good at facing 
the nightmare.  ;)


-Boris



Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Marc Fawzi
this backward compatibility stuff is making me think that the web is
built upon the axiom that we will never start over and we must keep piling
up new features and principles on top of the old ones

this has worked so far, miraculously and not without overhead, but I can
only assume that it's at the cost of growing complexity in the browser
codebase. I'm sure you have to manage a ton of code that has to do with old
features and old ideas...

how long can this be sustained? forever? what is the point in time where
the business of retaining backward compatibility becomes a huge nightmare?








On Wed, Feb 11, 2015 at 12:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 2/11/15 3:04 PM, Brendan Eich wrote:

 If you want multi-threaded DOM access, then again based on all that I
 know about the three open source browser engines in the field, I do not
 see any implementor taking the huge bug-risk and opportunity-cost and
 (mainly) performance-regression hit of adding barriers and other
 synchronization devices all over their DOM code. Only the Servo project,
 which is all about safety with maximal hardware parallelism, might get
 to the promised land you seek (even that's not clear yet).


 A good start is defining terms.  What do we mean by multi-threaded DOM
 access?

 If we mean concurrent access to the same DOM objects from both a window
 and a worker, or multiple workers, then I think that's a no-go in Servo as
 well, and not worth trying to design for: it would introduce a lot of spec
 and implementation complexity that I don't think is warranted by the use
 cases I've seen.

 If we mean the much more modest have a DOM implementation available in
 workers then that might be viable.  Even _that_ is pretty hard to do in
 Gecko, at least, because there is various global state (caches of various
 sorts) that the DOM uses that would need to either move into TLS or become
 threadsafe in some form or something...  Again, various specs (mostly DOM
 and HTML) would need to be gone over very carefully to make sure they're
 not making assumptions about the availability of such global shared state.

  We should add lighter-weight workers and immutable data structures


 I should note that even some things that could be immutable might involved
 a shared cache in current implementations (e.g. to speed up sequential
 indexed access into a child list implemented as a linked list)...
 Obviously that sort of thing can be changed, but your bigger point that
 there is a lot of risk to doing that in existing implementations remains.

 -Boris




Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Tab Atkins Jr.
On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi marc.fa...@gmail.com wrote:
 this backward compatibility stuff is making me think that the web is built
 upon the axiom that we will never start over and we must keep piling up new
 features and principles on top of the old ones

Yup.

 this has worked so far, miraculously and not without overhead, but I can
 only assume that it's at the cost of growing complexity in the browser
 codebase. I'm sure you have to manage a ton of code that has to do with old
 features and old ideas...

 how long can this be sustained? forever? what is the point in time where the
 business of retaining backward compatibility becomes a huge nightmare?

When someone comes up with something sufficiently better to be worth
abandoning trillions of existing pages for (or duplicating the read
trillions of old pages engine alongside the new one).

~TJ



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Glenn Adams
Given implementations already support synchronous behavior, the only reason
to deprecate would be if continuing to support that behavior comes at a
significant burden to future versions of these implementations. I would
conjecture it is not, so I oppose deprecation on the principle that policy
should be determined by the user/author, not the standard.

Morality should not be legislated!


On Tue, Feb 10, 2015 at 7:47 AM, Ashley Gullen ash...@scirra.com wrote:

 I am on the side that synchronous AJAX should definitely be deprecated,
 except in web workers where sync stuff is OK.

 Especially on the modern web, there are two really good alternatives:
 - write your code in a web worker where synchronous calls don't hang the
 browser
 - write async code which doesn't hang the browser

 With modern tools like Promises and the new Fetch API, I can't think of
 any reason to write a synchronous AJAX request on the main thread, when an
 async one could have been written instead with probably little extra effort.

 Alas, existing codebases rely on it, so it cannot be removed easily. But I
 can't see why anyone would argue that it's a good design principle to make
 possibly seconds-long synchronous calls on the UI thread.




 On 9 February 2015 at 19:33, George Calvert george.calv...@loudthink.com
 wrote:

 I third Michaela and Gregg.



 It is the app and site developers' job to decide whether the user should
 wait on the server — not the standard's and, 99.9% of the time, not the
 browser's either.



 I agree a well-designed site avoids synchronous calls.  BUT — there still
 are plenty of real-world cases where the best choice is having the user
 wait: Like when subsequent options depend on the server's reply.  Or more
 nuanced, app/content-specific cases where rewinding after an earlier
 transaction fails is detrimental to the overall UX or simply impractical to
 code.



 Let's focus our energies elsewhere — dispensing with browser warnings
 that tell me what I already know and with deprecating features that are
 well-entrenched and, on occasion, incredibly useful.



 Thanks,
 George Calvert





Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Ashley Gullen
I am on the side that synchronous AJAX should definitely be deprecated,
except in web workers where sync stuff is OK.

Especially on the modern web, there are two really good alternatives:
- write your code in a web worker where synchronous calls don't hang the
browser
- write async code which doesn't hang the browser

With modern tools like Promises and the new Fetch API, I can't think of any
reason to write a synchronous AJAX request on the main thread, when an
async one could have been written instead with probably little extra effort.

Alas, existing codebases rely on it, so it cannot be removed easily. But I
can't see why anyone would argue that it's a good design principle to make
possibly seconds-long synchronous calls on the UI thread.




On 9 February 2015 at 19:33, George Calvert george.calv...@loudthink.com
wrote:

 I third Michaela and Gregg.



 It is the app and site developers' job to decide whether the user should
 wait on the server — not the standard's and, 99.9% of the time, not the
 browser's either.



 I agree a well-designed site avoids synchronous calls.  BUT — there still
 are plenty of real-world cases where the best choice is having the user
 wait: Like when subsequent options depend on the server's reply.  Or more
 nuanced, app/content-specific cases where rewinding after an earlier
 transaction fails is detrimental to the overall UX or simply impractical to
 code.



 Let's focus our energies elsewhere — dispensing with browser warnings that
 tell me what I already know and with deprecating features that are
 well-entrenched and, on occasion, incredibly useful.



 Thanks,
 George Calvert



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
What? a good cop bad cop routine? Jonas asks for a constructive contribution or 
ideas for missing functionality in the web platform and the inventor of JS 
honors me with a condescending response, as if ... 
 
What the hey! Mr. Eich!

I guess this explains the origin of JS: a knee jerk reaction to then-trendy 
ideas... 

That's not the way to go about all inclusive debate.

Thank you.

Sent from my iPhone

 On Feb 10, 2015, at 5:44 PM, Brendan Eich bren...@secure.meer.net wrote:
 
 Please stop overloading public-webapps with idle chatter.
 
 React and things like it or based on it are going strong. Work there, above 
 the standards. De-jure standardization will follow, and we'll all be better 
 off for that order of work.
 
 /be
 
 Marc Fawzi wrote:
 How about a thread-safe but lock-free version of the DOM based on something 
 like Clojure's atom? So we can manipulate the DOM from web workers? With 
 cursor support?
 
 How about immutable data structures for side-effect-free functional 
 programming?
 
 How about  Will think of more



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi


Sent from my iPhone

 On Feb 10, 2015, at 5:44 PM, Brendan Eich bren...@secure.meer.net wrote:
 
 Please stop overloading public-webapps with idle chatter.
 
 React and things like it or based on it are going strong. Work there, above 
 the standards. De-jure standardization will follow, and we'll all be better 
 off for that order of work.
 
 /be
 
 Marc Fawzi wrote:
 How about a thread-safe but lock-free version of the DOM based on something 
 like Clojure's atom? So we can manipulate the DOM from web workers? With 
 cursor support?
 
 How about immutable data structures for side-effect-free functional 
 programming?
 
 How about  Will think of more



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Your message to which I replied is not cited accurately below by you. 
The text you wrote is here, in between  lines:



How about a thread-safe but lock-free version of the DOM based on 
something like Clojure's atom? So we can manipulate the DOM from web 
workers? With cursor support?


How about immutable data structures for side-effect-free functional 
programming?


How about  Will think of more


This message text is exactly what I wrote my reply against.

It's useless; sorry, this happens, but don't make a habit of it, or most 
practitioners will unsubscribe to public-webapps. The DOM is a mutable 
single-threaded store, so there's no lock-free version possible. You'd 
have snapshots, with some cost in the snapshotting mechanism, at best. 
Then, you wouldn't be able to manipulate in any shared-state sense of 
that word, the DOM from workers.


Sorry, but that's the way things are. Dropping words like immutable and 
lock-free doesn't help. That, plus a lot of attitude about deprecating 
sync XHR (on all sides; I'm not in favor of useless deprecation, myself 
-- good luck to browsers who go first on actually *removing* sync XHR 
support), adds up to noise in this list. What good purpose does noise to 
signal serve?


/be


Marc Fawzi mailto:marc.fa...@gmail.com
February 10, 2015 at 6:24 PM
What? a good cop bad cop routine? Jonas asks for a constructive 
contribution or ideas for missing functionality in the web platform 
and the inventor of JS honors me with a condescending response, as if ...


What the hey! Mr. Eich!

I guess this explains the origin of JS: a knee jerk reaction to 
then-trendy ideas...


That's not the way to go about all inclusive debate.

Thank you.

Sent from my iPhone


Brendan Eich mailto:bren...@secure.meer.net
February 10, 2015 at 5:44 PM
Please stop overloading public-webapps with idle chatter.

React and things like it or based on it are going strong. Work there, 
above the standards. De-jure standardization will follow, and we'll 
all be better off for that order of work.


/be



Marc Fawzi mailto:marc.fa...@gmail.com
February 10, 2015 at 12:51 PM
i agree that it's not a democratic process and even though some 
W3C/TAG people will engage you every now and then the end result is 
the browser vendors and even companies like Akamai have more say than 
the users and developers. It's a classic top-down system, but at least 
most debates and discussions happen over open-access mailing lists.


I wish there was an app like Hacker News where browser vendors via 
W3C, TAG, webapps etc engage users and developers in discussions and 
use up/down votes to tell what matters most to users and developers.


But design by committee is really hard and sub-optimal, and you need a 
group of true and tried experts (open minded ones) to call the shots 
on various technical aspects.











Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
I've recently started using something called an atom in ClojureScript and it is 
described as a mutable reference to an immutable value. It holds the state for 
the app and can be safely mutated by multiple components, and has an 
interesting thing called a cursor. It is lock free but synchronous. I think I 
understand it to some degree.

I don't understand the implementation of the DOM but why couldn't we have a 
representation of it that acted like the atom in clojure and then write the 
diff to the actual DOM. Is that what React does with I virtual DOM? No idea but 
I wasn't dropping words, I was describing what was explained to me about the 
atom in clojure and I saw parallels and possibility of something similar in JS 
to manage the DOM.

With all the brains in this place are you telling me flat out that it is 
impossible to have a version of the DOM (call it virtual or atomic DOM) that 
could be manipulated from web workers?

Also I was mentioning immutable and transient types because they are so 
necessary to performant functional programming, as I understand it.

Again the clojure atom is lock free and synchronous and is mutable and thread 
safe. Why couldn't something like that act as a layer to hold DOM state. Maybe 
that's how React's virtual DOM works? I don't know but I find the idea behind 
the atom very intriguing and not sure why it wouldn't be applicable to making 
the DOM thread safe. What do the biggest brains in the room think? That's all. 
A discussion. If people leave the list because of it then that's their right 
but it is a human right to speak ones mind as long as the speech is not 
demeaning or otherwise hurtful. 

I really don't understand the arrogance here.

Sent from my iPhone

 On Feb 10, 2015, at 6:43 PM, Brendan Eich bren...@secure.meer.net wrote:
 
 Your message to which I replied is not cited accurately below by you. The 
 text you wrote is here, in between  lines:
 
 
 How about a thread-safe but lock-free version of the DOM based on something 
 like Clojure's atom? So we can manipulate the DOM from web workers? With 
 cursor support?
 
 How about immutable data structures for side-effect-free functional 
 programming?
 
 How about  Will think of more
 
 
 This message text is exactly what I wrote my reply against.
 
 It's useless; sorry, this happens, but don't make a habit of it, or most 
 practitioners will unsubscribe to public-webapps. The DOM is a mutable 
 single-threaded store, so there's no lock-free version possible. You'd have 
 snapshots, with some cost in the snapshotting mechanism, at best. Then, you 
 wouldn't be able to manipulate in any shared-state sense of that word, the 
 DOM from workers.
 
 Sorry, but that's the way things are. Dropping words like immutable and 
 lock-free doesn't help. That, plus a lot of attitude about deprecating sync 
 XHR (on all sides; I'm not in favor of useless deprecation, myself -- good 
 luck to browsers who go first on actually *removing* sync XHR support), 
 adds up to noise in this list. What good purpose does noise to signal serve?
 
 /be
 
 Marc Fawzi mailto:marc.fa...@gmail.com
 February 10, 2015 at 6:24 PM
 What? a good cop bad cop routine? Jonas asks for a constructive contribution 
 or ideas for missing functionality in the web platform and the inventor of 
 JS honors me with a condescending response, as if ...
 
 What the hey! Mr. Eich!
 
 I guess this explains the origin of JS: a knee jerk reaction to then-trendy 
 ideas...
 
 That's not the way to go about all inclusive debate.
 
 Thank you.
 
 Sent from my iPhone
 
 
 Brendan Eich mailto:bren...@secure.meer.net
 February 10, 2015 at 5:44 PM
 Please stop overloading public-webapps with idle chatter.
 
 React and things like it or based on it are going strong. Work there, above 
 the standards. De-jure standardization will follow, and we'll all be better 
 off for that order of work.
 
 /be
 
 
 
 Marc Fawzi mailto:marc.fa...@gmail.com
 February 10, 2015 at 12:51 PM
 i agree that it's not a democratic process and even though some W3C/TAG 
 people will engage you every now and then the end result is the browser 
 vendors and even companies like Akamai have more say than the users and 
 developers. It's a classic top-down system, but at least most debates and 
 discussions happen over open-access mailing lists.
 
 I wish there was an app like Hacker News where browser vendors via W3C, TAG, 
 webapps etc engage users and developers in discussions and use up/down votes 
 to tell what matters most to users and developers.
 
 But design by committee is really hard and sub-optimal, and you need a group 
 of true and tried experts (open minded ones) to call the shots on various 
 technical aspects.
 
 
 
 
 
 



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich

Please stop overloading public-webapps with idle chatter.

React and things like it or based on it are going strong. Work there, 
above the standards. De-jure standardization will follow, and we'll all 
be better off for that order of work.


/be

Marc Fawzi wrote:

How about a thread-safe but lock-free version of the DOM based on something 
like Clojure's atom? So we can manipulate the DOM from web workers? With cursor 
support?

How about immutable data structures for side-effect-free functional programming?

How about  Will think of more




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich

Marc Fawzi wrote:

I've recently started using something called an atom in ClojureScript and it is described 
as a mutable reference to an immutable value. It holds the state for the app and can be 
safely mutated by multiple components, and has an interesting thing called a 
cursor. It is lock free but synchronous. I think I understand it to some degree.


The win there is the mutations are local to the clients of the atom, but 
the underlying data structure it reflects is immutable. The DOM is not 
immutable and must not be for backward compatibility.



I don't understand the implementation of the DOM but why couldn't we have a 
representation of it that acted like the atom in clojure and then write the 
diff to the actual DOM.


Because browsers don't work that way. I wish they did, but they can't 
afford to stop the world, reimplement, optimize (if possible -- they 
will probably see regressions that are both hard to fix, and that hurt 
them in the market), and then restart the world.



Is that what React does with I virtual DOM? No idea but I wasn't dropping 
words, I was describing what was explained to me about the atom in clojure and 
I saw parallels and possibility of something similar in JS to manage the DOM.


I'm a big React fan. But it can virtualize the DOM using JS objects and 
do diffing/patching, without having to jack up the browsers (all of 
them; note stop the world above), rewrite their DOMs to match, and get 
them optimized and running again.



With all the brains in this place are you telling me flat out that it is 
impossible to have a version of the DOM (call it virtual or atomic DOM) that 
could be manipulated from web workers?


I'm not. People are doing this. My explicit point in a previous reply 
was that you don't need public-webapps or browser vendors to agree on 
doing this in full to start, and what you do in JS can inform smaller, 
easier steps in the standards body. One such step would be a way to do 
sync i/o from workers. Clear?



Also I was mentioning immutable and transient types because they are so 
necessary to performant functional programming, as I understand it.


Sure, but we're back to motherhood-and-apple-pie rhetoric now.


Again the clojure atom is lock free and synchronous and is mutable and thread 
safe. Why couldn't something like that act as a layer to hold DOM state.


First, lock-free data structures are not free. They require a memory 
barrier or fence, e.g., cmpxchg on Intel. Study this before endorsing it 
as a free lunch. Competing browsers will not add such overhead to their 
DOMs right now.


Second, even if the DOM must remain a single-threaded and truly 
lock/barrier/fence-free data structure, what you are reaching for is 
doable now, with some help from standards bodies. But not by vague 
blather, and nothing to do with sync XHR, to get back on topic.



  Maybe that's how React's virtual DOM works? I don't know but I find the idea 
behind the atom very intriguing and not sure why it wouldn't be applicable to 
making the DOM thread safe. What do the biggest brains in the room think? 
That's all. A discussion. If people leave the list because of it then that's 
their right but it is a human right to speak ones mind as long as the speech is 
not demeaning or otherwise hurtful.


I think you're on the wrong list. This isn't the place for vague albeit 
well-intentioned -- but as you allow above, uninformed (I don't know) 
-- speculations and hopes.



I really don't understand the arrogance here.


Cut it out, or I'll cite your faux-humility as tit-for-tat. We need to 
be serious, well-informed, and concrete here. No speculations based on 
free-lunch (!= lock-free) myths.


As for sync XHR, I agree with you (I think! I may be misremembering your 
position) that compatibility trumps intentions on the Web. This favors 
the React built it in JS on top approach, with future DOM (and other, 
e.g. WebComponents) standards following fast.


/be



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz
No argument in regard to the problems that might arise from using sync
calls.  But it is IMHO not the job of the browser developers to decide
who can use what, when and why. It is up the guys (or gals) coding a
web site to select an appropriate AJAX call to get the job done.

Once again: Please remember that it is your job to make my (and
countless other web developers) life easier and to give us more
choices, more possibilities to do cool stuff. We appreciate your work.
But must of us don't need hard coded education in regard to the way we
think that web-apps and -services should be created.

m.

On 02/10/2015 08:47 AM, Ashley Gullen wrote:
 I am on the side that synchronous AJAX should definitely be
 deprecated, except in web workers where sync stuff is OK.
 
 Especially on the modern web, there are two really good
 alternatives: - write your code in a web worker where synchronous
 calls don't hang the browser - write async code which doesn't hang
 the browser
 
 With modern tools like Promises and the new Fetch API, I can't
 think of any reason to write a synchronous AJAX request on the main
 thread, when an async one could have been written instead with
 probably little extra effort.
 
 Alas, existing codebases rely on it, so it cannot be removed
 easily. But I can't see why anyone would argue that it's a good
 design principle to make possibly seconds-long synchronous calls on
 the UI thread.
 
 
 
 
 On 9 February 2015 at 19:33, George Calvert 
 george.calv...@loudthink.com
 mailto:george.calv...@loudthink.com wrote:
 
 I third Michaela and Gregg.
 
 __ __
 
 It is the app and site developers' job to decide whether the user 
 should wait on the server — not the standard's and, 99.9% of the 
 time, not the browser's either.
 
 __ __
 
 I agree a well-designed site avoids synchronous calls.  BUT —
 there still are plenty of real-world cases where the best choice is
 having the user wait: Like when subsequent options depend on the
 server's reply.  Or more nuanced, app/content-specific cases where
 rewinding after an earlier transaction fails is detrimental to the
 overall UX or simply impractical to code.
 
 __ __
 
 Let's focus our energies elsewhere — dispensing with browser 
 warnings that tell me what I already know and with deprecating 
 features that are well-entrenched and, on occasion, incredibly 
 useful.
 
 __ __
 
 Thanks, George Calvert
 
 




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz

LOL .. good one. But it's not only about whether or not s-xhr should be
depreciated. It's also about the focus and scope of the browsers teams work.

m.


On 02/10/2015 11:28 AM, Marc Fawzi wrote:
 Here is a really bad idea:
 
 Launch an async xhr and monitor its readyState in a while loop and don't exit 
 the loop till it has finished.
 
 Easier than writing charged emails. Less drain on the soul. 
 
 Sent from my iPhone
 
 On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com 
 wrote:

 No argument in regard to the problems that might arise from using sync
 calls.  But it is IMHO not the job of the browser developers to decide
 who can use what, when and why. It is up the guys (or gals) coding a
 web site to select an appropriate AJAX call to get the job done.

 Once again: Please remember that it is your job to make my (and
 countless other web developers) life easier and to give us more
 choices, more possibilities to do cool stuff. We appreciate your work.
 But must of us don't need hard coded education in regard to the way we
 think that web-apps and -services should be created.

 m.

 On 02/10/2015 08:47 AM, Ashley Gullen wrote:
 I am on the side that synchronous AJAX should definitely be
 deprecated, except in web workers where sync stuff is OK.

 Especially on the modern web, there are two really good
 alternatives: - write your code in a web worker where synchronous
 calls don't hang the browser - write async code which doesn't hang
 the browser

 With modern tools like Promises and the new Fetch API, I can't
 think of any reason to write a synchronous AJAX request on the main
 thread, when an async one could have been written instead with
 probably little extra effort.

 Alas, existing codebases rely on it, so it cannot be removed
 easily. But I can't see why anyone would argue that it's a good
 design principle to make possibly seconds-long synchronous calls on
 the UI thread.




 On 9 February 2015 at 19:33, George Calvert 
 george.calv...@loudthink.com
 mailto:george.calv...@loudthink.com wrote:

 I third Michaela and Gregg.

 __ __

 It is the app and site developers' job to decide whether the user 
 should wait on the server — not the standard's and, 99.9% of the 
 time, not the browser's either.

 __ __

 I agree a well-designed site avoids synchronous calls.  BUT —
 there still are plenty of real-world cases where the best choice is
 having the user wait: Like when subsequent options depend on the
 server's reply.  Or more nuanced, app/content-specific cases where
 rewinding after an earlier transaction fails is detrimental to the
 overall UX or simply impractical to code.

 __ __

 Let's focus our energies elsewhere — dispensing with browser 
 warnings that tell me what I already know and with deprecating 
 features that are well-entrenched and, on occasion, incredibly 
 useful.

 __ __

 Thanks, George Calvert






Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread George Calvert
Ashley,

Isn't it for the app dev team - rather than the standards body or even the 
browser team - to decide whether the UI thread should wait on the server?

I see it like this: The user, with the app as middleman, is conversing with the 
server.  Just as we want modal dialogs because sometimes it makes sense to say 
Answer this before proceeding, sometimes we want a synchronous call in the 
main thread (because we want an answer from the server before proceeding).

Sure, I can present a dialog as non-modal - but then I've got to manage the 
loose-ends if left unfinished.  Maybe I can toss all that into a cookie - and 
maybe I can't.  Having a modal dialog as an option allows us to simplify the 
code and avoid a lot of what-happened-to-my-data calls to the help desk.

For me, it's the same with calls to the server.  Common use-cases are log-in 
and master/parent-object creates.   In my apps, the UI depends on user-specific 
config that is returned upon log-in.  As well, there are instances where 
creating a parent object precedes creating child objects and it just creates a 
dozen headaches to let the user proceed without confirmation that the parent 
exists server-side.

I agree the goal is to model as much as possible as asynchronous.  My issue is 
that there are still real-world, practical applications for S-JAX and that 
identifying those is the app developer's job, not W3C's.

Heck, why not go the other way and deprecate AJAX now that web workers make 
background threads a first-class object available for any processing?  ;-)

Best,
George





Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
Here is a really bad idea:

Launch an async xhr and monitor its readyState in a while loop and don't exit 
the loop till it has finished.

Easier than writing charged emails. Less drain on the soul. 

Sent from my iPhone

 On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com wrote:
 
 No argument in regard to the problems that might arise from using sync
 calls.  But it is IMHO not the job of the browser developers to decide
 who can use what, when and why. It is up the guys (or gals) coding a
 web site to select an appropriate AJAX call to get the job done.
 
 Once again: Please remember that it is your job to make my (and
 countless other web developers) life easier and to give us more
 choices, more possibilities to do cool stuff. We appreciate your work.
 But must of us don't need hard coded education in regard to the way we
 think that web-apps and -services should be created.
 
 m.
 
 On 02/10/2015 08:47 AM, Ashley Gullen wrote:
 I am on the side that synchronous AJAX should definitely be
 deprecated, except in web workers where sync stuff is OK.
 
 Especially on the modern web, there are two really good
 alternatives: - write your code in a web worker where synchronous
 calls don't hang the browser - write async code which doesn't hang
 the browser
 
 With modern tools like Promises and the new Fetch API, I can't
 think of any reason to write a synchronous AJAX request on the main
 thread, when an async one could have been written instead with
 probably little extra effort.
 
 Alas, existing codebases rely on it, so it cannot be removed
 easily. But I can't see why anyone would argue that it's a good
 design principle to make possibly seconds-long synchronous calls on
 the UI thread.
 
 
 
 
 On 9 February 2015 at 19:33, George Calvert 
 george.calv...@loudthink.com
 mailto:george.calv...@loudthink.com wrote:
 
 I third Michaela and Gregg.
 
 __ __
 
 It is the app and site developers' job to decide whether the user 
 should wait on the server — not the standard's and, 99.9% of the 
 time, not the browser's either.
 
 __ __
 
 I agree a well-designed site avoids synchronous calls.  BUT —
 there still are plenty of real-world cases where the best choice is
 having the user wait: Like when subsequent options depend on the
 server's reply.  Or more nuanced, app/content-specific cases where
 rewinding after an earlier transaction fails is detrimental to the
 overall UX or simply impractical to code.
 
 __ __
 
 Let's focus our energies elsewhere — dispensing with browser 
 warnings that tell me what I already know and with deprecating 
 features that are well-entrenched and, on occasion, incredibly 
 useful.
 
 __ __
 
 Thanks, George Calvert
 
 



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Elliott Sprehn
On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote:

 Here is a really bad idea:

 Launch an async xhr and monitor its readyState in a while loop and don't
 exit the loop till it has finished.

 Easier than writing charged emails. Less drain on the soul


This won't work, state changes are async and long running while loops
result in the hung script dialog which means we'll probably just kill your
page.

The main thread of your web app is the UI thread, you shouldn't be doing IO
there (or anything else expensive). Some other application platforms will
even flash the whole screen or kill your process if you do that to warn
you're doing something awful.



 Sent from my iPhone

  On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com
 javascript:; wrote:
 
  No argument in regard to the problems that might arise from using sync
  calls.  But it is IMHO not the job of the browser developers to decide
  who can use what, when and why. It is up the guys (or gals) coding a
  web site to select an appropriate AJAX call to get the job done.
 
  Once again: Please remember that it is your job to make my (and
  countless other web developers) life easier and to give us more
  choices, more possibilities to do cool stuff. We appreciate your work.
  But must of us don't need hard coded education in regard to the way we
  think that web-apps and -services should be created.
 
  m.
 
  On 02/10/2015 08:47 AM, Ashley Gullen wrote:
  I am on the side that synchronous AJAX should definitely be
  deprecated, except in web workers where sync stuff is OK.
 
  Especially on the modern web, there are two really good
  alternatives: - write your code in a web worker where synchronous
  calls don't hang the browser - write async code which doesn't hang
  the browser
 
  With modern tools like Promises and the new Fetch API, I can't
  think of any reason to write a synchronous AJAX request on the main
  thread, when an async one could have been written instead with
  probably little extra effort.
 
  Alas, existing codebases rely on it, so it cannot be removed
  easily. But I can't see why anyone would argue that it's a good
  design principle to make possibly seconds-long synchronous calls on
  the UI thread.
 
 
 
 
  On 9 February 2015 at 19:33, George Calvert
  george.calv...@loudthink.com javascript:;
  mailto:george.calv...@loudthink.com javascript:; wrote:
 
  I third Michaela and Gregg.
 
  __ __
 
  It is the app and site developers' job to decide whether the user
  should wait on the server — not the standard's and, 99.9% of the
  time, not the browser's either.
 
  __ __
 
  I agree a well-designed site avoids synchronous calls.  BUT —
  there still are plenty of real-world cases where the best choice is
  having the user wait: Like when subsequent options depend on the
  server's reply.  Or more nuanced, app/content-specific cases where
  rewinding after an earlier transaction fails is detrimental to the
  overall UX or simply impractical to code.
 
  __ __
 
  Let's focus our energies elsewhere — dispensing with browser
  warnings that tell me what I already know and with deprecating
  features that are well-entrenched and, on occasion, incredibly
  useful.
 
  __ __
 
  Thanks, George Calvert
 
 




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Boris Zbarsky

On 2/10/15 12:28 PM, Marc Fawzi wrote:

Launch an async xhr and monitor its readyState in a while loop and don't exit 
the loop till it has finished.


Per spec (and in implementations last I checked), the readyState isn't 
allowed to change during the loop.  So all that will happen is you will 
get a slow script dialog or equivalent.


-Boris




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
If readyState is async then have set a variable in the readyState change
callback and monitor that variable in a while loop :D

What am I missing?

On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn espr...@chromium.org
wrote:



 On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote:

 Here is a really bad idea:

 Launch an async xhr and monitor its readyState in a while loop and don't
 exit the loop till it has finished.

 Easier than writing charged emails. Less drain on the soul


 This won't work, state changes are async and long running while loops
 result in the hung script dialog which means we'll probably just kill your
 page.

 The main thread of your web app is the UI thread, you shouldn't be doing
 IO there (or anything else expensive). Some other application
 platforms will even flash the whole screen or kill your process if you do
 that to warn you're doing something awful.




 Sent from my iPhone

  On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com
 wrote:
 
  No argument in regard to the problems that might arise from using sync
  calls.  But it is IMHO not the job of the browser developers to decide
  who can use what, when and why. It is up the guys (or gals) coding a
  web site to select an appropriate AJAX call to get the job done.
 
  Once again: Please remember that it is your job to make my (and
  countless other web developers) life easier and to give us more
  choices, more possibilities to do cool stuff. We appreciate your work.
  But must of us don't need hard coded education in regard to the way we
  think that web-apps and -services should be created.
 
  m.
 
  On 02/10/2015 08:47 AM, Ashley Gullen wrote:
  I am on the side that synchronous AJAX should definitely be
  deprecated, except in web workers where sync stuff is OK.
 
  Especially on the modern web, there are two really good
  alternatives: - write your code in a web worker where synchronous
  calls don't hang the browser - write async code which doesn't hang
  the browser
 
  With modern tools like Promises and the new Fetch API, I can't
  think of any reason to write a synchronous AJAX request on the main
  thread, when an async one could have been written instead with
  probably little extra effort.
 
  Alas, existing codebases rely on it, so it cannot be removed
  easily. But I can't see why anyone would argue that it's a good
  design principle to make possibly seconds-long synchronous calls on
  the UI thread.
 
 
 
 
  On 9 February 2015 at 19:33, George Calvert
  george.calv...@loudthink.com
  mailto:george.calv...@loudthink.com wrote:
 
  I third Michaela and Gregg.
 
  __ __
 
  It is the app and site developers' job to decide whether the user
  should wait on the server — not the standard's and, 99.9% of the
  time, not the browser's either.
 
  __ __
 
  I agree a well-designed site avoids synchronous calls.  BUT —
  there still are plenty of real-world cases where the best choice is
  having the user wait: Like when subsequent options depend on the
  server's reply.  Or more nuanced, app/content-specific cases where
  rewinding after an earlier transaction fails is detrimental to the
  overall UX or simply impractical to code.
 
  __ __
 
  Let's focus our energies elsewhere — dispensing with browser
  warnings that tell me what I already know and with deprecating
  features that are well-entrenched and, on occasion, incredibly
  useful.
 
  __ __
 
  Thanks, George Calvert
 
 




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
Async xhr with callback let's you manage the flow such that you don't do 
anything until a successful response from the server. Promises make it even 
nicer. 

Sent from my iPhone

 On Feb 10, 2015, at 9:15 AM, George Calvert george.calv...@loudthink.com 
 wrote:
 
 Ashley,
  
 Isn't it for the app dev team — rather than the standards body or even the 
 browser team — to decide whether the UI thread should wait on the server?
  
 I see it like this: The user, with the app as middleman, is conversing with 
 the server.  Just as we want modal dialogs because sometimes it makes sense 
 to say Answer this before proceeding, sometimes we want a synchronous call 
 in the main thread (because we want an answer from the server before 
 proceeding).
  
 Sure, I can present a dialog as non-modal — but then I've got to manage the 
 loose-ends if left unfinished.  Maybe I can toss all that into a cookie — and 
 maybe I can't.  Having a modal dialog as an option allows us to simplify the 
 code and avoid a lot of what-happened-to-my-data calls to the help desk.
  
 For me, it's the same with calls to the server.  Common use-cases are log-in 
 and master/parent-object creates.   In my apps, the UI depends on 
 user-specific config that is returned upon log-in.  As well, there are 
 instances where creating a parent object precedes creating child objects and 
 it just creates a dozen headaches to let the user proceed without 
 confirmation that the parent exists server-side.
  
 I agree the goal is to model as much as possible as asynchronous.  My issue 
 is that there are still real-world, practical applications for S-JAX and that 
 identifying those is the app developer's job, not W3C's.
  
 Heck, why not go the other way and deprecate AJAX now that web workers make 
 background threads a first-class object available for any processing?  ;-)
  
 Best,
 George
  
  
  


Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Elliott Sprehn
On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote:

 If readyState is async then have set a variable in the readyState change
 callback and monitor that variable in a while loop :D

 What am I missing?


The event fires async, at the time we update the property. There is no way
to synchronously observe an XHR.



 On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn espr...@chromium.org
 javascript:_e(%7B%7D,'cvml','espr...@chromium.org'); wrote:



 On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com
 javascript:_e(%7B%7D,'cvml','marc.fa...@gmail.com'); wrote:

 Here is a really bad idea:

 Launch an async xhr and monitor its readyState in a while loop and don't
 exit the loop till it has finished.

 Easier than writing charged emails. Less drain on the soul


 This won't work, state changes are async and long running while loops
 result in the hung script dialog which means we'll probably just kill your
 page.

 The main thread of your web app is the UI thread, you shouldn't be doing
 IO there (or anything else expensive). Some other application
 platforms will even flash the whole screen or kill your process if you do
 that to warn you're doing something awful.




 Sent from my iPhone

  On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com
 wrote:
 
  No argument in regard to the problems that might arise from using sync
  calls.  But it is IMHO not the job of the browser developers to decide
  who can use what, when and why. It is up the guys (or gals) coding a
  web site to select an appropriate AJAX call to get the job done.
 
  Once again: Please remember that it is your job to make my (and
  countless other web developers) life easier and to give us more
  choices, more possibilities to do cool stuff. We appreciate your work.
  But must of us don't need hard coded education in regard to the way we
  think that web-apps and -services should be created.
 
  m.
 
  On 02/10/2015 08:47 AM, Ashley Gullen wrote:
  I am on the side that synchronous AJAX should definitely be
  deprecated, except in web workers where sync stuff is OK.
 
  Especially on the modern web, there are two really good
  alternatives: - write your code in a web worker where synchronous
  calls don't hang the browser - write async code which doesn't hang
  the browser
 
  With modern tools like Promises and the new Fetch API, I can't
  think of any reason to write a synchronous AJAX request on the main
  thread, when an async one could have been written instead with
  probably little extra effort.
 
  Alas, existing codebases rely on it, so it cannot be removed
  easily. But I can't see why anyone would argue that it's a good
  design principle to make possibly seconds-long synchronous calls on
  the UI thread.
 
 
 
 
  On 9 February 2015 at 19:33, George Calvert
  george.calv...@loudthink.com
  mailto:george.calv...@loudthink.com wrote:
 
  I third Michaela and Gregg.
 
  __ __
 
  It is the app and site developers' job to decide whether the user
  should wait on the server — not the standard's and, 99.9% of the
  time, not the browser's either.
 
  __ __
 
  I agree a well-designed site avoids synchronous calls.  BUT —
  there still are plenty of real-world cases where the best choice is
  having the user wait: Like when subsequent options depend on the
  server's reply.  Or more nuanced, app/content-specific cases where
  rewinding after an earlier transaction fails is detrimental to the
  overall UX or simply impractical to code.
 
  __ __
 
  Let's focus our energies elsewhere — dispensing with browser
  warnings that tell me what I already know and with deprecating
  features that are well-entrenched and, on occasion, incredibly
  useful.
 
  __ __
 
  Thanks, George Calvert
 
 





Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi

How about a thread-safe but lock-free version of the DOM based on something 
like Clojure's atom? So we can manipulate the DOM from web workers? With cursor 
support? 

How about immutable data structures for side-effect-free functional 
programming? 

How about  Will think of more

Sent from my iPhone

 On Feb 10, 2015, at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote:
 
 On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi marc.fa...@gmail.com wrote:
 i agree that it's not a democratic process and even though some W3C/TAG
 people will engage you every now and then the end result is the browser
 vendors and even companies like Akamai have more say than the users and
 developers
 
 Developers actually have more say than any other party in this process.
 
 Browsers are not interested in shipping any APIs that developers
 aren't going to use. Likewise they are not going to remove any APIs
 that developers are using (hence sync XHR is not going to go anywhere,
 no matter what the spec says).
 
 Sadly W3C and the developer community has not yet figured out a good
 way to communicate.
 
 But here's where you can make a difference!
 
 Please do suggest problems that you think needs to be solved. With new
 specifications that are still in the development phase, with existing
 specifications that have problems, and with specifications that
 doesn't exist yet but you think should.
 
 Looking forward to your constructive contributions.
 
 / Jonas



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Jonas Sicking
On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz
michaela.m...@hermetos.com wrote:
 Blobs are immutable but it would be cool to have blob
 'pipes' or FIFOs allowing us to stream from those pipes by feeding them
 via AJAX.

Since it sounds like you want to help with this, there's good news!
There's an API draft available. It would be very helpful to have web
developers, such as yourself, to try it out and find any rough edges
before it ships in browsers.

There's a spec and a prototype implementation over at
https://github.com/whatwg/streams/

It would be very helpful if you try it out and report any problems
that you find or share any cool demos that you create.

/ Jonas



Standards wonks and developers working together [Was: Re: do not deprecate synchronous XMLHttpRequest]

2015-02-10 Thread Arthur Barstow

On 2/10/15 3:51 PM, Marc Fawzi wrote:
I wish there was an app like Hacker News where browser vendors via 
W3C, TAG, webapps etc engage users and developers in discussions and 
use up/down votes to tell what matters most to users and developers.


I like this idea. I think this is one of the reasons Robin (and others) 
created Specifiction(/Discourse) http://specifiction.org/.
But design by committee is really hard and sub-optimal, and you need a 
group of true and tried experts (open minded ones) to call the shots 
on various technical aspects.
Mostly agree ;-). I suspect the more useful specs are those created by 
_all_ affected stakeholders.


-Thanks, AB





Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Jonas Sicking
On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi marc.fa...@gmail.com wrote:
 i agree that it's not a democratic process and even though some W3C/TAG
 people will engage you every now and then the end result is the browser
 vendors and even companies like Akamai have more say than the users and
 developers

Developers actually have more say than any other party in this process.

Browsers are not interested in shipping any APIs that developers
aren't going to use. Likewise they are not going to remove any APIs
that developers are using (hence sync XHR is not going to go anywhere,
no matter what the spec says).

Sadly W3C and the developer community has not yet figured out a good
way to communicate.

But here's where you can make a difference!

Please do suggest problems that you think needs to be solved. With new
specifications that are still in the development phase, with existing
specifications that have problems, and with specifications that
doesn't exist yet but you think should.

Looking forward to your constructive contributions.

/ Jonas



Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz

That is good news indeed. And I am glad to help.

m.



On 02/10/2015 03:02 PM, Jonas Sicking wrote:
 On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz 
 michaela.m...@hermetos.com wrote:
 Blobs are immutable but it would be cool to have blob 'pipes' or
 FIFOs allowing us to stream from those pipes by feeding them via
 AJAX.
 
 Since it sounds like you want to help with this, there's good
 news! There's an API draft available. It would be very helpful to
 have web developers, such as yourself, to try it out and find any
 rough edges before it ships in browsers.
 
 There's a spec and a prototype implementation over at 
 https://github.com/whatwg/streams/
 
 It would be very helpful if you try it out and report any problems 
 that you find or share any cool demos that you create.
 
 / Jonas
 




Staying on topic [Was: Re: do not deprecate synchronous XMLHttpRequest]

2015-02-10 Thread Arthur Barstow

On 2/10/15 3:43 PM, Michaela Merz wrote:

The web-developers are the people who have
to use the available browser technologies to provide what users want.
And often we can't oblige because - well, browsers don't implement it
for whatever reason.


Michaela - this list is for technical discussions regarding WebApps' 
specs. However, your last couple of e-mails  directly targeted specific 
browser vendors. I ask that you please refrain such targeting on this 
list (perhaps you could move such comments/dialogue to vendor-specific 
forum).


-Thanks, AB




Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi

How about a thread-safe but lock-free version of the DOM based on something
like Clojure's atom? So we can manipulate the DOM from web workers? With
cursor support?

How about immutable data structures for side-effect-free functional
programming?


and transients! to complete the picture.

I think maybe aside from the thread-safe DOM idea, everything below that
should belong to the ES7 discussion list.



On Tue, Feb 10, 2015 at 1:46 PM, Marc Fawzi marc.fa...@gmail.com wrote:


 How about a thread-safe but lock-free version of the DOM based on
 something like Clojure's atom? So we can manipulate the DOM from web
 workers? With cursor support?

 How about immutable data structures for side-effect-free functional
 programming?

 How about  Will think of more

 Sent from my iPhone

  On Feb 10, 2015, at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi marc.fa...@gmail.com
 wrote:
  i agree that it's not a democratic process and even though some W3C/TAG
  people will engage you every now and then the end result is the browser
  vendors and even companies like Akamai have more say than the users and
  developers
 
  Developers actually have more say than any other party in this process.
 
  Browsers are not interested in shipping any APIs that developers
  aren't going to use. Likewise they are not going to remove any APIs
  that developers are using (hence sync XHR is not going to go anywhere,
  no matter what the spec says).
 
  Sadly W3C and the developer community has not yet figured out a good
  way to communicate.
 
  But here's where you can make a difference!
 
  Please do suggest problems that you think needs to be solved. With new
  specifications that are still in the development phase, with existing
  specifications that have problems, and with specifications that
  doesn't exist yet but you think should.
 
  Looking forward to your constructive contributions.
 
  / Jonas



Re: do not deprecate synchronous XMLHttpRequest

2015-02-09 Thread George Calvert
I third Michaela and Gregg.

It is the app and site developers' job to decide whether the user should wait 
on the server - not the standard's and, 99.9% of the time, not the browser's 
either.

I agree a well-designed site avoids synchronous calls.  BUT - there still are 
plenty of real-world cases where the best choice is having the user wait: Like 
when subsequent options depend on the server's reply.  Or more nuanced, 
app/content-specific cases where rewinding after an earlier transaction fails 
is detrimental to the overall UX or simply impractical to code.

Let's focus our energies elsewhere - dispensing with browser warnings that tell 
me what I already know and with deprecating features that are well-entrenched 
and, on occasion, incredibly useful.

Thanks,
George Calvert


Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Marc Fawzi
You either block the JS event loop or you don't. If you do, I'm not sure
how a long running synchronous call to the server won't result in this
script is taking too long alert and basically hold up all execution till
it's done. What am I missing? If you want to synchronize tasks you can
promises or callbacks or (in ES6/7) I'm sure other ways too

On Fri, Feb 6, 2015 at 10:38 AM, Michaela Merz michaela.m...@hermetos.com
wrote:

  Well yeah. But the manufacturer of your audio equipment doesn't come
 into your home to yank the player out of your setup. But that's not really
 the issue here. We're talking about technology that is being developed so
 that people like me can build good content. As long as there are a lot of
 people out there using synchronous calls, it would be the job of the
 browser development community to find a way to make such calls less harmful.

 Michaela



 On 02/06/2015 12:28 PM, Marc Fawzi wrote:

 I have several 8-track tapes from the early-to-mid 70s that I'm really
 fond of. They are bigger than my iPod. Maybe I can build an adapter with
 mechanical parts, magnetic reader and A/D convertor etc. But that's my job,
 not Apple's job.

  The point is, old technologies die all the time, and people who want to
 hold on to old content and have it play on the latest player (browser) need
 to either recode the content or build adapters/hosts/wrappers such that the
 old content will think it's running in the old player.

  As far as stuff we build today, we have several options for waiting
 until ajax response comes back, and I'm not why we'd want to block
 everything until it does. It sounds unreasonable. There are legitimate
 scenarios for blocking the event loop but not when it comes to fetching
 data from a server.





 On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz michaela.m...@hermetos.com
 wrote:


 Well .. may be some folks should take a deep breath and think what they
 are doing. I am 'just' coding web services and too often I find myself
 asking: Why did the guys think that this would make sense? Indexeddb is
 such a case. It might be a clever design, but it's horrible from a coders
 perspective.

 Would it have been the end of the world to stick with some kind of
 database language most coders already are familiar with? Same with (sand
 boxed) file system access. Google went the right way with functions trying
 to give us what we already knew: files, dirs, read, write, append.  But
 that's water under the bridge.

 I have learned to code my stuff in a way that I have to invest time and
 work so that my users don't have to. This is IMHO a good approach.
 Unfortunately - some people up the chain have a different approach.
 Synchronous calls are bad. Get rid of them. Don't care if developers have a
 need for it. Why bother. Our way or highway. Frankly - I find that
 offensive.  If you believe that synchronous calls are too much of a problem
 for the browser, find a way for the browser to deal with it.

 Building browsers and adding functionality is not and end in itself. The
 purpose is not to make cool stuff. We don't need people telling us what we
 are allowed to do. Don't get me wrong: I really appreciate your work and I
 am exited about what we can do in script nowadays. But please give more
 thought to the folks coding web sites. We are already dealing with a wide
 variety of problems: From browser incompatibilities, to responsive designs,
 server side development, sql, memcached, php, script - you name it. Try to
 make our life easier by keeping stuff simple and understandable even for
 those, who don't have the appreciation or the understanding what's going on
 under the hood of a browser.

 Thanks.

 Michaela





 On 02/06/2015 09:54 AM, Florian Bösch wrote:
 
  I had an Android device, but now I have an iPhone. In addition to
 the popup problem, and the fake X on ads, the iPhone browsers (Safari,
 Chrome, Opera) will start to show a site, then they will lock up for 10-30
 seconds before finally becoming responsive.
 
 
  Via. Ask Slashdot:
 http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser
 
  Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
 SeaMonkey 2.27), synchronous requests on the main thread have been
 deprecated due to the negative effects to the user experience.
 
 
 
  Via
 https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
 
  Heads up! The XMLHttpRequest2 spec was recently changed to prohibit
 sending a synchronous request whenxhr.responseType is set. The idea behind
 the change is to help mitigate further usage of synchronous xhrs wherever
 possible.
 
 
  Via
 http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
 
 







Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Florian Bösch
On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com
wrote:

  it would be the job of the browser development community to find a way
 to make such calls less harmful.

If there was a way to make synchronous calls less harmful, it'd have been
implemented a long time ago. There isn't.

You could service synchronous semantics with co-routine based schedulers.
It wouldn't block the main thread, but there'd still be nothing going on
while your single-threaded code waits for the XHR to complete, and so it's
still bad UX. Solving the bad UX would require you to deal with the
scheduler (spawn microthreads that do other things so it's not bad UX).
Regardless, ES-discuss isn't fond of co-routines, so that's not gonna
happen.


Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Michaela Merz
Ryosuke:

I understand the reasoning behind the thought. But it is IMHO not the
job of  browser implementations to educated web developers or to tell
them, how things should (not) be done. All I am asking is to keep in
mind that it is us who actually makes the content - the very reason for
browsers to be developed and improved. And - seeing the e-mail address
and hoping that you have some influence on the development of Safari: 
Please make the necessary improvements so that Safari can be used in a
highly complex script environment. That includes indexeddb/file handle
and the possibilities to export and store arbitrary blobs of data into
the file system (eg. createObjectURL for any kind of data). Thanks.

m.



On 02/06/2015 12:30 PM, Ryosuke Niwa wrote:

 On Feb 6, 2015, at 9:27 AM, Michaela Merz
michaela.m...@hermetos.com wrote:

 Well .. may be some folks should take a deep breath and think what
they are doing. I am 'just' coding web services and too often I find
myself asking: Why did the guys think that this would make sense?
Indexeddb is such a case. It might be a clever design, but it's horrible
from a coders perspective.

 Would it have been the end of the world to stick with some kind of
database language most coders already are familiar with? Same with (sand
boxed) file system access. Google went the right way with functions
trying to give us what we already knew: files, dirs, read, write,
append.  But that's water under the bridge.

 I have learned to code my stuff in a way that I have to invest time
and work so that my users don't have to. This is IMHO a good approach.

 In that regard, I'm on the same boat.  I still write simple web apps
in PHP with PostgreSQL instead of Scala/Ruby and a non-schema database
today.  So I totally understand your sentiment.  However,

 Unfortunately - some people up the chain have a different approach.
Synchronous calls are bad. Get rid of them. Don't care if developers
have a need for it. Why bother. Our way or highway. Frankly - I find
that offensive.  If you believe that synchronous calls are too much of a
problem for the browser, find a way for the browser to deal with it.

 The problem isn't so much that it causes a problem for browser
implementors but rather it results in poor user experience.  While a
synchronous XHR is on the fly, user cannot interact with the page at
all.  With some spinner, etc... UI indicating that the user has to wait,
the user can at least still click on hyperlinks and so forth.

 Since browser vendors (and I hope so are other participants of the
working group) are interested in providing better user experience, we
would like websites to use asynchronous XHR.

 Having said that, don't worry.  Synchronous XHR isn't going away
anytime soon.  As long as real websites are using synchronous XHR,
browser vendors aren't going to remove/unsupport it.

 - R. Niwa






Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Michaela Merz
Florian:

I ain't got a problem with synchronous calls. Its just that I had the
need to rant because the rift between you guys and simple developer
folks is getting deeper every day. If somebody fucks up his web site
because he doesn't get the differences between asynchronous and
synchronous calls, that's his prerogative.

m.






On 02/06/2015 12:50 PM, Florian Bösch wrote:
 On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com
mailto:michaela.m...@hermetos.com wrote:

 it would be the job of the browser development community to find a
way to make such calls less harmful.

 If there was a way to make synchronous calls less harmful, it'd have
been implemented a long time ago. There isn't.

 You could service synchronous semantics with co-routine based
schedulers. It wouldn't block the main thread, but there'd still be
nothing going on while your single-threaded code waits for the XHR to
complete, and so it's still bad UX. Solving the bad UX would require you
to deal with the scheduler (spawn microthreads that do other things so
it's not bad UX). Regardless, ES-discuss isn't fond of co-routines, so
that's not gonna happen.




do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Gregg Tracton
I disagree with deprecating synchronous XMLHttpRequest:

1) it is not upward compatible  so can break numerous sites.
Many websites do not have active development, and framework updates
that fix this are even slower to roll out to web apps.  Many web
app clients would much prefer a sub-optimal experience than a
broken website.

2) A better way to approach this might be to respect the async=false
setting but have the browser move the script thread to another thread which
is blocked until the jax (not ajax anymore) completes.  Make the browser do
the heavy lifting so scripts remain simple.

3) Loading long chains of on-demand content becomes unnecessarily complex.
Example: a config file that specifies URLs for column headers which specify
 URLs for content requires 3 nested .success handlers.  With async=false,
 one can simple write those sequentially.

4) Have it been considered if jQuery can create a work-around to simulate
async=false?  If not, do not deprecate, as there will be even more
browser-specific code splintering.

5) When data loads slowly, many sites will show a please wait
view anyway, which disables useful interactions, so how much value
does this deprecation add to usability?

6) Do you really want script writers to deal with scroll events while
an ajax is outstanding?  That seems to be beyond the ability of a plug-in
to handle in the general case. async=false really simplifies some tasks.

--Gregg Tracton, Chapel Hill, NC, USA






Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Florian Bösch

 I had an Android device, but now I have an iPhone. In addition to the
 popup problem, and the fake X on ads, the iPhone browsers (Safari,
 Chrome, Opera) will start to show a site, then they will lock up for 10-30
 seconds before finally becoming responsive.


Via. Ask Slashdot:
http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser

Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey
 2.27), synchronous requests on the main thread have been deprecated due to
 the negative effects to the user experience.



Via
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

Heads up! The XMLHttpRequest2 spec was recently changed to prohibit sending
 a synchronous request whenxhr.responseType is set. The idea behind the
 change is to help mitigate further usage of synchronous xhrs wherever
 possible.


Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs


Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Michaela Merz

I second Gregg's suggestion. It should be up to the developer to decide
whether he wants to block or not.


On 02/05/2015 08:58 PM, Gregg Tracton wrote:
 I disagree with deprecating synchronous XMLHttpRequest:

 1) it is not upward compatible  so can break numerous sites.
 Many websites do not have active development, and framework updates
 that fix this are even slower to roll out to web apps.  Many web
 app clients would much prefer a sub-optimal experience than a
 broken website.

 2) A better way to approach this might be to respect the async=false
 setting but have the browser move the script thread to another thread which
 is blocked until the jax (not ajax anymore) completes.  Make the browser do
 the heavy lifting so scripts remain simple.

 3) Loading long chains of on-demand content becomes unnecessarily complex.
 Example: a config file that specifies URLs for column headers which specify
  URLs for content requires 3 nested .success handlers.  With async=false,
  one can simple write those sequentially.

 4) Have it been considered if jQuery can create a work-around to simulate
 async=false?  If not, do not deprecate, as there will be even more
 browser-specific code splintering.

 5) When data loads slowly, many sites will show a please wait
 view anyway, which disables useful interactions, so how much value
 does this deprecation add to usability?

 6) Do you really want script writers to deal with scroll events while
 an ajax is outstanding?  That seems to be beyond the ability of a plug-in
 to handle in the general case. async=false really simplifies some tasks.

 --Gregg Tracton, Chapel Hill, NC, USA








Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Michaela Merz

Well .. may be some folks should take a deep breath and think what they
are doing. I am 'just' coding web services and too often I find myself
asking: Why did the guys think that this would make sense? Indexeddb is
such a case. It might be a clever design, but it's horrible from a
coders perspective.

Would it have been the end of the world to stick with some kind of
database language most coders already are familiar with? Same with (sand
boxed) file system access. Google went the right way with functions
trying to give us what we already knew: files, dirs, read, write,
append.  But that's water under the bridge.

I have learned to code my stuff in a way that I have to invest time and
work so that my users don't have to. This is IMHO a good approach.
Unfortunately - some people up the chain have a different approach.
Synchronous calls are bad. Get rid of them. Don't care if developers
have a need for it. Why bother. Our way or highway. Frankly - I find
that offensive.  If you believe that synchronous calls are too much of a
problem for the browser, find a way for the browser to deal with it.

Building browsers and adding functionality is not and end in itself. The
purpose is not to make cool stuff. We don't need people telling us what
we are allowed to do. Don't get me wrong: I really appreciate your work
and I am exited about what we can do in script nowadays. But please give
more thought to the folks coding web sites. We are already dealing with
a wide variety of problems: From browser incompatibilities, to
responsive designs, server side development, sql, memcached, php, script
- you name it. Try to make our life easier by keeping stuff simple and
understandable even for those, who don't have the appreciation or the
understanding what's going on under the hood of a browser.

Thanks.

Michaela




On 02/06/2015 09:54 AM, Florian Bösch wrote:

 I had an Android device, but now I have an iPhone. In addition to
the popup problem, and the fake X on ads, the iPhone browsers (Safari,
Chrome, Opera) will start to show a site, then they will lock up for
10-30 seconds before finally becoming responsive.


 Via. Ask Slashdot:
http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser

 Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
SeaMonkey 2.27), synchronous requests on the main thread have been
deprecated due to the negative effects to the user experience.


 
 Via
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

 Heads up! The XMLHttpRequest2 spec was recently changed to
prohibit sending a synchronous request whenxhr.responseType is set. The
idea behind the change is to help mitigate further usage of synchronous
xhrs wherever possible.


 Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs

 




Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread James M. Greene
Here is an additional past discussion of this topic:
   https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0232.html

Sincerely,
James Greene


On Fri, Feb 6, 2015 at 9:54 AM, Florian Bösch pya...@gmail.com wrote:

 I had an Android device, but now I have an iPhone. In addition to the
 popup problem, and the fake X on ads, the iPhone browsers (Safari,
 Chrome, Opera) will start to show a site, then they will lock up for 10-30
 seconds before finally becoming responsive.


 Via. Ask Slashdot:
 http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser

 Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
 SeaMonkey 2.27), synchronous requests on the main thread have been
 deprecated due to the negative effects to the user experience.



 Via
 https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

 Heads up! The XMLHttpRequest2 spec was recently changed to prohibit
 sending a synchronous request whenxhr.responseType is set. The idea behind
 the change is to help mitigate further usage of synchronous xhrs wherever
 possible.


 Via http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs





Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Ryosuke Niwa

 On Feb 6, 2015, at 9:27 AM, Michaela Merz michaela.m...@hermetos.com wrote:
 
 Well .. may be some folks should take a deep breath and think what they are 
 doing. I am 'just' coding web services and too often I find myself asking: 
 Why did the guys think that this would make sense? Indexeddb is such a case. 
 It might be a clever design, but it's horrible from a coders perspective. 
 
 Would it have been the end of the world to stick with some kind of database 
 language most coders already are familiar with? Same with (sand boxed) file 
 system access. Google went the right way with functions trying to give us 
 what we already knew: files, dirs, read, write, append.  But that's water 
 under the bridge.
 
 I have learned to code my stuff in a way that I have to invest time and work 
 so that my users don't have to. This is IMHO a good approach.

In that regard, I'm on the same boat.  I still write simple web apps in PHP 
with PostgreSQL instead of Scala/Ruby and a non-schema database today.  So I 
totally understand your sentiment.  However,

 Unfortunately - some people up the chain have a different approach. 
 Synchronous calls are bad. Get rid of them. Don't care if developers have a 
 need for it. Why bother. Our way or highway. Frankly - I find that offensive. 
  If you believe that synchronous calls are too much of a problem for the 
 browser, find a way for the browser to deal with it.

The problem isn't so much that it causes a problem for browser implementors but 
rather it results in poor user experience.  While a synchronous XHR is on the 
fly, user cannot interact with the page at all.  With some spinner, etc... UI 
indicating that the user has to wait, the user can at least still click on 
hyperlinks and so forth.

Since browser vendors (and I hope so are other participants of the working 
group) are interested in providing better user experience, we would like 
websites to use asynchronous XHR.

Having said that, don't worry.  Synchronous XHR isn't going away anytime soon.  
As long as real websites are using synchronous XHR, browser vendors aren't 
going to remove/unsupport it.

- R. Niwa




Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Marc Fawzi
I have several 8-track tapes from the early-to-mid 70s that I'm really fond
of. They are bigger than my iPod. Maybe I can build an adapter with
mechanical parts, magnetic reader and A/D convertor etc. But that's my job,
not Apple's job.

The point is, old technologies die all the time, and people who want to
hold on to old content and have it play on the latest player (browser) need
to either recode the content or build adapters/hosts/wrappers such that the
old content will think it's running in the old player.

As far as stuff we build today, we have several options for waiting until
ajax response comes back, and I'm not why we'd want to block everything
until it does. It sounds unreasonable. There are legitimate scenarios for
blocking the event loop but not when it comes to fetching data from a
server.





On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz michaela.m...@hermetos.com
wrote:


 Well .. may be some folks should take a deep breath and think what they
 are doing. I am 'just' coding web services and too often I find myself
 asking: Why did the guys think that this would make sense? Indexeddb is
 such a case. It might be a clever design, but it's horrible from a coders
 perspective.

 Would it have been the end of the world to stick with some kind of
 database language most coders already are familiar with? Same with (sand
 boxed) file system access. Google went the right way with functions trying
 to give us what we already knew: files, dirs, read, write, append.  But
 that's water under the bridge.

 I have learned to code my stuff in a way that I have to invest time and
 work so that my users don't have to. This is IMHO a good approach.
 Unfortunately - some people up the chain have a different approach.
 Synchronous calls are bad. Get rid of them. Don't care if developers have a
 need for it. Why bother. Our way or highway. Frankly - I find that
 offensive.  If you believe that synchronous calls are too much of a problem
 for the browser, find a way for the browser to deal with it.

 Building browsers and adding functionality is not and end in itself. The
 purpose is not to make cool stuff. We don't need people telling us what we
 are allowed to do. Don't get me wrong: I really appreciate your work and I
 am exited about what we can do in script nowadays. But please give more
 thought to the folks coding web sites. We are already dealing with a wide
 variety of problems: From browser incompatibilities, to responsive designs,
 server side development, sql, memcached, php, script - you name it. Try to
 make our life easier by keeping stuff simple and understandable even for
 those, who don't have the appreciation or the understanding what's going on
 under the hood of a browser.

 Thanks.

 Michaela





 On 02/06/2015 09:54 AM, Florian Bösch wrote:
 
  I had an Android device, but now I have an iPhone. In addition to
 the popup problem, and the fake X on ads, the iPhone browsers (Safari,
 Chrome, Opera) will start to show a site, then they will lock up for 10-30
 seconds before finally becoming responsive.
 
 
  Via. Ask Slashdot:
 http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser
 
  Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
 SeaMonkey 2.27), synchronous requests on the main thread have been
 deprecated due to the negative effects to the user experience.
 
 
 
  Via
 https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
 
  Heads up! The XMLHttpRequest2 spec was recently changed to prohibit
 sending a synchronous request whenxhr.responseType is set. The idea behind
 the change is to help mitigate further usage of synchronous xhrs wherever
 possible.
 
 
  Via
 http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
 
 





Re: do not deprecate synchronous XMLHttpRequest

2015-02-06 Thread Michaela Merz
Well yeah. But the manufacturer of your audio equipment doesn't come
into your home to yank the player out of your setup. But that's not
really the issue here. We're talking about technology that is being
developed so that people like me can build good content. As long as
there are a lot of people out there using synchronous calls, it would be
the job of the browser development community to find a way to make such
calls less harmful.

Michaela


On 02/06/2015 12:28 PM, Marc Fawzi wrote:
 I have several 8-track tapes from the early-to-mid 70s that I'm really
 fond of. They are bigger than my iPod. Maybe I can build an adapter
 with mechanical parts, magnetic reader and A/D convertor etc. But
 that's my job, not Apple's job.

 The point is, old technologies die all the time, and people who want
 to hold on to old content and have it play on the latest player
 (browser) need to either recode the content or build
 adapters/hosts/wrappers such that the old content will think it's
 running in the old player.  

 As far as stuff we build today, we have several options for waiting
 until ajax response comes back, and I'm not why we'd want to block
 everything until it does. It sounds unreasonable. There are legitimate
 scenarios for blocking the event loop but not when it comes to
 fetching data from a server. 





 On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz
 michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote:


 Well .. may be some folks should take a deep breath and think what
 they are doing. I am 'just' coding web services and too often I
 find myself asking: Why did the guys think that this would make
 sense? Indexeddb is such a case. It might be a clever design, but
 it's horrible from a coders perspective.

 Would it have been the end of the world to stick with some kind of
 database language most coders already are familiar with? Same with
 (sand boxed) file system access. Google went the right way with
 functions trying to give us what we already knew: files, dirs,
 read, write, append.  But that's water under the bridge.

 I have learned to code my stuff in a way that I have to invest
 time and work so that my users don't have to. This is IMHO a good
 approach. Unfortunately - some people up the chain have a
 different approach. Synchronous calls are bad. Get rid of them.
 Don't care if developers have a need for it. Why bother. Our way
 or highway. Frankly - I find that offensive.  If you believe that
 synchronous calls are too much of a problem for the browser, find
 a way for the browser to deal with it.

 Building browsers and adding functionality is not and end in
 itself. The purpose is not to make cool stuff. We don't need
 people telling us what we are allowed to do. Don't get me wrong: I
 really appreciate your work and I am exited about what we can do
 in script nowadays. But please give more thought to the folks
 coding web sites. We are already dealing with a wide variety of
 problems: From browser incompatibilities, to responsive designs,
 server side development, sql, memcached, php, script - you name
 it. Try to make our life easier by keeping stuff simple and
 understandable even for those, who don't have the appreciation or
 the understanding what's going on under the hood of a browser.

 Thanks.

 Michaela





 On 02/06/2015 09:54 AM, Florian Bösch wrote:
 
  I had an Android device, but now I have an iPhone. In
 addition to the popup problem, and the fake X on ads, the iPhone
 browsers (Safari, Chrome, Opera) will start to show a site, then
 they will lock up for 10-30 seconds before finally becoming
 responsive.
 
 
  Via. Ask Slashdot:
 
 http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser
 
  Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird
 30.0 / SeaMonkey 2.27), synchronous requests on the main thread
 have been deprecated due to the negative effects to the user
 experience.
 
 
  
  Via
 
 https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
 
  Heads up! The XMLHttpRequest2 spec was recently changed to
 prohibit sending a synchronous request whenxhr.responseType is
 set. The idea behind the change is to help mitigate further usage
 of synchronous xhrs wherever possible.
 
 
  Via
 http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs