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

[DOM3Events/UIEvents] Minutes from 10 Feb 2015 teleconference

Contents * Topics * Bug 27991 * Bug 27990 * Summary of Action Items

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

[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: n

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: [webcomponents]: Let's reach consensus on Shadow DOM

On Sat, Feb 7, 2015 at 12:25 AM, Dimitri Glazkov 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 discu

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