Panel

Pete Hodgson (twitter github blog)
Rod Schmidt (twitter github infiniteNIL)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:06 - Web Apps vs Native Apps

HTML
UIWebView
Platform Coverage vs User Experience

04:48 - Uncanny Valley Effect
 06:18 - Frameworks

Sencha Touch
Appcelerator
Titanium SDK
PhoneGap
Kony

08:37 - Mobile vs Web Experience
 13:15 - Uncanny Valley Effect

Toy Story vs Polar Express

15:20 - Scrolling of Web Views
 17:04 - Making Smart Technology Choices

Platform Reach

22:13 - Access

PhoneGap
Calatrava

25:29 - Focus
 28:18 - Exposure and Discoverability
 30:20 - Cross-Platform Tradeoffs
 32:21 - Offline Access

HTML5 App Cache
Every Time Zone

35:45 - HTML Presentation Frameworks

jQuery Mobile
059 JSJ jQuery Mobile with Todd Parker

Picks

Calatrava (Pete)
Iain Banks (Pete)
Elixir (Rod)
The Power Formula for LinkedIn Success: Kick-start Your Business, Brand, and Job Search by Wayne Breitbarth (Chuck)
Twitter Bootstrap (Chuck)
HTML5 Rocks (Chuck)

Next Week
 iPhreaks Show: Open Source with Sam Soffes
 Transcript

