The Changelog: Software Development, Open Source - Mobile Web Development and jQuery (Interview)

Episode Date: June 25, 2010

Adam and Wynn caught up with John Resig at TXJS and talked about mobile web development with jQuery and TestSwarm, a continuous integration project from Mozilla Labs.

I am Jan Lennard from Berlin. I work on Couch TV and you should listen to The Change Log. Welcome to The Change Log, episode 0.2.8. I'm Adam Stachowiak. And I'm Wendell Edelman. This is The Change Log. We cover what's.8. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also on GitHub. Yep, if you go to github.com forward slash explore, you'll find some training repos,

some feature repos from our blog, as well as our audio podcasts. If you're on Twitter, follow Change LogogShow, not the ChangeLog. And I'm Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N. Episode 28, can you believe it? Wow, man. On location, too. On location at Texas JavaScript.

Another interview that we did while we were down in Austin. Talked to John Resig from jQuery. Yeah, Mozilla, yeah. Mozilla Labs. Talked about the state of mobile web development. What did he say? It would be fun in about three years? Well, he said in three years it would be finally fun to develop for the web on the mobile devices.

What's three years in tech years? That's like a decade, right? Yeah, it's 30 years, right? At least. So he's got a project called Test Swarm from Mozilla Labs that allows you to do continuous integration testing for your JavaScripts across a wide range of browsers and simulators. Talked a bit about what's entailed to support all these browsers that are beyond iPhone and Android,

especially on BlackBerry and Simeon and Nokia. He's also got the devices to battle, the platforms and the software, the browsers to battle. It's a mess. Sounds like a recipe for insanity personally, but he seems pretty excited about it. Well, if there's one man who could do it, maybe it's John and his team.

Agreed. Should we get to it? Let's do it. We're joined today by John Rezig, creator of jQuery, worker at Mozilla Labs, to talk to us today about Testform, some other projects you've got. For the four or five people out there that may not know who you are, John, why don't you introduce yourself? Sure. So thanks for having me, but I'm the creator of the jQuery JavaScript library and a number of other JavaScript-y projects. I'm also the author of the book Pro JavaScript Techniques and the author of the upcoming Secrets of the JavaScript Ninja.

Cool. So we're at Texas JavaScript. JavaScript's really had kind of a renaissance in the last couple of years. Thanks mainly to client-side frameworks like your own and then Node.js on the server side. What's the state of JavaScript as you see it? I think it's, you know, very favorable. I just, I do not, like, I frequently sit down and I think, you know, where, you know, the web is going and how languages are evolving.

And I just can't envision a world in which JavaScript is not still relevant five, ten years, fifteen years down the line. It's part of every browser. It's the language everyone's using. In a lot of ways, I think now if you're still on the edge or trying to decide if you want to get into JavaScript, it's a phenomenal language to get into. There's oodles of jobs. Everyone hires for JavaScript

since everyone does web apps. I think it's the tops. Of course, I'm seeing this as a guy who does JavaScript all the time. So to suppress my inner fanboy, we'll postpone a couple of the jQuery questions here for a minute. Give me a chance to talk about TestWarm and this project from Mozilla Labs. What is it and what's it trying to do? Sure.

So this is a project that I developed last year, 2009, and it was trying to solve a definite problem I was encountering, which is that when you're testing, trying to do automated testing in browsers, specifically for JavaScript code, you have to open up a large number of browsers, you have to run the code, you have to collect the results, display the results, et cetera, et cetera. It gets very time consuming. And so sort of the premise behind getting Test Swarm up and running was that people could contribute their machines and their browsers and hook them into the swarm, as

it's called. And then projects like us, like jQuery, could just submit tests and they would run in the client machines and we would collect results back. So it would remove the burden of running those machines from us and we could just take all the advantage of running and having nice and easy test runs. So what that sort of led up to, though, and what I've been working on lately, is that when you start doing testing on mobile devices and testing on phones, it's really hard to automate that. And whereas typically on the desktop, there is some way you can automate it.

There's toolkits like Selenium, for example, and those can automate browser execution. But in phones, it's just a wild west. There's nothing there to automate that. So this is where Testform is really helping us because we're able to automate the execution of tests on mobile devices. And we're able to get results back. And we're able to develop very similarly to how we would in the desktop. So it helps to just smooth things over and make our development process work that much better.

