Slashdot Mirror
An Interesting Look At the Performance of JavaScript On Mobile Devices
First time accepted submitter faffod writes "Coming from a background of console development, where memory management is a daily concern, I found it interesting that there was any doubt that memory management on a constrained system, like a mobile device, would be a concern. Drew Crawford took the time to document his thoughts, and though there is room for some bikesheding, overall it is spot on. Plus it taught me what bikeshedding means."
Don't blame Timothy for the dupe; no doubt he posted it from his mobile.
But it didn't teach you how to spell it...
Whew, I'm glad we managed to get everyone to switch off of memory-leaking and CPU intensive Flash stuff over to standards compliant HTML5 and JavaScript then!
The problem is that your baby is not the only thing running on the system. When you waste resources, you do it on behalf of everything else that runs too. Even if your baby isn't doing anything critical when you waste it.
It only takes one selfish programmer to screw up an embedded system. You are he.
Coincidentally, most IDEs for javascript have little to no spelling assistance
Spell-check in IDEs generally relies on static analysis of the variables in scope at any given point in the program. The more dynamic a language's type system is, the harder it is to statically find the names of symbols in scope at any given point in the program. PHP and Python are kinda-sorta OK for this because all global variables are out-of-scope (PHP) or read-only (Python) unless declared otherwise at the top of a function's definition (or, in PHP, unless the variable is one of the predefined superglobals, whose names are all uppercase starting with $_). This way, the IDE can parse a function for all variables assigned to in a function and assume they're local. JavaScript, on the other hand, defaults to making all variables global unless declared local with the var keyword.
Spell-check also relies on static knowledge of what source code files are in scope. This is dead easy for Java. In PHP you scan for require_once, and in Python you scan for import, but even then, a module is occasionally conditionally imported, and importing has side effects. JavaScript can't include JavaScript at all except by appending a <script> element to the HTML DOM with the src= attribute referring to the other script, and the idiom for that is harder to recognize than a simple import statement.
it seems like there could be a pretty simple automated dupe-checker that flags it and tells the editors
It's called the "visited link color" function. Or perhaps not even the editors read the featured article.
I made a comment to a poster over on the original posting of this. I think it's worth expanding upon in case people are persuaded by the arguments in the paper.
First off, just as TFA predicts, I'm not going to try to conquer his mountain of facts and experts by presenting a mountain of citations. Instead, I'm going to point out where his conclusions are not supported by his facts and point out his straw man arguments and his attempt to convince us through overwhelming expert opinion.
The straw man: In the article, he presents two scenarios (photo editing and video streaming) and claims that you can't reasonably do those because of memory limitations (on the iPhone/iPad). He then concludes you can't produce useful apps because you can't do those two. I couldn't find any citations of people attempting to do this on mobile using JavaScript. Choose the right tool for the job here. I'll give him these two use cases (and several others: 3D Games, audio processing, etc), however to extrapolate from here that no useful apps can be produced (ever!) using JavaScript is a leap too far.
Next, he spends a lot of time diving into the particulars of garbage collection (GC). I'm going to grant him practically every point he made about GCs. They're true. And, it's true that mobile is a constrained environment and you must pay attention to this. But, this is largely known by developers who are trying to write high-performance JavaScript applications on mobile. Hell, -anyone- writing high-performance apps in any language need to be aware of this. If you allocate memory during your animation routines in a game you're asking for trouble, regardless of the language. So, to me, this part is just a call to pay attention to your memory usage in your apps. This is really useful advice and I will be paying even more attention to the new memory tools available in the latest Google Chrome dev tools.
One of the biggest problems in the rant is the comparison of pure computing performance and his claim that ARM will never be as fast as desktop. I'm going to again grant that this is true. However, this means crap-all for most apps. Tell me: How many apps do you have one your phone that are processor bound? None? One? Two? The vast majority of apps spend their time either waiting on the user or, possibly, waiting on the network. You can write a lot of really useful apps even given constrained processor and memory. Anyone remember the Palm Pre? The TouchPad? Most of those apps were JavaScript and they worked just fine.
This brings me to the point of all this, TFA's author focuses on performance. However, users focus on responsiveness. JavaScript is perfectly capable of producing responsive applications. Sometimes, it takes attention to detail. Nothing is ever 100% free and easy. JavaScript is not a magic solution and those of us who think that JavaScript has a future in mobile app development know this. This is why programmers get the big bucks. Writing mobile apps, you need to be aware of the effects of CSS, memory, processor, responsiveness and more.
Author of Enyo: Up and Running from O'Reilly Media
Actually a pretty well written piece, if a bit wordy. I see a lot of people commenting here are perhaps missing the point, thinking that the author's angle was JS=BAD. Not at all. My take was his issue was not so much with JavaScript, but with Garbage Collected languages in general.
An important point he made regarding GC routines and how they tend to be unpredictable in terms of when and how long they run. Also, much was discussed on his observations that, if you have several times more memory available than what your app needs, the GC routines are very non-intrusive. However, when you get into a low memory situation, the performance hit from GC is huge and causes obvious stutters in the application and/or it's UI.
Also, some discussion on the irony of working around (or trying to "spoof") the GC by using various manual techniques, and how that almost amounts to manual memory management. All in all, a really interesting read.
I am not the GP but I sympathise with his comment.
"It looks like you want to get rid of all JavaScript in web pages. What's a better way to present interactive forms over the Internet that doesn't involve reloading an entire 100 kB page whenever the tiniest bit changes and doesn't involve paying someone to make six different native applications, one for each operating system?"
Dont force a single 100kB monster to begin with, doh. Break the monster down into bytesized chunks and this suddenly doesnt look so impossible to do in straight html, now does it? You can even keep your 100kB script as well if you want, but you must put a link to the straight version in the noscript tags at the very least. (Personally I urge you to give me an option to use the straight version even in a scriptless browser, otherwise you will probably force me to disable all scripts on your site, but it's not a formal requirement like the noscript tag.)
From day one that was the way you were supposed to do it when you added scripts to your web pages, and it's not that I want to remove all scripts from the web, I want to remove this idiotic assumption it's ok to skip the webpage, hand out a script instead, and pretend all is well. It isnt. Javascript is fine for making a fancier version of a webpage (but only as long as you dont use it as an excuse to skip the simple version.) But scriptless browsers are an integral part of the web as long as it's existed and they arent going away. If you dont support them you arent supporting the web and are missing the point of the web.
With the current threats and trends in malware, you're likely to see only more and more scriptless browsers. Browsers that support scripts just fine are being told not to support YOUR scripts - at least not until you are trusted. Making a good first impression more and more means making a good first impression WITHOUT grabbing your ecmascript crutches, without just ASSUMING that the visitor is immediately comfortable enough with you to be touched in that way.
Even if you cant figure out how to write a webpage or hire someone that knows, you should not need to pay for 6 different native apps - unless your app has a really niche market at least. Just get it written once in a high level language, release it GPL so that anyone interested in porting it to a new platform can. You'll likely have ports contributed back faster than you can pick out the right guy internally to receive them. (This part assumes your app does something that a computer literate person might find useful, of course, it strikes me that is a blind assumption though.)
Dont tell me your afraid to release your precious source - you're doing that right now every time your server sends out 100kB of ecmascript already.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Try looking into node.js and see all your fears come true.
I was promised a flying car. Where is my flying car?