Why JavaScript On Mobile Is Slow 407
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.'"
Easy (Score:5, Interesting)
Stop loading dozens of fucking libraries and frameworks and learn to really code.
Re:That's just not a viable option. (Score:3, Interesting)
I really do appreciate a good framework... My favorite one currently is Vanilla-js http://vanilla-js.com/ [vanilla-js.com]
Check it out. Amazing performance.
How about giving some examples, son? (Score:1, Interesting)
Yeah, we know about document.querySelector(). It's still limited and more of a pain in the ass to use than jQuery's $().
Here's what you're going to do, son. You're going to go through these lists of library functions, and you're going to list the native equivalent, and how well it's supported by the major browsers:
http://api.jquery.com/ [jquery.com]
http://underscorejs.org/ [underscorejs.org]
http://mochi.github.io/mochikit/doc/html/MochiKit/index.html [github.io]
We're even starting easy, and just giving you three JavaScript libraries to cover. Remember, you have to do this analysis for each and every one of those functions.
I sure hope that you don't give up once you realize how wrong you are with your bullshit claim that "every feature has a native equivalent that works across browsers".
Oh, and if you don't prepare this comparison and have it ready within a few hours, we're going to know that you're wrong and that you're full of shit, son.
Re: Mobile is not a special case (Score:4, Interesting)
10 years ago, desktop computers didn't page to hard drive sectors with half-lives of 100k writes or less, and siphon the bits through a single-bit (SPI/MMC mode) or 4-bit wide (SD-mode) cocktail straw. As a few guys @ XDA learned the hard way, micro-SD wear-leveling is NOWHERE close to being as robust as what's in a desktop SSD, and onboard flash (like what's in the Nexus 4) might not have "SSD" logic *at all* (leaving its management *entirely* up to the OS to cut costs). Vigorously swap to a mostly-full microSD card, and you can *literally* push it into "hard error" land and end up with weakened cells in just one single weekend of aggressive benchmarking. Blindly swapping to internal or microSD flash desktop-style is NOT consequence-free, and is *totally* unsafe to do on any phone without microSD (at least end users can toss & replace a worn-out microSD card).
Re:That's just not a viable option. (Score:5, Interesting)
I'm giving up moderation to post this but it has to be said. You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow. Both jQueryUI and jQueryMobile are designed to completely change (and unify) what the browser controls look like. Of course they are slower than native. I even went to your little site and ran this one : http://jsperf.com/jquery-body-vs-document-body-selector [jsperf.com]. jQuery came up about 5%-6% slower than native. If you give up a unified, well tested framework and a tenth of the development time for a 5% speedup you are either working on something very special or need to be fired immediately.
jQuery is not a performance killer. If it was you wouldn't see it on nearly every website more complicated than "hi my name is narcc". What it does do, however, is cut development time considerably. Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions. And provides far more web-specific features that Javascript does not (otherwise people wouldn't use it).
I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.
Just for fun: Just look at how readable and maintainable that code is. I'd love to try to figure out why a $100000 web-application isn't working in BroswerX 10 months after somebody else wrote it written like that.
Additionally: if you are doing 2+ million operations than yes maybe you might want to devote some time to writing a specialized function. But normally you're only doing less than 50 on a fairly complicated web-app so your benchmarks won't show too much of a difference there.
Just for my own fun. What happens if you go : document.querySelector('.menu > a:last') in IE9?