So dealing with such a wide array of simulators and all these different platforms, all unicorn and rainbows? Not really, no. I mean, it's a lot better than what it used to be. And in a lot of ways, I think that it's... We're sort of on the cusp of mobile web development becoming really really good I think probably in a couple

years here it's going to be phenomenal because right now what we have are we have a good number of web kit based browsers which is fantastic but we also have a lot of really just weird and old browsers, like the BlackBerry browsers or the older Windows mobile browsers. And that's just a lot of legacy that's hanging around and making it frustrating for us. So yeah, it's definitely a challenging process,

especially since there has been no good information published on how to do mobile web development. When you're doing desktop web development, you know you just have to download Firefox, download Safari, download Opera, and you just open it up and you test. But you know that because it's common knowledge at this point. Whereas with mobile development,

no one knows what the popular browsers are or how to download them or how to test them. And so this is something I've been trying to figure out. And this is what I talked about today, but it's something I'm going to be publishing here within the next couple of weeks on the jQuery mobile website. Very cool. In your talk, you'd mentioned that

in three years from now, it's going to get real fun to develop applications. Are we going towards web browser? Are we going towards native? What is the best way to go towards the mobile web? The way I think about it is that you could develop mobile applications. When I say mobile

applications, I mean something you buy off an app store and you install. You can do this using HTML, CSS, JavaScript. And there are a bunch of people that are really interested in that. There's a phone gap that makes that possible. That's all well and good. As far as I'm concerned, though, that's really, really easy. You're using a latest web kit. It's a dream. But the reality is that that's a very small subset of the total number of devices that you could be targeting. The best way to get your application or your website, for that matter, in front of the most number of people is to make it a website. And just treat it like you would anything else.

So that way, your users can just open up a URL, interact with your web application, you know, what have you, but just using, you know, traditional web technologies. And in a lot of ways here, you can just, you know, it's the, what, write once, use everywhere. And so It's simply even from a logistical standpoint

it makes more sense. You just have to write one web application, it works, and you get more users. Whereas if you're targeting strictly application installs, you're severely limited.

At least from a technological perspective, I find that it's a much more challenging problem to try and target those multiple platforms, whereas simply targeting like iPhone,

for example, is rather trivial. It's a subset of the larger issue. So when we look at the mobile web, how many browsers do we really have to support? There's Symbian, there's Windows. How many are there? There's a lot. At least in counting all the different operating system versions and devices, what it boils down to is about a dozen devices, physical devices you have to own. And then on those there's a varying number of

browsers you have to support. It depends because, for example, Opera runs on most mobile phones. Opera Mobile and Opera Mini. And then Fennec, the Firefox for mobile, runs on Android and M Mini. And then Fennec, the Firefox for mobile, runs on Android and Mamo. And so it's...

The total number of browsers is a little bit larger than the 12. But in total, it's definitely more browsers than what we currently support on a jQuery desktop. Because right now we support, I think it's 11 browsers, and so this is more than double our browser coverage. Talk about Finnec for a moment and Firefox on mobile. Is this a code name?

Is this the marketing name for this particular platform? And where are we at in the lifespan of Firefox on mobile? I think it was a code name. I think it's the actual name now. Don't quote me on that. Where are we in the lifespan of Firefox on mobile? I think it was a codename. I think it's the actual name now. Don't quote me on that. Because, I mean, they have, like, the logo and everything. It's Little Fennec Fox, and it looks really cute. And so, I mean, the big push,

or so traditionally it's been running on Mamo, which is a Linux-based operating system that was on Nokia tablet devices. It doesn't have a lot of market share. They started work on a Windows Mobile version, which was probably a good idea, but the problem was that they weren't able to get tools for Windows Mobile that allowed them to build a good enough Firefox. So they canceled that project, and they're focusing almost entirely on Android now, shipping a really good Firefox browser for Android.

And I've played around with it some, and it's fantastic. In some ways, it's even faster than the built-in WebKit-based browser, which I think is pretty cool. And so I think there's a lot of potential here for additional competition to really bring new browsers into this market, especially so on Android. Because Android is growing like gangbusters here. And so both Opera and Android, I think, have a lot of potential to grow here. When we look at the space of the mobile browser, like you just mentioned,

