Are mobile web apps really slow?

http://danbricklin.com/log/2013_06_19.htm#jsspeed

by fpgeek • 13 years ago

87 56 13 years ago

anon1385• 13 years ago

So, one argument in favor of web apps is that many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation. Browsers are constantly being upgraded more and more of this important functionality built-in, including rich-text editing

Many tough-to-program things like rich text editing have also been implemented for you in native frameworks. For example see the source of TextEdit[1], it does not implement a rich text editing control from scratch, it uses NSTextView and the other NSText* classes.

Only slowly has Objective-C been seeing strings and hash-tables becoming more than libraries accessed like other objects. This means that handling of modern cases (e.g., characters taking up more than one byte) happens naturally, efficiently, and hopefully more bug-free

NSString has supported NSUTF8StringEncoding since OS X 10.0 (and I imagine since before that). Dictionaries and arrays did recently get some syntactic sugar, but strings have always had the @"" syntax, so I'm not sure what the author is referring to here.

[1] https://developer.apple.com/library/mac/#samplecode/TextEdit...

pjmlp2• 13 years ago

In these type of discussions they tend to selectively ignore all what the desktop has brought to the development and what is possible in native code frameworks.

saurik2• 13 years ago

As do the people on the other side of the discussion; it is really best to just ignore these discussions ;P.

millstone• 13 years ago

This means that handling of modern cases (e.g., characters taking up more than one byte) happens naturally, efficiently, and hopefully more bug-free.

This isn't true at all, right? JavaScript is missing fundamental Unicode support, like normalization or testing for canonical equivalence.

saurik2• 13 years ago

JavaScript doesn't even handle "characters taking up more than one byte" once you abstract to "more than one X" (or, alternatively, "more than two bytes"): JavaScript strings are really binary 16-bit numeric arrays, which frankly is even worse than using 8-bit numeric arrays as developers are much more likely to throw up their hands and claim "those characters don't happen often enough for me to dirty up my beautiful code" (the response I seriously got when I started working on patches to support UTF-16 for ACE; it was really annoying and horribly disappointing: they seemed to believe they could just ignore the problem in general and solve it at the edges, which is a total misunderstanding of the scope of the issue).

