Category: Web

Recommended reading: Why mobile web apps are slow (Drew Crawford)

I don’t often link to other articles, but this one is worth reading.

Why mobile web apps are slow

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

“Mobile” vs. “PC”?

In answering a reader question about Flash today, I linked to Adobe’s November press release and I commented:

Granted, Adobe says it’s abandoning Flash ‘only for new mobile device browsers while still supporting it for PC browsers.’ This is still a painful statement because [in part] … the distinction between mobile devices and PCs is quickly disappearing as of this year as PCs are becoming fully mobilized.

But what’s a “mobile device” vs. a “PC” as of 2012? Here’s a current data point, at least for me.

For almost two weeks now, my current primary machine has been a Slate 7 running Windows 8 Consumer Preview, and I’m extremely pleased with it. It’s a full Windows notebook (sans keyboard), and a full modern tablet. How do I slot it between “mobile device” and “PC,” exactly? Oh, and the desktop browser still supports Flash, but the tablet style browser doesn’t…

Since I’ve been using it (and am using it to write this post), let me write a mini-review.

I loved my iPad, and still do, and so I was surprised how quickly I came to love this snappy device even more. Here are a few thoughts, in rough order from least to most important:

  • It has a few nice touches that I miss on iOS, like task switching by simple swipe-from-left (much easier than double-clicking the home button and swiping, and my iPhone home button is started to get unreliable with all the double-clicking [ETA: and I never got used to four-finger swiping probably in part because it isn’t useful on the iPhone]), having a second app open as a sidebar (which greatly relieves the aforementioned back-and-forth task-switching I find myself doing on iOS to refer to two apps), and some little things like including left- and right-cursor keys on the on-screen keyboard (compared to iOS’s touch-and-hold to position the cursor by finger using the magnification loupe). In general, the on-screen keyboard is not only unspeakably better than Win7’s attempt, but even slightly nicer than iPad’s as I find myself not having to switch keyboards as much to get at common punctuation symbols.
  • I was happily surprised to find that some of my key web-related apps like Live Writer came already installed.
  • The App Store, which isn’t even live yet, already had many of my major apps including Kindle, USA Today, and Cut the Rope. Most seem very reliable; a few marked “App Preview” are definitely beta quality at the moment though. The Kindle app is solid and has everything I expected, except for one complaint: It should really go to a two-column layout in landscape mode like it does on iPad, especially given the wider screen. Still, the non-“preview” apps do work, and the experience and content is surprisingly nice for a not-officially-open App Store.
  • Real pen+ink support. This is a Big Deal, as I said two years ago. Yes, I’ve tried several iPad pens and apps for sort-of-writing notes, and no, iOS has nothing comparable here; the best I can say for the very best of them is that they’re like using crayons. Be sure to try real “ink” before claiming otherwise – if you haven’t, you don’t know what you’re missing. iPad does have other good non-pen annotation apps, and I’ve enjoyed using iAnnotate PDF extensively to read and annotate almost half of Andrei’s D book. But for reading articles and papers I just really, really miss pen+ink.
  • All my software just works, from compilers and editors to desktop apps for full Office and other work.
  • Therefore, finally, I get my desktop environment and my modern tablet environment without carrying two devices. My entire environment, from apps to files, is always there without syncing between notebook and tablet devices, and I can finally eliminate a device. I expected I would do that this year, but I’m pleasantly surprised to be able to do it for real already this early in the year with a beta OS and beta app store.

I didn’t expect to switch over to it this quickly, but within a few days of getting it I just easily switched to reading my current book-in-progress on this device while traveling (thanks to the Kindle app), reading and pen-annotating a couple of research papers on lock-free coding techniques (it’s by far my favorite OneNote device ever thanks to having both great touch and great pen+ink and light weight so I can just write), and using it both as a notebook and as a tablet without having to switch devices (just docking when I’m at my desk and using the usual large monitors and my favorite keyboard+mouse, or holding it and using touch+pen only). It already feels like a dream and very familiar both ways. I’m pretty sure I’ll never go back to a traditional clamshell notebook, ever.

