
Are mobile web apps really slow? - fpgeek
http://danbricklin.com/log/2013_06_19.htm#jsspeed
======
JunkDNA
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_
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
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](http://www.metafilter.com/122001/Visicalc-on-your-iPhone)

------
anon1385
_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...](https://developer.apple.com/library/mac/#samplecode/TextEdit/Introduction/Intro.html)

~~~
pjmlp
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.

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

~~~
pjmlp
I do work on both sides, and my experience with web just makes me wish for
native projects every time I change customer, but it does not always happen.

------
JackdawX
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...](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.

~~~
williamcotton
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.

------
mgraczyk
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.

------
npalli
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
> 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.

------
i_c_b
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.

------
millstone
_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.

~~~
saurik
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.)

------
guygurari
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
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
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?

------
coldtea
> _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.

~~~
smackfu
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.

~~~
coldtea
> _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.

~~~
smackfu
My point is mainly that there is a middle ground, like spreadsheets and word
processors and vector drawing programs and tons of useful every day programs,
that are not "just fancy CRUD" but that are also not generally going to be CPU
bound.

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

What a surprise...

~~~
JunkDNA
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
> 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.

~~~
JunkDNA
Fair enough, I stand corrected.

------
hamidpalo
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.

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

~~~
hamidpalo
Thanks!

------
andrewgleave
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

------
coldtea
> _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
What do you consider contenteditable=true if not a rich text editing widget?

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

~~~
jimktrains2
No. It is possible to bold and such. With some code to hook things up you have
pretty much everything you need for a "real" rich text box.

~~~
portmanteaufu
Can you point me to an example of being able to click on the contenteditable
div and make some text bold without extra code? I've never seen something like
that. Thanks!

~~~
jimktrains2
Ctrl+b or eqivilent selected text iirc.

------
mbesto
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?

------
heroic
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.

------
Stranger2013
"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
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?

------
samstave
> __ _Are mobile web apps really slow?_ __

Do you have Sprint?

------
camus
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.

~~~
ecopoesis
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...](http://blog.korynunn.com/javascript/the-dom-isnt-slow-you-are/)

~~~
iknight
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.

~~~
coldtea
Below 200ms? Still nowhere smooth enough to get to 60fps.