In essence, JavaScript's string is no better than C++11's std::u16string, and in fact is even worse as the language doesn't provide anything similar to std::codecvt, so you are stuck implementing UTF-16 conversions yourself in a language that doesn't even have an integral data type :(. (Incidentally, Java's String also sucks at this, so it isn't like the "native applications" side of this argument is doing so well, with C++ and Java both down for the count; only Objective-C has a real Unicode-compliant NSString class.)

coldtea5• 13 years ago

Browsers are constantly being upgraded more and more of this important functionality built-in, including rich-text editing

I don't see any "rich-text editing" widgets built-in in browsers.

And even if that was the case (that they are available in some) it has been 18+ years we've have had to put with BS solutions like the common "rich-text editors" found in most Content Management Systems: slow, buggy, crappy output AND brittle.

jsnell• 13 years ago

What do you consider contenteditable=true if not a rich text editing widget?

portmanteaufu2• 13 years ago

I think typically "Rich Text Editing" includes controls for presentational aspects: fonts, colors, weights, etc. Contenteditable only lets you change the text itself.

coldtea5• 13 years ago

A barebones, 1992 quality, text edit field, with some formatting thrown in.

Nothing like a "rich text editing widget".

hamidpalo2• 13 years ago

Speed is only one of the tradeoffs. You also lose access to the native interactions, controls, transitions etc.., which makes a lot of the mobile web apps be very alien to the users since they don't really quite fit with the rest of the apps.

I am curious, can anyone point to an well-done mobile web app? The best way to shut up all of us yelling "js is worthless for mobile development" is to point to such apps and explain how they were made.

camus3• 13 years ago

Especially with Ios redesign , this is going to hurt , quite a lot, for some devs who tried to fake native feel. It's just difficult to reproduce in HTML5 CSS3.

RyLuke• 13 years ago

See https://news.ycombinator.com/item?id=5953345 for a discussion of a well-done performant mobile web app.

hamidpalo2• 13 years ago

Thanks!

williamcotton2• 13 years ago

Check out http://forecast.io

coldtea5• 13 years ago

For most of what we are talking about, JavaScript does not execute in a vacuum. It runs in a browser. That browser environment brings a lot to the table. The applications you are coding are often ones that lend themselves to what a browser is good for: Presenting information.

We already covered this too. Apps that are just about "presenting information" (your typical CRUD stuff, or glorified CRUD, from Gmail to twitter clients), are plenty fast.

Mobile web apps are really slow for those OTHER uses. Anything with multimedia for one.

smackfu2• 13 years ago

At heart, arbitrary distinctions like that end up just being "apps that run well" vs "apps that run badly". And no matter how good the system, there will always be some apps in both camps.

coldtea5• 13 years ago

At heart, arbitrary distinctions like that end up just being "apps that run well" vs "apps that run badly". And no matter how good the system, there will always be some apps in both camps.

What's "arbitrary" about the distinction? Any app that depends on CPU intensive work, with high memory overhead, that doesn't want to be interrupted by GC pauses, will be slow as web based mobile app.

It's a technical distinction. The only reason it's somewhat generic, is that nobody can tell in advance which app belongs in which camp, until we know what the app needs to do.

For a specific app, with known requirements, whether it'll be slow as a web app or not, is anything but arbitrary. E.g "Can I write an image editor as a mobile web app, editing 5MP images with filters etc?", "No, you can't, it will be dog slow".

Sure, you can write a slow native mobile app too. But that's beside the point. We're talking about apps written properly in both cases here. That is, what are the limits of an app in each case.

camus3• 13 years ago

The problem again is not really javascript, it is DOM manipulation. You can have the fastest javascript engine ever,if the bottelneck is the DOM , there is little you can do about it. And everybody doesnt own a quad-core mobile.

I like Titanium approach where the ui is native and the code is javascript,so you are basically using javascript with a specific API,not the DOM. I'd like to see more frameworks like this , or even , i'd like mobile os vendors to faciliate the use of their native framework with javascript, instead of having to use HTML5 in a webview for development. I believe that's what WP is doing. As much as i h*te MS , it is a good move.

gummydude• 13 years ago

Ubuntu QML. http://www.ubuntu.com/phone/app-ecosystem

ecopoesis• 13 years ago

Do you have any proof that DOM manipulation is slow? This is a common refrain that I've never seen proof of (other then anecdotally). There are folks saying that the DOM is fast, and how the JS we use to manipulate it is slow. http://blog.korynunn.com/javascript/the-dom-isnt-slow-you-ar...

iknight2• 13 years ago

Ran this on Android 4.1.1 in chrome and it was 913ms. Desktop was ~40ms on average.

iknight2• 13 years ago

To be fair, I'm not sure I would endeavor to make a mobile-only web app load 10000 elements to the DOM all at once. When I set to 2000, for instance, I can get below 200ms on Android 4.1.1 in chrome.

JackdawX• 13 years ago

This is a post responding to the following article that was posted on HN yesterday-ish: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

The point of that article was to specifically call out lazy surface-level discussions of HTML5/js apps by throwing out some benchmarks, and trying to have a practical fact-based discussion. I found the article very convincing actually, and what I wanted to see was both browser-app proponents and detractors testing out the limits of what the browser is capable of, so we can determine what is and is not viable to program in the browser stack.

This piece is simply not an answer to that article in any way. It does not attempt to answer the question posed in the title, nor does it address any of the points of it's parent article. I think we need to step up the level of discussion here if we want browser tech to be more viable for general use.

williamcotton2• 13 years ago

Oh, but it does step up the level of discussion, because there are more important matters involved than mere performance gains. Also, the author of yesterday's article pinned a good deal of his "thesis" on some hand waving about how pocket-sized computers won't increase in performance and memory. He stated that ARM is incapable of keeping up with Moore's Law and will have to be replaced by x86. His statements about the likelihood of vendors being capable of shipping hardware that continues to improve is based on nothing but his opinion. It is not in any way supported by some cursory emails with hardware engineers. The MHz limit has nothing to do with Moore's Law, it merely pushes us Ina multi ore direction... So lets say we have 80 cores... Well, one javascript run time could potentially use an entire core! Also, his one engineer quote admits to having an 'incredibly biased opinion'. Really guys, this kind of stuff is what convinces you?

The reason a veteran like Dan take issue with the hardware and performance side of things is that is what originally held back dynamic interpreted languages in the first place. There were a zillion arguments about how Smalltalk and Lisp were just too damn slow and would never be capable of the performance present in languages closer to the metal. Thought the 90s and the 00s these opinions were clearly rendered moot.

Also, lets think about where are problems are actually bound. With games, 3D rendering and graphics are a big pain point and developers spend a lot of resources to cordon off and optimize this code. And then they frequently use a language like Lua to do everything else. This is basically the approach of APIs like WebGL.

dgreensp• 13 years ago

The way I see it, if you look at the iPhone as a slightly faster IE8 plus a graphics card (plus string concatenation that doesn't memcpy and probably various other asymptotic or order-of-magnitude improvements in specific areas), you can do a lot with that. You can perfectly well argue about the less-well-supported facts and opinions in the original article that are used to interpret the performance facts.

For example, the anecdote about Wave that's supposed to demonstrate you can't do realtime collaboration on IE8. Well, I worked on Wave at Google (briefly) and it's no such proof. I also wrote EtherPad, which was realtime collaborative in IE6. You can't disqualify arguments of the type "I wrote an app one time" and then talk about the impossibility of writing apps.

The matter of whether phones will get yet faster is another great question, and one I'm not qualified to comment on, but I wouldn't bet against it.

I totally get the part about GC in a memory-constrained environment, photos, and the iPad's giant screen. However, the author of the original article doesn't stop before making many broad, indefensible claims.

andrewgleave• 13 years ago

Anyone interested in optimising their mobile web applications should watch Apple's Safari tracks from this year's WWDC.

They have plenty of advice on improving general performance and how to use the WebKitInspector to measure performance problems.

Some key take aways:

Avoid using libraries (like jQuery) unless you really need them - It will reduce memory consumption significantly.

Be careful how often you're invalidating style/layout info and forcing recompilation.

Avoid using onscroll events to do layout. Especially when you're likely to inadvertently invalidate styles/layout at the same time e.g. accessing element offsets and positions

kenshi• 13 years ago

The CTO of a company which makes a web platform for mobile development (http://www.alphasoftware.com/products.asp), thinks mobile web apps are good enough?

What a surprise...

JunkDNA3• 13 years ago

I'm not sure the cynicism is warranted. Dan does a bunch of native iOS development. He's got more experience than the vast majority of people who read this site. This isn't some random brogrammer writing a post about JavaScript. Dan Bricklin's resume rightfully could include the line "1979: Invented the spreadsheet".

jawngee• 13 years ago

1979: Invented the spreadsheet

Not to diminish his accomplishments, because I consider him one of my heroes, but he didn't invent spreadsheets. That honor would go to Richard Mattessich 18 years earlier.

mbesto• 13 years ago

Mobile performance has to do more with the expectations of multi-touch interaction for the user and less about the whole application simply being "slow". Very marginal differences in performance can have massive effects on the usability of apps on a mobile devices. For example - imagine the lock screen slider didn't follow your finger as you swiped, but slightly lagged behind. Would you know initially that it was even swipe-able if that were the case?

mgraczyk• 13 years ago

If I open iTunes on Windows and scroll through my music library (~20,000 songs) then move over to Google Play in chrome 28 and scroll through the same library, I notice very quickly that the native experience is undeniably better. I would estimate the total lag (between spinning the scroll wheel on my mouse and seeing the ui begin to scroll) is about 10 times as long on chrome.

Another example: try using any web based spreadsheet software after using Excel for a while. I guarantee that you'll be immediately frustrated with the web apps sluggishness.

Web apps are getting better, but anything that uses both the HID and graphics stacks is still way faster if native.

i_c_b• 13 years ago

Huh. It's like he's saying (because of libraries in the web browser) that we should be benchmarking HTML5 the way that we would a C64 or an Amiga 500... not as a general purpose machine that can implement arbitrary algorithms, but as a crummy machine where all the magic is done in hardware (or, here, libraries).

Part of me wants to resist that frame. The whole point of browsers running (sandbox safe) arbitrary code is getting the benefits of arbitrary code, right? Who wants to distort their problem solving to conform to the ad hoc details of the current state of browser vendor libraries? Isn't that what we're trying to get away from?

But then a part of me thinks... we do that with GPUs too, right? If you benchmarked a modern game that didn't use the GPU (and didn't distort what work was done to accommodate the particularities of the how the GPU expects computation to happen), its performance would be relatively speaking even more dreadful. Just like a web app that doesn't lean heavily on the browsers' libraries.

Obviously there is a difference in that browser constraints are mostly social (and thus kind of arbitrary), and GPU constraints (and those of the C64, for that matter) seem to be responses to certain physical realities.

I guess in the short run, he has the right attitude if you want to make code that actually performs well today, but wrong if you think that putting political pressure on standards bodies and browser vendors by offering up critiques like the original article is likely to improve things.

JunkDNA3• 13 years ago

Dan is too humble when giving his credentials in this article. Reading the comments already, it seems some may be unaware that his first claim to fame was VisiCalc: the software from which all modern day spreadsheets are direct descendants.

He's got years of accumulated wisdom that make his comments about programming natively vs. in the browser worth some careful thought. As you read his post, remember he developed a functional, useful, modern spreadsheet package on 1979 hardware.

_random_2• 13 years ago

Maybe he could provide a quick sample/prototype of VisiCalc ported to iOS as a web-app? After all 2013-1979 = 34 of innovation, so HTML5 and JS _must_ be a pinnacle of programmer's productivity, right? An if-it-compiles-it-is-correct kind of thing?

pasbesoin• 13 years ago

Actually, it's been some months and my memory is vague on details, but I seem to recall that someone has done this in the browser. Perhaps/probably via an emulator.

Hmm...

I'm in a bit of a hurry, but this sounds familiar:

http://www.metafilter.com/122001/Visicalc-on-your-iPhone

Stranger2013• 13 years ago

"Any programmer ignoring JavaScript is doing themselves a disservice."

Not really. You get to work with a buggy language and you loose competitive edge on the work market. Management's/business's point of view could be different though.

ChikkaChiChi• 13 years ago

If you want your code to run as fast as possible, don't add needless bloat.

I guess I am failing to see where the argument lies? Isn't this still the first rule of Programming Club?

npalli• 13 years ago

It is a little disappointing that this doesn't directly address the issues with the original article's claims. Instead it continues focusing on CPU execution timings. Like many responses to the original article, the elephant in the room is javascript performance on DOM manipulation/UI. To take an example on the desktop, if I gave you two options a) language a which is about 2 times slower than C in doing some math operations b) language b which is about 15 times slower than C in doing some math operations. Both are GC languages with large memory footprint (3-8x) that of C. Which language would you choose to write your UI? If you chose a. you chose WRONG!. a) is java with its horrible AWT/Swing libraries and b) is Visual Basic.

