Bijan Vaez on HTML5, Mobile Development with Web vs Native Apps

1. We're here at QCon New York 2013, and I'm sitting here with the creator of the EventMobi platform and app. So who are you

I'm Bijan Vaez. I'm the CTO of EventMobi and what we do is develop a platform that allows events like QCon to be able to build their own apps, HTML5 apps, and distribute to their attendees in a matter of minutes. We have an API that you can push all of your conference data to, and our system will generate offline capable cross-platform HTML5 apps that you have full control over all the customizability and look and feel and all that sort of stuff.

2. EventMobi is essentially a web service and that creates resources that you can load on into the browser, an app so to speak. Is that right?

Exactly. We do essentially data management for conferences and turn all that data interactive through mobile apps and there are different features that we offer events.

3. How customizable is that? Can I put in my own CSS or is that mostly specified by you or created by you?

So the HTML structure we have to maintain mainly because it's mobile web and gets kind of finicky keeping cross-platform compatibility, but we do have clients who do a full CSS reskin and they can really customize everything. We allow some sort of customizability through our backend so people who aren’t so techie, the graphic design team can come in, upload their icons, change color schemes, edit their branding, all that sort of stuff. So it's fairly customizable. We're working on making it more and more and more customizable so it's really a self-service platform they can do everything with.

4. I can vouch for the quality of the app because everyone here has been using it and it works. Its HTML5, it works offline. It's amazing. It shouldn't work, but it does. So why did you go with HTML5 and not a proper mobile solution, proper C or Java, like every upstanding developer?

I'd still say this is just as proper as any of the others. I think for us it came out of necessity in the beginning and mainly because we were -- we actually started doing native apps in 2009, and we were trying to prove the business model. And being the engineers we were, we quickly realized that this gets really tedious and boring, doing similar type apps over and over again for different clients. You're essentially copy/pasting a certain base framework of code you have and then customizing for a client. We thought we could autogenerate this. And to do this we're like, okay, the web is the easiest way to manage this. So let's move towards mobile web, build it out, and then once we prove it then we'll come back to native. And then that's been four years and we've never had to look at native yet mainly because of the way HTML5 progressed, it gave us the flexibility to add in offline features, things that would have forced us to go native but we can now do an HTML5. And it works fairly well and browser support is great, and we can keep innovating in this space.

5. And so you couldn’t have created, auto-created, these same apps. As you say, you create these HTML apps from data. Couldn't you have also sort of created these things, one for iOS, one for Windows Phone and so on? Is that an approach that wouldn’t have worked? Would it have been too tedious?

It would have been far too tedious mainly because when we started Android still wasn’t around. The tooling around these developers' ecosystems so the iOS, XCode packages and that sort of thing wasn’t really there for us to be able to automate it really nicely and then we'd require expertise in a variety of different frameworks and languages. And with two engineers, you're kind of limited in what you can do. But, yeah, it is certainly possible but even at some stage with native apps, you can't automate everything.

And even the standard stuff that we take for granted on the web becomes much more difficult on the native side where -- the way you do your testing and integration test, functional test, load test become much more simpler on the web whereas become much more difficult on native in trying to automate all of that. So for us it enables us to move quite a bit faster, iterate on our product multiple factors faster than it would be on native, and we require less personnel to do so so we can optimize on working on the stuff that we enjoy working on rather than tooling to just get stuff working.

Werner: And of course, it's much easier to deploy the app because it's not really -- there's no deployment I mean, app stores you have to go for all the madness of pushing things and signing things and stuff like that.

So there are tools now that do like the auto certificate kind of generation and all that sort of stuff and it becomes a pain to work with, and you need a lot of admin work kind of around it to manage this whole process. You need people kind of overlooking it. Oh, and then, hey, Apple is going to change their certificate a little bit and everything breaks and you kind of have to go through it. And then it's taking away from what you actually need to focus on which is the product. That's why we like the web and we can focus on the product and what really matters and kind of leave all the extra stuff behind. And as long as we can keep innovating in that space, I think the web makes sense. There is -- I'm not saying nobody should do iOS and that sort of thing. I think there are probably use cases where native action makes more sense. But for our use case and for what our customers want, the web is a much better platform to be on.

