- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 6 Aug 2015 15:00:33 +0200
- To: www-archive <www-archive@w3.org>
Maybe www-archive feels responsible. ---------- Forwarded message ---------- From: Joshua Donnelly <joshuadonnelly@gmail.com> Date: Thu, Aug 6, 2015 at 2:30 PM Subject: Please foward this to whoever was responsible for this: Please foward this to whoever was responsible for this: "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/." the removal of that long standing feature is having a detrimental and hellish effect on my Desktop browser based App. I have some variables i wish to retrieve in a browser based App the data is somewhere between 0 and 1ms away right there on the local disk... ms=Date.now(); data=j.o('A.5.in|get|l'); Date.now()-ms //returns after a 0 or 1 millisecond delay i am quite happy to wait the 1 millisecond for the data to arrive!! since the data will be needed for the next step, i choose to wait and block, that is my desired use case, because it gives far greater simplicity for using and consuming data we have been able to do this for years, by doing something as straightforward as: xhr=new XMLHttpRequest(); xhr.open('GET','../../../../2/A/Ax/5/_/in',false); xhr.responseText but now that some busy body wish to take back, reject, and break 15+ years of being able to read text out of a file directly i don't want to make every variable into a function. The thing is i thought that was only deprecated?? the thing is, it flat out doesn't work anymore!!! so congratulations on all the "good" work (so, now when i browse the web there will be no more "detrimental effects" to my user experience"?? lol). When the majority of task based programming (50-60 years of history) is synchronous, there should be a way to simply Get/Set values without having to descend into callback hell. """Asynchronous JavaScript APIs can be tough to use. They're large. They're complex. But what's most frustrating is that they offer plenty of opportunities for things to go wrong. The last thing you want to deal with is layering on a complex asynchronous API (FileSystem) in an already asynchronous world (Workers)! ~ http://www.html5rocks.com/en/tutorials/file/filesystem-sync/ """ an API that allows this has been part of the web and the web framework for MANY years and extends to MILLIONS of pages and MANY people who have spend MILLIONS of hours coding apps to work with these STANDARDS the idea that once given such simple functionality (the ability to simply get some data directly, for immediate inline use) taking that away is egregious, offensive, and a very stupid limitation (something basic has been lost, with no better replacement), it breaks not only lots of code, but also the social contract API makers have established with all the people who have been working with XMLHttpRequest for years. And for the reason given... "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/." ...makes me think the people responsible for such a decision are petty, pedantic irresponsible "superior thinking" fascist, nazi, bastard, indian giving, idiot scum with the utmost disdain and mistrust of everyone using their STANDARDS (like my standards are better than your standards) and we know best!! and you know nothing and we will put child locks on all the doors even though it is a fire hazard. It's anti freedom, and anti choice, and totally ignores the few cases where such a feature could be very useful. Removing something like true/false for the async flag will do nothing to improve UX, because in many ways the web was built and won, and is in fact composed of LOTS and LOTS of bad end user experience -- that's what made it and makes i wonderful. What will you do next? delete all the web pages that in YOUR opinion offer a bad UX? People will avoid blocking, and then quite often freeze or up the entire UI, by graying out the entire page to offer up a Modal Dialog box!!! We see that many times all over the web, which is a fair enough, and popular use case. But the thing is it should be up to the designer to muck up the UX/UI however they want. But if you muck around with what was previously offfered and available, flip/flopping on what is allowable, then we will hate and distrust anything you offer now and in the future. Rather than just letting good practices be rise to the top, and become popular, for their obvious merits as surfaced and experienced by end users, you have chosen to get prescriptive about disallowing what you consider "detrimental", and spit in the face of 60 years worth of synchronous programming. I for one KNOW that asynchronous programming is very "detrimental" in terms of getting things done, directly and in order (the judicious use of async is fine, but going to far into, or 100% into "asynchronous programming" horrible nesting with anything happening at any time, in random, unpredictable order with no escape hatch, is insane!!! it takes FIVE times as long to write such code, and for any sizable task, if you put a pin at random somewhere in the source code it would be very hard to explain or determine what it is doing, it's a floaty detached mind f**k, and to say that people MUST do THEIR data and THEIR APP like that is a repulsive, arrogant misuse of whatever power or intelligence you think you have. What gives you the right to DICTATE how EVERYONE structures their Apps? Not everyone is running with lots of network lag, synchronous code is far easier to write, and app makers are end users too. Why destroy choice? You have taken something that was simple and straight forward and made it impossible complex and convoluted. Across the web many people will express their hatred and distaste for such a selfish and idiotic decision, in this case it would have been far better to do nothing (they got it right the first time!!) and who are you to say they did not? Many people will disagree... """ Michaela Merz | 6 Feb 15:53 2015 do not deprecate synchronous XMLHttpRequest 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. "I second Gregg's suggestion. It should be up to the developer to decide whether he wants to block or not." ~ Michaela Merz | 6 Feb 15:53 2015 http://comments.gmane.org/gmane.org.w3c.webapps/18413 """ Douglas Crockford has likened doing changes like the ones you and your ilk imposed, as being like a physical assault, like cutting people with knives -- where does that get useful or wise? Please stop what you are doing (for reasons that aren't even reasons at all) such a retraction of such a basic bit of functionality is idiotic and disguising in the extreme. Did you take a vote? That little thing wasn't broken, it was entirely opt-in, opt-out, what you have done is taken a big step to making it entirely unavailable (the ability to get a bit of data simply and directly, without forcing people to swallow the nightmare that quite often in asynchronous coding, aka callback hell, it is real, and many times the alternative is a far superior quicker and wiser way to go) >From someone who knows callbacks/async/JS programming better than most... "callbacks suck" ~tjholowaychuk, yes they do!! so why have that as the ONLY way to go? """ https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b you may get duplicate callbacks you may not get a callback at all (lost in limbo) you may get out-of-band errors emitters may get multiple “error” events missing “error” events sends everything to hell often unsure what requires “error” handlers “error” handlers are very verbose callbacks suck """ Why not async where appropriate and sync where appropriate or needed? Why undo what was already there? (for the most part the web was/is a huge success WITH that part included!!!) Why force things the one way? async has already been forced into 99% of html nooks and crannies Why not leave some escape hatch for the other (simpler) paradigm to have some play? I can wait 20ms for the file to arrive, one way or another I will wait for it. (the result depends on it -- i can do nothing without it) i don't want every variable to be a function Not all web Apps deal with excessive amounts of network lag. I would think that laggy apps are punishment enough. Why should we have to deal with your well meaning efforts to seal up all the exits? Typical fascist, standards based, ridiculousness, from up in your ivory tower ~ "we'll do them a favor by forcing it on them" because we know best!!! What gives? It's like a war on drugs, so at some point all the "detrimental effects to the end user's experience" will be eradicated, due to your brilliant decisions. At what point will that be? (never) Crappy UX will be there forever, there are 1001 ways to engage it, and new ones being added every day, it will not be eradicated, it is personal choice, because some prefer it that way, varying tastes etc, there's no right or wrong. How many lines of existing code are you instructing browser makers to break? If YOU have drunk the cool-aid on async hell -- Why insist that everyone else does? Welcome to Jone's Town and Web 3.0 "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help please procced to the pavillion at http://xhr.spec.whatwg.org/ and drink drink, it's just a little bitter tasting, they're not crying out of any pain..." Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the JavaScript global environment is a document environment. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs. is that basically saying that one cannot do synchronous data access from the browser? i think that is a huge loss, because one long standing or complete paradigm of programming has been obliterated. nice one http://stackoverflow.com/questions/15532546/getting-a-return-value-back-from-a-web-worker so a whole bunch of people voted for this, no members of the public will thank you for it (but my hate and that of many others will be forever), maybe at some point, as hybrid Desktop browser based Apps become more popular, people may wish for simpler times with a simple way to get a bit of data directly, and some people may remember we had that for years and then some people thought it was a "good idea" to do away with it.
Received on Thursday, 6 August 2015 13:01:02 UTC