Fwd: Please foward this to whoever was responsible for this:

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