[raganwald]

While I laud your transparency, I lament the chilling effect this will have on existing libraries like JQTouch. jQuery Mobile isn't available today but this announcement will make a lot of people sit on their hands waiting to see how things play out in the hope that they won't invest in a dead-end platform.

Oh well, not saying you shouldn't have chosen this path, just pointing out the consequences...

[jeresig]

jQTouch has been out for a couple years at this point - a two month "chill" period before release seems totally appropriate.

Honestly, I don't see the "chill" as being a bad thing in this regard: jQTouch and Sencha Touch are doing mobile web development a great disservice by only supporting the latest-and-greatest WebKit platforms. If we can get developers to actually think about supporting more of the mobile platforms that are actually used then I will consider the project to be a victory.

I discuss this much more in our strategy outline: http://jquerymobile.com/strategy/

[dcurtis]

"jQTouch and Sencha Touch are doing mobile web development a great disservice by only supporting the latest-and-greatest WebKit platforms."

How is focusing on the future doing a disservice to anyone? We're at the very beginning of the mobile-optimized web, and the future is still unclear. There's still room to define it. Supporting the equivalent of IE6 on mobile devices seems like a waste of time to me, especially after we've just spent a decade watching the evolution of the desktop web be stunted by obsessive focus on backwards/cross compatibility.

Also, nearly all major device manufacturers have committed to using WebKit. In five years, how many mobile devices will not run WebKit? If Windows Phone 7 isn't dead by then, it might be the only one.

[mrkurt]

I don't really relish a future where one browser engine dominates the way IE has in the past. I fully expect and hope for more viable mobile engines.

Even still, jQtouch (at least, I haven't messed with the Sencha thing) is very iDevice slanted. There's "webkit" and then there's "webkit on iOS", and most tools are targeted specifically at "webkit on iOS".

[dcurtis]

The thing the differentiates WebKit from IE in a good way is that it's completely open source and it's used and built by several competing companies working together toward a common goal.

[mrkurt]

It's also behind both IE and Firefox in various ways. You're right that it would be a better dominant engine than IE was, but it's still not as good as having a nice three way competition for browser share.

[paulirish]

How is focusing on the future doing a disservice to anyone?

Well, you're clearly not serving the present.

[_neil]

Competition is a good thing. Choice is cool.

[raganwald]

Well it's your call to make and I'm not going to second-guess you on it. Good luck with the project, as you probably know I'm a jQuery fan and I'm looking forward to seeing what you come up with.

Naturally, I expect to see into, tap, ergo and when in the jQuery core as well...

http://github.com/raganwald/jQuery-Combinators

;-)

[armandososa]

With all due respecy John, I think we all should focus only on the latest-and-greatest WebKit platforms or on platforms that are comparably good. Mobile development is exciting precisely because it's a road to the future.

Look at the place we are in desktop web development because we have to support old browser. We are stuck 7+ years in the past.

I understand the intellectual allure of writing a framework that supports a gazillion different devices and I appreciate what you've done with jQuery for web development but frankly, I don't care about jQueryMobile.

Except that it scares the hell out of me the day some client starts asking me to support 5 year old Nokias.

[mixmax]

Jquery mobile is great because they will try to support as many platforms as possible. If you run a real mobile site with a lot of users you have to take small platforms into consideration, just like your website needs to support IE 6 if you have lots of users. It's not fun but it would be bad business not to do it.[1]

If a mobile framework can reach this goal it will make mobile development a heck of a lot easier, and I applaud that.

[1] You need some scale before development for platforms that maybe constitute 3% of your users will be a financially good option.

[patrickaljord]

Youtube and other google apps don't support IE6, not to mention many other big traffic web apps and web sites (including 37signals apps).

[mixmax]

IE6 has around 7% marketshare according to this: http://www.w3schools.com/browsers/browsers_stats.asp

Not supporting it is like telling one in fourteen of your customers you don't want their business. This seems like a bad idea, unless of course you have non-financial motives, such as wanting to kill off IE6 by not supporting it and driving it into oblivion.

[patrickaljord]

Those are general stats, you need to look at your personal stats which might be at 0.5% or 65% and decide from there, not based on these kind of sites. Making your site work on IE will require tons of hour of work and therefor money. It'll also just not work for HTML5 apps, unless you have a second version of your site coded in flash. Make sure it's worth it.

