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 bren...@secure.meer.net
wrote:
Hang on a sec before going off to a private or single-vendor
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*
://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
XMLHttpRequest
On 2/11/15 3:04 PM, Brendan
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
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
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 without
On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com 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
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/
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
top
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 control
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 own
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
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
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
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
On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi marc.fa...@gmail.com 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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com
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
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
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
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
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:
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 not
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
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 pya...@gmail.com wrote:
I had an Android device, but now I have an iPhone. In addition to
On Feb 6, 2015, at 9:27 AM, Michaela Merz michaela.m...@hermetos.com 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
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
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
53 matches
Mail list logo
