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...
I'm probably going to get downvoted as troll, but my experiences with most console developers were often strange (as a developer myself).
Talks usually end up in most of them dismissing scripting languages, higher level APIs (such as OpenGL), or certain algorithms as useless because they are slow, use too many instructions unnecessarily, waste cache, etc.
Any attempt to raising a point about how you don't need to optimize everything but only few critical zones of your code (what matters), or that a cache wasting algorithm can end up being faster anyway just because it's more efficient, immediately results in myself being dismissed or treated as ignorant because, something inefficient is obviously inefficient and I must be stupid for not realizing that.
This article reminds me of that. The author claims (in his first claim) that he is determined to prove that something is less useful because it's slower, and nowhere in that huge long piece of text there is anything useful offered as proof, instead he keeps posting data about how slow Javascript really is.
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!
https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
It gripped her hand gently. 'Regret is for humans,' it said.
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 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?
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.
Try looking into node.js and see all your fears come true.
I was promised a flying car. Where is my flying car?