Sure, my name is David Kaneda, I am the Creative Director at Sencha and also the creator of JQTouch which was about two or three years ago I wrote one of the early JavaScript to feeling like a native application frameworks. And I also helped work on Sencha Touch which is our current rich internet application for mobile.
So I actually came at it from a different prospective in regard to starting as a web developer, web designer of course the iPhone came out and I got super excited by that, right around when the iPhone came out, and Jobs gave his web apps future thing, I started to investigate the browser on the iPhone and that’s when I became specialized in WebKit. And from there I had a few iPhone apps that I wanted to work on, and I put out one native app called Outpost which was for Basecamp and then I started to look at doing more. Outpost I actually created with a partner who handled most of the development whereas I did the design, and as I started to look at building these things myself, I began comparing Objective C, seeing what was possible in the browser, and just ended up deciding we could just build the whole thing in the browser.
Yes, so I would say for a large portion of it the browser unfortunately is a little bit behind in terms of native, compared to native. When you are looking at things like speed, performance, those types of things, it’s very difficult to achieve that native performance but as we are moving forward we are seeing these devices get far more capable with each revision and now we are actually at the point where we are pretty much on par with native in terms of performance and then on top of that as you mentioned CSS as a theming layer I’ve always found it’s far superior to every other theme system I’ve been presented with, Objective C, any object oriented system forces you to put theming into classes even ActionScript, Flash, things like that, whereas compared to the web where you have this idea this separation of HTML for structure, CSS for style and JavaScript for functionality, I’ve just always found that separation to be far more efficient when customizing applications or creating them.
So again personally as a design centric sort of guy, everything that is going on with CSS3 is very exciting, there are a lot of things out there in regard to the specs for CSS4 which I find very exciting things like variables, referencing parents, that sort of thing within your style sheet, currently and for the past year or so I’ve been focused on Sass and Compass as two emerging technologies, which are extremely helpful in creating CSS and style sheets, in addition to the styling aspects there are also local storage I would say the device APIs in general are one of the most exciting parts of the emerging spec. And I am not entirely sure if that’s under HTML5 or parallel but it’s part of that whole group that’s moving together.
Exactly, yes, that’s obviously one of the biggest areas that I hope rapidly moves forward, we already have things like on Android access to the camera, accelerometers, access everywhere I believe, but there’s still a long way to go I think there is no reason why we can’t expose more and more these things like we expose to applications to the browser as long as people take security considerations into account that should be fine.
I would say, well by developing things on mobile browser especially targeting some of the newer class A browsers, WebKit especially which is super popular right now, you can actually develop and debug almost your entire application on the desktop side using just Chrome, WebKit inspector, for me personally as I create apps I generally develop the entire app on desktop within my browser and then near the later stages will bring it on device and see if there are any sort of discrepancies and fix those. But for the most part I actually much prefer debugging and testing a web application compared to something like a native application where you have to worry about garbage collection and those types of things.
It’s depending yes, it always depends on what your target is. So by targeting Android, IOS and Blackberry, these sort of class A browsers, there is actually a tone of rock solid layout techniques my favorite being the flexible box layout that was introduced in CSS2, and is now seeing some revisions in CSS3 but it’s actually very solid and very powerful layout system.
Exactly and again it comes back to your target audience, I think a lot of enterprises are forced to support Internet Explorer and so obviously you’re not seeing HTML5 development in 6 and 7 there, but as IE iterates, you are actually seeing some decent support for HTML5 in IE9, IE10 especially and I think it’s moving along, it always comes back to what your target audience is, and if you are supporting these legacy browsers, but as an emerging spec, as looking at the browsers that are out today, and browsers that are coming out within next year or so, it’s becoming very widely adopted actually.
I think the biggest challenge I would probably say is performance, and so within the Sencha Touch specifically we’ve spent months around just focusing on improving frame rate for scrolling, getting transitions to happen smoothly, those sorts of things. You know and also loading quickly and those sort of things because you are on a mobile, there is a good chance you are on 3G, you might even be on Edge so that initial load, getting that as low as possible is sort of one of our biggest challenges. And what we focus on probably the most of everything.
Right, so the event system granted it’s on WebKit so at its core the event system is very similar but of course abstracting things to the point where they can use mouse events where they need to and touch event where you can becomes important. Aside from that the actual setup of those types of components and interactions is very similar, it just really comes down to how you are handling touch events versus the mouse.
11. I suppose your suggestion would be that my best bet would be to use something like Sencha Touch?
Yes, not to hock product but yes, I mean that is one of the huge reasons people look to frameworks especially on mobile is some of this stuff can be extremely complex in terms of performance. One very quick easy example is a simple tap, for some reason on mobile WebKit they decided at some point although touching the screen and everything in your browser will fire these touch events they also fire the click event mouse down etcetera, except those events are delayed. The click event especially is delayed around two hundred, three hundred milliseconds after one takes the finger off the screen, so being able to abstract that to a point where we say actually look for the touch events and say touch start, they haven’t moved their finger and touch end that constitutes a tap and that’s one we should act on it. Minor things like that can actually be incredibly complex to program but at the end of the day, if your app has a three hundred millisecond lag for every button that you tap, it’s just not going to be good enough.
So on the user interface side, that touch abstraction and we also abstract for performance, so that we basically delegate all of the events, so that the developer can bind as many as they want without too much of a performance degradation, but also we add in events on top of the default system, things like tap, swipe, double tap, and of course it’s all object oriented so you can create your own gestures as well.
13. Is it through a specifically API or not?
Yes so we have our own API built around binding events etcetera, it’s pretty basic and simple, but that touch layer, sort of the core, sort of the bottom of the UI stack. And then as we move up we’ve actually also created a scrolling layer, which again one of those biggest hurdles that you face developing from a WebKit is that there is no position fixed, aside for IOS5. But there is no position fixed and there is no overflow auto so to create an application where there is a tool bar fixed at the top and a middle piece that actually scrolls, as simple as it sounds it’s actually the most complex things that you can do. So we take care of that for you. Again, you are able to just say this is a scrollable view, and then you can actually give it the bounce that IOS has, it has friction, it has momentum of those types of things just sort of out of the box we provide. And then to go one level higher, we then build all of our widgets on top of those two so things like buttons are responsive to touch immediately, lists can scroll up and down, even more advanced form elements like pickers and spinners and those types of things, are all based on that core platform.
And so on the UI side we provide all that out of the box, so a whole widget system that is rich, responsive, fast, and then on the application side we also provide an MVC part of the framework, a data layer which is extremely important when you are building sort of a data driven rich application, and even within that data layer for easily lets you consume JSON, XML, whatever you want, we also include a client side ORM which actually lets you create associations between your data, has many belongs-to etcetera, which makes it a lot easier to get the information you need as you are building the app.
Yes and again it comes down to your goals and what you are trying to create. It is not a responsive design framework, it’s not about progressively enhancing your website, to sort of fit a twenty pixels screen, but at the same time it sort of comes down to what you want to accomplish I could see a news site for example or a blog let’s say, kind of getting away with a responsive website where you have this really long page to scroll, or sort of serving up the desktop version, making user double tap, zooming in on content etc, but is that the experience you want to give? If I am Netflix for example or if I am a car seller, that sort of thing, I would want the user to come in and give them an application experience where they can add favorites, add things to some sort of list, all in terms of comfortable user experience.
Sure, so it’s interesting because there is the spectrum of website and mobile website and then there is the application and now there is this entire middle grounds of what you can accomplish in between, we’ve seen full fledged data driven applications for accounting, finance, all that sorts of things built in Sencha Touch. Boston.com has a Boston deals site which is very pretty, but then also a company that I used to work with actually creates these beautiful experiences for architects, where they are essentially portfolio websites, but they are rich they have carousels where you can look through their images things like that, experiences that you can’t achieve in a responsive environment because those clients to them are expecting that sort of higher level of experience.
Well, I would say the experience in general is achievable I used to be a Flash developer, and fortunately for whatever reason it never came to the iPhone in terms to the browser, so in regard to the ability to serve it as a websites, as a full fledged web application at a URL, they are just not capable, at the moment.
Yes, so HTML5 in general, somewhat unfortunately has kind of split the community in terms of you have these "standardistas" who are interested in new tags, and new semantic aspect, the accessibility layer, all that and then there is the applications centric part of it, where you have new input types, the device APIs that are merging, so obviously that side of it is a bit more interesting to me, device APIs as we mentioned are a huge area of interest that I think would expand greatly in the next year or two.