I don’t often link to other articles, but this one is worth reading.
by Drew Crawford
… So if you are trying to figure out exactly what brand of crazy all your native developer friends are on for continuing to write the evil native applications on the cusp of the open web revolution, or whatever, then bookmark this page, make yourself a cup of coffee, clear an afternoon, find a comfy chair, and then we’ll both be ready.
He offers data (imagine!) to justly debunk many common memes and “easy answers” that routinely litter HN/Reddit/Slashdot comment threads. The piece is also often subtly (and intentionally) hilarious – do watch for the subtle humor, not just the obvious wit.
Don’t be distracted by the author’s viewpoint and emphasis on “iOS and Javascript” development – the article covers lots of important ground, including:
- developing for ARM vs. x86;
- developing for desktop vs. mobile;
- managed vs. native code performance;
- JIT issues vs. inherent language design tensions;
- why garbage collection is not at all the panacea it’s often billed to be and often needs to be emphatically avoided (did you realize Apple already jettisoned GC?); and
- as many of you know already, why if you’re serious about performance you’ll be seriously serious about memory usage and access patterns as a first-order issue.
I agree with most of it, and not just because he quotes from my When Will Better JITs Save Managed Code blog post from last year.
Recommended.
Spoilers
A few takeaways from the conclusion (spoiler alert):
Garbage collection is exponentially bad in a memory-constrained environment. It is way, way worse than it is in desktop-class or server-class environments.
Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.
asm.js show some promise, but even if they win you will be using C/C++ or similar “backwards” language as a frontend, rather than something dynamic like JavaScript
Sutter’s Mill 