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?
When mobile web developers see what's possible with native apps and how successful they are, what do they do? They try to clone them in typical "webapp-uber-alles" fashion, instead of building quality mobile websites.
And that's why I have to look at dumbed down iOS-clone UIs while trying to browse a website from my phone.
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.
The techniques in mobile web development are still young. A general knowledge of how to build a site for mobile interfaces has not come around yet.
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:
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 spent some time with jQuery mobile and the performance is just too poor for it to be usable. What's crazy is that regular jquerymobile.com is more responsive than the 'Docs and Demos' section that is built using jQuery mobile on my phone (Nexus S).
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.
In it's current state of affairs jQuery mobile is too slow to be a universal solution for mobile.
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?
> 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.
Jquery mobile is following the groundwork laid by Jquery-UI, not Jquery-Plain.
I have just completed an R&D project for my company on using JQuery Mobile, with knockout.js, so perhaps I am qualified to answer this.
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.
I never had app reflex and find the overall experience slower in most cases. For reading hn/reddit/aggregators in general on Android, opening new things in tabbed browser from links and bookmarks is a magnitude faster (I use Dolphin browser and allows the option to load in background), and the browser automatically formats text with a simple double click. Its very rare when this doesn't work. Opening an app, moving back and forth from content, and then trying to find and use several of the same native apps to me is slower. On tablet I really don't need apps at all unless like WebOs they cripple the browser.
Most sites do email notifications correctly and prefer this so I can deal with it on my own terms rather than the constant push of notifications.
I have an iPhone and iPad, and sure - I do use a lot of native applications - but the browser certainly is one of my most-used apps on the tablet.
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.
tl;dr: "As long as you have a good browser, your device won't become a brick."
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).
Not just raw APIs. What I miss the most are tools and frameworks.
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.
I think it isn't so much about the technology lagging behind, but more about understanding on how to best use the web technologies on mobile, and probably libraries packaging this understanding into easy to use format.
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 me to develop anything webapp related the following must happen: The development environment has to become a lot better. I don't want to write my application in 3 different languages on 3 different layers using 3 different technologies. And I certainly don't want to write anything in JavaScript.
Can I ask why you don't want to write anything in javascript, used in the right way, it is a very powerful and expressive language, plus with technologies like coffeescript, you can write Javascript (the good parts) in a clean and neat format.
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).
Hmm, I just don't like JS. It feels to me rather fragile. Alone == and === let ring my alarm bells. And the most examples you can find on the web for JavaScript are just a messy hell. Abuse of closures (are those real closures in JS anyway?) leads to spaghetti code. And most of the major frameworks tend to support this "paradigm".
> 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.)
Security cuts the other way, as well. If you put out a bad desktop release with a major security flaw, you'd better have a good way of force-upgrading everyone or you'll have some percentage of users running the insecure version forever.
I suppose you could use GWT to compile Java to JavaScript. To me GWT is still the weirdest open source project ever: why would you go to these lengths to be able to write in an ugly language (Java) that compiles to a pretty language (JavaScript). But to each their own - I know people who use GWT in production.
I use both Javascript/JQuery and GWT, depending on the task. I'd use GWT when I want more predictability - when an app is complex enough that I'd like to be able to move bugs to compile time instead of run time (unit test or otherwise). With GWT you don't look for a bug in Chrome's Javascript console, say. A new browser comes out with weird specifics? Great. Switch on the flag for that browser and recompile, and that browser gets a unique snowflake version that works perfectly. Over time, GWT will improve the JS it compiles to, even given the same source code. It gets faster independent of the browser improvements.
I tend to agree with you - I greatly prefer JavaScript to Java myself. But I did hear one argument for GWT that I found persuasive - that they are able to do optimizations in the generated JavaScript code that we probably wouldn't - or couldn't - do in more idiomatic JavaScript.
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.
There are some interesting projects out there for you. One of them is NS Basic/App Studio, which provide a VB like environment, then generates the JavaScript, HTML and CSS. (You can also program in JavaScript.) I agree - dev environments have to become more user friendly to be really good.
(disclosure - I'm one of the guys having fun working on the NSB project)
I'd still much rather use Twitter for iPhone than I would mobile.twitter.com. It's not only a matter of lack of integration with the system as the author pointed out, but responsiveness as well. It may not be as obvious on platforms like webOS that are generally less responsive than other platforms like iPhone (in my experience), but I personally can't imagine using Facebook's sluggish web app when I could use the Facebook app that reacts instantly when I tap a button. Am I alone?
I found in the twitter app for some reason I can only go back so far in history. It appears to be a possibly only 100 messages, maybe more. The web client doesn't seem to have this limitation. Again this maybe an IOS issue because a lack of a tabbed browser like Dolphin on Android, but with the twitter apps the usage is, you click on a message and the screen slides or you open the link. Wait for link to load, and then press back each time to go back to your main feed. This is a a very tedious process. With proper tabbed browsing and background loading, the web client will feel slightly faster. I go through my feed open several links in different tabs, let them load while I continue down my feed. At some point, Ill go through the tabs I opened, read, close tab and repeat. Basically I avoid the time of sliding animation and page loading times, but I mainly use twitter similar to a rss feed.
While I completely agree with your point, I have to mention Facebook app is not the best example. It's slow/sluggish and buggy every now and then. I still prefer it to the one on the TouchPad but wish it was more reliable.
Halfway through the first paragraph I thought "This guy doesn't get how webOS is supposed to work." I was glad to hear he figured it out by the end. Bookmarks to web versions of apps are an integral part of webOS design. It's not a workaround, it's a feature.
Sounds like a hyper version of what's here in Kenya(and africa). More mobile, Opera mini everywhere, native apps preference, a little bit of Android, far much less Apple,. Even Nokia's running a S40 app contest for its Ovi Store(50K Euro top-prize).
In my opinion, native apps are most useful when one is using celluar data networks, as then you are transferring data and not things like interface elements. I've also heard the iOS Safari has issues with very limited caching.
I had the first palm pre and to this day still think it's the most intuitive mobile OS. Over the past year HTML5 has become pretty legit.
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.
Someone lended me a tablet for a week. I didn't install a single application.... everything I needed was on the browser (Twitter / Facebook / Mail / Searching on Google)
I can't find any evidence that any version of Opera actually runs on WebOS. Their forums are full of people assuring each other that there is no such thing. Unless I'm being thick and one of these download options is a synonym for "WebOS", I have no idea how to find it. http://www.opera.com/mobile/download/versions/
OP never said he used Opera on his WebOS device: he said that WebOS's standard browser is very good and that mobile Opera (as well as mobile browsers in general) is big in Taiwan.
A claim for which I would love to see data, anyway. I am in southern Taiwan, but usually see IE on the desktop and iOS/Android default browsers on cellphones. (Or just the respective Facebook app.) Not sure if this site is super legit, but it seems to second my impression:
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.
When iPad first shipped with iOS 3.2, there was no support for traditional Chinese input. So anyone wanting to log in with a Chinese name, or type some Chinese into a form, would have been out of luck on an iPad unless they had some kind of add-on solution. Just a guess, but maybe Opera came with some kind of built-in Chinese input that compensated for this shortcoming?
But Opera Mini for the iPad came out even later than iOS 4.2 (if I did my googling correctly).
So I hope that wasn't the reason, people entering TC characters on a low-resolution device in a scaled-up iPhone Opera Mini is a terrible image :)
Regarding the poor RSS readers on WebOS, I encountered this problem but found a good free one that supports Google feeds at https://github.com/deliciousmorsel/Feeds
I find Feeder on webOS excellent, better than any of the readers I have tried on Android. Likewise for the twitter client, Carbon, which is much better than Twitter's official client on Android.
Good read! I think Apple is responsible for all this "App reflex" we are experiencing. They capitalized on this and it undoubtedly made them more successful. Without this 'reflex' we would be using more non-Apple devices.
From what I've heard, they are canning the WebOS hardware, but will still be developing the operating system. In fact they are having developer events for WebOS in a few locations this month I believe.
The problem: The browser on a mobile phone is an app, not the platform.
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.
I think we can forgive the author for not mentioning his day job at the top of every post. Check out his front page. He's not exactly shy about where he works - http://paulrouget.com/
http://jquerymobile.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?