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
[Bug 27994] New: [Shadow]: Distribution result usage examples
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27994 Bug ID: 27994 Summary: [Shadow]: Distribution result usage examples Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 If any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result. It seems both layout and events make use of the distribution result. That would be worth mentioning I think to make it clear what the observable bits are. However, if events make use of them, wouldn't we be able to work out when distribution happens by firing synthetic events? And how does this work for ranges that can reach into the shadow DOM? Wouldn't we get problems there too with how deterministic things are? -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents]: Let's reach consensus on Shadow DOM
On Sat, Feb 7, 2015 at 12:25 AM, Dimitri Glazkov dglaz...@google.com wrote: So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits This is really great Dimitri, thanks. All the pointers to past discussion help a lot as well. When we discussed shadow DOM at Mozilla at the end of last year, this was roughly our thinking for the various points listed: A) Having shadow inheritance would be useful and is actually something we use in Firefox UI (through XBL). B) We would prefer encapsulation by default. C) We would like to come up with a distribution API. (I need to grasp the distribution algorithm a bit better. It's still a bit unclear to me why we can do it lazily while everything else in DOM is live.) D) We would like these to be separated. E) When we discussed this there were no clear thoughts on styling. There was interest for having some kind of way to style the component while letting the component retain control over what the outside can actually affect. Possibly through CSS variables or some way to restrict what properties apply. My personal worry with shadow DOM is that frameworks such as React and perhaps also Ember now are going in quite a different direction. Perhaps a bit more hostile towards DOM, but with server-side rendering not necessarily more hostile towards users. So while we solve a problem some developers have today, it's not necessarily clear this is how pages will be written going forward. -- https://annevankesteren.nl/
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
[DOM3Events/UIEvents] Minutes from 10 Feb 2015 teleconference
Contents * Topicshttp://www.w3.org/2015/02/11-webapps-minutes.html#agenda * Bug 27991http://www.w3.org/2015/02/11-webapps-minutes.html#item01 * Bug 27990http://www.w3.org/2015/02/11-webapps-minutes.html#item02 * Summary of Action Itemshttp://www.w3.org/2015/02/11-webapps-minutes.html#ActionSummary masayuki: Hi! scribe Scribe: Travis scribe ScribeNick: Travis Any topics for today? masayuki I'm trouble in bug 27991 and bug 27990 masayuki https://www.w3.org/Bugs/Public/show_bug.cgi?id=27991 masayuki https://www.w3.org/Bugs/Public/show_bug.cgi?id=27990 We can look at those. Any other topics? I've been working on a fix for 26019 :-) Should have it checked in tomorrow. masayuki Travis: Sounds great! Gary is getting his head in the game. (Still sore at the recent Seahawks loss, I'm sure.) masayuki Ah, I have a news. Gecko will support .code in release build starting 38. garykac Yay! Great! garykac I realize that I need to update the specs for the rename - UIEvents and then ping the powers that be to have them redirect the short URLs as appropriate masayuki (38 will ship May, 2015) garykac We're working on getting 'code' exposed as well. I don't recall the release schedule, though. OK. Gary and I have some updates to finish from last telco which we should be able to do this week. Let's take a look at those bugs masayuki reference earlier. Bug 27991 garykac For 27991 garykac I *think* that Numpad makes more sense (because of the arrangement of the keys) garykac But NumLock is not present, so I don't think that hacking NumLock to be true makes sense masayuki Okay, so, if they input [0-9], NumLock should be hacked, otherwise, shouldn't be hacked? garykac For 27990, my initial thought is NumpadAsterisk and NumpadHash garykac masayuki: I don't think we should set NumLock at all for these keys. I commented in the bug--I suggested Digit for the horizontal layout. scribe: I'd expect more common code would look for digits, rather than numpad keys. masayuki Wow, is there horizontal layout? garykac The 'Digit*' keys are the one that have punct in their shifted state (US layout). They do not produce digits for some other layouts (like French), so the Digit codes don't seem appropriate for the phone numpad keys. garykac masayuki: horizontal as opposed to in a 2d grid garykac masayuki: 1d (horizontal row) vs. 2d (3x4 grid) masayuki garykac: Thanks, I've never seen 1d in Japan. masayuki I still have no idea which is better... (Numpad* vs. Digit*) garykac I'm adding a comment to the bug. garykac I don't think that Digit is appropriate for Phone keypads. I think it's mostly arbitrary, but we should recommend one or the other. Digit works for me. scribe: but I could go with either. ... but not both :-) If we do Numpad*, then bug 27990 is easier to resolve. scribe: code of Digit3 doesn't conflict with code of NumpadHash ... or we could have the numbers be Numpad*, and just reuse Digit3 for the code of #. masayuki I think there are two scenarios one is some developers use scancode which is used by PC keyboard, the other is some developers use scancode which is NOT used by PC keyboard. garykac masayuki: Phone keypads in the US have '#' and '*', but is that universal? masayuki For the former, Digit3 and Digit8 may make sense. For the latter, NumpadHash and NumpadAsterisk may be good values. masayuki gacykac: I'm not sure, but Japanese phones have them and in some countries, they are. masayuki https://www.google.co.jp/search?q=phone%201d%20layoutoe=utf-8gws_rd=crum=1ie=UTF-8hl=jatbm=ischsource=ogsa=Ntab=wiei=Wq_aVJHJM5fz8gXAwIHgAg#um=1hl=jatbm=ischq=featurephone+buttonsimgdii=_ Bug 27990 garykac I think that NumpadAsterisk and Hash make the most sense for phones in all cases. If you hook up your phone to a PC, I would still expect to see the Numpad values. garykac Digit3 and Digit8 just happen to match (shifted) the # and *, but that's only for the US locale and that seems very arbitrary. masayuki garykac: yeah, but there might be no unused scancode. garykac masayuki: thanks for the link. The '#' and '*' keys seem pretty universal. garykac masayuki: unused scancode? why does that matter? masayuki garykac: If so, vendors might map scancode which are used by PC keyboard. Then, browsers cannot distinguish the key event comes from the keys on feature phone or connected PC keyboard. masayuki Ah, but it could be solved with virtual keycode values if the platform has specific keycode values for them. masayuki Anyway, I'd like you to add featurephone section into D3E KeyboardEvent code spec. garykac masayuki: we could expand the Numpad section to include a feature phone keypad. Since the other keypad values are there, it seems like a good place for that info to live. garykac masayuki: File a bug for me to add a section for that. masayuki garykac: Okay! garykac That's probably about it for today...
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