Nothing specific to Java though, the .NET guys have spent about 15 years optimizing their GC. Yet every UI framework on that platform seems like a turd compared to Visual Basic (WinForms, WPF, Silverlight). Looks like they are throwing the towel and asking everyone to move to HTML and javascript. I wish javascript guys spent more time benchmarking UI performance than making it look like C++ (asm.js and other things). Take a paper draw circle on it. Push it on a smooth desk. That's your use case and how things should perform. No jitter, no flashes. Don't care about some fancy assembler optimization for matrix multiplications.

Of course that is only one part of the problem with javascript. The other big problem is lack of tools for putting UI's and writing large programs. On top of that you have to add in all the libraries (jQuery, Angular etc.) now you are totally hosed. You don't know where your performance issues are. In any case, mobile apps today have really two platforms - iOS and Android. They have quite different use cases (paid vs advertising). Most UIs are thin wrappers on services. Porting to the next platform is not some huge rewrite.

mwcampbell• 13 years ago

Most UIs are thin wrappers on services. Porting to the next platform is not some huge rewrite.

I beg to differ. In my current project, the client (written in JS) has about 10x as much non-UI code as the server. Currently this app only targets desktop platforms through a thin wrapper. When it's time to target mobile platforms, the UI will need to be native, or at least a mix of native and Web. I have no plan to rewrite all the non-UI code twice, once in ObjC and once in Java. So we need a way to have a common, memory-safe language for non-UI client code, that can be shared between the major mobile platforms and the Web platform. I'm going to take another look at Titanium Mobile, though I don't like the way it attempts to provide a greatest-common-denominator API for the UI. I'd rather use the platforms' native UI APIs, in their native languages if necessary, while using a common language for non-UI code.