Interestingly, as a side benefit, even the desktop apps are often very, and more, usable when in pure tablet+touch mode than before despite the apparently-small targets. Those small targets do sometimes matter, and I occasionally reach for my pen when using those on my lap. But I’ve found in practice they often don’t matter at all when you swipe to scroll a large region – I was surprised to find myself happily using Outlook in touch-only mode. In particular, it’s my favorite OneNote device ever.

By the end of this week when I install a couple of more apps, including the rest of my test C++ compilers, it will have fully replaced my previous notebook and my previous tablet, with roughly equal price and power as the former alone (4GB RAM, 128GB SSD + Micro SD slot, Intel Core i5-2467M) and roughly equal weight and touch friendliness as the latter alone (1.98lb vs. 1.44lb). Dear Windows team, my back thanks you.

So, then, returning to the point – in our very near future, how much sense does it really make to distinguish between browsers for “mobile devices” and “PCs,” anyway? Convergence is already upon us and is only accelerating.

Reader Q&A: Flash Redux

David Braun asked:

@Tom @Herb: What’s so wrong with flash that it should be boycotted? Have I been being abused by it in some way I’m not aware of? Also,does HTML5 have any bearing on the subject?

I’m not saying it should be boycotted, only that I avoid it. Here’s what I wrote two years ago: “Flash In the Pan”.  Besides security issues and crashing a lot, Flash is a headache for servicing and seems to be architecturally unsuited for lower-power environments.

Since then, two more major developments:

1. Even Adobe has given ground (if not given up).

Adobe subsequently abandoned Flash for mobile browsers and started shipping straight-to-HTML5 tools.

Granted, Adobe says it’s abandoning Flash ‘only for new mobile device browsers while still supporting it for PC browsers.’ This is still a painful statement because:

  • it’s obvious that ceding such high-profile and hard-fought ground sends a message about overall direction; and
  • the distinction between mobile devices and PCs is quickly disappearing as of this year as PCs are becoming fully mobilized (more on this in my next blog post).

2. We’re moving toward plugin-avoiding browsing.

Browsers are increasingly moving to reduce plugins, or eliminate them outright, for security/reliability/servicing reasons. Moving in that direction crease pressure or necessity to either:

I’m not saying Flash will die off immediately or necessarily even die off entirely at all; there’s a lot of inertia, it’s still useful in many kinds of devices, and it may well hang on for some time. But its architectural problems and current trajectory are fairly clear, and it’s been months since I’ve heard someone complain that certain people were just being unfair – Jobs’ technical points are on the right side of history.

Talk Video: Welcome to the Jungle

Last month in Kansas City I gave a talk on “Welcome to the Jungle,” based on my recent essay of the same name (sequel to “The Free Lunch Is Over”) concerning the turn to mainstream heterogeneous distributed computing and the end of Moore’s Law.

Perceptive Software has now made the talk available online [EOA: the talk itself starts six minutes in]:

Welcome to the Jungle

In the twilight of Moore’s Law, the transitions to multicore processors, GPU computing, and HaaS cloud computing are not separate trends, but aspects of a single trend – mainstream computers from desktops to ‘smartphones’ are being permanently transformed into heterogeneous supercomputer clusters. Henceforth, a single compute-intensive application will need to harness different kinds of cores, in immense numbers, to get its job done. – The free lunch is over. Now welcome to the hardware jungle.

I hope you enjoy it.

Warning: It’s two hours (with Q&A) because of the broad and deep material. There’s a nice pause point between major sections at the one-hour mark that makes it convenient to split it into two one-hour lunchtime brownbag viewings.

Links I enjoyed this week: Flash and HTML5

These are the two best links I’ve read in the wake of the Flash and HTML5 brouhaha(s). They discuss other informative points too, but their biggest value lies in discussing three things, to which I’ll offer the answers that make the most sense to me:

  • What is the web, really? “The web” is the cross-linked content, regardless of what in-browser/PC-based/phone-based generator/viewer/app is used to produce it and/or consume it.
  • Does web == in-browser? No. Native apps can be web apps just as much so as in-browser ones, and increasingly many native apps are web apps. Conversely, not everything that runs in a browser is part of the web, even though most of them are for the obvious historical reasons.
  • Is it necessary/desirable/possible to make in-browser apps be like native apps? No, maybe, and maybe. The jury is still out, but at the moment developers are still trying while some pundits keep decrying.