how does that trickle down in comparison to, say, the desktop browsers? Like, the standards, do we have the same troubles, the same different issues with supporting standards and certain types of standards being supported on web browsers for mobile? So the problems do exist. They're tending, generally speaking, they're tending towards a better state. So, like, for example, BlackBerry they're tending towards a better state. So, like, for example,

BlackBerry has their own custom browser that they wrote, and it's not quite as good as what the other browsers have. They just did a rewrite, and the next version of the BlackBerry browser is going to be WebKit-based. But generally speaking, the browsers that we're supporting on

mobile are generally equivalent to the browsers you see on desktop. Roughly speaking, what you end up supporting in mobile is like Safari 2 and newer, Firefox 3.5 and newer, IE 6 and 7, and Opera 9.5 and newer. That's roughly what the versions correlate to. So yeah, it's a pretty manageable problem. The difficulty is just those little quirks that get you, and the simulators and all the knowledge that has to go into making sure everything runs smoothly. I'd say probably most of the issues you're going to encounter

in doing mobile development aren't going to be logistical JavaScript-y issues. They're going to be more interaction issues. Developing good UIs, developing things that work with touch interfaces. I've got a feeling that's probably where most of the work's going to go. A lot of web development is using tools like Firebug. Since you're developing for the platform, you're also consuming as a developer, you get to kind of inspect the markup and interact with your application in a live environment. You mentioned in your talk that the simulators are often kind of, it's difficult

to simulate the actions that you're performing. How much more important are tests in this Brave New World? I mean, it's critical. And so it's, there's two things. There's the testing and there's the debugging. And unfortunately, debugging is really not solved yet. So there's tools like Dragonfly for Opera, which does that a little bit. It gives you like a developer console that you can use and have it hook into mobile devices.

So that's something. But in general, there aren't really tools, like Windows Mobile or BlackBerry or Fennec, for that matter. They don't have those debug consoles. So it's definitely tricky. And this is one case where... So testing will get you part of the way there and that it'll make sure you have good coverage and stop you from getting regressions or at least help lead you on the right track um but it's not going to help you

to actually fix the bugs and that's still hard so you didn't jump into this new mobile world because you were bored and needed a weekend hobby you really are trying to push forward to get jQuery in a more mobile-friendly state. Talk about progress around that. So when looking at the mobile system, I wanted to make sure that jQuery was going to be a capable mobile library. And one of the things that I thought originally was maybe a good way to distribute jQuery would be like have a stripped down build of just things where only like WebKit devices. That could work, but I don't think that's as interesting of a problem. What I think is more interesting is being able to ship one copy of jQuery, have it be the copy of jQuery, it's the same one you download on the website,

and have it work for both all the desktop browsers and all the mobile browsers, and just have it just work. So that way you can publish your website using jQuery, and it's going to work on desktop and mobile, and we can make that guarantee. I think that's a far more interesting

problem, and something that no one else is really tackling right now. So at least going forward, most of our effort isn't going to be that interesting, or at least it's not going to be flashy and gestures and stuff. It's going to be very straightforward in that we're just going to make sure we work and we can guarantee that we work and we're testing. Which is, it's a lot of work and that's something that we really want to push forward towards. How much has projects like JQtouch

influenced your work at all? I mean, yeah, JQtouch and IUI, I mean, they're both fantastic projects and they they're predominantly focusing on the user interface, making sure that users have an easy way to produce an interface to interact with. The thing is that both of them tend to emphasize

replicating an iPhone-like experience. And that's something, but it doesn't really work outside of an iPhone. It doesn't really work on Android, it doesn't work on a Palm, it doesn't work work outside of an iPhone. It doesn't really work on Android, it doesn't work on a Palm, it doesn't work on Windows Mobile. You really need to have something that's much more generic

and something that is producing a good user experience more universally. So this is something that I'm very interested in and something I'm going to be pushing forward on after the jQuery core bits are done so that we can provide users with the tools they need to have a good mobile application that isn't iPhone-specific.

Continuing that thread, the health of an open-source project can really be judged by the ecosystem it supports as well. Two projects that we featured on the show that I'd like to get your feedback on. First is Sammy.js, and the second, UnderscoreJS. I played around with both of those a little bit and I wish I had more time to play with fun JavaScript projects. But yeah, I mean

