Are mobile web apps really slow?
danbricklin.com
danbricklin.com
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.
Hmm...
I'm in a bit of a hurry, but this sounds familiar:
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...
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.
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.
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.
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.
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.
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.
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.
This isn't true at all, right? JavaScript is missing fundamental Unicode support, like normalization or testing for canonical equivalence.
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.)
Even when native apps are slow, they can have a feeling of cohesiveness and polish that web apps lack.
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.
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?
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.
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.
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.
What a surprise...
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.
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.
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
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.
Nothing like a "rich text editing widget".
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.
I guess I am failing to see where the argument lies? Isn't this still the first rule of Programming Club?
Do you have Sprint?
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.