Here are the two articles.

Understand the Web (Ben Ward)

This rambly piece needs serious editing, but is nevertheless very informative. Much of the debate about Flash and/or HTML5 conflates two things: the web, and application development platforms. They aren’t the same thing, and in fact are mostly orthogonal. From the article:

Think about that word; ‘web’. Think about why it was so named. It’s nothing to do with rich applications. Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it.

… [in the confused Flash and HTML5 debates] We’re talking about two very different things: The web of information and content, and a desire for a free, cross-platform Cocoa or .NET quality application framework that runs in the browsers people already use.

On a different note, speaking of the desire for super-rich in-browser apps, he adds:

Personally, aside from all of this almost ideological disagreement over what the web is for, and what you can reasonably expect it to be good at, I honestly think that ‘Desktop-class Web Applications’ are a fools folly. Java, Flash, AIR and QT demonstrate right now that cross-platform applications are always inferior to the functionality and operation of the native framework on a host platform. Steve Jobs is right in his comments that third-party frameworks are an obstacle to native functionality.

HTML5 and the Web (Tim Bray)

Again, what “the web” is – and it has nothing specifically to do with HTML. From the article:

The Web is a tripod, depending critically on three architectural principles:

  • Pieces of the Web, which we call Resources, are identified by short strings of characters called “URIs”.

  • Work is accomplished by exchanging messages, which comprise metadata and representations of Resources.

  • The representations are expressed in a number of well-defined data formats; you can count on the message data to tell you which one is in use. It is essential that some of the representation formats be capable of containing URIs. The “Web” in WWW is that composed by the universe of Resources linked by the URIs in their representations.

That’s all. You notice that there’s nothing there that depends crucially on any flavor of HTML. Speaking only for myself, an increasingly large proportion of my Web experience arrives in the form of feed entries and Twitter posts; not HTML at all, but 100% part of the Web.

On Flash · This may be a side-trip, but anyhow: I entirely loathe Flash but by any definition it’s part of the Web. It works just fine as a resource representation and it can contain URI hyperlinks.

… Native Applications · A large proportion of the native applications on iPhone, and on Android, and on Windows, and on Mac, and on Linux, are Web applications. They depend in a fundamental way on being able to recognize and make intelligent use of hyperlinks and traverse the great big wonderful Web.

… So whatever you may think of native applications, please don’t try to pretend that they are (or are not) necessarily good citizens of the Web. Being native (or not) has nothing to do with it.

Good stuff.

“Readability”

If you like reading just about anything on the web, including my articles, in a pretty nicely rendered plain format with no ads or other distractions, you might want to try out arc90’s Readability.

All you do is drag a bookmarklet to your bookmark bar, and then on any article-like web page you can click on the bookmarklet to turn this:

image

into this (with a few choices each for font, size, and margin):

image

This lets you gain a lot in readability when all you want to do is read the article itself with basic text and graphics rendered fairly nicely. You do lose a little formatting, such as colored text which I sometimes use in my articles’ code examples, but the overall effect is pretty nice.

I’ll keep trying Readability out, especially on smaller-than-desktop screens, to see if it’s a keeper. So far the overall effect is pretty nice. Thanks to James P. Hogan for the tip, even if the link his page gives is broken.

 

Note: If you’re using Mobile Safari (i.e., iPhone or iPad) you’ll need to do a little bit more work because that software doesn’t currently support dragging the bookmarklet to its bookmark bar. Fortunately, there’s a workaround:

  • Find the Javascript code. I just made the bookmarklet on a desktop browser and copied the code from there to an email to myself (some things are faster with a keyboard and mouse). Alternatively you can inspect the HTML using HTML Viewer right on the same device as Mobile Safari and cut-and-paste from that.
  • In Mobile Safari, make a new bookmarklet.
  • Edit it, and paste the Javascript code as the URL.

As has been true since the early Mac days in the 1980s, Apple products and SDKs make every piece of functionality either super easy if it’s supported, or super painful if it’s not. :-)

Pre-emptive snarky comment: Yes, I know some people will retort that Microsoft and Linux products are better, because at least they consistently make everything super painful all of the time… but I think that’s only half true.