Why JavaScript On Mobile Is Slow

An anonymous reader writes "Drew Crawford has a good write up of the current state of JavaScript in mobile development, and why the lack of explicit memory handling (and a design philosophy that ignores memory issues) leads to massive garbage collection overhead, which prevents HTML5/JS from being deployed for anything besides light duty mobile web development. Quoting: 'Here’s the point: memory management is hard on mobile. iOS has formed a culture around doing most things manually and trying to make the compiler do some of the easy parts. Android has formed a culture around improving a garbage collector that they try very hard not to use in practice. But either way, everybody spends a lot of time thinking about memory management when they write mobile applications. There’s just no substitute for thinking about memory. Like, a lot. When JavaScript people or Ruby people or Python people hear "garbage collector," they understand it to mean "silver bullet garbage collector." They mean "garbage collector that frees me from thinking about managing memory." But there’s no silver bullet on mobile devices. Everybody thinks about memory on mobile, whether they have a garbage collector or not. The only way to get "silver bullet" memory management is the same way we do it on the desktop–by having 10x more memory than your program really needs.'"

Comments

That's just not a viable option.

[Anonymous Coward]

Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.

Even if you don't use jQuery, for example, you're going to need to find and then use some other library that does the same thing, or write a whole shitload of code yourself to implement the same functionality. Zepto works as an alternative for some people, but even it still has some overhead.

That applies to almost anything you want your app to do. If you want to work with objects, arrays or even strings in any way beyond the simplest of manipulations, you're going to need to use some third-party code, or write a whole lot of it yourself.

JavaScript developers are so wholly dependent on these third-party libraries because the JavaScript implementations themselves are so bloody lacking. It's totally different than a language like Python, where there's a rich, yet still compact and efficient, standard library that developers know will be available on just about every user's system. JavaScript programmers have to provide this basic infrastructure with each and every app they write.

Re:That's just not a viable option.

[snadrus]

The last major jQuery jump dropped IE8 & older support because there were too many quirks they didn't want to bloat everyone's use of the lib with.

Re:That's just not a viable option.

[Kielistic]

Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.

Pure bullshit. Ignoring the glaring fallacy of "I've seen amateurs do bad things so jQuery is bad" I will just comment on it being difficult to maintain. Javascript in general is difficult to maintain in a large web application. jQuery makes things easier because it provides a fairly consistent syntax for common things you would likely do in a web application.

Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.

Their future branch has cut off support for legacy browsers. This is for people who don't need them and to ease production of new features. They still maintain the 1.x line that fully supports IE8. This is where it is clear you are talking from inexperience and flat out lying to avoid admitting you've been less than truthful. It is very rare you ever see jQuery do something inconsistently between the common browsers. Definitely less than you see vanilla javascript being inconsistent.

The ONLY reason you see jQuery used today is that those same developers never bothered to learn JavaScript. They assume jQuery saves them time and effort (it does not, it costs them time both early and in the long term) because that's what they were told years ago.

Explain how jQuery doesn't save time? It is a framework that provides common functionality that people want from Javascript. So without a framework your options are to re-write that functionality every time you want it or build your own framework. Both of those options will be less maintainable in the long-run and far more bug-prone (being less tested etc). You can't just keep claiming "jQuery bad; reinvent wheel good" with some handwaving about performance and amateurs and blathering on about how much smarter you are for using vanilla Javascript instead.

Fortunately, developers are starting to realize that they've been fooled and are actually starting to learn JavaScript.

Or maybe Javascript has started to become consistent enough and functional enough for specific tasks that people can easily use it for simple tasks now. People that don't have to worry about any kind of legacy support that is.

With any luck, by 2015 we might not have jQuery bogging down the web.

With any luck by 2015 we won't have Javascript bogging down the web. It is a language that is not a good match for what it is used for in this case.

Re:always

[Anonymous Coward]

You think about it a *lot* less in a garbage collected language. There's a big difference between occasionally realizing one part of your system is using a lot of memory and spending time almost every day asking if something will leak or double free.

But they're correct that generational garbage collection uses more RAM to solve the same problems. Usually even if it's compacting.

Re:CPython uses reference counting, like objective

[EvanED]

As opposed to the standard mark and sweep garbage collecting like those in Java where every few seconds everything grinds to a hold to clean up memory.

Not to say that tracing collectors don't have a bit of a stuttring problem and I don't want to get into tracing vs reference counting, but:

1) Decent tracing collectors (and the Java VM has had one for a while) are not nearly as bad as you make them out to be, and

2) You mean "tracing collector" rather than mark-and-sweep. The latter is just the simplest form of tracing collectors, which is really pretty bad and is essentially never used. The JVM uses a generational collector, .Net uses a semispace collector (I think), all three of which differ pretty significantly in both mechanics and performance characteristics.

The second point is a bit pedantic and in many stories I probably wouldn't even reply, but in a discussion that is basically specifically about GC it is a good idea to use correct terminology.

This is why I write my own JS

[FuzzNugget]

This is why, for anything other than very obscure and complicated functionality that would put a project way over budget, I write my own JavaScript. That includes AJAX functions, dynamic element management, form data collection and processing and all the fancy stuff that jQuery makes super easy.

Because when you use a generalizing library or framework, you trade convenience for performance and contribute to the continual problem of lazy programmers relying on unnecessarily powerful hardware.

Currently, jQuery loads 90+ KB of JavaScript and processes a whole lot of it every time you invoke functionality that uses it. Similarly capable CMS tools I've built load ~30KB of original JavaScript and only run the relevant functions when called, rather than parsing through and jumping around reams of nested and interdependent routines.