alunny

Agreed - I'd definitely like to see something like JSFiddle for PhoneGap. We're working on weinre right now - http://phonegap.github.com/weinre/ - and also recommend Aardowlf - https://github.com/lexandera/Aardwolf - and Ripple - http://ripple.tinyhippos.com/

re only affecting emulators: see @pmuellr's reply below - the bug in question affects 2.2 devices also. Since we're a community-driven open source project, you can see the discussion process :) http://groups.google.com/group/phonegap-dev/browse_thread/th...

Again, "such significant performance gains for our users" is just FUD when you're talking about arbitrary benchmarks. An app built using Forge and PhoneGap, providing the same functionality, with the same UI layer, would be a much better measure of that. I'd be happy to be proven wrong.

(disclaimer: I work for Adobe on a competing service (PhoneGap Build) and have worked with PhoneGap for years)

This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once.

The bridge in PhoneGap Android probably is slower than the one in Forge but

1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release.

2) synthetic benchmarks aside, there's no indication this would affect the usability of the app.

Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip.

With PhoneGap: * first half of the trip (7ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively) * second half of the trip (7ms) = 514ms

With Forge: * first half of the trip (1.5ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (500ms) * second half of the trip (1.5ms) = 503ms

This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.

Node itself (the core js library) isn't strict mode compliant: it uses octal literals for filesystem interactions.

As I understand it, the main objection to `__proto__` is that it's writable, and thus not atomic with object creation. This creates a bunch of headaches for implementors for performance and security.

More knowledgable people than myself discuss it on this es-discuss thread: http://www.mail-archive.com/es-discuss@mozilla.org/msg06142....

There is a Harmony proposal for a "set prototype of operator" that would solve this problem; instead of writing:

    var newObj = {__proto__: OldObject, id: 5}

You would write:

    var newObj = OldObject <| { id: 5 }

Detailed here: http://wiki.ecmascript.org/doku.php?id=harmony:proto_operato...

For very short, "oh there's a syntax error I missed" commits, "commit --amend" is very useful, and quicker than "rebase -i".

Interesting - looks like chart.googleapis.com works over HTTPS: https://chart.googleapis.com/chart?chs=150x150&cht=qr...

but chart.apis.google.com (which Google formerly used) does not: https://chart.apis.google.com/chart?chs=150x150&cht=qr&#...

Turns out I was looking at some outdated docs. Thanks!

The Google charts API doesn't provide an SSL interface - if you use it on a page served over https, you'll get a mixed content warning.

[EDIT] I was mistaken, see andrewjshults's reply.

The Underscore functions do exactly the same as Resig's in the simple case (when passed just an array of numbers). They're longer because they accept custom iterators for non-numerical arrays.

Well yes, but if you have 20+ tabs open in a couple of windows, it's disruptive and time consuming to close and reopen all of them.

releasing the source != pushing out over the air OS updates

It's a sixty line JS file that's been online for less than a day. I don't think API stability is a major concern at this point.

camelCase is the de facto standard for JavaScript - all of the DOM APIs and major libraries use it.

edit: oh, you probably mean the language name. Again, JavaScript is the correct formatting, even if it looks silly to most eyes.

There are also Fab.js http://github.com/jed/fab (which hasn't seen any updates in a while, but I'm sure it's still being worked on), Pintura http://github.com/kriszyp/pintura and Picard http://github.com/dantebronto/picard

At a lower level of abstractions are the middleware layers Connect http://github.com/extjs/Connect and JSGI http://github.com/kriszyp/jsgi-node

The core of Node has very few functions that perform I/O, but there's no reason you can't use I/O in your own programs (in the original link, the network stream is read and written out, and also the blacklist file is read, synchronously). The readFileSync call is an anomaly in Node - typically you use evented I/O - open a stream and set listeners/callbacks for particular events.

There are modules developed for most of the major open source databases (I'm not sure what the status of the async MySQL driver is, but there's definitely something you can use).

I've believe it's because SVG support is still listed as experimental in WebKit; there are 258 SVG bugs listed on WebKit's Bugzilla: https://bugs.webkit.org/buglist.cgi?product=WebKit&compo...

No it's not - unlike iPhone, Android WebKit does not have SVG support.

> "Are you that great?". No, apparently he's not.

That's not really fair - there are plenty of very good motivations for writing (and reading) fiction other than immersion in a sustained imaginative world. By that criterion, "Avatar" is a better film than than, say, "Casablanca," because James Cameron knows more about the flora of Pandora than Michael Curtiz does about Morocco.

Adams is a great writer precisely because of his lack of pretension, his humility, and his irreverence -- I'd be disappointed if he didn't regard his own work with the same outlook he had for everything else.

it's because of type conversion - null has the same value as 0 (as in `(+ null)`), so it is a number

Regarding PhoneGap specifically, which the book seems geared toward, for a short period of time Apple believed, erroneously, that the iPhone PhoneGap code was exposing unapproved APIs to developers, and were rejecting apps that used the platform. At that time, I think some devs were obfuscating PhoneGap and submitting the same apps, which were approved, so even then Apple were not objecting to anything actually in the iPhone PhoneGap code.

Apple have been in touch with PhoneGap devs since and clarified the matter; there's a good blog post here regarding that: http://nachbaur.com/blog/updates-on-apple-phonegap

Since then Apple have had a much more informed stance towards PhoneGap and have approved lots of apps using the framework (there's a list on the PhoneGap site).

*full disclosure - I work for Nitobi, who sponsor PhoneGap's development. Though the original link suggests using PhoneGap in its preface, there are competing platforms, such as Rhodes and Appcelerator, that also get through to the App Store.