An Interesting Look At the Performance of JavaScript On Mobile Devices 157
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."
Mobile web really IS slow! (Score:5, Funny)
Don't blame Timothy for the dupe [slashdot.org]; no doubt he posted it from his mobile.
Re:Mobile web really IS slow! (Score:3)
Re:Mobile web really IS slow! (Score:5, Insightful)
Since this was literally the same link, not just the same story but via a different source, it seems like there could be a pretty simple automated dupe-checker that flags it and tells the editors: a story with the same link was posted in the past N weeks, are you sure you want to post?
Re:Mobile web really IS slow! (Score:3)
The editors don't RTFA (Score:5, Funny)
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.
Re:The editors don't RTFA (Score:2, Informative)
- Is there only one editor, who always reads every single featured article?
- Are slashdot editors barred from clearing their browser histories?
Re:The editors don't RTFA (Score:3)
Is there only one editor, who always reads every single featured article?
Ideally, the buck is supposed to stop with an editor-in-chief.
Re:The editors don't RTFA (Score:2)
If this were a newspaper where the 'editor in chief' was responsible for that, sure.
I'm not convinced that 'editor' at Slashdot meets the same level of rigor. In fact, I'm quite certain it doesn't.
Re:Mobile web really IS slow! (Score:2)
Indeed, even Fark has had this feature for years and years.
-l
Re:Mobile web really IS slow! (Score:2)
A Slashdot story isn't a single link. It's a block of text that may contain 0 or more links. It's not like reddit or Fark where you're posting a link to a single article, and that's about it. They could write code to scan all summaries for all links and log each of them, but it's not as simple as it would be with something like Fark.
Re:Mobile web really IS slow! (Score:5, Funny)
Re:Mobile web really IS slow! (Score:5, Funny)
Chek your speling (Score:5, Funny)
But it didn't teach you how to spell it...
Re:Chek your speling (Score:3, Funny)
<Ralphie Wiggam> The missing 'D' was used for my grade. </Ralphie Wiggam>
Re:Chek your speling (Score:3)
Re:Chek your speling (Score:3)
I'm glad I don't work with you, if you laugh at loud for every sentence you write.
Re:Chek your speling (Score:3)
I like the comma before "lol." Write sentence, little pause, bellylaugh. Classic.
Re:Chek your speling (Score:2, Offtopic)
Spell-check in IDEs (Score:5, Informative)
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.
Re:Chek your speling (Score:3)
Spelling isn't important in programming, lol. That's what the IDE is for. Coincidentally, most IDEs for javascript have little to no spelling assistance, lol.
Tell that to Microsoft who had to break compatibility [microsoft.com] due to some spelling mistakes. Specifically, the MFC/ATL section.
Re:Chek your speling (Score:3)
"Spelling isn't important when writing. Thats what the word processor is for!"....."lol"
You're me at 13 aren't you? :)
Re:Chek your speling (Score:2)
Re:Chek your speling (Score:2)
Irony overload, abort, abort!
Typical console developer rant, IMO. (Score:3, Interesting)
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.
Re:Typical console developer rant, IMO. (Score:3)
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) ... immediately results in myself being dismissed or treated as ignorant
To be fair, if you were debating with someone who writes applications that really do need the very top levels of performance, and you claimed that optimising trouble-spots would be sufficient to achieve that, then you were ignorant. For most software, being within a factor of 2 or 3 of hand-optimised low-level code is easily sufficient, and a bit of work with the profiler to identify the most serious flaws will go a long way. The rules change when you shift from that kind of performance standard to needing the very top levels, because then the emphasis on speed permeates everything.
Comment removed (Score:2)
Comment removed (Score:2)
Re:Typical console developer rant, IMO. (Score:3)
They arent useless but they are certainly not always the best (or even simply an appropriate) tool to use. Scripting is great for the trivial-but-useful, particularly a one-off or a mock-up. But any sort of serious computer program is going to be better if you program it and most anything that is trivial-but-useful enough to have a jscript app should be quickly reproducable on any platform that you want in a native fashion. Do you need a native program to have a simple calculator? No, javascript will do. And that's great.
At the same time, if that simple calculator is something you use very often, make an app. You dont have to be worried about the simple calculator overwhelming your phone to think that makes sense - because we all multitask these days and/or worry about electricity/battery life etc. on many devices.
It's funny seeing how people are rediscovering the importance of programming as a result of these phones. The reason it makes me chuckle is that I remember working with PCs that had orders of magnitude less system resources than these phones do, so I understand that it is actually the abstraction layers in use that make the hardware seem so limited.
You kids nowadays think a power-throttled ARM processor and a couple gigabytes of RAM is 'limited resources.' You should try a z80 with 8kb ram. Believe it or not, if you actually program the thing instead of expecting your libraries and abstraction layers to deal with it for you, you could make that work too.
Re:Typical console developer rant, IMO. (Score:2)
Very, very well said, sir.
Re:Typical console developer rant, IMO. (Score:2)
It's funny seeing how people are rediscovering the importance of programming as a result of these phones Very, very well said, sir.
And the most fun!
Re:Typical console developer rant, IMO. (Score:2)
Whee, the UI of a game is scripted. That's not exactly a critical application, and it's not like they tried to write the whole thing in ecmascript. And it's not like the gamer market hasnt been well traind to accept and even expect to constantly buy more powerful hardware in order to 'consume' a never-ending string of bugfixes from game launch date to EOL.. Anyone that sets anything up so that his game UI crashing or malfunctioning in strange or unforseen ways is a big problem is an idiot.
"Scripted languages have enormous advantage of being much easier to bugfix than native apps."
This is a strange statement to make. They do avoid certain types of bugs by not giving you enough control to introduce them, of course. But when you hit a bug it's more likely to be a bug in your environment (beyond your control) that you cannot fix. Other than that, what? A shorter text to sort through finding the bug I guess. A molehill beside mountains, in the wrong application.
Re:Typical console developer rant, IMO. (Score:2)
"Scripted languages have enormous advantage of being much easier to bugfix than native apps."
This is a strange statement to make.
No its not a strange statement.
Perhaps you haven't scripted much, but you'll understand that you dont need to recompile or even restart software.
Fix. Test. Ok, next.
It allows designers to experiment on their own initiative, and R&D to focus on the important stuff.
Re:Typical console developer rant, IMO. (Score:2)
Re:Typical console developer rant, IMO. (Score:2)
I have used Lua in a variety of console games that I have shipped, and it has its uses. In particular, iteration time with an interpreted language is typically much faster. When trying to hone the experience, iteration rules, and the developers that allow their content creators to iterate quickly and effortlessly will always be able to produce a game that feels more polished. It is a case of knowing why you are making your choices, not a case of allowing dogma (only low level is fast) or ignorance (ease of development can overcome inherent limitations). Note, I think that WOW uses Lua because it is easy for the servers to modify the code by sending data packages (but that may just be my male answer syndrome kicking in)
I disagree with the sentiment that scripted languages are easier to debug. I've shipped games where there was no Lua debugger for the designers (yes, that is abusive, and I still apologize to them today, but that was the hand we were dealt). The fast iteration time might make you think that you can keep trying different solutions as a method of debugging. Where the rapid iteration is great for improving the experience, it is a poor approach to take for debugging. Too many developers take the shot gun approach to debugging (and this has nothing to do with interpreted vs compiled, I've seen it everywhere). Though a bit too extreme to be realistic, I like to make people think about this: Debuggers are the worst tool for development, it makes programmers not think and analyze their code and therefore they don't understand it. Once again, between the two is right balance, use your debugger but think about your code - and that has nothing to do with scripting languages.
Re:Typical console developer rant, IMO. (Score:2)
Re:Typical console developer rant, IMO. (Score:2)
Someone please mod this up!!!
That is THE fundamental problem with junior / immature programmers. They don't know how to THINK about the problem: its boundary and edge cases, the run-time memory usage, knowing if they are CPU bound, knowing if they IO bound, etc.
Re:Typical console developer rant, IMO. (Score:2)
PFFFF Hahahahaha! Damn you, my desk is now a coffe mess!
Re:Typical console developer rant, IMO. (Score:5, Insightful)
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.
Re:Typical console developer rant, IMO. (Score:2)
It only takes one selfish programmer to screw up an embedded system. You are he.
Even though it's unrelated with my original post, you are saying that not going native is worse because it uses more CPU cycles/battery?
Explain to me why, for decades, the industry used J2ME, Java (Android) and now ObjC (Apple). I guess the entire mobile industry is selfish and greedy?
You probably didn't understand GP, though, the message is that you don't need to optimize something that doesn't consume enough cycles be a performance problem.
Re:Typical console developer rant, IMO. (Score:2)
Even though it's unrelated with my original post, you are saying that not going native is worse because it uses more CPU cycles/battery?
Explain to me why, for decades, the industry used J2ME, Java (Android) and now ObjC (Apple). I guess the entire mobile industry is selfish and greedy?
Of course they are. But that's beside the point. Development is a trade-off - you have to work with the market you have, within deadlines that means you'll sell, and developers you can find and afford. So yes, you make do with what makes the task feasible.
But you don't have to make it any worse than necessary by allowing bloat and doing things inefficiently. Adapting a mindset that you do work in a shared embedded environment, and do things frugally doesn't incur a great cost.
You probably didn't understand GP, though, the message is that you don't need to optimize something that doesn't consume enough cycles be a performance problem.
It's not just about cycles. It's also about resource use in a shared environment. The key word being shared. Whether something doesn't impact your own application isn't the problem - unless you have thought about how it could impact other applications and the overall system, you haven't done your job.
Re:Typical console developer rant, IMO. (Score:2)
To follow up on my own post, what we see in environments like the Android world is a tragedy of the commons. If everybody played nice, everybody would benefit. But there's no penalty to yourself for being greedy, so you are. And so are all others.
Android really needs something like strictly enforced cgroups.
Re:Typical console developer rant, IMO. (Score:2)
In the real world, It is always possible to write more efficient code, but the more you optimize, the more difficult to develop, maintain or port it becomes, exponentially.
So in the end, it's always a trade off between performance and cost of development, added to the fact that not all code needs to be optimized, only the little portions that perform the most critical tasks.
Re:Typical console developer rant, IMO. (Score:2)
added to the fact that not all code needs to be optimized, only the little portions that perform the most critical tasks.
That this is false is my point - it's only true if your app is the only app on a system. On a shared embedded system, the portions that don't do critical tasks are just as important to optimize for the rest of the system.
Because there's no penalty to your own app, it becomes a tragedy of the commons [wikipedia.org].
Re:Typical console developer rant, IMO. (Score:2)
It seems much cheaper to solve this by adding a little more battery capacity, yet keep your phone OS and applications easier and cheaper to develop.
No matter how you look at it, I can't see the scenario you describe as being a tragedy..
Re:Typical console developer rant, IMO. (Score:2)
You didn't follow the link, did you? It's a situation that's called "a tragedy of the commons", which doesn't mean it's a tragedy.
And anyhow, it's not about battery life, but applications using more than their fair share of memory, IO or other resources contribute to starvation for other apps that run at the same time, possibly causing crashes in other apps when they cannot allocate memory (because they're well behaved and allocate when needed and free when done), cannot update alarms in time, can't take a phone call(!), can't AV scan an incoming e-mail, or a million other things that can go wrong if too many apps on a system are hogs.
Re:Typical console developer rant, IMO. (Score:2)
except this has nothing to do at all with my original post, nor the article, both about processor usage.
Re:Typical console developer rant, IMO. (Score:2)
Explain to me why, for decades, the industry used J2ME
Because Sun pushed it on everyone. It sucked big time, though. Did you ever write a J2ME app? It was the kind of platform where everything was an object except for primitives, but memory management was so messed up because of the combination of GC and extremely small heap, that pretty much any serious app didn't use any objects. Instead, you preallocated arrays of primitives, and used that for everything.
Java (Android)
You mean, the only mobile platform that still has horrible UI latency?
and now ObjC (Apple).
Obj-C compiles to native code and does not have a GC.
In fact, it's kinda one of the major points in TFA. Are you sure you've actually read it?
the message is that you don't need to optimize something that doesn't consume enough cycles be a performance problem.
The problem in question is not a performance problem, it's a responsiveness problem. If you have a GC kick in during a touch-driven animation (e.g. user swiping a list to scroll), and it takes 200ms to walk your object graph and collect unreferenced objects, you've already lost that battle - the user will see lag and jittery animation that desyncs from his finger movement. Yet this exact thing is unavoidable in languages with tracing background GC, like Java or JS, since you don't have any control about when the GC kicks in. The only thing you can really do is avoid object allocations in the first place - which turns Java into an ugly and unwieldy subset of C (J2ME-style), and is utterly impossible in JS since what gets allocated where is an implementation detail there.
Re:Typical console developer rant, IMO. (Score:2)
Re-read his second paragraph, AC.
Or did you just intend to troll and see how many moderators you could trick?
Re:Typical console developer rant, IMO. (Score:2)
It's impossible to personally attack an Anonymous Coward.
But I'm glad you recognize what you are doing.
As for "What wasting", I asked you(?) to re-read the guy's second paragraph, but this was apparently too hard. So let me quote it:
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.
That wasting. Right there.
Re:Typical console developer rant, IMO. (Score:2)
His point was, that there is no point in optimizing the code that barely takes any resources to begin with.
Actually his point is usually applied to a concept of "hot path" where, regardless of how many resources a peice of code "takes", what matters is how often that peice of code is run. The problem with doing this is that programs and their usage patterns change and evolve over time. What was not a "hot path" yesterday can become one due to changes outside the program itself -- e.g. suddenly all the packets it receives have an option set that was only set on 1% of packets when the code was initially profiled.
So you end up with code that can break into being slow, rather than being obviously broken. This increases your workload supporting the program post-release. You have to replicate what customers are doing (good luck) and re-profile while under that particular load to find the new hot paths. So while scripting languages are hailed for ease of development, ease of maintenance in a high performance environment is another matter entirely. If you optimize more things to start out with, you don't end up with this explosion of performance test cases to check.
Not just console (Score:2)
I happen to have an average of about 200 tabs open on most of my daily use machines. This tends to eat most of the resources that my machine has, regardless of how modern the machine is. If it's an old clunker, it chokes on less and I generally don't make it that far before I have to kill the browser and restart it. It seems impossible for any OS vendor and any "full featured" web browser to just deal with the limitations of the system and keep the application snappy and usable.
Sure, it is way faster if you load just a few pages, but I just don't close tabs I think I might need later. Bookmarks accumulate so fast and searching them is bothersome, let alone cleaning them out. Regardless of my reasons why I do it, I see a lot of people hit the limitations of the model in which speed is achieved by unlimited resource claiming and not by efficient coding, if it comes to web browsers. The reason that mobile is in the picture is because a mobile device is way less powerful and battery life is much more of a concern than for a desktop or AC powered laptop.
I wish they would test "speed" by simultaneously loading 200 tabs of content-rich web pages on a single core system with 512M ram available to the browser and a slow magnetic media drive (5400rpm laptop drive) for storage. In my opinion, it would be a way more realistic test than just loading a single page, keeping everything in RAM and only looking at methods that will bottle neck at CPU/GPU or memory access. I bet that "speed improvements" in the JS engine would suddenly come from very different optimizations than from the current philosophy and that they would greatly benefit "mobile" too.
Re:Not just console (Score:2)
Re:Not just console (Score:2)
Exactly, i do all of the above. Except i do pull up a new browser (row of tabs) to seperate unrelated groups of tabs.
Re:Typical console developer rant, IMO. (Score:2)
The funny thing is that he's recommending Automatic Reference Counting instead, which destroys cache much more than GC during regular processing.
Re:Typical console developer rant, IMO. (Score:3)
> Talks usually end up in most of them dismissing scripting languages, higher level APIs (such as OpenGL),
A few years back I've implemented OpenGL on the Wii and did maintenance work on our OpenGL version running on the PS2. Hell, even shipped a couple of games with it. OpenGL 1.x _can_ be implemented efficiently on a console if you apply some discipline. People who dismiss a rendering pipeline probably have never implemented one. HOWEVER, their point is that memory manage CAN be an issue if one isn't careful. ( NOTE please don't confuse the misapplication with the theory: Broadcom has a garbage implementation of OpenGL ES 1.x & 2.x across there devices from the ones I've worked with, but there is no reason it needs to be that bad. Apple has a very nice OpenGL ES implementation.)
> I'm probably going to get downvoted as troll, but my experiences with most console developers were often strange (as a developer myself).
> 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),
No, the reason you should get down modded is BECAUSE your mindset is part of the problem not the solution,
1. You don't understand the first rule of computing:
TINSTAAFL: There Is No Such Thing As A Free Lunch.
I do not know to the extent you are but lazy developers are spoiled by their excessive Virtual Memory, slow high level languages, and including every bloated 3rd party library under the sun and the kitchen sink that OVERALL add to a SLOW machine. Great developers _constantly_ keep optimizations a low priority THROUGHOUT the writing process in the background so they don't have go and clean up all the crap later. Your mentality of "we will fix it later" is the sign of an immature and inexperienced programmer.
2. Your boss / peers are trying to teach you an important lesson:
Do It Right The First Time!
and
Keep is Simple, silly!
THAT is the point -- not your uneducated rant about "Who cares about memory usage, memory fragmentation, garbage collection, memory leaks, cpu cycles, etc." -- well your USER does EVEN if they don't understand the technical terms. ONCE you say the user experience is no longer important you have FAILED as a programmer. People are the SOLE reason software even exists in the first place. Please stop this shitty attitude that "performance doesn't matter -- we'll just throw more hardware at it." No! NO! NO! How about doing the best* with what you have instead?? ALL your code should be (relatively) clean, simple, fast, efficient. This has the side-effect that it is EASY to maintain to boot! Who wouldn't want. And you are going to make excuses that you can't be bothered???
* Apply the 80/20 rule for time-management in case it wasn't obvious.
To bring this back on topic, Javascript is a badly designed & implemented language because of
a) lack of memory control which leads to memory fragmentation and bloat, and
b) lack of types and which forces the run-time to do extra unnecessary work if they had designed the language properly in the first place.
There is a time and place for everything. Just never forgot to keep asking the questions: Can we do this better?
--
"Necessity is the Mother of Invention, but Curiosity is the Father." -- Michaelangelo
Re:Typical console developer rant, IMO. (Score:2)
Re:Typical console developer rant, IMO. (Score:2)
your mindset is part of the problem not the solution,
Your mentality of "we will fix it later" is the sign of an immature and inexperienced programmer.
1. You don't understand the first rule of computing:
2. Your boss / peers are trying to teach you an important lesson:
you have FAILED as a programmer
Please stop this shitty attitude
THAT is the point -- not your uneducated rant
And you are going to make excuses that you can't be bothered???
I'm so sorry, I'll never do it again!
Obvious (Score:2)
The one thing I can't wrap my head around is if it was made a "real" language, would it be a gigantic security disaster? Or could it be limited enough to not turn into Flash, Java, etc?
Re:Obvious (Score:2)
What happened to languages that pick some things and then do them well? JavaScript seems to have evolved to try to do everything, and yet it doesnt do anything even close to well at all.
node.js (Score:5, Funny)
Re:Obvious (Score:2)
Crisis Averted! (Score:5, Insightful)
Bikeshedding = Slashdot (Score:3)
https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality [wikipedia.org]
Re:Bikeshedding = Slashdot (Score:2)
One thing that's horribly slow on my iPad (Score:2)
Animated GIFs.
I think they're of the devil, but for some reason a lot of baseball stat heads still use them instead of a video format when they want to post a few seconds of a game for illustrative purposes. It's weird because these are generally young guys, not the old farts who you'd expect not to have changed their workflow since 1995...
JavaScript on the iPad? That doesn't seem slow - certainly not enough to where it registers anyway.
Supported by more browsers (Score:2)
for some reason a lot of baseball stat heads still use [GIF animations] instead of a video format
Some browsers can view only H.264 and animated GIF. Other browsers can view only Theora, WebM, and animated GIF. Some, such as the latest version of Internet Explorer that runs on Windows XP, can't view anything but animated GIF without plug-ins that may or may not be installed and that the current user may or may not have privileges to install. If the only video format supported by all browsers is animated GIF, what should a site use to reach the most viewers?
but it's slow (Score:2)
Re:but it's slow (Score:2)
Re:but it's slow (Score:2)
Maybe because animated GIF has been reasonably performant on x86 browsers since the 486 days.
More Full Response (Score:5, Insightful)
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.
Re:More Full Response (Score:2)
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 other issue you're not addressing it runtime memory requirements. From the GC performance chart, the best performing GC that provides near native performance does so by requiring 5x more memory. This is going to impact the number of concurrently running apps on your phone/tablet before things start slowing down. Users prize snappy interfaces and if their mobile device slows down then the knowledgable users will bring up a task manager to figure out what's going on.
Do you want to stick around to see what they'd write on your app's page in the App Store?
Re:More Full Response (Score:2)
I think you're overstating the case of performance verses responsiveness. He does specifically point out that GC is negatively impacting UI response times and that that is not going to work.
I agree with you that people who work in the problem space know about memory management by experience. However, that JavaScript makes it so difficult to manually manage memory seems to be his real point.
Lastly, if we could solve the network speed problem, you would just outsource real CPU/memory apps to the server and simply RDP* the relevant bits back to the mobile device.
-l
* RDP or whatever protocol makes the most sense. I just used RDP to get the example across.
Re:More Full Response (Score:2)
Lastly, if we could solve the network speed problem
That sounds like a big problem, especially through the air....
Re:More Full Response (Score:2)
If you allocate memory during your animation routines in a game you're asking for trouble, regardless of the language.
That's not true at all. If you allocate memory during animation in a language with deterministic memory management, you have a pretty good understanding of what it'll cost and whether you can afford it (and in many cases, the answer is yes).
Note that animations are not specific to games. One common case where you allocate memory during an animation is when the user is scrolling a list that is backed by a dynamic data store (i.e. items are generated "on the fly").
More importantly, the problem with GC is not allocation, it's deallocation (or rather the object graph walk that precedes it). You might have not allocated anything inside your animation loop, but you have surely allocated something at some point in the past. You have no guarantee that the GC does not decide to kick in, pause your loop, and do a graph walk to clean that up, if e.g. the OS reports that it's low on memory.
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.
I would argue it's exactly the other way around: author focuses on responsiveness, and brings performance largely as part of the discussion about responsiveness. That's precisely why he dedicates so much time specifically to GC, and comparatively little on other things that affect raw perf (like dynamic typing) - because GC and responsiveness don't mix well.
TLDR version (Score:5, Informative)
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.
Re:TLDR version (Score:2, Informative)
Your super short summary was still 3 paragraphs long... TL;DR indeed!
Re:TLDR version of TLDR version (Score:2)
Something wrong here (Score:2)
Re:Something wrong here (Score:2)
Both submissions Opera is ignored (Score:2)
Opera browser (versions up to 12) was shown on one graph (iphone 4S) in the article and it kicked some serious a$$ but never mentioned again.
One reply to the article was about Opera being only browser to run Google Wave, kind of... "The only browser that ran it with anything resembling
“speed” for it’s first year or so was Opera, and Opera never really worked very well with it anyway."
I enjoy security through obscurity but Opera is just too good a browser to ignore.
It's more about developers than technology (Score:2)
Bottom line: just because you're using a GC'd language and you CAN ignore memory management, doesn't mean you SHOULD. That goes for JS, Java or any other GC'd language in existence.
I hate to go off on a tangent... but that won't stop me from doing so, because I think it's actually the core of the issue and is entirely non-technical:
This all goes back to the abysmal state of many (most?) "modern" developers.
If you grew you with computers at the time I did, the late 70's/early 80's, and you learned to program those early 8-bit home computers, you kinda take this stuff for granted (memory management I mean). You just inherently think differently than "modern" developers do. You see things at a much lower level... even when you're working at a high level of abstraction, your mind automatically goes lower... instantiating an object in Java? You're mind at some level is thinking about how memory is being allocated, how the object reference is being stored, etc. Hell, you even start to think about the messages the OS is passing around, how those messages must map to C functions, and how those functions ultimately resolve down to assembly.
I'm NOT saying you KNOW all those details... not really... you just know the concepts... and I'm certainly not saying such details are relevant most of the time because they're not... I'm just saying that's the way our brains work... we can "see" all the levels below the one we're actually working on in our minds' eye, if only in a conceptual sense, and it happens without trying.
I's because we generally started learning at those low levels and everything over the years has built up logically from there. Most of us started with BASIC but quickly jump to Assembly because that was the only way to achieve what we really wanted to (games, mostly). Once you're at that level, it's an entirely different mindset. Those of us that also had an electronics background go a step further because we even go below the Assembly level sometimes (and that wasn't all that uncommon back then... of course, the electronics were considerably simpler and easier to understand than they are now).
That's a VERY different evolution than the kid that STARTS with Java or JavaScript or whatever now, then goes to school and learns more high-level stuff. And it shows in daily work life all the time! I see people constantly in my career who aren't really bad developers, but they are, somehow, lacking... it usually shows when things aren't working as expected. They have a difficult time breaking things down and figuring out what's going on. Oh, they can Google an answer as well as anyone, and hey, probably 9 times out of 10 that's sufficient. But they're just stumped beyond belief that one time... they just can't get into the details and work the problem at a fundamental level. They don't REALLY understand how these machines, these operating systems, work. And that's a really bad state of affairs.
(to be fair, some of us that learned in the "ground-up" way sometimes have difficulty STAYING at a high level... we sometimes trip over discussions that are too abstract because our brains are searching for the details that aren't there, and really aren't even relevant... that's a whole other discussion, but it's a true phenomenon).
All of this... to try and pull it back to topic relevance... means that relatively simple things like designing your code to minimize object allocation and deallocation seems mysterious to a lot of modern developers... they don't always get why it's important, and it seems like some black art or something even when they do... to us old-schoolers, I guess that's what we are now, it's actually quite natural to think that way. Even in JavaScript, where I've done considerable work, and highly complex work, GC has never presented a big issue for me, primarily because I've ALWAYS thought about it and know how to avoid it at the right times. The language itself isn't flawed, modern developers' ability to use it effectively is.
We're proba
Owner-operator or slave (Score:2)
"How much memory is available on iOS? It’s hard to say exactly."
Exactly. Because it's an appliance. And you're either willing to take it apart and learn how it works so you can make it do what's needed, or you accept that you're an appliance operator and stop bitching about it.
What's better than JS? (Score:3)
Re:What's better than JS? (Score:5, Interesting)
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.
Re:What's better than JS? (Score:4, Informative)
Sorry. Things change. It won't be long before browsers are just wrappers around the JSVM and all web addresses are just sandboxed applications running in it. The web is the biggest App Store there is.
You want raw data in a structured format? There are REST APIs for that, they return JSON. HTML is too verbose by far as the default response and is useless for any other client besides an HTML renderer.
Text content is moving to Markdown as a standard as well. It's quicker and easier and covers text formatting. Clients should just render it directly.
I could go on but it's probably lost on you. Suffice to say that modern server app development is evolving to be service driven and client agnostic. HTML is one of many targets. Why write server apps or content engines (CMS/blog/forum) for a single client when you can instead create a server based API and several thin client apps (JS, DART, iOS, Android, C++, .Net, Lua, etc).
Re:What's better than JS? (Score:2)
So your big complaint is ads? You do know they are inevitable regardless of the tech employed. If HTML had never become the standard and everything was written in C++ you would still get ads. Look at iOS and Android apps. Look at the latest Ubuntu search (and Windows now too). There are ad supported (and malware linking) apps all over. It's even worse as they have less sandboxing and can cause more problems.
Re:What's better than JS? (Score:2)
"So your big complaint is ads?"
Did you really not even read the message you replied to?
He said (and I agree) that the problem is NOT ads. But if you choose to make your ads annoying javascript contraptions instead of readable text, THEN we will block your ads. And not feel bad at all about it. If you want us to see your ads, you know what to do.
Re:Wrong (malware in adbanners)... apk (Score:2)
Re:Wrong (malware in adbanners)... apk (Score:2)
Did you mean one comment at a time? (Score:2)
Dont force a single 100kB monster to begin with, doh.
Say a Slashdot story has 100 comments, and each comment is 1 kB. How should these comments be sent to the browser?
Break the monster down into bytesized chunks
Without JavaScript, you can't use AJAX, and without AJAX, you can't retrieve comments incrementally as the user requests them and add them to the page. Or are you talking about displaying one comment on each page the way certain mailing list archives do?
Hundreds of iframes make a page unresponsive (Score:2)
It's not the language that's the problem (Score:2)
Re:What's better than JS? (Score:3)
He doesn't, but he makes a good point that "2%" performance isn't good enough, and you should avoid javascript if you can.
I consider this most important for projects like Firefox OS, which are pushing a platform for slow, mobile devices, where Javascript is the only programming language available.
In my extensive experience, reloading the page every time is actually still FASTER and makes for a more responsive experience. Compare gmail with JS or in classic mode... Classic mode isn't as shiny, but it sure moves a lot faster. Or look at Netflix's queue... Insane delays from clicking the "move to top" arrow, until it actually happens, or the delete button, while reloading the page on each button press would happen in a fraction the time, and would work far better on low-end devices (and they wouldn't need a super-crippled "mobile" version of their site).
A tiny bit more load on your server, in exchange for a much more responsive client-side experience. A bit more bandwidth usage, but compression and caching of all other page elements should make it pretty insignificant.
Re:What's better than JS? (Score:2)
In my extensive experience, reloading the page every time is actually still FASTER and makes for a more responsive experience.
I agree with you that some sites using AJAX are poorly designed. I disagree that sites using AJAX must necessarily be slower than reloading the whole page for every little piddly action. Say you've landed on an article with 100 comments in the discussion section. Every time you expand or collapse a thread, the article and all 100 comments reload. Every time you begin, preview, or submit a comment, the article and all 100 comments reload. I don't see how that'd be so convenient for people on slow and/or metered Internet connections.
Re:What's better than JS? (Score:2)
That's been *almost* exclusively my experience.
That's assuming you WANT the threads loaded by your browsers, but hidden from your view for some reason. Instead, if you had the threads expanded, you wouldn't have to worry about it.
But if you're talking about JS loading each comment...
But see, you're still making the same number (or perhaps MORE) HTTP requests with JS as you would with plain HTML. Latency is in no way reduced, and you're not really saving time on the client side, as they've got the latency, and THEN the browser has to essential re-render the whole page after the content change in the middle. However browsers handle that kind of change, I've never seen it done FASTER than loading another static page.
As I said, the mod_gzip your HTML page is only 1/10th the uncompressed size, and all the CSS, images, etc., are all cached locally, so I say you're saving VERY, LITTLE bandwidth, and you're causing more client side delay and unresponsiveness.
Re:What's better than JS? (Score:2)
Re:What's better than JS? (Score:2)
A standardized (or at least, well-documented) protocol that anyone who cares can use to implement their own user interfaces
The protocol that the world appears to have standardized on for this purpose consists of HTTP, HTML, CSS, and JavaScript. Yet certain people continue with the phobia of JavaScript.
Re:What's better than JS? (Score:2)
The problem with that protocol is that it, to state things simply, sucks. Which is not surprising, given that it is an ad-hoc hodge-podge of technologies, most of which were not particularly good in the first place, and which were also used for the purpose their design did not originally anticipate.
It's basically one of the worst examples of design-by-mob: take random things that people know, put them together, and add a lot of kludges so that the whole thing works. Yes, it does work, but that's about the only good thing that can be said about it. It's certainly not a cause for celebration - at best it's something you grudgingly accept on a temporary basis, while working on a better solution.
Re:Bikeshedding (Score:2)
I think I had one of those at TGIFridays one time.
Re:thanks for sharing the link (Score:2)
This is in the spirit of that post, which identified the problem as RAM wastage. By posting it again, more RAM gets consumed for the same object.