I've been researching writing an app for iPhone. I really like the look of PhoneGap which basically allows you to contain a webpage in an app. My skills are primarially in HTML/Javascript so this tool allows me to make the most of my skills without having to spend many hours learning how to write an app natively for the iPhone.
I've been doing some tests on my iPhone for Javascript, and some seemingly simple examples run painfully slow. Really slow. This unfortunatly is a big problem for my task!
Any work arounds? If I want to do anything interesting am I going to have to write a 'proper' app?
An explanation on why Apple have seemingly created such a bad implementation of Javascript would be interesting as well (possibly to make more money? Less web apps = more apps in the store?)
References
http://ajaxian.com/archives/ipad-javascript-shockingly-slow
Javascript is not particularly slow, but the DOM is very slow.
I think it is the same as a desktop browser, but magnified.
I would check first all DOM manipulations, if they can't be optimized.
Another option, is to use a templating engine.The main DOM manipulations are done through innerHTML injection, which is fast even on mobiles.
We've built a mobile version of our web app, and we use PURE (an open source JS lib we created) to render the HTML from JSON data, and it is very responsive.
We went the HTML5 way(not native) but I think generating the HTML could be done the same way when wrapped in PhoneGap.
I don't think Apple has created any special implementation of Javascript for Mobile Safari. Probably it's the same as or very similar to the desktop Safari.
These devices are small and have strict power constraints, so the CPU is slow.
Apparently iOS won't do JIT compilation of JavaScript (unlike Android) due to a security feature: http://daringfireball.net/linked/2010/07/22/android-ios-js-benchmarks
Good point about DOM access being the issue though: I don't know how much these benchmarks test DOM operations.
#Rudiger: Just a thought - A lot of the improvements to desktop computer speed since "8 years ago" have been attained in part through the use of multiple processors. Javascript is single-threaded, and so presumably would not be able to take advantage of such multiple processors. Yes, I know that browsers can take advantage of it, and that putting the other stuff on the other processors can provide more CPU power to the Javascript thread, but I have an app that is mostly raw Javscript internal processing, where the main thing that is going on is search and array manipulation.
So, when comparing desktop power to mobile processor power, for my purposes, maybe the slowdown would not be so bad? I currently run at very acceptable speeds on Safari on a six-year-old notebook computer with a single processor. So I'm thinking that Safari on iPhone or iPad for me might not be that much worse. Do you think this is reasonable?
Actually, I think Apple has a vested interest in keeping javascript out of the Iphone as much as possible.. they seem to want to regulate things through their appstore by requiring applications that run natively.. I'm curious if javascript is also slow on Android phones, (I've never used one before).. if its not then I think it is a bit strange that the Iphone would be slow with javascript, at any rate, they are already losing market share and will have to address the issue at some point I am sure, I think people are catching on to Apple's games and idiocy in trying to micromanage everything now that more legitimate alternatives are coming out in the mobile device space.
Related
I don't know whether my question belongs here but I am asking it anyways. Why is there not a lot of shift in creating the game using HTML5 rather than creating a native game app, especially for mobile application? While I understand completely and assuming my understanding to be correct, for desktop games, a native game can use the graphics card in the computer taking the hefty load of graphics processing off from the CPU. What is the case for mobile browser? Does the mobile browser allowed to have the equal amount of processing resources as the native app? As far as I think, the processor is all and all in mobile phones. If this is correct then, I would think it would be more easier to create game with browser.
Is my understanding correct? Am I missing something here? What is the catch if I want to create game app using HTML and javascript?
A game as a native app would usually be written in a much more efficient language than javascript, for example Java on Android or Objective-C on iOS. Javascript is usually interpreted as it is run (as far as I know), and this affects the performance. Also, while you can obfuscate javascript to hide the implementation (if you want to protect your code), it isn't as effective as compiling a native app (I don't know how hard it is to reverse-engineer Java though).
However, WebGL is becoming more popular, and lets javascript code use hardware acceleration to accelerate graphics. When this is well supported on mobile devices, it might be feasible to make a complex game in the web browser. It certainly makes it more portable, and you could put it in a native WebView (or similar), for it to act like a native app.
Some examples here: http://www.chromeexperiments.com/webgl/
There's a couple potential drawbacks for HTML 5, one of which has already been pointed out, is a potential performance hit. This is sorta a big one, especially for devices that aren't capable of using WebGL. The other really big one for me anyways, is bandwidth use. Most phones (at least in the USA) are on fairly restrictive data plans, and thus if you're accessing the game via HTML 5, you're potentially eating into your bandwidth use every time you play, meanwhile a native app is downloaded once, and that's the last of the data usage...input lag is another biggie, particularly if your game requires specific timing. Granted, as speeds get faster on mobile devices this becomes less and less of an issue, but it will never be equal to what can be done locally on a native app. Lastly, as was pointed out, code hiding, you may or may not care about, but it's easier to do on a native app.
Currently I'm developing an Android App with Phonegap/Cordova (2.1.0/2.2.0) , JQ-Mobi(not jQueryMobile), HTML5 and Javascript and CSS3. The App contains 2 native exstensions.
Somehow, when I export my project to a device with the lastest Android version, the app runs so much slower than an 2.3.5 device.
I've tried enabling the HardwareAcceleration and removed all of the box-shadows and other tough to render css3 stuff. Still on a 4.1.1 or 4.0.4 it runs crappy.
I also upgraded to the latest version of Cordova (now 2.2.0) and it doesn't seem to make it better.
Javascript DOM manipulation happens for about 80-90% when the app is started.
The worst performance is in switching panels and scrolling through forms, most of them have some transitions in them.
I tested it on a Samsung Galaxy S2 android 2.3.5 and it look fine and performs well.
Same device, but 4.0.4 runs crappy.
Samsung Galaxy S3 4.1.1 runs even crappier.
HTC Flyer P512 with android 3.2.1 runs it how it should be running.
Can anyone help me out here? How do I get this performance up? Any Hint or Tips which I havn't mentioned?
I'd like to add that I don't get the issues on an Iphone 3gs and up to explain that it is definitly an Android problem.
My phonegap apps run smoothly on iOS, but perform extremely poorly on Android. As I understand it this is just because Android is much slower at interpreting JavaScript than iOS.
One thing that can help a lot is cutting down on the use of libraries such as jQuery and JQM. If you want to include them, don't use them where you don't have to.
functions such as jQuery.animate run notoriously slow on Android and you'd be better of iterating over arrays with raw JS rather than using jQuery.each etc. etc.
The problem is not just with graphical rendering, but with the speed at which JavaScript is executed. Although lowering the screen resolution can boost your performance.
Edit
I am trying to get to the bottom of this myself and the only answer I can get is to keep computational operations at a minimal.
Use libraries sparingly and solve your problems with raw and well written JavaScript when possible
Keep a small DOM and manipulate it as seldom as possible
Make use of JavaScript performance enhancing techniques
So it really seems that this is a core performance issue, rather than something that could be solved on the Phonegap layer. As a non-scientific example, the exact same init() function on one of my apps executes in about 1.2 seconds in iPhone 4s on average, while taking a sluggish 5 seconds to complete on my samsung galaxy s3.
The core of the problem is that everything is loaded and running in a single page (execution context), personally, though single page apps (sencha, jqmobile etc) are all the rage, the performance on modern devices does not do the user experience any justice. I would separate the app into different pages, this will significantly reduce the size of the DOM and create separate execution contexts for each new page, meaning that your main page (execution context) is nice and lean (DOM is small).
I had the exact same problem. I asked a similar question and eventually answered it myself here after a tonne of research:
Cordova/Phonegap slow performance with Open Layers on new Tablet, but fine on new phone
I won't repeat the entire answer I gave, but the slow performance on certain Android versions is due to what is essentially a bug in WebView which throttles the CPU support for GPU based processes, but doesn't provide GPU support to compensate.
Kitkat V4.4.3 upwards have this fixed, but older versions such as V4.4.2 which are still being used on some devices still suffer.
You can avoid this by not using WebView at all for the HTML rendering, and instead use Crosswalk. For our project this solved the problem entirely and we now have a smooth running application across all Android versions we're targeting. It's quite trivial to do as well.
https://crosswalk-project.org/documentation/cordova.html
https://blog.nraboy.com/2014/10/use-crosswalk-ionic-framework-android-apps/
Try using multithreading and background processing for resource extensive operations.
That worked for me when i had similar problem with one of my apps when it crashes when it runs on versions later than 2.3.3. I never worked with PhoneGap so I'm not sure how you are going to do it.
There's been a lot of talk about Google being forced to go with UIWebView for Chrome for iOS, and Facebook ditching HTML5 entirely for their iOS apps because UIWebView was too slow. I'll soon be needing to port an HTML5 application that requires lots of intensive Javascript computations (too much code to rewrite natively given my time constraints) but none of the display functionality that a browser provides (i.e. it works fine headlessly on Node.js). I've never heard of anyone trying to embed Google's V8 into an iOS app, but given that MobiRuby does practically the same thing (linking in the mruby interpreter), would it be permissible to do something similar, linking in Google's V8 interpreter within the same process? As long as code isn't downloaded, and processes aren't forked, it doesn't seem to be against the rules, but has anyone ever tried this?
EDIT: I'm aware of PhoneGap/Cordova and similar technologies, but they all work with a full UIWebView, and due to Apple's paranoia, UIWebView cannot JIT-compile Javascript code (which, as I said, is essential for my application).
According to what is mentioned in this this thread on the v8-dev mailing list, it may now be possible. You may be interested in the state of the work on this issue.
I need to implement a paint type program that will run on all major browsers as well as can be packaged as an app on the iPad/iPhone. After some investigation I have learned the following facts (correct me if any are wrong):
Javascript is entirely too slow to handle an app of this type by itself
HTML5 seems like a good solution, it has a canvas tag and everything and can easily be packaged into a UIWebView for a Cocoa app. However, I need to be able to reach the majority market for web users, which unfortunately includes most IE users who aren't using the public beta for IE 9.
Flash vs. Apple
Right now I'm debating just making two completely separate apps, one in OpenGL ES for iPad/iPhone and another in something like Flash for web browsers. I was just wondering if anyone had an immediate solutions in mind to make one app instead?
I'd question the accuracy of your first point (Javascript is too slow). Since it's possible to run Quake II in pure Javascript, it's likely that your paint application is less resource-intensive and thus could also run. Of course, one could ask how much optimisation effort and/or experience is required to write performant Javascript of this standard - I can't give you an answer there.
But I'm certainly sure that it's possible to get enough performance out of Javascript to implement such a paint tool, in any modern browser. That doesn't preclude the other options, though; using JS along with HTML 5 sounds like the ideal solution here for "out of the box" cross-platform compatibility.
At a recent discussion on Silverlight the advantage of speed was brought up. The argument for Silverlight was that it performed better in the browser than Javascript because it is compiled (and managed) code.
It was then stated that this advantage only applies to IE because IE interprets Javascript which is inefficient when compared to that of other browsers such as Chrome and FireFox which compile Javascript to machine code before execution and as such perform as well as Silverlight.
Does anybody have a definitive answer to this performance question. i.e. Do/will Silverlight and Javascript have comparable performance on Chrome and Firefox?
Speculating is fun. Or we could actually try a test or two...
That Silverlight vs. Javascript chess sample has been updated for Silverlight 2. When I run it, C# averages 420,000 nodes per second vs. Javascript at 23,000 nodes per second. I'm running the dev branch of Google Chrome (v. 0.4.154.25). That's still almost an 18x speed advantage for Silverlight.
Primes calculation shows a 3x advantage for Silverlight: calculating 1,000,000 primes in Javascript takes 3.7 seconds, in Silverlight takes 1.2 seconds.
So I think that for calculation, there's still a pretty strong advantage for Silverlight, and my gut feel is that it's likely to stay that way. Both sides will continue to optimize, but there are some limits to what you can optimize in a dynamic language.
Silverlight doesn't (yet) have an advantage when it comes to animation. For instance, the Bubblemark test shows Javascript running at 170 fps, and Silverlight running at 100 fps. I think we can expect to see that change when Silverlight 3 comes out, since it will include GPU support.
Javascript is ran in a virtual machine by most browsers. However, Javascript is still a funky language, and even a "fast" virtual machine like V8 is incredibly slow by modern standards.
I'd expect the CLR to be faster.
I'd say that architecturally, it's a wash.
On the one hand Silverlight is MSIL code, which is reasonably fast compared to raw, optimized native code but still runs slower due to the VM (CLR) overhead and will still have slow initial load times when being ngen'd.
On the other hand the speed of Javascript is much less reliable due to the huge variations in Javascript engines which have an order of magnitude, or more, range in performance. You have slow interpreters like IE, though IE8 is speeding things up, and then you have faster compilers/interpreters like SpiderMonkey and V8 which have only recently begun to explore the performance limits of Javascript. There's also new technologies in the R&D phase like TraceMonkey which have tremendous potential to vastly improve Javascript performance (getting close to native code speeds). Javascript does have the inherent disadvantage that it is single-threaded, but given the difficulty of writing good threaded code it's hard to say how much difference that makes.
At the end of the day when comparing apples to apples the real performance bottleneck is the DOM, and there it doesn't much matter what technology you're using to manipulate it.
I don't understand why you're trying to compare a scripting language with a browser plug-in.
They don't do the same thing. The former interacts with the DOM while the latter runs multimedia apps inside the browser.
Comparing Flash and Silverlight from a performance point of view would seem more useful to me.
EDIT: After some research I found out that you can interact with the DOM in Silverlight. I don't think it can be seen as a good Javascript replacement though, performance concerns aside, unless you have some heavy client-side interaction needed. I see two main disavantadges :
1) You will force your users to download a Silverlight app instead of relying on a relatively small .js file.
2) Your users are required to install Silverlight before using your page.
From the cursory testing I've done, Silverlight runs faster.
Here are some intersting results I gathered from http://bubblemark.com/
In general, Silverlight was much faster, but Chrome's javascript implementation tore everyone else to bits!
Keep in mind, this is only on one machine, one os (XP) etc. you would need to do much more extensive tests to achieve more.
I'd say yes, since it has .NET's CLR. At that, with resent developments in JavaScript implemented in Google Chrome and in the yet to be fully released Firefox 3.1, one may want do do some benchmarking of their own; I don't know of any comparisons as yet. (anyone?)
Nonetheless, in my opinion, .NET should be generally faster than Javascript, and as has been noted before, this will not speed up the network. Consequently for complex algorithms, SilverLight will be faster, but for network requests, you may not have any noticeable difference.
On the performance question, you may want to have a look at Flash 10 which can allow c/c++ code using "Alchemy". This may be a more portable solution than SilverLight.
It looks like that Chrome's javascript implementation is faster than Silverlight
Platforms should be considered here. How Silverlight performs in Lnux or Solaris or Mac is really big question !
How abt HTML5 .I think while comparing the performance of javascript HTMl plays a serious role. So we shoul definitely compare the performance using HTML5 + javascript and Silverlight .
Sre, if you're using "Internet Exploder" it probably will...
If you're using V8 (Chrome) or the upcoming Safari and FireFox, I seriously doubt it ;)
I would love to see that Chess thn BTW where IE is playing using Silverlight and Chrome is using Javascript. THAT would rock MSFT...!! ;)