[detst]

Since the first commit of jQTouch on GitHub in June, there doesn't seem to be much going on and every commit has come from one person. So I don't think you have to worry too much about that.

I wanted to like it but there just didn't seem to be much going on over there. Now that it's part of "Sencha Labs", it seems the focus is now over on Sencha Touch.

While, Sencha Touch is definitely interesting, they still don't appear to have announced pricing. Based on how they license and price their other products, I don't think I'm going to like it.

This announcement is awesome and makes me giddy. There really aren't any good options out there for mobile websites. You basically have to roll your own so this is great news.

[Encosia]

jQTouch has a great looking website/demo and was very exciting a year or so ago, but I'll be happy to see a robust alternative. After having used jQTouch to implement iPhone-specific views for a couple sites, I won't use it again.

jQTouch could have preempted the possibility of jQuery Mobile being viable in the first place, but it stagnated instead. The jQuery team can't be blamed for that.

[toddheasley]

I'm guessing that jQTouch maybe never had any ambition to address the need that jQuery Mobile is hoping to address. It was clever, and it was first. Credit where due. But it was always a toy. Modern mobile JavaScript frameworks can't ignore the need for a true touch event model. Thank god John and his team are writing one, because (1) we pretty much know it will be good and (2) I sure as he'll wasn't going to write one.

[voidfiles]

Besides what jresig has already said, it's okay for there to be many answers to the same question. It's just like having two open source rendering engines, at least, Mozilla, and Webkit, that don't cannibalize one another. I don't think two approaches to mobile using jQuery will cannibalize one another.

[raganwald]

I did not say that there shouldn't be multiple answers to the question, however if you're starting a new project today, you don't have a choice between A and B, you have a choice between something here today and something else promised Real Soon Now. Naturally, the one promised Real Soon Now is extremely shiny, it supports every browser, and it hasn't made any compromises to do so.

This kind of situation forces people to sit on their hands, which means that development stalls for a while. I won't go any further because I'm fighting the urge to compare this to things that have happened in other marketplaces, and I greatly respect John's code and design taste.

[detst]

I made the point in another comment but, in the case of jQTouch, I would like to see some evidence of any real development to be stalled. It seems they've transfered focus to Sencha Touch. As for that, it's a commercial product; if anything, this announcement should accelerate their development.

[raganwald]

Ah, I see the misunderstanding. I don't mean that it stalls framework development, I mean it stalls projects. If I'm starting a new project today for a mobile app, do I go with jQTouch today? Or do I wait and see how jQuery Mobile goes?

This happens all the time in the industry. Familiarity breeds contempt, so it's easy to make a list of problems with jQTouch. But whatever is announced but not shipping has no bugs. It has no performance trade-offs. It is effortlessly compatible with mobile devices back to the Radio Telephones of the 1970s. And its programming model is intuitive, flexible, and powerful with no learning curve.

How can you resist waiting? What project is so urgent that you take a chance targeting jQTouch when it will obviously be made extinct by jQUery Mobile? So an announcement has a chilling effect on framework use, that's what I meant.

Alas, no way around it, you can't drum up support for it without perturbing the environment a little.

[detst]

That makes more sense. I was interpreting it as getting others to contribute to those projects.

I buy that argument in theory. The problem I have is that there really isn't anything that comes close to what jQuery Mobile is trying to do. Something like this is desperately needed. Sure, Sencha Touch is trying to do something similar but I don't think it's really in any state at this point to have the effect you describe.

As for jQTouch, if it fits the requirements, I don't see people stalling projects for jQuery Mobile. If it doesn't, you're either hacking it to do what you want or rolling your own. Both will probably take considerable time.

As for me, since nothing else out there really does what I want, I decided to roll my own highly customized framework. I'll keep a close eye on, and perhaps contribute to, jQuery Mobile.

[toddheasley]

Is anybody using jQTouch now (before this announcement)?

[raganwald]

Yes. "Wood & Stones" is a "Goban" for playing Go face to face with a friend on an iPad:

http://github.com/raganwald/wood_and_stones

I'm not even a novice player, so in addition to supporting Classic Go, Wood & Stones supports a number of Go variations that offer some learning benefit.

You can try it on Github Pages:

http://raganwald.github.com/wood_and_stones

It's based on jQuery, jQTouch, iGesture, and JQuery Combinators.