[This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

CHUCK: Hey everybody and welcome to Episode 11 of iPhreaks! This week on our panel, we have Pete Hodgson.

PETE: Good morning!

CHUCK: Rod Schmidt.

ROD: Good morning!

CHUCK: I'm Charles Max Wood from DevChat.tv. This week we're going to be talking about the tradeoffs between "Web Apps and Native Apps". One of the things that kind of made me want to talk about this was that I remember a while ago, 37signals came out and basically said, "We're not going to write iPhone Apps or Android Apps for our products. We're just going to make mobile versions of the websites and people could just use that," and I thought that was really interesting. So I'm curious with you guys, what you see as the tradeoffs between one or the other.

ROD: Well, since they've changed a little bit, they're now using RubyMotion for their Basecamp App mixed with some web technology, so now they're kind of hybrid.

PETE: I think that's a really good point. When I talk about this stuff to clients, I say like the question of Web versus Native, the answer is "Yes". And really it's not like, "Should I do Web? Or, should I do Native?" It's "Where should I sit on the spectrum between Fully-Native and Fully-HTML?" Actually, not that many people go to [Inaudible], so there's not that many products that don't have any installed app or tool, and there's not that many products that don't use the web at some point inside of their, even if it's a Native App, a lot of apps still have webby stuff inside of them; that's sometimes surprising.

CHUCK: What do you mean by webby stuff? Are you talking about --

PETE: Even just something as simple as HTML, an HTML View. Let's say you're doing legal disclaimer as the classic example they always use, you're doing legal disclaimers for your app, you could do the layout and mock up and stuff in code. Or, you could just write some simple HTML, shove it in the UIWebView, and embed it in your app. That's normally about a way to go.

CHUCK: Yeah, that was what I was wondering; it's if they were using UIWebView,

 

the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

Hey everybody and welcome to Episode 11 of iPhreaks! This week on our panel, we have Pete Hodgson.

Good morning!

Rod Schmidt.

Good morning!

I'm Charles Max Wood from DevChat.tv. This week we're going to be talking about the tradeoffs between "Web Apps and Native Apps". One of the things that kind of made me want to talk about this was that I remember a while ago, 37signals came out and basically said, "We're not going to write iPhone Apps or Android Apps for our products. We're just going to make mobile versions of the websites and people could just use that," and I thought that was really interesting. So I'm curious with you guys, what you see as the tradeoffs between one or the other.

Well, since they've changed a little bit, they're now using RubyMotion for their Basecamp App mixed with some web technology, so now they're kind of hybrid.

I think that's a really good point. When I talk about this stuff to clients, I say like the question of Web versus Native, the answer is "Yes". And really it's not like, "Should I do Web? Or, should I do Native?" It's "Where should I sit on the spectrum between Fully-Native and Fully-HTML?" Actually, not that many people go to [Inaudible], so there's not that many products that don't have any installed app or tool, and there's not that many products that don't use the web at some point inside of their, even if it's a Native App, a lot of apps still have webby stuff inside of them; that's sometimes surprising.

What do you mean by webby stuff? Are you talking about --

Even just something as simple as HTML, an HTML View. Let's say you're doing legal disclaimer as the classic example they always use, you're doing legal disclaimers for your app, you could do the layout and mock up and stuff in code. Or, you could just write some simple HTML, shove it in the UIWebView, and embed it in your app. That's normally about a way to go.

Yeah, that was what I was wondering; it's if they were using UIWebView, or if there were some other ways of getting web technologies into your iOS application.

The other thing that some people do if they want to run JaveScripts inside of their iOS App is you can actually embed -- or actually, [Sigh] WWDC has just happened and there's NDAs and I can't remember what [Inaudible]. You can compile -- I can talk about this because this is not related to WWDC -- you can compile a JavaScript Interpreter, the one that shifts with WebKit, you can compile that and put it into your app if you want to.

Oh, that makes sense.

That's a pretty extreme thing to do. Normally, when I have stuff where I want to execute JavaScript out to all the context of the browser, I just create a UIWebView and just kind of don't attach it to any View, but just use it to execute JavaScript because you can pass JavaScript to UIWebView and have it executed and return the result.

Right. And then you're just taking advantage of the built in runtime for JavaScript.

Yeah, which is good if you've got cross-platform; if you've got code that you don't want to reimplement in every single platform.

Uhm-hmm.

I think the big tradeoff that most people think about is platform coverage versus like the user experience. If you do have think native, you'll probably going to get a better experience, but you're only covering iOS, obviously. If you do have think with the web page and you cover every platform, the experience is not going to be as good as if you kind of sync a bunch of time into polishing every picks all of your beautiful iPad Apple, iPhone App.

I can definitely tell when I'm using a web based app like ReDBox is; the performance is just horrible.

Yup. ROD: And it doesn't feel right.

That's an interesting one as well; it's that "uncanny valley" thing of like it doesn't feel right. Do you get that feeling, Rod, when you're using a website? Like if you go browse to a site on Mobile Safari, I would argue that you'd probably don't feel like it doesn't feel right because you expect it to be webby; you expect it to feel like a web page.

Uh-huh.

But when you're in a Native App, you expect it to feel native. And if someone kind of tries to fool you by pretending to be native when it's actually HTML, then you'd get this uncanny valley effect where you know what they're trying to do, but it doesn't quite look right so you kind of focus on what's different.

Right.

That's like Final Fantasy - the Final Fantasy movie. They tried to make it photorealistic, so if one obsessed by the fact was focus on the fact that it really looked weird. Whereas Toy Story, they didn't try and make it photorealistic and everyone talked about how amazing the CGI was.

Right. I think that's fair. A lot of times you're looking at the scrolling, and the scrolling is this slow. But I could see, if you didn't try to completely simulate the look of iOS and all the needed widgets and you just went for kind of a pure web UI, then yeah, it probably wouldn't be as much of a deal. PETE: Yeah! That's why I don't like frameworks like Sencha Touch because they do that thing, like trying to feel native. Also, if you think about it, you're trying to target multiple platforms. If you make it look just like an iPhone App, the people who use Androids are going to think that you're bit of a weirdo, like...[Laughs].

Yeah.

Yeah. I guess one, there are different levels along here, and one is just to go straight for the web app and they have to get open your application in their browser.

Uhm-hmm.

And then the next one is, there are frameworks out there like a Appcelerator, Titanium, and --

PhoneGap.

PhoneGap, that basically give you a UIWebView, and then you have basically your HTML layout, most of your touch events and stuff are JavaScript, and then they have some hooks into some of the needed functionality like cameras and things.

Yeah.

And then you'll go all the way to its built in interface builder, or your interface's built in code, and everything is just full stack, Objective C, or statically compiled whatever, Ruby or whatever.

There's one other configuration that's where you have a Native App with the UIWebView, and you put some web stuff in there. I've done that; a lot of apps do that actually. And it works well when you have some kind of data or page, like a fact that we talked about earlier, that updates a lot. And you don't want to issue an update every time you go to the whole app approval process, every time you update the fact.

Right. So can't you just set up some kind of API that it could pull from and then just do it all in native code anyway?

You could do that, too. Yeah.

And the other thing that you can do, which people don't do enough and they should do more of, is set up an API, pull down JSON, and then render at client-side in HTML, then you get the best of both worlds, in my opinion.

Right.

So you don't get the crappy performance characteristics of downloading a huge chunk of HTML, but you get the cross-platform in this using HTML and not having to rewrite the puzzling code and write the rendering code for Android and iPhone or whatever.

Yeah. So let's go back to just a web page on the web that you hit with your browser for a minute. The tradeoffs that I really see with that are, (a) you get a universal experience across everything, provided that works in all of the browsers and on all of different devices. So that's really nice. But the flipside for me is that, I like having that app icon on my phone and I don't always like going to --

Well, you can still do that, though.

I know, but I hate going to the trouble of figuring -- because I have to figure it out every time. Okay, how do I make this bookmarked on my phone interface so that when I tap it, it opens up the browser and opens up to this place.

Yeah.

And a lot of people don't know about that. So that doesn't become this super usable, accessible, available thing for people.

Maybe I'm a little bit of a weirdo in this regard, but I actually have the opposite things sometimes where I don't want to install an app on my phone just to check into unite it or whatever. So I would be very happy to fire up the browser and go to uniteit.com and have them take me to their media cum mobile experience. The argument I always make as well is when people say, "Oh, we don't want to make a mobile web app," is even if you don't make a mobile experience for your products, people are going to go to your website on their phone. You're kidding us off. Do you think that everyone who wants to use your product is not going to try and go there using a browser? If your product is a mobile app, so if you're Instagram for example, then that's not a big deal because you just don't have a mobile experience. But if you're a -- I guess the kind of clients I work with are like clients where mobile is just a channel into their product; it's not the product. So the product isn't a mobile app, the mobile app is a channel into their products. In that case, you've got to have a web experience of some kind, so why not make it a good web experience, and then maybe do native stuff on top of them.

That, I completely agree with. You need a mobile presence, moblie-friendly presence anyway.

Yeah. Unless you're Angry Birds for example. Angry Birds, they don't need -- they probably have a website, I don't know -- but they don't need to worry about like people who get an email that links to their website, and then what's of that experience can be like. They can rely on people installing stuff. But if you're building something as a channel into your product, the thing of building isn't the product itself, then you need to think about the web and the UI.

I would say that most people are probably accessing websites from mobile devices these days. I realeased a website getnumerology.com and I used the responsive design template. As I was developing, I kind of had this mindset that everyone's going to hit it from a browser on their desktop. But when I checked the analytics, most access came from mobile devices.

Yeah!

I've heard that from a lot of people and I think the most conservative numbers that I've heard is still like 30-35% of their traffic is coming from mobile. And I've heard all the way up to 80%, depending on what they do and who their audience is and how they tend to surf the web. So, it's a really interesting problem.

Yeah, it is. And one thing that you kind of, when you were talking, Chuck, about the spectrum from Fully-Web to Fully-Native is, you kind of said PhoneGap, and Titanium, and kind of lump those in the same category. I think people do that a lot but actually don't really agree with that. PhoneGap is just a wrapper around web technologies. It's basically just a way of taking your mobile website and putting enough native stuff around it that you can install it and put it in the App Store, and also so that you can access native stuff like the camera, phone book, location, all that kind of stuff. That's actually pretty different from something like Appcelerator, or Kony, or one of these right-ones-runanywhere tools because they -- you're writing stuff in JavaScripts with Appcelerator for example, but still, it doesn't just use HTML. It does actually create native components, native UIComponents. But it also suffers from the uncanny valley effect. If Ben was here, I'm sure he would agree with me on that one.

What do you mean by the uncanny valley.

That's that thing I was talking about where it tries to be native, but it can't quite do it. And because you know what it's trying to do, because it's in the context of looking, it's changed impersonally a native application. And because it doesn't quite get it right, you focus on the fact that it doesn't get it right. Did that phrase comes from robotics? This guy in the '80s observed this effect that if you have a robot that looks like a robot, that looks like a machine, people are very happy to work for them. But if you try and make that robot look human, as you get kind of close to humanness, it stops becoming something that people like, and people suddenly stop finding it uncanny or zombie-like. There's weird Japanese robot, you see where it's like kind of a human face and it's like got this weird kind of plastic look and you just kind of focus on the fact that it looks almost human, but not quite, and people kind of freak out about it. This was called the "uncanny valley" because it's kind of dipped in people's response to what it looks like. And then, you can apply that same principle to animation, for example; I was making that reference earlier to Final Fantasy.

Uh-huh.

And how Final Fantasy people obsessed out. The movie with the train, the winter movie with the train with Tom Hanks, the one with --

Oh, yeah.

Everyone thinks about that movie, and they think about how they didn't get it quite right. Whereas Toy Story, people talk about how amazing the CGI was. Now, it wasn't because the CGI in Toy Story was better, it was because Toy Story wasn't pretending to be photorealistic. That's the analogy that I make for -- that's the uncanny valley thing.

Yeah, my wife loved Polar Express. And yeah, my brain parsing it and going, "That's a human face, except, except, except..." Yeah, I couldn't enjoy the movie.

Exactly. And you focus on it because you know what it's trying to do. And it's the same thing, I think Rod had the classic example, that all developers notice is the scrollling in Web Views when they're in the Native App. I've actually said just like a perfect example because it is true. The scrolling's worst, but it's like, "If you weren't in the context of a Native Application, you really wouldn't care whether the scrolling is get or not." When I'm going to bbc.com on Mobile Safari, I don't even think about the scrolling. But if I'm using the BBC App and it has funny scrolling, I'm going to focus on it because I expect a native experience in that context. When I'm in the context of a browser, I don't expect native performance.

That makes sense.

Yeah!

If you think about it, unless you're playing a video game, who really cares about the scrolling? Maybe I'm a little bit extreme on that one, but for me, if you're serving up content, then the presentation is important, but the content is a thing that's really important. And maybe, as a content provider, you're more interested in reach the UI and affection of the UI, for example.

Yeah, I think the main thing with some of the apps that I've seen that are built on sort of that, they set up a UIWebView and then everything kind of lives in there, and then they bring in some native components so that they can do what they have to do.

Yeah.

I guess that it doesn't always behave as I expect. And I can't really quantify what all of that is because it's kind of like I couldn't quantify why the people on the Polar Express looked funny.

Yeah.

But at the same time, it just seems like, "Okay, well, the devices designed to run these apps this way," so I tend to lean more toward the native experience. The other thing is that I kind of like having the option. You mentioned that things like united where you won't necessarily want an app on your phone, I tend to agree with that in the sense that things that I don't use very often, I have the habit of removing from my phone.

Right.

And then I just use the web experience every once in a great while. Or, I'll reinstall the app if I really want it. But for things that I'm using all the time, I still tend to prefer the Native Apps.

Yeah, me too. I'm actually looking on my phone right now, I'm trying to find stuff that I've bookmarked that's a Web App, and there isn't or ones anything at all. If there's anything which I

use on a regular basis, I haven't installed that. Although, I think you'd be kind of surprised at how many of these applications are using a large amount of HTML under the covers and kind of blend it with the native. That's to me is the really successful kind of technology choices - when you pick and choose the right thing based on all the factors. So you can do layout in HTML, but put it inside of a native experience so that you still get great scrolling and still get the kind of the responsiveness and whatever of a native application. But you get to use HTML and CSS for layout, for example, rather than having to do all of that by hands. Or use [Inaudible] trying to understand all that layout and all of that stuff. I think it's about making smart technology choices and not thinking of it as like we have to do a Web View or we have to do a Native View.

I guess my question then is, you make it sound like you would use HTML or UIWebViews for certain things inside of a Native App, but what are the circumstances underwhich you'd want to do something like that? Why? What's the tradeoff between doing that and managing it and need it for code?

I guess that this platform reach is one of them. Let's say I want to support Android and iPhone, and I want to do a fairly rich data entry thing...Let's not say data entry, let's say I want to do a rich kind of layout of information and I want to add some graphs and charts in there, and some text, and blah, blah, blah. I could have write the code to generate those natively in Android and natively in iOS, and that's going to be not just too expensive because I'm going to do it on 2 platforms. But also expensive because doing this stuff natively is, in my experience, low but slow in doing it with web technologies. That's this tradeoff where you can sync less time into doing it natively, possibly on multiple platforms. Or, if you do it with web, then you can reuse that; you can pay a one-time cost of building it, which is probably going to be less than building it natively. In exchange, you also get something that you can use on all of your platforms including your mobile website maybe.

So you just tie a little bit differently for little different platforms kind of thing?

No. I guess back to that uncanny valley thing, I'm not a fan of that; I'm a fan of like embracing the fact that you're not trying to be fully native. If you think about it, if you look at most apps, the chrome around the outside, it fits in with the platform, but the content in the middle often doesn't. So I think that you can get away with having your own style that's not native that doesn't look like iOS or Android, it just looks well-designed. The Google Apps were really good examples of this. The Google Maps on your iPhone doesn't really look very iPhone-y, but it looks good, and it has some paradigms that feel familiar. But it doesn't look like it has iPhone chrome in it. So you can do the same kind of thing where you have something that's just a nice experience, but isn't necessarily iOS-y or Android-y.

Okay, that makes sense.

The reason I know lots about this stuff is because I spent like a year building a native iOS App for a bank, and then a year building that same app fully HTML. The tradeoffs that we did there, we kind of learnt that neither of that was the right thing to do necessarily or was the best decision. So the best decision was somewhere in the middle, where you're sharing a lot of the boring layout code and all of the business logic. I dearly want to share that across all platforms. I want to set my plug care, we did like an open source. We open sourced a framework around that called "Calatrava", I guess I'll probably put that as a pick so we'll have it link in the show notes. But that's kind of a

similar but different idea to some of these cross-platform tools like Kony or Appcelerator.

The other question I have is on just a mobile web app where it's mobile-friendly, maybe you have responsive design or something on it. Are there ways of accessing like the camera or the GPS?

I've had Web Apps request access to my location for example, how do you do that kind of stuff?

That's kind of PhoneGap's sweet spot. The philosophy behind PhoneGap, I think it's really interesting. I don't know if they still say this, but they used to say that their goal was to not exist. Their goal is to not be necessary, so they kind of expose that kind of native stuff like access to the camera, access to location. So they expose it for a JavaScript API so you're still writing your app in JavaScript to an HTML, but you just have access to this kind of more, there's a kind of a bridge to native functionality. Their goal is for eventually that stuff to be built into the browser so you don't have to run in PhoneGaps. So access to the accelerometer there for example, right now I think with PhoneGap, you would use some kind of custom PhoneGap API inside of your JavaScript code to access the accelerometer on your device. But they would hope that in the future, that would become a web standard, like a mobile web standard for accessing the accelerometer just like there's now a pretty established mobile web standard for accessing geolocation. So PhoneGap's kind of goal is to not be necessary because that stuff would be built into the browsers rather than having to use something like PhoneGap to access it. Does that make sense? I'm not sure if I've explained that very well.

Yeah, that makes sense.

We also find a lot with our clients that PhoneGap is good to get you started and trying this out. But quite often, you end up kind of building your own custom PhoneGap-y like thing because, again, you want to be able to make that choice at a more granular level between native and HTML. And PhoneGap is pretty far on the spectrum towards HTML because you're basically using HTML for everything; you're just using PhoneGap to access the hardware, access the platform.

I think this PhoneGap, I don't know much about PhoneGap, but I think what it does is pretty easy to do on your own with just UIWebView and you can have it delegate for the UIWebView and intercept clicks on links and then do whatever you want.

Yup.

So you could even have a custom scheme that tells your app, "Okay, this is my job," and does its thing, like getting a location or taking a picture or whatever.

Yeah, it's actually not that much work to do. [Inaudible], the devs and the details and the first state to present is always the easiest and all that kind of stuff. But during the basics of PhoneGap -when we first started working on this open source Calatrava thing, part of what that does is bridges between JavaScript and Native just the same as PhoneGap does. I was actually pretty surprised how easy it was to do that bridging between the two; it's not that much work.

I guess my next question is more along the lines of let's say that I'm going to start a new internet company and I'm building a social network for dogs. I definitely want this online component. In fact, let me take it back. Let's say that I have some app that I really want to be on the mobile, like mobile is my focus. So it can be some kind of social thing, but mainly it's for me to get information on my phone. So, should I focus more on building out the Web Component of it first? Or, should I worry about the mobile native parts of it?

There's all these factors that tie into that. There's "Do you care about platform reach more than you care about experience?" for example. These things are always end up being tradeoffs. Some examples of tradeoffs would be time to market, what your skillset is, what technology is you're more comfortable with, how many platforms do you want to support, how important experience is versus those other things. And like, this is me being classic consultant, but it depends, like it depends on the context. [Chuck laughs]

Uhm-hmm.

Let's take this example of a social network. One of the most important things for you early on is to be able to grow your user base because that's how social networks become popular. I would say that the most important thing is to make your network super duper sticky and easy to get involved with. You probably want to be able to have someone send a link or something. And if you're doing that, then someone's going to be on their phone, opening up this thing in an email, they're going to tap that link and they're going to look at it in a browser. So you need some kind of browser experience anyway.

And you could definitely going to need a backend --

Yup. Well, early so. We could do a different episode on MBAS - Mobile Backend As A Service, which is like things like pause and stop to open all those, guys. So you can actually build quite a lot of stuff these days without actually running a server.

That's true.

Yeah. So Chuck, I just basically kind of reigned on your parade with, "It depends".

No, it's fine. [Pete laughs]

And those are the kinds of tradeoffs that I think we really want to help people understand. It's just that, depending on what your application is and depending on what your goals are, the Web Component maybe more important than the Mobile Component or vice versa.

Yeah. I'm distracted because I actually -- I went to Australia a while ago and did a talk on just this stuff. I'm looking for the deck because if I find this deck, then I can just read the deck and then I don't have to think. [Laughter]

What about this case? I have a lot of people approach me and they have a question, they want to write an app, they just want to write an app and they have a web development background. So they don't know the mobile technologies, and they want an Android app or an iPhone app. So they want a cross-platform development systems so they typically kind of lean towards something like PhoneGap, and I tried to talk to them out of that. What do you guys think about that?

Why do you try to actually talk them out of that? I guess that's a good place to start.

Well, because it's going to be an app that just runs on the device; there's no backend. For me, the user experience isn't going to be what they want. That's my main reasoning. Mainly, we've kind of talked about that.

Yeah, I think it really comes to the right tool for the right job if they will do what they needed to do and it doesn't feel funny when people try and use it on their phone. In other words, if it doen't behave in ways that people don't expect it to.

Another thing is, when you have just a web app, you don't have the same exposure as you do in the App Store.

Yup!

And granted there's tons of apps in the App Store and you have a battle with exposure there, but not as much as on the general web.

Yup! That's definitely a fact to that discoverability.

Uhm-hmm.

Right.

And again, like Chuck have classical example, if he's building a new server so I'm trying to get it off the ground, probably, that discoverability is valuable to him. If you're Starbucks, then you dont need to really worry that someone's not going to be aware of your app. You can just assume they will search for it or they'll search, they'll fire up the search engine in their phone's browser and look for you.

The other thing with that, too, is that most of their business walks in the door so they can put up QR Code or something that takes people into the App Store to get it. So all you really have to do is sell them on the perks of that, and then understand what the value proposition is for your app.

Yup. And one thing we haven't talked about in this kind of realm of cross-platform options is -- one of the reasons I think that people go for cross-platform stuff like HTML is they don't want to reimplement everything on each platform and maintain everything on each platform and that functionality on each platform. You can use like all of this cooler plans like technologies like Kony or PhoneGap or Calatrava or whatever. But the other option is just to move that logic off the client and onto the server. So make your kind of your client application as skinny and thin as possible, and put the logic over there in your backend. The challenge there is the performance and the usability is going to suffer because you're having to talk to your server all the time.

Yeah, I guess we didn't really talk about that, but there is that tradeoff as well where if you'll rely it on a backend service, there's going to be some performance degradation unless you're caching your saving, the information on your device in one way or another.

Yeah. That's why Facebook -- Facebook famously had this horrible app for the longest time and they said it was because they tried to this FaceWeb HTML thing and marked up both famously, well, famously I think they said, that that FaceWeb decision was the biggest strategic mistake Facebook have ever made. They made this big deal about moving from web based technologies to native technologies, they did this big rebate. But I think a lot of the reasons why they failed or had a hard time doing stuff with web based technologies was because they would using them wrong. They were kind of downloading 2 megs of HTML when you want it to find out what update, see what photos your friends has posted. You can still do that with web technologies, but if you're pulling down JSON and rendering it on the client side or something like that, then you can sometimes get the best of both worlds.

Another consideration is depending on what your app does. You may not have access to the web all the time and it may be important to access your data when you're offline.

Yeah, totally.

Yeah, and I guess that's another tradeoff when it comes down to fully on the web views; it's if you can't get to the internet, then you can't get to the application.

Right.

Yeah. Although technically, that's not true. You can use HTML 5 technologies like App Cache, which lets you kind of download to the application and store it locally in the browser. So it's kind of like local storage, but you're actually storing the HTML, the CSS, the JavaScript.

Right.

And then, even if you're totally offline, you can still use the application. I think an old but good example of this is like a little app called "Every Time Zone", I think it's called "Every Time Zone"; I always forget the name of it. But that uses App Cache and other things to make like a reunited time zone picker thing that you can look at in a browser. But if you go to it on your iPad, then you get a nice app that will work even if you're on a plane.

Now, is that tied to the HTML 5 storage?

Yes, so it's like local storage -- it's a parallel specification I suppose to local storage.

So you can use this and local storage around the whole thing offline?

Yeah, exactly.

Do you explicitly have to do that?

Yeah, it's really...it's a horrible, horrible implementation actually. It's really hard to get right; it's famously hard to get right. Like I went to a talk at a conference from -- ft.com is a really good example of folks that have embraced HTML and done a great job -- one of the things they talked about doing is using App Cache as little as possible because it's so fiddly to implement it correctly. This is weird protocol. I can never remember exactly what makes it so weird, but basically, when you first open up the page in the browser, it shows you whatever is in the cache and then in the backend, or in the background, it goes to the server and asks like, "Has this stuff changed since the last time?" like basically, "Has the app been upgraded?" If never has, then it kind of downloads the new version, but it doesn't show you the new version until you close the web page and then reopen it again. So it's very confusing to develop it; it's very confusing to debug. And if you get things wrong, then it will just never update [Laughs].

Oh, man!

And I've done that. I actually still have that. One of my 500 little side-projects is this transit app and I did a web version, a couple of different web versions and the native iOS version. The web version, I think, is still broken because it's side-project, so I kind of half-finished it and then got distracted. But it never updates so if you visited that web page at some point, then you're kind of screwed; it's like locked into this old version. Unless you manually kind of clear out your cache, it's not going to ever update. It's a horrible thing to implement, but it does work. It's just horrible to do implement.

Interesting. Any other aspects of HTML 5 or HTML versus Native Web Apps that we should talk about?

We could talk a little bit about like the presentation - the HTML Presentation Frameworks. So things like jQuery Mobile, Sencha Touch, those kinds of things, if you are going to do HTML.

Uhm-hmm.

We used jQuery Mobile when we are building this big JavaScript app. It's kind of cool because you kind of declaratively -- you can kind of decribe your user interface in very kind of declarative semantic HTML. And then, it does a bunch of work, bunch of kind of magic to turn that into a good UI. So you send down to the client like pretty skinny, straightforward looking HTML. And then when the page loads, the browser does a bunch of work to kind of like -- and actually like will run through the dawn and finds an elements and like replace them with other HTML elements and like change a button into a div and change the dropdown into a different kind of drop-down depending on the phone, and it's great! It's really cool technology. But it's also -- when we were using it, which is pre 1.0 -- but when we were using it, the performance was actually quite bad because it was doing so much of this awesome client side stuff. We found, particularly with older Android browsers, that it was like -- it was a really, really horrible experience, from a user experience point of view.

If I want to use jQuery Mobile in a UIWebView in a Native App, how do I build that in? Do I just put it in as part of the bundle and then --

Yeah, you'd probably have to do -- so what we had to do, we were doing a lot of stuff where we were building the UI client side. I have to cover all of this, this was like 3 years ago. But what we saw was that jQuery Mobile expects stuff to be downloaded from a server and then like when an document ready, it kind of says, "Alright, let's upgrade this to look cool." But if you're kind of manually inserting the HTML using client side templating or something like that, then you have to kind of tell jQuery Mobile like, "Hey, stuff just changed. I need you to do all that magic you did again." It might be easier to do that nowadays. I mean you totally can do it; you can just shove this HTML in your Web View, shove the jQuery Mobile runtime if you will into that Web View and then ask it to do its thing. It's absolutely possible. But again, you're going to get an uncanny valley type thing going on this as well because jQuery Mobile kind of tries vaguely to look native, I think. We had a pretty bad time getting rid of it.

We talked to Todd Parker from the jQuery Mobile team...

Okay.

On JavaScript Jabber, I should say. That was a month or two ago, it does a lot of interesting things, but yeah, we didn't really talk about building it into an app on the machine. We talked specifically about using it in a web page. But yeah, it sounded like they have a look and feel that is it doesn't try and look as native, but obviously, you can skin it to look native if you wanted to.

Yeah. I went to jquerymobile.com and there's this little thing where you can build the UI, which is actually really cool. But if you look at it, it does have that kind of like semi-native looking thing, it has like a button with a chevron on it. And it's a little bit ambiguous so it's not trying too hard to pretend to be -- it's not trying to reproduce the iPhone navigation or anything. But it's still quite...I don't know! I guess you're right. I guess you could just plug in different themes and try to make it null of native if you don't want to freak people out.

Yeah. But you're right, it does have the chevron and it does have some UIElements that look like UIElements that Apple provides you building iOS Apps.

And that's a good thing and a bad thing because you get all of this -- if someone is using this application, they know what chevron does; it reminds them of the chevron that they're used to on their apps so they know, "Oh, if I click that whatsoever, or I tap that, I'll probably be navigated to another page that gives me more details about that thing." So there's all these affordance he's built in because it's reusing the queues that a native UI has.

Yup.

But the flipside is you're obsessed about the fact that the chevron, the board and radius of the chevron is 12 picks, it was rather than 13 picks [Inaudible].

[Laughs] Yeah. [Pete laughs]

Alright.

I did a similar thing with my PackRat app, it's actually a Mac App that they did to hybrid. It was mostly on Objective C, but it was actually a RubyCocoa app and I would use ERB templates to generate of the page because the page, that was really complex so I decided to do an HTML layout and I used the ERB with templates to generate that. And it worked pretty well!

Yes.

Nice.

Yeah, I'm a big fan of using HTML for layout, but to do it in client side. I think it works surprisingly well.

Sounds good to me. Well, should we get to the picks?

Yes.

Alright, well, Pete, why don't you start this off?

Yeah, okay. I've been talking a lot in this episode so actually, I'm now going through and trying to decide what my picks would be. One of my picks is this open source framework, more shameless self-promotion by me. It's not something I wrote, but it was something I was kind of involved with the genesis of it. It's this framework called "Calatrava". What's great about Calatrava is you can build a base implementation of your application using web technologies, so JavaScripts, HTML, and CSS, and that will give you a Web App, an iPhone App, and an Android App. I think those were the platforms that it support at the moment. But because you separated the business logic in JavaScript from the presentation lair in HTML, you can actually take individual parts of that application and then upgrade them all the way to fully native. Let's say you have like a data entry field that you want to implement on Android in native code or on iPhone in native code, you can take just that screen, implement it natively now using Objective C, but then still drive it using the same JavaScript business logic. So the goal is to kind of get the best of both worlds where you get the cross-platform cheat to write stuff of web technologies, but then you don't hit this glass ceiling that you hit with technologies like Kony or Appcelerator where you end up having to rewrite the whole thing because you can't get the native experience that you want. So, I encourage over some people to check it out. And then my second pick is the author "Iain Banks" who has been on my list of people to pick or things to pick for a while - my pick list. He actually died the other day, which was really, really sad to hear about. A really, really awesome author; he did really good kind of regular writing I suppose, but he also did really awesome sci-fi. He wrote a bunch of sci-fi novels set in this kind of universe called The Culture, and they're really, really good. They're really good novels that happened to be sci-fi novels. They're not like really good sci-fi, they're really good novels that happened to be set in this awesome kind of crazy universe. Very dark, very twisted, but really, really awesome. So I highly recommend people to check out Iain Banks' as his name when he's writing regular books, and Iain M. Banks as his sci-fi nom de plume. He was awesome and I'm really sad that he's not around anymore. That's it!

Alright. Rod, what are your picks?

I just have one pick this week and it is the "Elixir Programming Language". Let's see, the Pragmatic Programming Guide that Dave Thomas, they have a book coming out and he did a screencast on it, and it looks really interesting. It's a functional programming language built on the Erlang virtual machine so it's kind of like Erlang with a Ruby syntax. So you got pattern matching and all the things that come with functional languages and it looks nice.

+1 for Elixir.

That's it.

Awesome. Alright, I'm going to pick a couple. The first one is a book that I've been reading. We're actually going to have the author on The Freelancers Show in about an hour. His name is Wayne Breitbarth, and his book is "The Power Formula for LinkedIn Success". I've been reading it and I realized that I'm missing out on a lot of stuff that I could be doing with LinkedIn to make my business a little bit more prominent and take advantage of it in that way for my business. So, that's one pick. The other pick that I have is related to web technologies. If you're looking to get into responsive design, and you're not really familiar with it, I have to recommend that you go look at "Twitter Bootstrap" because it makes it really easy, and then you can start to figure out what bootstraps doing to make it responsive. The last pick I have is another resource if you're building Web Apps for iOS, it's "html5rocks.com". It's just a great resource for HTML 5 and it will help you figure out how to use HTML 5 in your web pages. And a lot of the HTML 5 stuff is supported in Mobile Safari and in Chrome for iOS. So if you're looking to implement some of the stuff like the Application Cache and stuff, then that's a terrific way to go. And those are my picks! So, thanks for coming, guys! We'll wrap the show up, we'll catch you all next week!