Werner: There are services like PhoneGap Build which would do most of the job I guess, you give it some code and it spits out the binaries for different platforms.

Yes, that now would make life quite simple, and we are starting to look at PhoneGap Build for some of our premium clients maybe that do that marketing kind of push to have a native app, and maybe we could eventually provide it for them. For the time being though it's not something that we've been pursuing. But, yeah, it is definitely is PhoneGap has really changed the landscape in kind of what you can do.

6. So obviously, HTML5 has progressed far enough to do everything you need to do right now. So one thing I can attest to is that this thing actually works offline so you can kill your Wi-Fi and the data is still there. So that's good. So what feature or what behavior would get you back to a native app? So what feature in iOS or in Android would get you back to write either a native app or customize some PhoneGap code?

in terms of the type of application that we work on, we're not doing gaming where we require low-level access and crazy hardware acceleration, that sort of thing. So for our UI, we can actually optimize it quite nicely to work and be very performant comparatively to native products as well and some of our animation. Sometimes you might just have to limit what our designers are going to come up with and then kind of manage it within that expectation.

But I think the main things that are still kind of outstanding in HTML5 is still getting closer links to device APIs which I understand is difficult from the vendor side because they are adding so many different features as well but things like push notifications I think would be huge, expanding on the idea of like an installed web app. And I think Mozilla has kind of been working on some of that as well but expanding that idea and making it more robust and what you can do when somebody actually installs it or adds it to their home screen. Opening up other functionalities to them and giving them some more device access I think would be huge.

But yeah, on the other hand, performance is also I think the main thing that's missing, getting that low-level access. But if you're going to go on web, you're probably not going to be working with crazy graphic stuff anyways. Well, I mean now there's some really cool WebGL stuff that's coming out so maybe I'm speaking too soon. But really I think for us I mean we have camera access now which is great. We have GPS on iPhone to get accelerometers through HTML5. So with all these I mean most of the features that you need are there. I'm really hoping actually NFC gets exposed through the web as well and that would really open up some interesting things.

7. Since you mentioned NFC, what would that be like? I mean, what would the -- would there be an event that an NFC tag has been detected or something?

Well, the way I would imagine it is there would be JavaScript APIs that have event handlers that you would listen to, and if you swipe something it will call that event handler and then you can just start parsing NFC, similar to QR codes, figure out what action it's trying to do and take that action on that person's phone. All this stuff that we deal with QR codes and everybody hating it but everybody still wanting to use it, I think all that will go away as soon as you have NFC proliferated not only through native apps but through the web as well. And I think what makes QR codes really powerful that everybody uses now is just that simple redirect and that's the main functionality of QR codes. But if you can't do that through NFC, then it's going to be a little bit of a -- I mean, there are obviously a million other uses for it, but I think that would be a really, really great use.

8. Do you see NFC taking off at some point? I mean, so Apple has been reticent to adopting it for various reasons. Do you think they have a good reason? Are there barriers to entry with NFC?

I'm really surprised actually. I thought with the iPhone 5 release they would have released it. I'm still hopeful that with the next iPhone they're going to release it. I don’t see any barriers. I think for them they need a very -- anytime Apple releases a feature or kind of a small product they need that ecosystem around it to make it useful. Whereas on Android, it's all feature packed. Everything is in there and then they're waiting for developers to build on top. Apple wants to introduce everyone to that feature with very specific use cases and say, "This is why you need to start using it now and it's available and here's what you can do with it."

So I think they're still waiting to get that ecosystem built out, and I think their main use is payments. And once they get payments kind of running and they have a nice system that they can work with, then for them they're going to come out and be like, "We revolutionized the world." Now you can pay with everything and everything has a wallet and all that sort of stuff. My guess anyways. But I honestly think NFC could take off. Now most of the mobile devices have it between Blackberry and newer Androids and that sort of thing. And it's not a new concept and although we've been hearing it in the context of mobile phones, NFC or RFID has been around for 20+ years in various different methodologies and people have implemented all sorts of different technology within and different tools. And I'm actually surprised it has taken this long to catch up with consumer electronics.

9. Well, I guess a particular important use case would be or worldwide standardized use case would be key for that and that doesn’t seem to exist. It's also I think the problem that vendors or point of salespeople need to -- I guess they need to install something, some hardware or something that might be a big issue. Is that right or is it easier than I think?

