Post about speed of Javascript on mobile

Of course this also applies to C2

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Overall, very informative. I wonder how things like CocoonJS and node-webkit factor into this.

I don't think this article is relevant to C2.

Ashley has documented many times through blog articles how C2 helps make HTML5 work, how he handled low garbage real time execution, published several benchmarks and performances comparison tests (that date from last year) and how webGL boosts the performances of games even on mobiles.

I haven't read all the article you've linked, but it just sounds like it's not talking about what C2 and cocoonJS really do.

You're not having a browser executing your JS code when exporting through cocoonJS, you're having some native application.

And even if it is "slower" as other apps, the recent cocoonJS 1.4 deals a solid 60 fps on most android devices (awaiting for Apple's approval on iOS) and that's what mostly matters as far as games go. (Also taking into account the recent addition/modification of 2DBox physics specifically for mobile through cocoonJS which should allow for proper physics handling which, so far, could be a bit of a bottleneck in mobile CPU performances).

Node-webkit exports as binary to desktop and so has about the same performances as chrome on desktop, so no issue/relevance there either.

I do believe it is relevant but I would agree that it is not maybe that crucial in our C2 context and the type of apps it produces.

Allow me elaborate.

Behind all the fancy names and frameworks, the code being executed it's always Javascript. And this article mainly speaks about performance of Javascript software in mobiles.

Now, I'm not quite familiar on how CocoonJS works (thus my original question) but if it's anything similar to node-webkit then it is some sort of "reimplementation" of a good browser in native code (as in the example that you give where node-webkit simulates a Chrome-like browser for desktops). There maybe even some parts of it rewritten in native code to speed things up and boosts to rendering like WebGL also improve the situation greatly...but in the end it still boils down to Javascript code so it really should be relevant to C2 (unless I am terribly wrong about something).

But I do agree that the article seems more focused on high-performace apps like photo editing, so for our scope (small 2d games) we should still see good framecounts, etc.

Nevertheless, I do believe that the article is still relevant for adjusting the "upper bounds" of our future expectations on improved performance and by linking it I wanted to show this reference to others and maybe discuss different opinions about it.

Sorry if it came out as the regular "performance complain" post that we are used to see emerge every now and then, that was not my intention at all.

I haven't read all the article you've linked, but it just sounds like it's not talking about what C2 and cocoonJS really do.

You're not having a browser executing your JS code when exporting through cocoonJS, you're having some native application.

It's a native application, but it's still interpreting JavaScript as far as I understand it. In a test I did a while ago, I seem to recall cocoonjs being less than half the speed at running code than safari on iOS, so being a native app isn't helping it there (I haven't tried the new 1.4 version though, maybe it's improved).

And even if it is "slower" as other apps, the recent cocoonJS 1.4 deals a solid 60 fps on most android devices (awaiting for Apple's approval on iOS) and that's what mostly matters as far as games go. (Also taking into account the recent addition/modification of 2DBox physics specifically for mobile through cocoonJS which should allow for proper physics handling which, so far, could be a bit of a bottleneck in mobile CPU performances).

But what results in 60 fps is highly variable. I can get 60 fps out of cocoonjs 1.3, but 1.4 with webgl is faster at rendering, so developers can do more per frame. A blank white screen is easy to process, but tons of collisions, instances and code running at once might get 60 fps in safari but not in cocoonjs. If JavaScript was replaced by something faster, it would be a significant boost to what people could do.

Node-webkit exports as binary to desktop and so has about the same performances as chrome on desktop, so no issue/relevance there either.

It's still relevant from a technical perspective, because node webkit is also still running JavaScript to run the C2 games. Even if v8 compiles them, as the article states, they can only do so much. However, it's true that the article is mainly talking about mobile, and desktops are fast enough that the concerns aren't really an issue, even on my amd Athlon 4400+ which scores like a tenth or less of the speed of a lot of modern processors.

My biggest frustration is that no one seems to be willing to collaborate on a proper modern language that solves all of the problems that JavaScript has. Nacl/pnacl sound brilliant, but no one else seems to have any interest in it. Dart also solves a bunch of problems, no one else seems to be backing that either. Everyone keeps talking about web technologies being the future but they keep using a language that is stuck in the past that simply has a lot of inherent performance problems, as it simply wasn't designed to be a high performance language. What we end up with is the equivalent of people trying to put rockets on a clunker to make it go faster rather than properly design an F1. Even if you can make it somewhat fast in the straightaways, the sucker can't turn.

Regardless, even on mobile, even in cocoonjs which is not as fast at running code as safari, it's obviously still fast enough to make a game with.

I'm not really meaning to complain about the performance issue either - it's fast enough for most of what I want to do on mobile, and desktop isn't an issue almost at all - I'm more frustrated by various groups' inability to work together to improve things properly.

Anyway, thanks for the article, Alcemon. It was an interesting read.

Edit: ninja'd

Agreed. The original reason that I got involved in the Construct community (even though I am a programmer that could in theory use a more efficient framework) was because I planned to use Construct as a "Level editor" and prototyping platform only, eventually exporting all the nicely ordered sprite, animation and event logic (it is all in xml after all) into a more platform-effective framework.

I was pleasantly surprised when I found out that the performance was "good enough" for a desktop game of the scope I had planned :)

If any of my projects are moderately successful, I would still like to follow my original plan of making a C2 to platform-specific C-like exporter, because nothing beats the ease of use of C2 for level building and quick AI programming. But for the moment and specially for desktop games, I do not see the need to do so.

Edits: grammar and such