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 wrote: > Hang on a sec before going off to a private or single-vendor thread > because you thin

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

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

ht 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,

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

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 XMLHttpReques

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 to

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/

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

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 contr

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

On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi 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

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 withou

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

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

On Thu, Feb 12, 2015 at 1: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 Yup. > this has worked so far, miraculo

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

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

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 gr

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

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

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

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

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

Re: do not deprecate synchronous XMLHttpRequest

Sent from my iPhone > On Feb 10, 2015, at 5:44 PM, Brendan Eich 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

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 loc

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 t

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

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 > 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

Re: do not deprecate synchronous XMLHttpRequest

On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi 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

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 reason

Re: do not deprecate synchronous XMLHttpRequest

On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz 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.

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

Re: do not deprecate synchronous XMLHttpRequest

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 discussio

Re: do not deprecate synchronous XMLHttpRequest

Marc: Its not about getting rid of badly designed APIs. It's about the feeling of not being taken seriously. 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 wh

Re: do not deprecate synchronous XMLHttpRequest

<< Reminds me on the days when Microsoft was trying to tell me what's good and what's not good. >> At least Microsoft didn't put a backdoor in Windows that can divulge your local IP (within a LAN) to the outside world. They call it WebRTC. If you want something to complain about there are far more

Re: do not deprecate synchronous XMLHttpRequest

Interesting notion. Thanks for sharing. Reminds me on the days when Microsoft was trying to tell me what's good and what's not good. m. On 02/10/2015 12:10 PM, Florian Bösch wrote: > On Tue, Feb 10, 2015 at 4:24 PM, Glenn Adams > wrote: > > Morality should not be leg

Re: do not deprecate synchronous XMLHttpRequest

On Tue, Feb 10, 2015 at 4:24 PM, Glenn Adams wrote: > Morality should not be legislated! > Browser vendors can (and do) do whatever they please. You're free to start your own browser and try getting it among the people. Legislation doesn't enter the picture, you have free choice in every respect

Re: do not deprecate synchronous XMLHttpRequest

pseudo code: var xhr = $.ajax blah blah async var done = false xhr.readyState = function(state) { if (stateIsDone) done = true} while (!done) { doNothing() } something like that? super bad On Tue, Feb 10, 2015 at 9:51 AM, Marc Fawzi wrote: > If readyState is async then have set a variable

Re: do not deprecate synchronous XMLHttpRequest

On Tuesday, February 10, 2015, Marc Fawzi 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

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 wrote: > > > On Tuesday, February 10, 2015, Marc Fawzi wrote: > >> Here is a really bad idea: >> >>

Re: do not deprecate synchronous XMLHttpRequest

On Tuesday, February 10, 2015, 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 This won't work, state changes are asyn

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 g

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 > wrote: > > Ashley, > > Isn't it for the app dev team — rather tha

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

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 wrote: > > No argument in rega

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 i

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 rem

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 shou

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 does

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 case

Re: Violation of mail list policy [Was: Fwd: Re: do not deprecate synchronous XMLHttpRequest]

I do apologize for the unfortunate selection of some words in this posting. It was not my intention to attack, to insult or to offend anybody. Michaela On 02/09/2015 12:53 PM, Arthur Barstow wrote: > Michaela, > > Some of the language you used in [1] is offensive. Per the group's mail list etiq

Violation of mail list policy [Was: Fwd: Re: do not deprecate synchronous XMLHttpRequest]

Michaela, Some of the language you used in [1] is offensive. Per the group's mail list etiquette policy ([2]), please do not use such language on WebApps' mail lists. -Regards, AB [1] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0538.html [2] https://www.w3.org/2008/webapp

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

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,

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

Re: do not deprecate synchronous XMLHttpRequest

On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz 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 servic

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

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 w

Re: do not deprecate synchronous XMLHttpRequest

> On Feb 6, 2015, at 9:27 AM, Michaela Merz 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 m

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 perspecti

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 wrote: > I had an Android device, but now I have an iPhone. In addition to the >> popup pro

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

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 no

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 exp