Google Groups

Re: PhoneGap vs. Native: Some Thoughts on Going Native


Kerri Shotts Apr 3, 2012 2:23 PM
Posted in group: phonegap
Of course, nor am I trying to indicate that one tool fits all. It doesn't. Never will. That's why I use a /lot/ of languages ranging from C to PHP to PL/SQL. I use what I think will work best for the situation. Obviously that doesn't always work out, as I initially believed (and my initial tests seemed to indicate) that html/js/css would do the job for this app. 

And actually, I think they would be a perfectly fine tool. It wasn't so much the language, it was the platform - that is, mobile webkit that got in the way one too many times. I perhaps should have retitled the post to Mobile Webkit vs. Native development, since this isn't PhoneGap's fault. It just provides the interface from webkit to some other native device features. 

My frustration largely stemmed from having to debug what felt like a webkit issue vs. debugging my own code. First off, debugging is a pain in the rear anyway, and it is worse when there is no proper debugger for the platform. You can only go so far by developing in Chrome or Safari, and then using the iOS Simulator + Safari. After that, issues become issues /on the device/, and while Weinre is great, it's not a fully-fledged debugger yet. Oh, for the day it is, because then one of my primary complaints goes away. But until then, my point stands. And when the issues show up only /on device/, you're left with being unable to debug in a proper environment. Oft times I was reduced to console.log(). People, this is the way we used to debug 20, 30, 40 years ago. 

If we discount debugging, the next big frustration was webkit. I /love/ it. Don't get me wrong. I use Chrome on my desktop (webkit). I use Mobile Safari on my iPad and iPhone (webkit). I /convert/ people to Chrome whenever I have a chance. I /love/ it as a browser, and as a platform. But when it translates to a touch environment on a mobile device, mobile safari has a long way to go. Let's see a few of my issues:

  • For a long time, the only scrolling solution was a js library like iScroll. Performance sucked when you got beyond a non-trivial amount of elements. In fact, it sucked so much, that I gave up. First, I converted my most element-heavy page to canvas, and then, I dropped iScroll entirely.
  • Native Scrolling stinks too. I mean seriously, Apple, why in the world do you have to bounce my entire UI? The typical fix is to stop the browser's default behavior. Which breaks other things -- like simply selecting text! Ack! And then you re-implement those things, only to discover that suddenly (for no good reason, and inconsistently across the board), pages will scroll, but /not/ paint their contents to the browser window. WTF? The fix? Adding a 3D Translation of (0,0,0) to the element. Now tell me, /why/ in the /world/ does that fix the problem?
  • Touch delays. Yipes, we shouldn't have to write funky code just to handle touches that are supposed to be "clicks" instantly. And then we end up having to write more special code to filter out those touches that get doubled up, causing all sorts of havoc either way you deal with it. You can ignore them, but then that hurts the responsiveness of the UI.
  • Animation performance. Yes, the hint is to use the CSS transforms whenever possible. And that's fine. What gets me is whenever the element being animated is suddenly non-trivial (and has dimensions over a certain size) then performance goes down the drain. I get we have limited memory. Was /tiling/ the textures to the GPU /really/ the best way around it? It screws with the fluidity of the interface in a bad way. Or, say, a simple fly-out leaving funky trails of itself behind during the animation. What a horrible user experience that is. 
  • Webkit repainting is not always predictable. In fact, for a while I had to go to a fix I found somewhere that essentially added a style to the page just to force webkit to redraw itself. First, I shouldn't even have to do that. Second, why in the world was adding a nonsensical style (it really did do NOTHING) the fix? Third, I shouldn't have to do that! I felt like I was back in the 90s building my own personal UIs. Even then I had repainting down. It's /not/ that hard!
I could go on and on, but seriously, it quickly became a feeling of debugging webkit vs. debugging my app. Honestly, I'm not doing anything in my code, my stylesheets, or my html, that is that hard. Regular Safari handles it just fine, and that's perhaps the only hope that mobile webkit will improve in future versions of iOS. But when I'm feeling like I'm debugging the very platform I'm running on vs. debugging my own code, productivity goes down the drain, and I'm forced to consider other options. 

It is true that the tools can only be as good as the person using them. This adage holds true in all walks of life. That said, I'm a pretty good programmer. I've been doing it for 20+ years. I've worked most of my adult life in programming positions creating successful applications for the companies I've worked at. Am I the /best/ programmer? No, by all means, no. Do I write hacks sometimes? Yes. Most programmers do at some point. Show me something /in production/ for a few years that hasn't become hacky over time. There's always an incredibly horrible exception to the rule, something most college courses and language purists like to ignore. Would I love to write pure, beautiful code all the time? Sure, but you may as well toss productivity down the drain, 'cause it just ain't happenin' in real life. Something always comes along to throw it out the window.

