What's new in Firefox 3.5
developer.mozilla.org
developer.mozilla.org
+ Mibbit as default IRC:// link handler
It's such a painfull experience. It'll be the beginning of the end of Flash, which makes me happy.
Moz: https://developer.mozilla.org/En/Using_web_workers WHATWG: http://www.whatwg.org/specs/web-workers/current-work/
If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane.
It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.
"What operations 'block' in js?"
Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0).
(Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
Yeah I much prefer that method personally.
Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.
http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre...
'''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''
"I think message passing shared nothing beats shared memory preemptively scheduled threads."
So Web Workers are an implementation of his preferred solution.
"The String object now has trim(), trimLeft(), and trimRight() methods."
You know, it's a little thing, and easy to implement yourself, but I'm still glad this finally got added.
FYI, in IE8, typing "hac" in the url bar sends you to a google search on "hac". In Safari, you end up at http://hac.com.
I still kinda do.
As far as I know, there is no official plan to remove the "awesome bar".
Also, I can't until Ubiquity becomes standard. There's a disappointing lack of plugins for it at the moment, and standardization will really help that. :)
This turns all completion off though, even URL prefix matching (as opposed to the awesomebar 'anywhere in the URL/page title matching'), which I'm guessing you don't want. There are some entries in about:config (browser.urlbar.match*) that might make it do what you want.
Safari 4 does some subset of the super-matching thing too now; I find it kind of a mixed bag (I end up autocompleting to HN/twitter way too often) but am slightly on the side of it being helpful, although more intentional history search would probably work just as well.