_random_2• 13 years ago

Working with HTML feels quite low-level after having worked with WPF. And there can't be core HTML innovation because of standards.

heroic• 13 years ago

A lot of your article goes on to talk about development time speed up. The original article discussed performance where it is critical, like a game. You can't have compensate on performance even if it comes at the price of higher development time.

guygurari• 13 years ago

For me, it is not just that web apps feel slow. It is that they feel clunky. I can often see the UI elements being drawn one by one, the animations are rarely smooth, and the gestures (if I'm on mobile) never register as well as they do in native apps. The seams are showing.

Even when native apps are slow, they can have a feeling of cohesiveness and polish that web apps lack.

potatolicious• 13 years ago

This really feeds into npalli's point above. Comparing native vs. web by simply comparing JS execution performance is a red herring.

The average native app doesn't really do that much app logic. I'd wager you can take almost any app in the App Store, rip its non-UI code out and replace it with JavaScript equivalents, and no one would be any the wiser.

We're talking about software that needs to respond in human-time. Taking a couple dozen milliseconds is not the end of the world.

What is the end of the world for these apps is laggy, unresponsive UI, and that's where hybrid web apps fall apart. Users are very timing-sensitive when it comes to visual elements. When I touch a button it should visually respond immediately, within at most a few milliseconds. Most web apps can't reach this level of performance.

Which leads to something from the article itself:

"many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation"

The problem with the web, as it pertains to UI, is that this isn't true. Take the dreaded carousel - that things needs to animate and scroll smoothly, but the code to do this isn't natively built into the platform, so everyone ends up rolling their own (or using what someone else has rolled) non-natively. And now you have shitty, laggy scrolling performance.

This goes double for webapps that pretend to be native. Now they're basically reimplementing all of the platform's native UI widgets in Javascript without the benefit of the legion of native platform developers who've smoothed out all the kinks.

talmand• 13 years ago

Isn't one of the reasons that a web app won't respond immediately to a button click is because of a built-in delay on the browser level on touch devices? The one in place to allow for some time to know whether the user intended to do a touch event versus a drag event?

For instance, I've made a simple tic-tac-toe app that I have on my phone through Phonegap that uses nothing but canvas for rendering. It doesn't seem to have this built-in delay and the buttons are quite responsive.

I don't think your example of the carousel works because the article, I believe, was referring to the programmers that are working on the browser itself. You can't necessarily hold them responsible for performance issues derived from what other programmers are doing on the platform that may or may not be a good idea. Besides, I would imagine you could build a rather snappy carousel these days on modern browsers using CSS3 features as the bulk of the animation as they are native to the browser.

You are also comparing today's Javascript endeavors to those of native developers that have already had their issues worked out, as you say. It would only be fair to wait until current Javascript issues are worked out before doing a proper comparison. It would be like saying your car is the obvious choice for the race because it outperforms my car even though I've yet to put the tires on my car.

Native is the proper choice today, but who knows what tomorrow may bring?

dk8996• 13 years ago

JavaScript is single threaded you will never get a good smooth UI. Maybe in the future there could be more support for a "UI-thread" and background tasks but for now that's how it is. Android UI framework is basically a copy of Java/Swing where you have single UI thread that does all the painting and event handling. As a developer you have two basic rules for making a smooth UI 1) don't block the UI thread -- create background task for IO, heave code, ect... 2) don't call UI framework from non-UI thread.

qznc• 13 years ago

"Taking a couple dozen milliseconds is not the end of the world."

In games, where you draw the whole screen for each frame, the magic number nowadays is 16ms. This gives you 60fps. For a TV-attached console, this is a good as it gets. For a PC it is just fine.

Taking longer than 16ms is not the end of the world, but noticeable lag for the gamer.

samstave• 13 years ago

Are mobile web apps really slow?

Do you have Sprint?

Are mobile web apps really slow?

Related Stories