Underscore, I played around with it because it provides all the different utilities and such. That's right. I like that one. It certainly had an interesting API. It was nice to use. Then Sammy was the script loader.

Sammy is the one that mimics Sinatra in the browser so it gives you routes and hash-based state. Yeah. And yeah, I mean, they're cool. And, like I said, I wish I had more time to, like, really dig into it. Same thing with, like, Node.js, for example.

Like, that's hot stuff, and, like, I just have, like, no time to, like, actually sit down and, like, build a Node.js application, which is funny because, like, you know, like, all I do all day is JavaScript, but, like, I have no time to, like, play with other JavaScript. So what, and this is usually the part of the show we ask, what is on your open source radar? So it doesn't have to be JavaScript related. Rocks you've uncovered in this new mobile world

where you're uncovering all these little known simulators that we're now being forced to deal with. What projects have you excited? What is pushing the envelope and has you excited to play with? I wish there were more projects relating to mobile web. There really aren't that many. The one that I was playing around with recently was

Touch Scroll, which helps to simulate scrolling gestures on iPhone devices. And because that's one of the problems with the iPhone is that you can't have position fixed elements. So that's something that helps position fixed elements. So that's something that helps to work around.

That was a pretty interesting piece of code there, and I've been playing around with that a little bit. Another one, the name is escaping me at the moment, but it is written by Yehuda Katz, W.Y. Katz, on GitHub. And he was working on doing state management.

So being able to manage, like loading in remote JSON resources and having them hit the cache wherever possible. So, I mean, that's been a challenge in and of itself, but it helps to allow you to build offline applications easier. When you say you wish there were more projects in the mobile web space,

for the JavaScript guys out there who either want to impress you say you wish there were more projects in the mobile web space for the JavaScript guys out there who either want to impress you or just get into a cool project. What kind of projects do you want to see happen in the mobile web? More projects that aren't just for the iPhone. If you look at almost all the

JavaScript projects that are for mobile are just for iPhone. They're, you know, JQtouch, IUI, you know, like all those, they're just, that's all they target. And if it happens to work in Android, then they're like, okay, but like they don't even go beyond that. So if something that would impress me would be things that work on more platforms, you know, things that take BlackBerry into account, take Windows Mobile into account, and then you'll have my attention, for sure.

You know, I'm seeing another parallel to, you know, when the web came out, we did a lot of work to try to emulate desktop interfaces in the web. And it seems like they always fall short. And as powerful as HTML5 and these new JavaScript frameworks, we have a lot more tools at our disposal now. And it seems like a lot of times when we're building web interfaces in the mobile web, we tend to want to emulate native widgets, where it seems like we're always just a bit lacking should we just be changing our focus and coming up with new interfaces that that are just web-based

and we're proud of it yeah i suspect so i mean i think a lot of what we've learned building because a lot of what we've been building historically on desktop web apps has been mimicking desktop applications. Modal dialogues and grids and stuff like that. It doesn't make sense at all on a mobile device. No one would ever use a grid on a mobile device. It's insane. You definitely have to rethink

how you interact with information and how you display it. This is something I'm very excited about. I definitely want people to tackle this and release frameworks that try

to think of new ways of interacting with this information and hopefully ways that aren't just copying what the iPhone is doing. One more question. There seems to be a lot of heat around templating in JavaScript these days with Mustache.js, and you've got your own templating thoughts that you've put on your blog. What's your thoughts on templating, and is it an idea that's here

to stay? Now that we have JSON, we're passing data back and forth. Is there a new way of building web applications? What's your take? I definitely think there's a lot of potential. I mean, we just recently worked on a new templating module for jQuery

core and that's been good. People have really enjoyed that. And it sort of took some of the existing templating work that I had done, combined in some of the techniques from Mustache.js,

and kind of come up with this new set of functionality that's really, I think, good and very usable. And people seem to like it. Cool. Thanks for joining us. Yeah, thanks for having me. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com

to find out what's going on right now in open source. Also, be sure to head to github.com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of The Change Log. Safe in your arms As a dark passion shown What's mine alone I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm

I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm Thank you.