Could different code have alleviated my issues with performance? Maybe. Actually the majority of performance was quite good. In fact, the one place that should have been slow as molasses /wasn't/ (canvas). The final straw became a ridiculous 5s delay (sometimes - like I said, this was inconsistent at best) between selecting a /list element/ in a simple unordered list (and I do mean /simple/) and the display of the next list in the hierarchy. There was nothing in my code there causing such a delay. Of course I couldn't reproduce it in a full debugger either, since there is no full debugging on the device. So /maybe/ there was code somewhere getting run taking up all the time. There is simply no way to know at the moment. But something was getting in the way, it was inconsistent at best, and the feeling was: oh no, not /another/ webkit problem to work around. When that was the feeling, I decided it best to start over in an environment where, at least, I could debug properly if any performance issues came up. In fact, they did. (They /always/ do.) But this time I could use the debugging tools at my disposal and pinpoint the problem precisely. Oh, if only I could have done that non-natively.

On Tuesday, April 3, 2012 3:05:59 AM UTC-5, Giacomo Balli wrote:
there is no "one" tool to make something.
You always need to assess what is the best technology depending on
what needs to be accomplished.
I would never say I'm abandoning something just because it was not
ideal for one project.

In addition, every tool is at most as good as the person using.Perhaps
there could have been something to improve your code...

Just my to cents...



On Tuesday, April 3, 2012 3:05:59 AM UTC-5, Giacomo Balli wrote:
there is no "one" tool to make something.
You always need to assess what is the best technology depending on
what needs to be accomplished.
I would never say I'm abandoning something just because it was not
ideal for one project.

In addition, every tool is at most as good as the person using.Perhaps
there could have been something to improve your code...

Just my to cents...

