I bought a webOS device and went to Taiwan. This is what I learned.
paulrouget.com
paulrouget.com
If you look at the platforms list on that page, you will see that you can actually use this framework to build a mobile site that looks and works decently on an extremely wide variety of devices.
One of the best things about jQuery Mobile is that it is extensively documented. Just go to the docs and demos and view the source for any page that impresses you. You will instantly be able to see the markup that you need to duplicate that pages functionality.
(Tip: Before viewing the source, make sure that you remove everything to the left of the # in the url, including the # itself. Just check out the docs, you'll know what I am referring to.)
Using a good mobile framework, it is trivial to provide a mobile version of sites that already exist on the Internet, so why not do it and gain access to a an additional audience?
That and it makes everything look like an iPhone app and there are enough people out there who dislikes that particular sense of aesthetics.
I honestly don't see jQuery mobile having the same "thing" as plain jQuery had which made it successfull: It stayed out of your way and just worked, without making any assumptions about what you liked and what you wanted beyond that.
Any word on how well knockoutjs or other options is working on mobile?
Jquery mobile is following the groundwork laid by Jquery-UI, not Jquery-Plain.
As another commenter pointed out JQuery Mobile (JQM) is following on from JQuery UI, not from straight JQuery. Knockout.js is a databinding and templating system. As such JQM and knockout.js are complementary instead of competing. Our system used knockout for databinding into the JQM UI.
My recommendation coming out of the R&D project was to use knockout for production apps and to continue to watch JQM, but not use it for production just yet. JQM is still evolving rapidly - there were a number of major changes made during our R&D project. We also ran across a number of issues making JQM work with knockout. For example JQM didn't like knockout changing some of the HTML dynamically, after JQM had been initialised. The JQM team are aware of the problems dealing with changing HTML via javascript and we saw a number of fixes committed during the course of our R&D project. One day soon JQM will be very good, but its not quite there yet.
Furthermore not every mobile application will benefit from JQM. Unless you are building an essentially forms and data driven application, it may not be very useful. Depending on your needs you will be able to get very far by using knockout to produce clean semantic markup, then just applying CSS over the top.
By the way, I have just looked at jquerymobile.com from an iPhone 4 and the UX is unresponsive, showing the checkerboard pattern, flickering and so on. Not something that I'd want more web developers to be aware of. I would want more developers to be aware of web standards and good design, not JavaScript hacks.
For now, it is understandable that you will see some imitation of successful "app" design patterns, but things can change quite easily. If it turns out that the iOS look is not good for the mobile web experience then things will change.
"By the way, I have just looked at jquerymobile.com from an iPhone 4 and the UX is unresponsive, showing the checkerboard pattern, flickering and so on."
The project is still in beta, and there are still some rough edges. It's an open source project, so the developers and users would greatly appreciate it if you could file a bug report about this issue:
https://github.com/jquery/jquery-mobile/issues
I did a quick check and I didn't see that your issue has already been reported, so your contribution would be doubly helpful.
"I would want more developers to be aware of web standards and good design, not JavaScript hacks."
I understand your perspective (all developers should definitely know web standards and good design), but, surely, you would agree that there is value in trying to do something a little different? Today's javascript hack may well turn out to be tomorrow's revolution.
I've seen the same sluggishness in jQuery Mobile apps I've tried building on the iPhone4, Palm Pre and a couple of Android devices. It's too bad really.
I think my top useage on the iPad is: 1) RSS reading (native app syncing with Google reader) 2) A browser (a tabbed-one) 3) GPS apps (Coyote / Navigon) 4) Instant messaging 5) Games (Death rally, Monopoly, Infinity blade, Minigore, Cut the rope, ...) 6) Mail 7) Movies (Youtube, Plex, TED, ...)
So the top 2 is actually web-browsing. The RSS reading is mostly looking at a Webkit-view anyway... I typically use a tablet when I'm relaxed and have the time.
On the phone however, this is completely different, although I mostly have both at hand. I use my phone in much shorter bursts, on the road. The phone is more an "I need to know something now" device, as quick as possible. Web-only simply can't beat that, small native apps are a lot quicker to start, offer a better interface for such a small display, well-optimized web-apps for smaller displays are not that easy to find. My top-apps are mostly phone and communication-related things like calling, texting, calendar, reading mail and facebook. Then stuff like google maps, and apps specialized in searching specific things or quickly looking up something, like weather, restaurants in the direct surroundings, ... And games :p
I do think the web is important, most apps use web-api's anyway, but one of the points of apps that is overlooked a lot - is that the online market makes it easy to browse for specific applications, native only. If there was something like the appstore for online native applications built-in in the os, where I could search for them, see popularity and ratings, I would probably use a lot more, certainly if they would have the quality of the full HTML5 financial times app, which is simply amazing.
Great post - while web apps are 'behind' native right now, it'll only take a few more APIs to make webapps the natural choice. And, developers to start working with them of course (local storage, geo, viewport, etc).
Although I agree with your point on the different layers, and different technologies, its worth considering the reach of a web-app, and the theoretical develop once, deploy on the most important platforms (iOS, android etc).
> theoretical develop once, deploy on the most important platforms
After all those years that's something I won't buy :) Today's html documents are still filled with "ifdefs" for different MS browsers and special css selectors for every major html rendering engine.
Testing a webapp for compatibility with common browser/os combinations must be hell.
But there are other reasons why I tend to avoid webdev:
There are considerations like security. If I deploy a desktop app and one user gets hacked because I messed up then this one user got hacked. Depending on the bug hacking more users tends to be non trivial.
If on the other hand I have a glitch in my web app suddenly all my customers' data is in danger because all the juicy targets sit in one place waiting to be mass-hacked by a script.
I hope that webapp shops hire a full time security guy for their apps but ... who am I kidding ... most of the apps probably run on unsecured boxes and have a dozen of (forgotten) developer backdoors in them.
Security is just a huge and complex issue I wouldn't want to deal with. (And couldn't to be honest.)
Yes, of course they're real closures.
Of course, nowadays you can do the same by using javascript both server and client side...
I didn't find this persuasive enough to use GWT myself, mind you. :-) But it does seem like a valid reason someone might want to use it.
Think of the "AJAX boom" of around 2005. XmlHttpRequest had been around since late 90s, but only then mainstream developers understood the potential for building more responsive web applications.
For example even putting together a basic UI for a simple todo list is a challenge for me to do in HTML. I need to know HTML, CSS, positioning, differences between mobile browsers, platform-specific css tricks, etc. It is really not so simple.
On iOS I just drag and drop stuff in Interface Builder and connect outlets and actions. Done.
The other thing is standardized frameworks. Everybody hates frameworks but on iOS (and Android) they implement all the hard stuff. Want to show a list with a million items? There is a framework that deals with that. Just fill in the blanks (create table view rows, lookup data) and you are done.
In the HTML world not so much. It is all way too low level. Developers either have to start from scratch or use something like jQuery. But all those frameworks are young and inherit the basic problems of the web platform.
jQuery Mobile is a good start, but some things really need to become part of a W3C standard and implemented natively for performance in my opionion.
> The Twitter Apps suck.
Harsh. I use Carbon for webOS and I find it excellent: http://carbonwebos.com/
Phnx is also great: https://developer.palm.com/appredirect/?packageid=com.davids...
Tons of big companies like Amazon and Financial Tomes are are using it to build awesome mobile sites.
JS will be the language of choice where we can create apps that run on mobiles, web, and even TV.
As long as the browser can't access certain aspects of the phone such as contacts and gps we will still have apps - but I def think we'll use mobile web more than apps in the long run.
http://gs.statcounter.com/#mobile_browser-TW-monthly-201008-...
Is it because the user agent is often faked? (Is it on by default?) Or is it that many people use Opera, but they only use it once a month each?
From watching locals use the iPad/iPhone, there is nothing wrong with Mobile Safari for Chinese either. It's just that many websites use Flash mouseover crap for navigation, or WMV movies or even ActiveX. But Opera wouldn't help there.
The poster is basically saying that a browser is the best way to view the TripAdvisor, HN and reddit websites while calling those websites apps.
For how long will HP push out updates (including new browser versions that keep up with new standards)?
Apps and the little icons on the phone's main page are like bookmarks to a website. If adding bookmarks to your phone were as OBVIOUS as adding an app, mobile apps would take off more.
Also, the phone vendors want to push their own middleman-marketplace to make money.
WebIntents solve his "register as content handler" bit.