PhoneGap certainly speeds mobile development along, and hopefully jQuery Mobile will support Android too, but until then I will stick with PhoneGap+jQuery vanilla.
Learning Obj-C is looking more and more like a poor investment of time. If my repurposed web skills are good enough to build 80% of the apps people want why would I start from scratch with a completely new and native stack?
I've been saying it for some time (I'm not the only one), but JavaScript is the language every developer should be learning. Not the only language, but it's a language you want under your belt. And it's only getting better. How times change. =)
I wouldn't say better. I'd say those that thing something else is better are missing out on key elements that made "worse" superior. Basically, the "worse" option is worse in areas that don't matter, and the "better" options are better in areas that don't matter.
I'd be more inclined to question those baffled how something is "worse is better." Did they really understand the technological needs?
I would never use this app. Even just from the screenshots I see that it cannot manage to follow even the most basic of iOS UI principles. Most users might not notice so specifically, but they will notice how unnative it is -- and more than likely dislike that.
> If my repurposed web skills are good enough to build 80% of the apps people want why would I start from scratch with a completely new and native stack?
Supply and demand.
Doing the easy and/or thing everyone else is doing means there is ton of supply, will the demand support it? Will the demand still be there when it's commoditized and outsourced / offshored.
Doing the hard and/or thing few other people doing means there is limited supply, will the demand be enough to support decent ROI?
That is why learning ObjC / proper mobile development might be worth it. Not saying it is, you'd have to evaluate supply and demand to figure out.
This cuts both ways though. Even today there are a lot more openings for JS people than Obj-C or Android. Either or both of the latter might be confined to a niche in five years but "HTML5" is clearly here to stay.
I've been working with jQuery Mobile for a week now and it's pretty cool just how quick you can get an app up and running...and most importantly looking great. Granted that's mostly to do with their CSS files. However, I really like how they designed their page navigations - in effect, the app acts as a browser within the browser and animates transitions between pages, auto-generates back buttons, lets you put footers with persistent buttons, all that stuff you've grown used to on phone apps.
As people have pointed out here, you can probably create 80% of the apps that your client would request with it and other HTML5 tools, rather than writing native code. Added bonus, it will run on iOS, Android, WebOS, and likely in the future Windows Phone 7.
I've also been using jq-mobile, and for the most part I like it, though you can still tell it's an immature project. Most recently I found that I was unable to pass url parameters to a page, which is a pretty big deal for a web app. I'm sure this will be fixed in the future, but it's the kind of things early adapters will have to deal with.
"Granted that's mostly to do with their CSS files."
I think that will be the #1 contributor to jQuery Mobile's inevitable success. It is just so easy to get working prototypes without having to mess with CSS or anything. Everything is taken care of for you, in a very convention-over-configuration way.
I recently built a mobile version of a HUGE web app in 2 days using jQuery mobile. Compared to the earlier mobile prototypes using jQTouch and Sencha Touch that took a month+.
> there is only one HTML page even though the app looks like it has dozens of screens!!
Ugh. Really, you guys think this is the future? It's a total perversion of what a URL and a webpage are supposed to be. It's ugly hacks on top of more ugly hacks to produce a substandard experience.
An app like this is not hard to produce with Xcode and Obj-C, and it will look feel and work 10x better. It will only get easier as development tools improve, and Xcode and Interface Builder have a ways to go to catch up with Visual Studio.
There is a place for web apps and a place for real apps. For many years now countless companies have been investing in shoehorning an app into a webpage, and they don't have much to show for it except buggy javascript and unreliable software. Not even semi-professionals would consider using Google Docs over client-based Word for serious document composition. Or substituting Photoshop with one of the dozens of webapp photo editing tools. It's all cute, but in the end its not practical for real world use.
It's unfortunate that so many talented programmers are sucked into this "webapp everything" mindset and devote themselves to crappy products, sometimes simply because they have a personal hangup with Microsoft or Apple. Obviously there are plenty of skilled coders who are making client-based software that's beautiful, useful, and profitable, but client software is still dominated by crap, even on super popular platforms like iOS and especially Android. There are enormous opportunities on the client that have been ignored for a decade.
Think about this, today for less than $200 you can have a more powerful computer (more RAM, more storage, more MHz) in your pocket than you could buy for $1000 in 2000. And today's has a phone, a camera, broadband internet, GPS all built in. Not only that, but that same computer is making its way into your TV and car. And what is being done with all that power? Still hacking choppy javascript animations on a document markup language!
> There is a place for web apps and a place for real apps.
And shoehorning web apps into real apps is bad. While I don't suggest every app should be made into a web app, I also think a lot of "real" apps make no sense outside of being a web app.
> Still hacking choppy javascript animations on a document markup language!
And yet, these "fake" apps are the most popular apps in the world, preferred by geeks, professionals, and non-technical people alike.
I don't see native apps going away, I just less natives apps merely doing something that can already be accomplished online, and usually better.
> And yet, these "fake" apps are the most popular apps in the world
I would dispute that, in every case where there is exists a native app with equal functionality, the app is used every time. Customers prefer the native apps. Yes, we all know the dev costs are high right now, but that will change just like it did for web development.
Also significant, there is finally again opportunities for developers to be paid for their work by real customers. The quality of native apps plus the AppStore model is resulting in end customers seeing value in software again.
The only reason so many web apps are popular now is because it's the only choice available to consumers. Tech companies have been distracted the last 10 years chasing the perpetual myth of write-once run-everywhere, this time instead of Java or Flash or XML (for data), it is HTML5+javscript. I guess we haven't learned yet.
There is a return to client coding happening, and it's going to produce a new renaissance in really great software.
> I would dispute that, in every case where there is exists a native app with equal functionality, the app is used every time.
Not true at all.
And, misses the point: so-called "fake" apps are the most popular over their "real" counter parts. Not in all areas, sure. But in many. It depends on the domain.
To assume that native is always better is dismissing the massive value provided by web-based.
> To assume that native is always better is dismissing the massive value provided by web-based.
Massive value to whom?
We all know the value to the developer. I'm not disputing the current cost savings of webapps, though it will quickly become irrelevant as native app dev/distribution costs plummet.
But is there any value to the customer? There used to be a lot more. Sure was convenient to be able to log in to your email from any computer. That was until you started to read all your email on your phone that you carry with you all the time.
The web interface isn't going to disappear, but it will become the secondary way to interact with apps. Right now it is still the primary for many apps like Facebook and Flickr. That is changing.
> That was until you started to read all your email on your phone that you carry with you all the time.
What does that have to do with web apps and native apps? Maybe your assuming that these web apps being discussed are merely that: on the web. The real fact is, you can load these apps locally, and use them without an internet connection, with local storage.
> Right now it is still the primary for many apps like Facebook and Flickr. That is changing.
You assume this is because native apps are better. This is not true. All your mobile apps aren't native because it's better to be native. They are native because they can get into the app store to be sold. And how do you get into the app store? Well, I guess you gotta learn Objective-C. And even then, the quality of the apps is questionable compared to the mobile versions.
There are also some heavy downsides in Xcode/Obj-C development, such as hunting down memory leaks and crashes, and having a relatively slow upgrade path for new versions, without a guarantee that everybody will upgrade.
I agree that there are cases for both approaches (native and web app), but it's also pretty amazing what you can do with HTML5/CSS3 if you know how to utilize e.g. iOS hardware acceleration properly.
In fact the whole iOS web stack with offline support, local storage, startup images and icons etc. is getting so complete, you can't even notice whether you're using a native or a well crafted HTML app.
> you can't even notice whether you're using a native or a well crafted HTML app.
That's completely untrue. It is immediately noticeable because of the lack of responsiveness, smoothness of transitions, and ugly layouts. Like I said, you can put together a bunch of hacks to try and imitate it, but you end up with something clunky and unprofessional. This wasn't as big a deal 10 years ago, but interface expectations on these devices (especially the tablets) are very high. Quality design is expected by a lot more customers in the hardware AND software. Interfacing with touch gestures needs to be instant and seamless.
Did you even look at the "Ali Quotes" app in the story? It's terrible. I've poked around the jQueryMobile already on my iPhone, the whole thing is, in a word, slow. Yes, I know it's new. It will be better in six months... after thousands of coding hours will be spent concocting ludicrous javascript and CSS hacks to duplicate something that's been done perfectly well on native client platforms for 3 years. It's a terrible waste of effort.
> There are also some heavy downsides in Xcode/Obj-C development, such as hunting down memory leaks and crashes
True, these are problems that have existed forever, and better dev tools help alleviate them. But don't forget these same problems are prevalent all over web apps too. Flash memory leaks are everywhere. Javascript suddenly consumes 100% of your CPU. Same problems, but no one care about fixing them because its just a webpage, just reload it. Well OK, but that's why even after 10 years people don't trust webapps.
you can't even notice whether you're using a native or a well crafted HTML app.
While HTML apps are nice and very good for quick-and-dirty prototyping, I think you are sadly mistaken if you think that no one notices the difference. It would take just a couple of seconds of playing around with certain UI widgets to know if you were running on an HTML app if you knew what to look for. Even a short period of use people who do not know the tell-tale signs tend to get a feeling that there is something "wrong" with the app.
"For many years now countless companies have been investing in shoehorning an app into a webpage, and they don't have much to show for it except buggy javascript and unreliable software."
Examples?
"Not even semi-professionals would consider using Google Docs over client-based Word for serious document composition."
Big ones: the whole Google suite. Gmail is clearly the most reliable, but strange things still happen in gmail, like chat dropping, task lists locking up, or crashes. I love gmail, use it all the time, has great features. But I'd love a native client for Gmail even more.
Flickr. Great content and community, but the web interface is clearly clunky. Imagine Flickr on a tablet. Swiping, pinching, tapping. If you had the choice, you'd use the app, not the webpage.
Facebook. Insanely popular, insanely buggy. Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive.
Just using those 3 examples, you will see great client front-ends created for those in the next few years. Though maybe not Google if they don't get their head out of the sand. Soon Facebook will do a great tablet client, and it will be a KILLER app.
So what type of professional document creation are you doing in Google Docs?
It seems to me that some of the issues you mention with web apps would also be apparent with native apps acting as a front-end to online apps. Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that.
Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I don't doubt for a minute that the experience would be better for each platform as a native app, but would it be profitable for small/medium size business? I feel like SMBs are the target of web-based mobile frameworks, for the most part. I don't think we'll see Facebook in JQuery Mobile any time soon.
> Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that.
Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform.
> I feel like SMBs are the target of web-based mobile frameworks
Sure, that's possible. But there are also people creating native frameworks to put SMBs into apps. Magazines are a good example. The big publishers are making their own apps, but they're are also working on frameworks to deliver other magazines. Then there are non-publishers like Zinio that are making the platform for any magazine to be published.
> Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P?
I'm not arguing that everyone who wants a blog needs to write their own blog software. No, obviously they can use something like Wordpress, and let WP worry about the programming and compatibility, and they can concentrate on content. Same goes for apps. I'm simply saying that native apps always were superior to webapps. People forgot because it became so easy and cheap to churn out functional web code. AND because these mobile client devices were closed off for development for so long. Love him or hate him, Jobs opened up everything with the iPhone SDK.
I think the expectation of a company to have a native app today is equivalent to the expectation that they would have a website in 1997. Back then it was a very expensive proposition. Today EVERYONE has a website. Tomorrow everyone will have an app. Doesn't mean they have to hire their own software team to build it from scratch.
> Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform.
I think you fail to realize this can be accomplished using the tools in the article. They have access to things like this, including cameras and what not.
You keep saying things that make no sense in context.
You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do. Why continue to struggle with a flawed platform?
> You keep saying things that make no sense in context.
In what context is that?
I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong?
Can you hack together a way to do all this in JS? Maybe, but it's unreliable, and it's years away from being comparable. Sure, you can wait 2 years until it's figured out, by then it will be outdated again anyway.
I think you're very comfortable writing your web apps, it's something you understand and you're good at it, and naturally you're resisting change. But the industry is not going to stop changing because you're good at CSS hacks to make rounded corners on div blocks and you just wish we'd keep doing it that way because it's easy for you.
> I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong?
Your not. However, I haven't argued against this.
> You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do.
Well, good thing they aren't using HTML then.
> In what context is that?
In the context of the article. PhoneGap let's you create native software but using technology like HTML and JS that hooks into Apple's (and others) existing API.
More importantly, Apple uses XML for it's UI as well, so the difference between HTML and Apple's own XML format for it's UI is negligible.
> and naturally you're resisting change.
The industry is changing from desktop TO web-based. Your cherished MS, Apple, and Google agree with this as well, as you can see by their plans to not only support, but promote these types of applications.
And, in this case, I can either follow the lead of Apple, MS, Google, and Mozilla, or take the advice of some nobody random commenter with a stick up his ass.
Maybe you can explain how these companies are wrong?
The entire 1.5hr interview is worth watching, but starting at the 4:30 mark and watch it for about 20 minutes (you'll have to find parts 5 6 and 7 in youtube). This was in May 2007. The first iPhone was announced in Jan 2007, and wasn't even for sale yet until June. And it wasn't until June that Jobs announced that the iPhone would be releasing an SDK for 3rd party apps.
Listen to what BOTH of them say about rich client experiences. Keep in mind that Apple was already working on the tablet at this point, earlier in the video the lady asks Steve about any new risky paradigm shifting devices and Steve says "I can't talk about it". Now we know it was obviously the iPad. Then and now, the two biggest software/technology companies in the world don't even see it being realistic to run apps in the browser, at least apps of any quality that people would want. They BOTH see enormous opportunities in rich clients and new human interfaces. Jobs spells it out: rich clients with internet services in the background. This is before the iPhone SDK was announced!
These guys are thinking about touch, voice, camera, kinect, and they see NO WAY it can happen in a browser. They've spent millions in R&D, and they see rich clients. You see a free JS library and think the rich client is dead! Laughable.
Gates and Jobs are crystal clear what THEIR view is, and they've been executing it through the products they're releasing. So I don't know where you get the idea that their objective is to promote webapps. Try listening to other people sometime, you might learn something from a random nobody commenter.
> Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks.
> But I'd love a native client for Gmail even more.
Email clients have been out for a long time.
> Imagine Flickr on a tablet. Swiping, pinching, tapping.
All of which can be accomplished without going native. These are accessible by normal web pages using JavaScript.
> Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive.
Facebook has native apps already, and they aren't any better. You can't find new messages, notifications not appearing properly are some of the problems I face. And you don't have to wait 30 minutes to have these problems. They appear before opening the app!
On the desktop, yes. Why? Because all the innovation in organizing, displaying, and managing email was focuses on webmail. Not because it was a better platform, but because it was incredibly easy to deploy and cheaper to develop.
Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Used to be the same on the desktop when being online meant you were tying up a phone line at a per minute cost. Your desktop is always online now, so it's not an issue.
But I still believe we will see a return to native email clients because of the integration possible with other client software and services. We already see it on tablets and phones.
> Where is the email client back? On the phone. People want access to their email if they don't have an internet connection.
Can still be accomplished without being native.
Listen, it's clear we aren't going to agree. But the simple fact is, unless things change, going the JS and HTML route for apps is best for the vast majority of applications people use on a daily basis. This is demonstrated by the fact that they are using these apps on a daily basis.
> This is demonstrated by the fact that they are using these apps on a daily basis
That's not true. People are using apps on their phones, not webapps. They're using apps on their TVs and tablets, not webapps. And people are actually paying for native apps, something no one is doing for webapps.
Seriously, you don't see any parallels between now and the late 90s? You don't think it's going to get drastically cheaper to produce native apps in the next couple years? The same thing happened in web development, a combination of better dev tools, more code libraries/frameworks, and more labor supply will drive costs down.
The big issue for the IPhone at least is the app store approval process. That alone imposes enough risk that HTML/CSS/JS may be better. And it's easier to maintain than an Objective C port.
> It's a total perversion of what a URL and a webpage are supposed to be.
No it's not, it's simple HTML with JavaScript attached. Most of it probably works even if you disable JS.
> It's ugly hacks on top of more ugly hacks to produce a substandard experience.
Some examples please! Otherwise I have to assume you have just made it up.
> An app like this is not hard to produce with Xcode and Obj-C
"not hard" for who? It doesn't even have garbage collection, it's basically C with OO capabilities.
> There is a place for web apps and a place for real apps.
You probably meant to say "native" apps, and you didn't even bother to back this up.
> they don't have much to show
Except for: Youtube, Facebook, Flickr and probably hundreds more.
> buggy javascript and unreliable software
How is the JavaScript buggy? are you assuming that no one can code properly in JavaScript? Are you saying that every software written in JavaScript is unreliable? All this without even giving a reason?
> Or substituting Photoshop with one of the dozens of webapp photo editing tools. It's all cute, but in the end its not practical for real world use.
You give one example, but ignore all counter examples.
> It's all cute, but in the end its not practical for real world use.
Then why are people using it? Why are developers developing for it?
> It's unfortunate that so many talented programmers are sucked into this "webapp everything" mindset and devote themselves to crappy products, sometimes simply because they have a personal hangup with Microsoft or Apple.
Are you assuming products are crappy just because they are webapps? Are you saying that people chose web just because they hate a company?
I'm getting tired of all this "imagine what you could do" hype.
Can you really build a well designed, polished app that people want with these tools? Well, so do it, release the app, make a lot of money and show us how you did it and why it's better than building a native app. As of now I never saw all this promises fulfilled, especially on the iPhone.
What sets jQuery Mobile apart from the others (jqtouch, etc.) is that it seriously adopts the things that make HTML5 unique as opposed to just Javascript+DOM/CSS/DHTML/etc. For being an "alpha" product, it's quite complete and relatively bug-free (again, for an alpha product).
If you have cross-platform aspirations it's hard to argue against the value proposition of going the web app route (and coupling it with something like PhoneGap if you need App Store distribution, etc.).
Certainly there are some apps that can't be done this way due to hardware support or other device features that are not accessible via a web app but for the vast majority of the apps being commissioned today this is not the case, and being able to launch on multiple platforms with almost zero additional effort is hard to argue with from a cost perspective.
Of course being able to leverage existing knowledge and experience in the HTML realm is another bonus.
I have to say also that with the diversity of platforms now available, the "it doesn't feel native" argument is loosing some steam, since what feels native is different on each platform.
Give it two years for the hardware to catch up, plus some blessing from Apple (instead of the hacky stringByEvaluatingJavaScriptFromString way of talking to Javascript), plus a open-source Javascript framework, then we are talking.
What does Native really mean in this context? It launches from Dashboard or is it that it's purchasable from the App Store? Being able to save sites to springboard has been possible for years.
This isn't using native controls, just HTML and CSS to make it look native. Javascript is a great languages however HTML + CSS were not designed for this purpose, try creating a complex UI in this and watch performance start dropping quickly.
45 comments
[ 3.1 ms ] story [ 102 ms ] threadI'd be more inclined to question those baffled how something is "worse is better." Did they really understand the technological needs?
Supply and demand.
Doing the easy and/or thing everyone else is doing means there is ton of supply, will the demand support it? Will the demand still be there when it's commoditized and outsourced / offshored.
Doing the hard and/or thing few other people doing means there is limited supply, will the demand be enough to support decent ROI?
That is why learning ObjC / proper mobile development might be worth it. Not saying it is, you'd have to evaluate supply and demand to figure out.
As people have pointed out here, you can probably create 80% of the apps that your client would request with it and other HTML5 tools, rather than writing native code. Added bonus, it will run on iOS, Android, WebOS, and likely in the future Windows Phone 7.
I think that will be the #1 contributor to jQuery Mobile's inevitable success. It is just so easy to get working prototypes without having to mess with CSS or anything. Everything is taken care of for you, in a very convention-over-configuration way.
I recently built a mobile version of a HUGE web app in 2 days using jQuery mobile. Compared to the earlier mobile prototypes using jQTouch and Sencha Touch that took a month+.
Ugh. Really, you guys think this is the future? It's a total perversion of what a URL and a webpage are supposed to be. It's ugly hacks on top of more ugly hacks to produce a substandard experience.
An app like this is not hard to produce with Xcode and Obj-C, and it will look feel and work 10x better. It will only get easier as development tools improve, and Xcode and Interface Builder have a ways to go to catch up with Visual Studio.
There is a place for web apps and a place for real apps. For many years now countless companies have been investing in shoehorning an app into a webpage, and they don't have much to show for it except buggy javascript and unreliable software. Not even semi-professionals would consider using Google Docs over client-based Word for serious document composition. Or substituting Photoshop with one of the dozens of webapp photo editing tools. It's all cute, but in the end its not practical for real world use.
It's unfortunate that so many talented programmers are sucked into this "webapp everything" mindset and devote themselves to crappy products, sometimes simply because they have a personal hangup with Microsoft or Apple. Obviously there are plenty of skilled coders who are making client-based software that's beautiful, useful, and profitable, but client software is still dominated by crap, even on super popular platforms like iOS and especially Android. There are enormous opportunities on the client that have been ignored for a decade.
Think about this, today for less than $200 you can have a more powerful computer (more RAM, more storage, more MHz) in your pocket than you could buy for $1000 in 2000. And today's has a phone, a camera, broadband internet, GPS all built in. Not only that, but that same computer is making its way into your TV and car. And what is being done with all that power? Still hacking choppy javascript animations on a document markup language!
Yes. So do you, apparently. Here...
> There is a place for web apps and a place for real apps.
And shoehorning web apps into real apps is bad. While I don't suggest every app should be made into a web app, I also think a lot of "real" apps make no sense outside of being a web app.
> Still hacking choppy javascript animations on a document markup language!
And yet, these "fake" apps are the most popular apps in the world, preferred by geeks, professionals, and non-technical people alike.
I don't see native apps going away, I just less natives apps merely doing something that can already be accomplished online, and usually better.
I would dispute that, in every case where there is exists a native app with equal functionality, the app is used every time. Customers prefer the native apps. Yes, we all know the dev costs are high right now, but that will change just like it did for web development.
Also significant, there is finally again opportunities for developers to be paid for their work by real customers. The quality of native apps plus the AppStore model is resulting in end customers seeing value in software again.
The only reason so many web apps are popular now is because it's the only choice available to consumers. Tech companies have been distracted the last 10 years chasing the perpetual myth of write-once run-everywhere, this time instead of Java or Flash or XML (for data), it is HTML5+javscript. I guess we haven't learned yet.
There is a return to client coding happening, and it's going to produce a new renaissance in really great software.
Not true at all.
And, misses the point: so-called "fake" apps are the most popular over their "real" counter parts. Not in all areas, sure. But in many. It depends on the domain.
To assume that native is always better is dismissing the massive value provided by web-based.
Massive value to whom?
We all know the value to the developer. I'm not disputing the current cost savings of webapps, though it will quickly become irrelevant as native app dev/distribution costs plummet.
But is there any value to the customer? There used to be a lot more. Sure was convenient to be able to log in to your email from any computer. That was until you started to read all your email on your phone that you carry with you all the time.
The web interface isn't going to disappear, but it will become the secondary way to interact with apps. Right now it is still the primary for many apps like Facebook and Flickr. That is changing.
Yes.
> That was until you started to read all your email on your phone that you carry with you all the time.
What does that have to do with web apps and native apps? Maybe your assuming that these web apps being discussed are merely that: on the web. The real fact is, you can load these apps locally, and use them without an internet connection, with local storage.
> Right now it is still the primary for many apps like Facebook and Flickr. That is changing.
You assume this is because native apps are better. This is not true. All your mobile apps aren't native because it's better to be native. They are native because they can get into the app store to be sold. And how do you get into the app store? Well, I guess you gotta learn Objective-C. And even then, the quality of the apps is questionable compared to the mobile versions.
I agree that there are cases for both approaches (native and web app), but it's also pretty amazing what you can do with HTML5/CSS3 if you know how to utilize e.g. iOS hardware acceleration properly.
In fact the whole iOS web stack with offline support, local storage, startup images and icons etc. is getting so complete, you can't even notice whether you're using a native or a well crafted HTML app.
That's completely untrue. It is immediately noticeable because of the lack of responsiveness, smoothness of transitions, and ugly layouts. Like I said, you can put together a bunch of hacks to try and imitate it, but you end up with something clunky and unprofessional. This wasn't as big a deal 10 years ago, but interface expectations on these devices (especially the tablets) are very high. Quality design is expected by a lot more customers in the hardware AND software. Interfacing with touch gestures needs to be instant and seamless.
Did you even look at the "Ali Quotes" app in the story? It's terrible. I've poked around the jQueryMobile already on my iPhone, the whole thing is, in a word, slow. Yes, I know it's new. It will be better in six months... after thousands of coding hours will be spent concocting ludicrous javascript and CSS hacks to duplicate something that's been done perfectly well on native client platforms for 3 years. It's a terrible waste of effort.
> There are also some heavy downsides in Xcode/Obj-C development, such as hunting down memory leaks and crashes
True, these are problems that have existed forever, and better dev tools help alleviate them. But don't forget these same problems are prevalent all over web apps too. Flash memory leaks are everywhere. Javascript suddenly consumes 100% of your CPU. Same problems, but no one care about fixing them because its just a webpage, just reload it. Well OK, but that's why even after 10 years people don't trust webapps.
As opposed to hunting DOM leaks and having your script silently fail?
While HTML apps are nice and very good for quick-and-dirty prototyping, I think you are sadly mistaken if you think that no one notices the difference. It would take just a couple of seconds of playing around with certain UI widgets to know if you were running on an HTML app if you knew what to look for. Even a short period of use people who do not know the tell-tale signs tend to get a feeling that there is something "wrong" with the app.
Examples?
"Not even semi-professionals would consider using Google Docs over client-based Word for serious document composition."
I do, I'm a 'professional'.
Big ones: the whole Google suite. Gmail is clearly the most reliable, but strange things still happen in gmail, like chat dropping, task lists locking up, or crashes. I love gmail, use it all the time, has great features. But I'd love a native client for Gmail even more.
Flickr. Great content and community, but the web interface is clearly clunky. Imagine Flickr on a tablet. Swiping, pinching, tapping. If you had the choice, you'd use the app, not the webpage.
Facebook. Insanely popular, insanely buggy. Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive.
Just using those 3 examples, you will see great client front-ends created for those in the next few years. Though maybe not Google if they don't get their head out of the sand. Soon Facebook will do a great tablet client, and it will be a KILLER app.
So what type of professional document creation are you doing in Google Docs?
Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I don't doubt for a minute that the experience would be better for each platform as a native app, but would it be profitable for small/medium size business? I feel like SMBs are the target of web-based mobile frameworks, for the most part. I don't think we'll see Facebook in JQuery Mobile any time soon.
Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform.
> I feel like SMBs are the target of web-based mobile frameworks
Sure, that's possible. But there are also people creating native frameworks to put SMBs into apps. Magazines are a good example. The big publishers are making their own apps, but they're are also working on frameworks to deliver other magazines. Then there are non-publishers like Zinio that are making the platform for any magazine to be published.
> Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P?
I'm not arguing that everyone who wants a blog needs to write their own blog software. No, obviously they can use something like Wordpress, and let WP worry about the programming and compatibility, and they can concentrate on content. Same goes for apps. I'm simply saying that native apps always were superior to webapps. People forgot because it became so easy and cheap to churn out functional web code. AND because these mobile client devices were closed off for development for so long. Love him or hate him, Jobs opened up everything with the iPhone SDK.
I think the expectation of a company to have a native app today is equivalent to the expectation that they would have a website in 1997. Back then it was a very expensive proposition. Today EVERYONE has a website. Tomorrow everyone will have an app. Doesn't mean they have to hire their own software team to build it from scratch.
I think you fail to realize this can be accomplished using the tools in the article. They have access to things like this, including cameras and what not.
You keep saying things that make no sense in context.
> You keep saying things that make no sense in context.
In what context is that?
I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong?
Can you hack together a way to do all this in JS? Maybe, but it's unreliable, and it's years away from being comparable. Sure, you can wait 2 years until it's figured out, by then it will be outdated again anyway.
I think you're very comfortable writing your web apps, it's something you understand and you're good at it, and naturally you're resisting change. But the industry is not going to stop changing because you're good at CSS hacks to make rounded corners on div blocks and you just wish we'd keep doing it that way because it's easy for you.
Your not. However, I haven't argued against this.
> You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do.
Well, good thing they aren't using HTML then.
> In what context is that?
In the context of the article. PhoneGap let's you create native software but using technology like HTML and JS that hooks into Apple's (and others) existing API.
More importantly, Apple uses XML for it's UI as well, so the difference between HTML and Apple's own XML format for it's UI is negligible.
> and naturally you're resisting change.
The industry is changing from desktop TO web-based. Your cherished MS, Apple, and Google agree with this as well, as you can see by their plans to not only support, but promote these types of applications.
And, in this case, I can either follow the lead of Apple, MS, Google, and Mozilla, or take the advice of some nobody random commenter with a stick up his ass.
Maybe you can explain how these companies are wrong?
I would hope you and everyone else here has already seen this, but let me remind you
http://www.youtube.com/watch?v=cCvLTlQWT6A&t=4m30s
The entire 1.5hr interview is worth watching, but starting at the 4:30 mark and watch it for about 20 minutes (you'll have to find parts 5 6 and 7 in youtube). This was in May 2007. The first iPhone was announced in Jan 2007, and wasn't even for sale yet until June. And it wasn't until June that Jobs announced that the iPhone would be releasing an SDK for 3rd party apps.
Listen to what BOTH of them say about rich client experiences. Keep in mind that Apple was already working on the tablet at this point, earlier in the video the lady asks Steve about any new risky paradigm shifting devices and Steve says "I can't talk about it". Now we know it was obviously the iPad. Then and now, the two biggest software/technology companies in the world don't even see it being realistic to run apps in the browser, at least apps of any quality that people would want. They BOTH see enormous opportunities in rich clients and new human interfaces. Jobs spells it out: rich clients with internet services in the background. This is before the iPhone SDK was announced!
These guys are thinking about touch, voice, camera, kinect, and they see NO WAY it can happen in a browser. They've spent millions in R&D, and they see rich clients. You see a free JS library and think the rich client is dead! Laughable.
Gates and Jobs are crystal clear what THEIR view is, and they've been executing it through the products they're releasing. So I don't know where you get the idea that their objective is to promote webapps. Try listening to other people sometime, you might learn something from a random nobody commenter.
You clearly have no idea what you talking about: http://www.w3.org/TR/offline-webapps/
You basically called web standards a hack, just in case you didn't notice.
> Imagine Flickr on a tablet. Swiping, pinching, tapping. All of which can be accomplished without going native. These are accessible by normal web pages using JavaScript.
> Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive. Facebook has native apps already, and they aren't any better. You can't find new messages, notifications not appearing properly are some of the problems I face. And you don't have to wait 30 minutes to have these problems. They appear before opening the app!
On the desktop, yes. Why? Because all the innovation in organizing, displaying, and managing email was focuses on webmail. Not because it was a better platform, but because it was incredibly easy to deploy and cheaper to develop.
Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Used to be the same on the desktop when being online meant you were tying up a phone line at a per minute cost. Your desktop is always online now, so it's not an issue.
But I still believe we will see a return to native email clients because of the integration possible with other client software and services. We already see it on tablets and phones.
Can still be accomplished without being native.
Listen, it's clear we aren't going to agree. But the simple fact is, unless things change, going the JS and HTML route for apps is best for the vast majority of applications people use on a daily basis. This is demonstrated by the fact that they are using these apps on a daily basis.
That's not true. People are using apps on their phones, not webapps. They're using apps on their TVs and tablets, not webapps. And people are actually paying for native apps, something no one is doing for webapps.
Seriously, you don't see any parallels between now and the late 90s? You don't think it's going to get drastically cheaper to produce native apps in the next couple years? The same thing happened in web development, a combination of better dev tools, more code libraries/frameworks, and more labor supply will drive costs down.
No it's not, it's simple HTML with JavaScript attached. Most of it probably works even if you disable JS.
> It's ugly hacks on top of more ugly hacks to produce a substandard experience.
Some examples please! Otherwise I have to assume you have just made it up.
> An app like this is not hard to produce with Xcode and Obj-C
"not hard" for who? It doesn't even have garbage collection, it's basically C with OO capabilities.
> There is a place for web apps and a place for real apps.
You probably meant to say "native" apps, and you didn't even bother to back this up.
> they don't have much to show
Except for: Youtube, Facebook, Flickr and probably hundreds more.
> buggy javascript and unreliable software
How is the JavaScript buggy? are you assuming that no one can code properly in JavaScript? Are you saying that every software written in JavaScript is unreliable? All this without even giving a reason?
> Or substituting Photoshop with one of the dozens of webapp photo editing tools. It's all cute, but in the end its not practical for real world use.
You give one example, but ignore all counter examples.
> It's all cute, but in the end its not practical for real world use.
Then why are people using it? Why are developers developing for it?
> It's unfortunate that so many talented programmers are sucked into this "webapp everything" mindset and devote themselves to crappy products, sometimes simply because they have a personal hangup with Microsoft or Apple.
Are you assuming products are crappy just because they are webapps? Are you saying that people chose web just because they hate a company?
Can you really build a well designed, polished app that people want with these tools? Well, so do it, release the app, make a lot of money and show us how you did it and why it's better than building a native app. As of now I never saw all this promises fulfilled, especially on the iPhone.
Otherwise it's just pure speculation.
EDIT: spelling and punctuation.
If you have cross-platform aspirations it's hard to argue against the value proposition of going the web app route (and coupling it with something like PhoneGap if you need App Store distribution, etc.).
Certainly there are some apps that can't be done this way due to hardware support or other device features that are not accessible via a web app but for the vast majority of the apps being commissioned today this is not the case, and being able to launch on multiple platforms with almost zero additional effort is hard to argue with from a cost perspective.
Of course being able to leverage existing knowledge and experience in the HTML realm is another bonus.
I have to say also that with the diversity of platforms now available, the "it doesn't feel native" argument is loosing some steam, since what feels native is different on each platform.
But not now.
This isn't using native controls, just HTML and CSS to make it look native. Javascript is a great languages however HTML + CSS were not designed for this purpose, try creating a complex UI in this and watch performance start dropping quickly.