On Apr 3, 7:41 am, Kerri Shotts <kerrisho...@gmail.com> wrote:
> First off, I just wanted to say what a fantastic community this is, and
> what a great thing PhoneGap is. That said, I wanted to share some of my
> thoughts about developing an app for iOS using PG vs. going the native
> route. Keep in mind that this isn't a knock on PhoneGap -- it's more a
> knock on mobile webkit development than anything, but I did want to get
> this out there in case anyone else is feeling similarly.
>
> The projects to which I am referring are below:
> PhoneGap Version:https://github.com/photokandyStudios/GreekInterlinearBible
> Native Version:https://github.com/photokandyStudios/gbible[Yes, the
> organization in the folder structure is horrible. Load it up in XCode for a
> legitimately organized view...]
>
> I was /this close/ to being finished with the PhoneGap version. It was 99%
> done. Almost ready to go. And then... *pow*... performance issues that
> weren't related to anything that I could find: it seemed some combination
> of CSS/HTML/JavaScript was getting in the way. Did some rework to attempt
> to fix, and on the iPad, it made it better, while on the iPhone it made it
> worse. (No consistency.) The delay was so much that I considered it
> unacceptable. I worked to find what was causing the issue, only to come to
> the conclusion that it was webkit's rendering slowing things down, and
> there was suddenly little I could do about that and maintain a good, native
> look & feel. And then the other niggles popped up: controls that looked
> good, but not quite great; controls that responded almost natively, but not
> quite; and more. Nothing terribly serious, mind you, but something that
> very indicated that the app was not really native. Again, none of this is a
> knock on PhoneGap. If anything it's a knock partly on Mobile Webkit and
> it's glitchiness/performance issues and my patience with dealing with it.
>
> So I decided to tinker natively and to see what I could come up with.
> Surprisingly, after a few rough starts (especially when trying to wrap my
> head around storyboards), I realized that this was /so much easier/ than
> trying to shoehorn my html, js, and css into a native look & feel. After
> all, you get native look & feel for /free/ natively (obviously), but I've
> suddenly realized how important that is. I went through lots of tweaking on
> my UI (and its all important, and will have future uses, so I'm not
> abandoning the /concept/) to get it close, but there are just some things
> that I don't think one can ever /totally/ duplicate. [Okay, yes, you
> probably can. But it would be a ridiculous amount of work, and likely not
> nearly as performant.]
>
> Now, I could probably have done something very similar by creating plugins
> that would do some native controls in phonegap -- and I did consider that.
> I considered creating tableviews and other controls that could live atop
> the webview, and then suddenly decided that if I was going to have to go to
> all that work, I may as well do the whole thing natively. Tableviews
> naturally fit my data model, and at that point, a very large portion of the
> code would be handled natively /anyway/.
>
> I could also have gone the route of Nimbus/Appcelerator/etc. But in each
> there was something missing that I would need, and the more I drilled down
> into them, it quickly became apparent that if I was going to have to live
> in Apple's world, I may as well live in objective C/UIKit/etc. as well,
> rather than always going through someone else's wrapper around it.
>
> And so here we are: I've got a project that (so far) is going quite well
> natively, and while there isn't feature parity yet (far from it!), I'm
> already feeling like I've made more progress than I did getting from 98% to
> 99% on the webapp. Why? Here's a few reasons:
>
>    - I'm not having to continually come up with a workaround for some silly
>    webkit bug, glitch, or quirk. Believe me, this was quickly becoming the
>    largest time consumer at the end.
>    - I'm not having to generate the native UI elements /and/ make them feel
>    native. They just /are/.
>    - Objective C and UIKit and Foundation, etc., are actually quite easy.
>    You can get a lot accomplished with a few lines of code. [Nothing against
>    JS here. I like the language.] Plus, there's a lot of sharing going on out
>    there, from components and controls to code snippets that really help.
>    [Note that html/js/css doesn't have the same thing, but it's not /quite/
>    the same. Hard to explain.]
>    - I can really, truly /debug/ on this now! That was perhaps the second
>    most frustrating part (aside from webkit getting in the way): no true
>    debugging. Yes, you could develop in a desktop browser for most
>    functionality, and then you could use the iOS simulator and Safari to
>    debug, but to debug /on/ the device was a pain. Weinre is a good solution,
>    but it's not /quite/ there (no breakpoints!). I can't say how /nice/ it is
>    to truly debug without having to drop in console.log() every few lines just
>    to see if JS got there or not.
>    - Drop-dead easy gesture recognition. In comparison, the equivalent code
>    to recognize a swipe gesture in JS is nuts.
>    - Lighter memory footprint. Of course, this just happens mainly by not
>    having to load a webview, a javscript engine, etc.
>
> Does native development have its issues? Yes - lots:
>
>    - XCode gets twitchy about what it decides to compile and deploy.
>    Sometimes it picks up a newly added file and does the right thing, and
>    other times you have to tell it what to do. I swear, if I add a .h/.m file
>    to the project, wouldn't you think XCode could figure out that I wanted it
>    /compiled/? Yes, it does this most of the time, but every once in a while
>    it decides not to, and you get some unfriendly linker error complaining
>    about missing references. Oi vey!
>    - XCode likes to crash. Even on my loaded iMac that has lots of memory
>    and space. Needless to say, saving frequently is a really good idea.
>    - UIKit does some very funny things. I mean why in the world is the
>    background color of a table cell decided at one point, when the /content/
>    of that same cell is decided at another point? And heaven help you if you
>    do it in the wrong place -- chances are you wont' get an error -- just that
>    it won't work as you expected.
>    - /Customization/ of the native elements isn't as straight-forward as I
>    would like. Apparently Apple's made great strides here, since before iOS 5
>    you would have to subclass almost anything to customize its appearance, but
>    still. Further, some customizations are still out-of-reach without
>    subclassing and drawRect:.
>    - Table View rendering takes a lot of thought to get right, and I won't
>    even say I'm 100% there /yet/. Mainly because if you do much of /anything/
>    when creating a cell, scrolling becomes herky-jerky. That means you
>    essentially have to do the work up-front so that you can quickly load the
>    contents of a cell rather than calculate them on demand. Or get into Grand
>    Central Dispatch or something similar to put part of the processing outside
>    of the main run loop. Whatever, my hat is off to anyone who can make a
>    beautiful, data-heavy table view in iOS that scrolls like butter.
>    - The view hierarchy is both amazing and a bit nuts. I've programmed for
>    Windows and Windows CE before, and goodness knows, it's nothing like that.
>    I've had to unlearn quite a lot of my notions about how UIs work underneath.
>    - Interface Builder/Storyboarding is too much magic for my tastes.
>    /Especially/ storyboarding. It's great for getting a prototype UI down, but
>    then just /try/ and do something simple like dismiss a popover. For some
>    nutty reason, you had to go to (what I considered) extreme lengths just to
>    do so. So I built my UI all from code. I can work with /that/. ;-)
>    - And plenty more...
>
> And even with all those quirks, I'm still happier with what I've got
> natively than with what I got with html, js, and css. Oh it looked nice
> enough. It functioned /almost/ natively. But look too close and you could
> spot the glitches -- like switches that you couldn't slide, or small
> differences in how shadows rendered, and scrolling -- don't get me started
> on scrolling! And then the performance issues that occur for no good reason
> on a simple list where in you could spend five seconds just /waiting/ for
> something /simple/ to happen. And there was no JS code running during that
> time -- it was pure webkit.
>
> Anyway, enough of a ramble. I'm not abandoning phonegap -- no, I think it
> has a lot of potential. Nor am I abandoning the concept of a native-feeling
> web-based UI -- just that I was overloading webkit in this particular app.
> I fully plan on using the things I've learned in building mobile sites that
> act like apps, and I also plan on working on some phonegap plugins,
> especially now that I'm getting a much firmer grasp on Objective C and the
> Apple Way. But this is one app where I think native is the better choice,
> and so far, I'm feeling much better having gone native. Oh well, live and
> learn, right? C'est la vie!
>
> So, I just wanted to share that and show a comparison between the two
> paradigms, including some code. Now, questions, comments, etc? I'm sure
> someone has something to say about all this. ;-)