So the NFC stickers are data essentially that you want to transfer in volume, cost less than a penny per. They're like thirds or fifths of a penny now. The last time I looked it was four or five years ago and it was already that cost. I'm sure it's even cheaper now. The readers themselves can get pricier here, but now that we're seeing them again in volume being incorporated within phones and I think that's where a lot of new POS systems are going. They're saying, "Hey, you guys already have these devices. You have an iPad and you have all these devices. They have all these capabilities. Why don’t you just use these instead of going and buying $2000 POS device? Just use your iPad which has all these capabilities." Or use this Android tablet that has an NFC in it and it has NFC reader and you can just tap stuff. So I think everything is pretty much there.

10. So it just needs some momentum, to gather momentum or...?

Yeah, yeah, it's -- I mean pushing stuff consumer side is always difficult. There are so many different challenges. But I honestly think it will -- in the next two to three years I wouldn’t be surprised if there's a major push towards NFC. And I mean we're already seeing it. The credit cards you use now all have that tap thing and everybody is using it. It makes life so much easier. You get something, tap it, and it just prints your receipt and all right, you're off.

Werner: Right. I still use cash so...

Okay.

Werner: That works everywhere.

That's true. It does unless the exchange rate doesn’t really help.

11. So coming back to HTML5, so as we said, we talked about device APIs or something that would be nice to have. Anything else? So we talked performance or efficiency. What about concurrency? Are web workers enough for you?

Yeah. So I think web workers is a great step towards where we need to be in terms of creating much more complex HTML applications. I think in terms of WebSockets as well. I can't wait until that becomes a little bit more prevalent in terms of usage. For us specifically it creates kind of barriers using WebSockets in the conference setting where very specific network infrastructure that blocks out certain protocols of communication that it doesn’t know and all that sort of thing. So we're waiting for the network infrastructure to upgrade so we can just use WebSockets. And I think until that happens, once that happens it will be amazing and not having to worry about HTTP overhead and sending cookies you're not supposed to and all that sort of stuff.

I think that would be really cool. I think in terms of -- the other kind of things that come from HTML5, I'm not sure what -- yeah, this is my spotlight to ask, but I'm not really sure what I would specifically ask for.

Werner: So maybe I can help you.

Sure.

Werner: How about -- so your app stores all the data locally and I think from looking at all these… -- well, there's a huge list of local storage options. That's the simplest one, localStorage, basically the key/value thing. Well, then there's Web SQL and this and that and the other. So what do you currently use or what would you like to see? I mean, are they any good or...

Right. Yeah, I completely skipped over this stuff that we deal with day to day because I'm dealing with it day to day. So I guess the first thing is the AppCache is a great kind of first start towards client-side persistent -- essentially has some edge, but getting granular control over that I think would be huge and actually being able to programmatically manage it rather than it's an all or nothing kind of cache. And it's a pain to deal with, I kind of mentioned in my talk as well. But it's really powerful and I think if browsers kind of expanded on that spec and start implementing better control over it, that would open up a lot of doors.

I think on the localStorage and WebSQL side of things, I really hope a spec can be reached between the vendors fairly soon. I think that's really one of the detracting factors about people not moving towards offline HTML5 yet is because it just seems like it's completely in disarray and vendors are kind of fighting over which spec it should be. And we know WebSQL is now deprecated but then what's the alternative, and nobody has really -- Safari has no plans of implementing IndexedDB as far as I know. So we need some sort of coordination there between the vendors to get this sort of spec up and running so it can give confidence to the community that, hey, it's set, you can use HTML5 offline and here is all the data you need and that sort of thing.

But, yeah, I mean I think it's a great start. There's a ton more that we can do. We deal with a lot of issues with the AppCache and a lot of nuances here and there. But, yeah, I mean you can get up and running but when it starts getting really complicated it becomes really difficult to deal with and I would love to see that kind of made easier.

12. So is AppCache fixable with an AppCache 2.0 or do you think something -- a different approach is needed? I mean, from working with it, what do you think?

