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: (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: (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: (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: (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: (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: (Score:2)
Indeed, even Fark has had this feature for years and years.
-l
Re: (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: (Score:3, Funny)
<Ralphie Wiggam> The missing 'D' was used for my grade. </Ralphie Wiggam>
Re: (Score:3)
Re: (Score:3)
I'm glad I don't work with you, if you laugh at loud for every sentence you write.
Re: (Score:3)
I like the comma before "lol." Write sentence, little pause, bellylaugh. Classic.
Re: (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: (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: (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: (Score:2)
Re: (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: (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
Re: (Score:2)
Re: (Score:2)
Re: (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. An
Re: (Score:2)
Very, very well said, sir.
Re: (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: (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 language
Re: (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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (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: (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: (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: (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.
Re: (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: (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: (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: (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: (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
Re: (Score:2)
except this has nothing to do at all with my original post, nor the article, both about processor usage.
Re: (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
Re: (Score:2)
Re-read his second paragraph, AC.
Or did you just intend to troll and see how many moderators you could trick?
Re: (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: (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
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 yo
Re: (Score:2)
Re: (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: (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: (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'
Re: (Score:2)
Re: (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: (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: (Score:2)
Crisis Averted! (Score:5, Insightful)
Bikeshedding = Slashdot (Score:3)
https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality [wikipedia.org]
Re: (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: (Score:2)
Re: (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: (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 wha
Re: (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 si
Re: (Score:2)
Lastly, if we could solve the network speed problem
That sounds like a big problem, especially through the air....
Re: (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
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: (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: (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 progra
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: (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: (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: (Score:2)
Re: (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: (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.
Re: (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 mete
Re: (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...
Re: (Score:2)
Re: (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: (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 o
Re: (Score:2)
I think I had one of those at TGIFridays one time.
Re: (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.