Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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]
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
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
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
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
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
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
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.
Re: do not deprecate synchronous XMLHttpRequest
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
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
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
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
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
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
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