I think it's fixable. I think everything is kind of progressive enhancement. I think people know where it needs to go and enough people have used it that there's a lot of people thinking about how it should be made better. I don’t think there's any need to completely scrap it and go with a different way. I think it's simple enough that traditional kind of web developers can use it right away. I mean, traditionally, we think of these complex web applications but even if you think about standard static websites just using an AppCache, they don’t have to make roundtrips to the server because these people probably are not into high performance websites and that sort of thing. They're just getting their static site up and running. If everybody uses these caches very simply, we're saving a lot of network bandwidth overall just of stuff that doesn’t need to be sent around. So I think it's a great spec that allows people to get up and running really quickly, but it does need -- it definitely needs some improvement.

13. Things like telling AppCache to update certain resources and things like that I suppose?

So being very granular and saying, "This one I know is out of date. So I want you to just make the single HTTP request for this one file." I think one of the other things that could be really helpful is managing when -- being able to restart essentially a cache manifest. So right now if you have any errors midway between when the manifest is trying to cache everything it will just stop and the cache goes stale and you can't really use it. You're going to have to tell your users to go and clear their cache, restart the page and then restart the process all over again and that just makes no sense. You should be able to programmatically see, oh, there's a 404, take some action or either remove it from the cache, restart it, whatever you need. And especially because we're -- for us one of the biggest difficulties we found is because we're dealing with 3G networks and poor Wi-Fi networks as well there's a high probability that the packets are going to drop, that that initial request isn’t going to make it to the server and the cache goes stale all the time and that becomes a really big problem.

14. Another issue that I might see is quotas, so maximum size of data that you have. Do you run into that with EventMobi or is your data compact enough? What do you think?

We do run into that. So initially we -- well, right now we're actually still using just localStorage and obviously that's very limited in size and we are running into that. I'm glad to see now that the IndexedDB shim and polyfill are kind of matured to a point where a lot of people are using it. Well, the shim has kind of Facebook support as well and they've been using it in production. So it's a great way to start making use of Web SQL and IndexedDB to get a lot more space to play with. And I think with those technologies that you -- I hope that stays the same where there's no specific set limit, but you can always ping the user and ask for more information. And I think that that's a really good way to approach this is every website is going to be different, but some websites they're just very data heavy apps and they require that to allow people to store that but ask the user kind of how they like to proceed. Yeah, I think now we're kind of slowly transitioning that way as well. We see that we have the capability to kind of play with both and have it work fine across those.

Werner: So I guess that's one of the big advantages of native apps because they don’t have to ask the user for more memory.

Yeah, yeah, exactly. Although even with native apps you run into the problem of if you are updating, if you are keeping kind of a dynamic app and you're updating stuff over the wire and you have to update this and that sort of thing, it's still very heavy process and then you generally -- well, most apps that I see have to block the user flow, update what they need. I mean, it doesn’t have to be this way, but most of them are. Whereas with web, we've already dealt with all those issues and keep the user experience much nicer.

15. So to wrap this up, are there any particular platforms that you're looking at like Firefox OS or Tizen? Are you looking forward to them or you think they are problematic? Are they going to introduce problems? What's your take? What's your tip for us?

I wouldn’t say that there are specific platforms that I'm looking at because mainly as much as we'd like to be super forward thinking we have most of our users are still very legacy using -- I mean, we look at our analytics and we get sad every time we see IE 5.5 still pop up. Not that many, but it's --

Werner: You poor man...

Hey and our apps still support it. So I look forward to what the future brings, and I can see where the vendors are going. They have been very good at listening to the application developers like us and kind of what we face. I think one of the biggest issues on mobile is still the login and authentication through mobile and the mistakes people make, the lack of attention span they have to deal with authentication systems and that sort of thing.

So I'm really looking forward to like Mozilla's Persona project and seeing how that picks up. For us we've been tweaking our user experience on our login page and many people as soon as they get to a log-in page they just drop the app. They don't want to do data entry on a phone, and I think that sort of thing would be really helpful. But in terms of what's coming out, I think there have been so many advancements in terms of the platforms and how Chrome -- and now Safari has sped up JavaScript on mobile because there really is orders of magnitude difference in performance on mobile browsers in JavaScript and desktop. So that's slowly being shrunk down and that's really promising to see so I'm just -- we're just excited that that's continually happening that innovation is going.

Werner: Great. Thank you very much, Bijan.

All right. Thank you.