In my experiments, canvas performance on iOS devices is horrible, and especially with Phonegap... it takes from 100..200 ms to draw a single frame, crazy... Try opening iPad http://funwithhtml5.com/source/reportCanvasBug.html and try to rotate iPad and see how from 1..2 ms per frame it goes to 200ms per frame.
I am playing right now with Ejecta which translates JavaScript to ObjectiveC, and then I get a very good speed, no matter how I rotate the screen.
Looks like it has some good info, but you need a copy editor. If I'm going to shell out $30 for a book, I don't want to see typos and strange run-on sentences. Those sorts of things make the book much harder to read.
For example, take your home page:
"You’re interested in making games or other interactive HTML5 apps, but you don’t quite know were to start and what you will need to accomplish that."
I have to agree, you could find a English copywriter fairly easy to do a quick read over.
For example...
The canvas is a native HTML-element that can be used to draw and alternate images and render its output to an HTML document. Drawing-methods can be accessed directly through the context of the canvas, however EaselJS will add a layer of abstraction to the canvas by automatically handling all drawing calls so that all you have to do is placing the images and calling stage.update().
"so that all you have to do is >placing< the images"
"that can be used to draw and >alternate< images >and< render its output"
(missing comma, run on sentence, alternate is probably the wrong word, I'd use change or replace.)
"The Stage is >so to say< the bottom-most container."
That doesn't make any sense to me, I'm Canadian so maybe it is a saying elsewhere but I've never heard "is so to say".
Okay, yes I can see why that could be an issue - I will look into getting a copywriter - do you have any experience/suggestions for that, what is a reasonable price?
has anyone had success with an html5 game on ios? it seems viable for android (v8 yay!), but i haven't been satisfied at all with javascript performance on iOS. maybe for something that's turn-based and doesn't require slick transitions?
(edit: this sounds a little negative... what i mean is, pointing to a really slick html5 game on the app store would make selling the book a lot easier)
Biolab Disaster (http://playbiolab.com/) has a great iOS port which has excellent performance on my iphone 4S. Its only a prototype though but people really seemed to like it. The engine they developed also has some clever appstore bundling tech which improves JS performance alot as it looks.
Depends on how you define success. My game Orbium made reasonably well on iOS.
HTML5 game development on Android is a performance nighmare. Even if it was true that v8 was used in Android Browser or Android WebView (it isnt), it doesnt matter, it is the horrible draw performance that is the bottleneck (both canvas and css translate3d).
Native performance is wrong, javascript (unless it's like asm.js or something) will never be "native performance".
All CocoonJS is, is just a OpenGL layer with html/css/javascript support. And while it is faster then just flat out using JSC. It is not faster then c/objective c + opengl.
There have also been several reports of CocoonJS actually being slower then UIWebView. A simple google search for "cocoonjs performance" returned several issues.
That is not entirely correct - UIWebView canvas rendering is far behind OpenGL layers like CocoonJS, Ejecta or directCanvas(AppMobi) in terms of performance - the difference however is, that those tools are able to ONLY render canvas-contents, so you are not really able to render any HTML5 forms, input ect... but that's not what canvas-games are about.
It still uses Javascript. Native OpenGL+ObjC/C (done correct) will always be faster. All it really is, is better performance then UIWebView as it doesn't have all the webcore/kit stuff.
ALl I'm getting at is saying "native performance" is not correct. In a world where even 2-3 FPS can mean a usable game or a not usable game. I think the terminology matters a lot.
But you should still recommend people to using those solutions, just don't pass them off as something they are not.
I'm guessing this book is more about the process than the actual coding aspect, given its length (129 pages)? Though I do like the prototype and the fact that the OP came from AS3/Flash into this, which hopefully provides some interesting perspective.
I am playing right now with Ejecta which translates JavaScript to ObjectiveC, and then I get a very good speed, no matter how I rotate the screen.