Web Apps: the Future of the Internet, Or Forever a Second-Class Citizen? 205
An anonymous reader writes "This article takes a look at whether web apps will ever match desktop and mobile apps in terms of performance and usability. Jo Rabin, who's leading the push by web standards body W3C to get web app performance up to scratch, is optimistic web apps will eventually be the default choice for building the majority of commercial and business apps, while the article weighs up just how much web technologies need to be improved before this could happen. Quoting: 'Native apps are generally first to gain access to new platform-specific hardware features — be it navigating using a phone's GPS and accelerometer or taking pictures with a phone's camera. But if a particular hardware feature becomes popular, standards to implement that feature in the browser will always follow, Rabin said. Work is taking place within W3C to standardise APIs for web technologies to access many of the features found on modern smartphones. Ongoing work this year includes setting out a system-level API to allow a web app to manage a device's contacts book, a messaging API for sending and receiving SMS and MMS, new mechanisms for capturing photos and recordings, new event triggers that could handle mouse, pen and touch inputs, a new push API to allow web apps to receive messages in the background, new media queries for responsive web design, an API for exchanging information using NFC and precise control over resource loading times in a web document.'"
Installed base, day one. (Score:2, Insightful)
web app: installed base on day one: a hundred million +
In what way did that make any sense? (Score:5, Insightful)
iOS/android app: installed base on day one: 0
web app: installed base on day one: a hundred million +
What are you getting at here?
Let's say you launch a new website/web app. How is your install base not ALSO zero?
It doesn't matter how many devices CAN run what you have built. What matters is, WILL they...
With either an Android or iOS app, your POTENTIAL install base is in the hundreds of millions. Furthermore, there's a huge increase in the chances of you getting paid for some of that work, which you can use to develop it further. With a web app chances are good you launch it, zero people notice, and you fade into obscurity.
Lastly, compare how many applications there are in the iOS/Android app stores, vs. how many web sites exist. Which has better odds of someone using what you have created?
Re:In what way did that make any sense? (Score:5, Insightful)
Installation period: web app, page download time. native app, application download. Winner, web app.
Approval process before you are in front of potential customers: web app, instant. native app, depends on the whim of the store curator. Winner, web app.
Chances that your app gets removed by a change to the terms of service: web app, zero. native app, depends upon the whim of the store curator. Winner, web app.
Effort for end-user to update their copy of your application to the newest: web app, none. native app, some to none (depending upon preferences set in app store application). Winner, web app.
Competitors in the market: web app, millions. native app, hundreds of thousands, rapidly climbing towards millions. Winner, native app - but only for the moment.
Restrictions on in-app purchases, restrictions in terms of use, requirement that you have to share revenue with mobile OS developer: web app, none. native app, some. Winner, web app.
Effort to make your product available on iOS, Android, Blackberry, Tizen, Windows Phone, Windows Mobile, Firefox OS, Ubuntu Touch: web app, none. native app, none if you use a cross-platform development kit. Winner, none.
Chances the end user deletes your application to save storage space on their device: web app - only if you use offline storage. native app, some. Winner, web app.
Again, I'm not saying web app is clearly the way to go. I'm just saying it has advantages.
Re:In what way did that make any sense? (Score:4, Informative)
This alone is a big plus in the web app category. If you discover a big bug/security hole in your app and make a fix, for a native app you need to submit this fix, wait for it to be approved, and then wait for your user base to upgrade. This means that many users will continue to use your buggy/vulnerable app for awhile both putting them at risk and hurting your image.
If you discover a big bug/security hole in your web app, though, and make a fix, it is fixed. Everyone immediately sees the fixed version and (hopefully) will notice how much better it is.
Plus, with a web app, you have one code base across Android, iOS, Blackberry, Windows Phone, etc. One code base means less chance that the port to platform X resulted in a horrible bug and it means that all of your resources can go to making that one code base as good as possible. Which means less bugs/vulnerabilities to fix in the first place.
Two problems (Score:2)
If you discover a big bug/security hole in your web app, though, and make a fix, it is fixed
And if you are hacked, EVERYONE of your users is hacked also, instantly. There is some value even in the small buffer an Android app store deployment provides.
And if your web server goes down ALL of your users are down. A native app can keep on trucking and upload updates to you later.
Plus, with a web app, you have one code base across Android, iOS, Blackberry, Windows Phone, etc.
Holy cow is THAT wrong. You have n
Re: In what way did that make any sense? (Score:2)
Sounds awesome. Start up your browser one day, stupid web app got updated and now some feature you use doesn't work. Awesome.
For example, when I was writing my thesis MS updated Office. Except my reference manager wouldn't work with the updated Office. What did I do? I didn't update Office
Winner: native app.
Revising your statements (Score:2)
Installation period: web app, PER page download time. native app, application download. Winner, NATIVE app. O(1) vs O(n)...
Approval process: Yes there absolutely a web app is more flexible. So much more flexible that if your site is hacked everyone gets the corrupted version instantly.
Chances that your app gets removed: Since I've never had it happen in scores of native apps I've worked on, I would say the chances of that are really low outside of certain categories, that I don't develop for anyway...
Ef
Re: (Score:2)
Installation period: web app, PER page download time. native app, application download.
For one thing, this applies only if your web application uses a "page" model, not an AJAX model. For another, most of a web application should stay cached for weeks on end.
Approval process: Yes there absolutely a web app is more flexible. So much more flexible that if your site is hacked everyone gets the corrupted version instantly.
The same thing can happen if your native application's version control server or backup server gets hacked.
Meanwhile on iOS they don't use "real" money to pay you, just iTunes.
If iTunes isn't real money, then why is PayPal real money?
Re: (Score:2)
For one thing, this applies only if your web application uses a "page" model, not an AJAX model.
No, then it's even worse, because you are not obviously going to a new page, but you get the same annoying delay as if you had...
The same thing can happen if your native application's version control server or backup server gets hacked.
Come on. It would have to be hacked, then a change made with no-one noticing, then it would have to go out to the app store in an update. It's farcically far-fetched and even if i
One other thing about real money... (Score:2)
If iTunes isn't real money, then why is PayPal real money?
I regularly get iTunes gift cards at a discount off face value, so do lots of people.
Meanwhile whoever gets discounts off the money they send through PayPal? I think there's on introductory credit for getting a PayPal VISA, and that is it.
That's why I say iTunes is less like "real" money to people, because you can load it up at a lesser expense than using real money.
But none of that affects the application developer, they get the same amount on thei
Re: (Score:2)
1. installation doesnt take much time at all. compared with the value of having direct access control of critical tools, this is a non issue.
2. most software is downloaded anyway. web or desktop, the site sells the application to the user. it's a wash.
3. webapps change their tos and featuresets all the damn time! at least with desktop applications, the user has the option of keeping the old binaries around (license be damned!) if they suit his purpose better than the less functional, more invasive current
Access to I/O (Score:2)
Re: (Score:2)
Smoothness and responsiveness of application: web app, varies from ok to painful in jerky steps, depending on the Internet "weather", the load on the servers, etc. Native app usually be far faster and always smoother.
Chance that app will disappear forever: web app, may disappear any time the supplier isn't making enough $$$. Native app, it's on your machine indefinitely.
Pros and Cons of Customizability (Score:2)
Web-apps are hosted on a competitive platform with open standards called a browser, which allows applications to be modified to the user's advantage by extensions and user-scripts. Native apps are locked down.
From the user's perspective, advantage Web. From the developer's perspective, advantage native.
Will customization be stopped by adding DRM to HTTP, forcing use of blessed browsers?
Re: (Score:2)
But - maybe this makes me boring - the most common feature I use on my Android phone is bookmarks. I have my movie theater ticket purchase site bookmarked, the local weather site bookmarked, and a few others. I don't use many native apps. So the "performance and usability" advantage of native apps is meaningless to me, the only native app I installed is Firefox browser.
Offline web apps vs. online backup of native apps (Score:2)
Net's down? Web app: Welp, you're SOL, son - Native app: Net? What net. Winner, native app.
Web applications can include an offline version using application manifests, IndexedDB, and an IndexedDB-compatible shim around the SQLite included in WebKit. Native applications can display an alert box and close if they fail to connect to the Internet service to which they were designed to connect. For example, good luck using the Facebook or Twitter application offline. Advantage neither.
Your data leaking due to hackers or court subpoena? Web app: Just cross your fingers and pray it doesn't happen. You probably won't know until too late, anyways - Native app: At least your data and its protection is in your own hands.
The court can just subpoena the server used by the native application's remote backup feature.
Whut, you thought setting up payment system for your site is that easy, requires no expenses to maintain and has no transaction fees?
Stripe, Authorize.Net, P
Re: (Score:2)
The comment was open-ended enough for the following interpretation: consumers are resistant to installing new stuff. They don't like to clutter their mobile device screens with icons, and they unconsciously fear security threats. If you have a web app, you bypass this installation step. Conversely, if you have a native app then just because it's installed doesn't mean people are going to use it. How many apps do you have on your mobile device, and how many do you actually use? The "install base" number is o
Re: (Score:2)
If you have a web app, you bypass this installation step.
I would argue this is absolutely not the case.
Security threats come MORE from the web than native application installs. So people are leery of clicking on links.
The idea that a "web app is installed on every computer in existence" is an interesting perspective on that practice.
If by "interesting" you mean "utter bullshit", then yes, that idea is "interesting". It means nothing until people run it. A native application downloaded is very likely to h
Not less restrictive, just broader. (Score:2)
For instance, Safari on iOS won't let you access the user's system logs (which other apps might occasionally write personal information to) but the containers that run native apps do.
That's not true, what you can do is query the logging system [cocoanetics.com]
While it may seem a fine distinction, you are still working through an API. A native app doesn't have "much less restrictive access" to the OS, it just has BROADER access.
Pretty much all of the untethered jailbreaks have come from holes in Safari - not native apps -
Bookmark == icon (Score:2)
consumers are resistant to installing new stuff. They don't like to clutter their mobile device screens with icons
A bookmark of a web application is an icon.
One click install (Score:2)
It's only a click to install an app too. Only there's a whole lot more web you have to fight for attention against, and more things that can go wrong in the process of delivering a web app to the user. Bad WiFi day for the user? A small hiccup in an app install, but it makes your web app look like garbage.
Re: (Score:3)
web app: installed base on day one: a hundred million +
first time someone doesn't have/has crappy network access: install base -= 1
Re: (Score:2)
Could Browsers Settled on an Alternate Language? (Score:2)
Re: (Score:2)
well, you could always go for canvas.
not so sure really if that's an option for mobile browsers though..
Re: (Score:2)
it works? damn I'll have to take a look at using it then, trying to make fancier things work with dom and css is just a bitch! I mean, covering desktop ie/firefox/chrome is no problem but covering mobile versions of those at the same time is. javascript itself isn't a problem for me, I like node.js despite it's limits too surprisingly lot(I've just been doing js for a year or so.. from java/c++ background it's not so bad). sure, you'll lose css but that's not that big of an issue when in all cases when I've
Re: (Score:3, Funny)
The primary problem is not JavaScript, but that so few web apps are licensed under AGPLv3+ and thus are not suitable for any kind of serious use.
Re: (Score:3)
It seems like some of the problem here is that Javascript is the Lingua Franca, and also that it has to use the web pages DOM. If the system were being designed from scratch, it seems unlikely this would be the choice.
Javascript is a very sloppy language for doing anything in. People, like me, continue to write in it because there's little alternative.
Writing in javascript drives people insane.
sent from my padded cell
Re: (Score:2)
Re: (Score:2)
Javascript is a horrible language
Why?
Do you have any complaints about it that don't boil down to "I hate dynamic languages" or "classes are the one true way to do oop".
That's what I thought.
That you can just "jump in" and get things done is certainly a testament to the language, but you really need to take the time to learn about it before you can use it effectively. Most people don't take the time to learn it and just jump on the bizarre "JavaScript is horrible" meme. Don't be like them!
If you need an easy introduction, there are quite
Dynamic languages in general (Score:2)
Do you have any complaints about it that don't boil down to "I hate dynamic languages"
Why should such boiling down be shameful? Fully dynamically typed languages impose substantial runtime overhead [slashdot.org] and require manual creation of even those test cases that would be implicit in a language that has even an option for static typing.
Re: (Score:2)
Re: (Score:2)
There are more, but I'm bored.
And horribly wrong, but you don't know that. I'll also note that your complaints are exactly what I expected "I want broken classes" and "I don't like dynamic languages". Ridiculous.
The fat arrow indirection pointer is a huge interpeter hole depending on how its implemented
Nonsense. While I agree that it should never have been added (thanks coffeescript, for your worse-than-useless contribution) there are certainly no fundamental problems with it. God only knows what you mean by "huge interpreter hole", though "depending on how its implemented" implies that it's not a problem with the language
Re: (Score:2)
And horribly wrong, but you don't know that. I'll also note that your complaints are exactly what I expected "I want broken classes" and "I don't like dynamic languages". Ridiculous.
I want broken classes??? How did you get that out of what I said?
(prototypal inheretance) It's much much more powerful and flexible than class-based inheritance. Your off your rocker pal. Protoypal inheretance my have its uses but it IS NOT OOP. Protypal inheretance works fine in the template world and has its place, but is no replacement for pure OOp pradigms.
This makes absolutely no sense.
js code reuse relies on nesting, which is a BAD IDEA.
This is equally incoherent. JavaScript, at one time, lacked block-level scope; but that had absolutely nothing to do with OOP. (Neither is JavaScript an "OOP language", whatever that's supposed to mean. It's closer to Lisp than it is to Java.)
WHAT IS THAT SUPPOSED TO MEAN?
I'd ask you what bizarre reasoning brought you to that conclusion...
Use makes me say these "bizarre" things. Js claims to be an OOP language, yet the rules it follows is more like PHP.
Re: (Score:2)
I want broken classes??? How did you get that out of what I said?
Class-based systems are fundamentally broken. We've known this since the 1980's. Get with the time, man!
Your off your rocker pal. Protoypal inheretance my have its uses but it IS NOT OOP.
No surprise there. You'll find that there's no consensus on what "OOP" actually is or entails. It's an ill-defined and incoherent concept. It's funny, you'll find that there's a lot of disagreement even about what languages are and are not "object oriented" -- which includes languages like Java and C++. If you want to have an "x is not OOP" argument, you can have it with someone else. I'm sure someo
Re:Could Browsers Settled on an Alternate Language (Score:5, Interesting)
It seems like some of the problem here is that Javascript is the Lingua Franca, and also that it has to use the web pages DOM. If the system were being designed from scratch, it seems unlikely this would be the choice.
I think there is a Peter Principle for technology: Every good, proven technology gets extended, extended, and extended until it breaks. Back in the day, the web was a fast, simple, stateless request/response document retrieval system. Then some markup was added to make the documents look pretty. Then CGI and server-side processing were added to make the content more dynamic. Then tricks were applied (eg- cookies) to break the statelessness, albeit in a limited way. Then the prettiness of documents were improved with CSS and liquid design. Things got slow. Then the scalability of the server side was improved with various frameworks like JSP, Struts, Rails, etc. Applets had been tried, but they didn't take off because security and version control turned out to be much bigger problems than anyone realized at the time. Then JavaScript was extended and made to do all sorts of unsecure things. AJAX came along and broke the request/response document retrieval model for good. Things got slow again, especially on newer mobile platforms. Now the w3c wants to figure out how to run fat applications on this platform, ostensibly because it's shared in common across OSes.
Rinse, Repeat. Everything old is new again.
Re: (Score:3)
Re: (Score:2)
I'm using the Google Web Toolkit to program JavaScript by writing Java. It seems to be working quite well. Learning DOM and CSS intricacies is the real bitch.
Re: (Score:2)
Web app? What's that? (Score:5, Insightful)
Do you mean a website?
Do you mean a website that has been optimized for mobile devices with a small screen and minimal javascript capabilities?
The reason the internet became popular is because of standards. Any web browser can connect to any web site, issue client http requests, and get an http response.
The web browser/web server is the better way to go. I don't need to download & install a program on to my laptop to bank online. I don't need to download & install a program on to my laptop to read the news.
I just just my web browser. It's the better model.
Re: (Score:2)
Re:Web app? What's that? (Score:4, Insightful)
You know what would really suck? If we decided to drop backwards compatibility simply because what was originally intended as a document sourcing and navigation solution has ended up in the hands of profiteers who want this document-oriented system to be used for 3D rendering. Yeah, HTML/CSS/Javascript can do that, but why use a screwdriver when a jackhammer is more appropriate?
Instead of saying "oh the web sucks because it's old, let's make it new", why not look at what the desktop environment has yet to deliver due to market fragmentation and misguided creative direction? There is much more to the Internet than what traverses ports 80 and 443, and it boggles my mind to think that instead of inventing new protocols and applications (not "apps") to get the job done in a better way - Steam is a great example of this - the popular idea is to say "well everyone has a web browser, let's find new ways to exploit it". It's lazy, uncreative thinking, like standing on the shoulders of giants and then deciding the giants need to be put to sleep because their clothes are no longer fashionable.
Re: (Score:3)
Steam, is, in fact, mostly just a web browser. It has a few other things it can do, like start games, and install things. The vast vast vast vast majority of the interface and design is just a web browser, hitting a web-app the steam devs created.
Re: (Score:2)
I don't need to download & install a program on to my laptop to bank online.
No, you just need to ignore the inherent insecurities that go with using html apps. How nice.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
When 90% or more of the computers accessing the internet were running Microsoft Windows (and then later almost all running IE), I don't think standards had much to do with web adoption. It was adopted because it was really, really cool. I don't mean it wasn't important at all, but I think standards were just one of many items in the WWW's plus column.
That said, as web-apps become more application-like, the web browser becomes more and more like an unstructured app store. I don't think that web apps will dis
Re: (Score:2)
It depends on what you're trying to do. For online banking and stuff like that, sure, you don't want to have to download some stupid proprietary application just to do that.
However, what if you're building a custom application for use in a business to manage payroll, or handle sales contacts, or do some other highly specialized business function (that only people in that business would understand the need for)? A lot of people seem to want to make web apps for these things, but there's a lot of problems w
Re: (Score:2)
or handle sales contacts,
Salesforce seems to be pretty popular, flexible, and powerful from where I am sitting. Our sales team switched over a while back and has not looked back.
Re: (Score:2)
Web apps are the world's biggest inner-platform effect, create an OS-like environment except you're tied to HTML and CSS for rendering and JavaScript and XML (AJAX) as your client-server protocol. Every website tries to reinvent every standard desktop UI component (menus, dialogs, tabs etc.) and poorly I might add. Don't get me wrong, a lot of business and administration applications, online banking and whatnot that only need a standard toolkit are better off as web apps but no, turning everything into a "w
Re: (Score:2)
Do you mean a website?
:
:
No... He does not mean a web site...
He actually means what he says... a web app[lication] - an application written using the latest web technologies (JavaScript, CSS, DOM and XML/HTML), downloaded from a web site to execute within a browser environment that supports the HTML5 API and standards against which the application has been coded.
A web app is as real an app as any of those that you say you "... don't need to download and install ..." You can even choose to save a web app locally on your phone or
Check deposit with a camera phone (Score:2)
I don't need to download & install a program on to my laptop to bank online.
In your opinion, should one have to download and install a program to take photographs and upload? Say you want to deposit a check. You can ride the bus to an ATM, ride the bus to a branch, ride the bus to the post office and mail it to the bank, or take a photo of the front and back of the check and upload the photos to the bank. Guess which of these is the easiest to do if your bank is in another state. Banks tend to require a native application for this because support in mobile browsers for photography
Re: (Score:2)
It has to be conceded that this exists. I only install apps where this is so. More often it is pointless, as you say.
Even now internet isn't always there (Score:2)
First World Problem (Score:2)
GRRRR (Score:2, Interesting)
GRRR, this is STUPID!
This drives me mad. Webapps have pushed usability a good 20 years back.
Look at all the pb in desktop apps: we still don't have it "right", and now, there is an increasing tendency towards webapps that have even worse choice of widgets, and don't respect many usability issues that desktop had barely started solving... And don't get me started on the browsers compatibility issues!
This is CRAZY! People are building GUI inside a medium that has never been designed for that, using always mor
Can we please stop reimplementing the wheel? (Score:5, Insightful)
From the article: "...today web browsers are capable of supporting sites that are getting close to the look and feel of apps we run directly on our phones and computers."
Great. So with a lot of work we're almost BACK TO WHERE WE WERE! How about some innovation and making better, more usable UI's rather than just trying to catch up with what we already have?
This is the same problem I have with Linux - constantly reimplementing things we already had. At least Linux is replacing closed software with open software. What's your excuse with webapps? Is MS Word in a browser inherently better or just different?
Re: (Score:2)
>> Is MS Word in a browser inherently better or just different?
When it's Google Docs vs. MS Word, it's better: 1) I can view or edit it from anywhere and 2) if someone else is working on it with me we can both edit (and see where we're each working) and 3) it's free.
Re: (Score:2)
Re: (Score:2)
Is MS Word in a browser inherently better or just different?
For who? For us, not necessarily; for MSFT, probably...
Re: (Score:2)
If every good native application in the iPhone app store, Google Play store, and Windows App Store has an equivalent web app version, then it's much easier to convince people to ditch their iPhone/Android phone/Windo
Good native games (Score:2)
If every good native application in the iPhone app store, Google Play store, and Windows App Store has an equivalent web app version
With WebGL disabled in Safari for iOS, good luck replacing every good native game with a good web application. And good luck being able to use a device's camera to take a picture in a web application.
Why it is not actually better for most people (Score:2)
Why is Google Docs better, at least in principle, than Microsoft Office? Because I can use Google Docs from Windows, from Linux, from Mac, from FreeBSD, from Android, from Tizen, from Blackberry, etc... etc...
The thing is, people don;t have Windows AND Linux AND a Mac...
The have a small number of devices, and if the data can be read on one and worked on on the other, good enough.
That is true of most people, and why web apps have not mattered that much.
Re: (Score:2)
And that's actually a good thing. There are so many inherent advantages to web-based applications from a maintenance and overhead perspective, that businesses, large and small, are going to push more applications to them.
Mobile apps exist because the capabilities of the hardware got so far out in front of browser software that a decent experience couldn't be provided. But, back to point 1, as the capabilities of browser based software inevitably improves, a lot of this development is g
Not as long as we have to write them in javascript (Score:3)
Not as long as we have to write them in javascript. javascript might be an ok language, but it is not designed to help with development of large projects. The type system, and the prototype based objects are not good at doing that.
Re: (Score:2)
Many languages now compile to Javascript. Some are specifically designed for this (TypeScript, Dart, Elm), others have gained it later, especially thanks to emscripten.
The DOM can still be a pain, since it's difficult to abstract away. There are those who abandon the DOM altogether, eg. using Canvas or WebGL. That brings its own concerns though (especially accessibility).
Re: (Score:2)
Re: (Score:2)
"Apps" are not web interfaces (Score:3)
There is a big disconnect here. Using HTML 5 to implement an app interface on a smart phone is not the same thing as implementing a general browser web interface using the same technologies.
Heaven forbid a web interface should ever have data to manipulate anything more than the cookies it needs in my browser. That would be a security hole you could drive a whole fleet of trucks through.
However, I don't believe that web interfaces will ever equal custom client code or custom apps for the simple reason that you get hesitations and delays during page and AJAX refreshes. One of the worst culprits for this is trying to implement drop down choice boxes that adapt their contents to previously selected data, such as country-state interactions. The only way I know of to do that with a web interface is to refresh the whole page, which is obscenely slow compared to the repopulation of the choice box data itself done by a custom interface.
There is also no way to perform performance tuning and UI tricks like dynamically making widgets visible/invisible with a web app, something that is very common to high performance custom interfaces. In part, this is because web apps don't have the necessary layout management interfaces that a custom application does, which allows them to position those hidden widgets appropriately so that they overlay each other to the pixel.
Re: (Score:3)
One of the worst culprits for this is trying to implement drop down choice boxes that adapt their contents to previously selected data, such as country-state interactions. The only way I know of to do that with a web interface is to refresh the whole page, which is obscenely slow compared to the repopulation of the choice box data itself done by a custom interface.
Then you don't really have much of a grasp on web development. It is trivial to create controls that update themselves with content based on a previous selection without round-tripping to the webserver - you just have to send the complete set of data with the initial pageload, and just operate on it - which, incidentally, is exactly the same way a native application does it: when you install a native application, it needs to either copy the entire dataset it's working on onto your local machine, or retrieve
Re: (Score:2)
Good to know.
Thanks for the tip.
Re: (Score:2)
Your approach has one big glaring gigantic behemoth flaw:
You can't submit the form data as a form any more when you inject a frame in such a fashion.
Don't forget stuff like DRM (Score:2)
Web apps are great. But then you get the W3C to try stuff a little bit controversial like DRM and everyone wants a "free web" and "they should make an app!".
And then get surprised when developers do.
The iTunes store is probably the best example of this - it's basically a few web pages strung together but which really wants to get you into iTunes. (Honestly - is it even possible to use iTunes preview? The only way I've seen it was through Google).
The reality is, we're going to have to have some long and very
Generations... (Score:5, Insightful)
Apropos of the question in the title of this post. I had a meeting today with a guy in his early 20s. I mentioned that one of my current projects is a Java Client/Server application. He found this totally bizarre, because "Web apps are the future".
Now, I'm a geezer by IT standards. I cut my teeth on an IBM 360 (yes, that old). One of my standard charts that I use in general IT presentations is a spiral. I'll do it here in text, a bit oversimplified:
The pendulum swings back and forth, but you only start to recognize the pattern after you've lived through a couple of cycles. In fact, it seems that by the time one trend has established itself as inevitable, the next (opposite) trend is already well underway. Right now, Web-apps and Cloud computing are the buzzwords, but mobile computing is already well underway for dominance by 2020.
So, if I may answer the question posed in the title: Web Apps: the Future of the Internet?
No.
Re: (Score:2)
It is nice to see I am not the only one to recognize this pattern. I chuckle at all the market speak buzz words that surround "new" technology, but is in fact, a rehashed version of the same old stuff (I cut my teeth on a smaller cousin around the same time). As I have had to re-invent myself three times over I keep getting asked questions like "what language do your write in?" or "What experience do you have in developing applications?" Really? I've coded in languages I've now forgotten and written mor
Re: (Score:2)
- 2010: centralized computation (Web apps and cloud computing)
Most computation tasks are performed locally. Only centralized tasks are the ones where functionality requires this approach, i.e. posting on Slashdot, checking bank account balance, etc -- you cannot perform these locally.
- 2020: distributed computation (mobile computing)
New pocket computers will eclipse today's PCs in almost every aspect (almost happened already), yet nothing will change in terms of paradigm: tasks that can be per
Re: (Score:2)
I've seen this happen a lot. I see it as a tug of war between users and IT/IS management. You start with centralized computing and then the users have a valid need to have locally controlled management of their own resources, so they buy minicomputers owned and operated by their departments. Then the centralized priesthood steps in to say "we can handle that tedious work for you if you put your computers under our control", and the overworked departments agree.
Workstations -- the priesthood controls acce
couldn't figure out how to vote (Score:5, Insightful)
Seriously, to add some content to my snark. Until internet speeds reach parity with access to local resources, web apps will always be second class compared to a similar application running locally.
Re: (Score:2)
Are they talking about extremely remote internet web apps (google docs), or instead local web apps that only go to the back office so that connectivity is fast and robust and secure?
Why does this get asked every N months? (Score:5, Informative)
The answer will forever be NO, until the bandwidth between me and the server == the bandwidth between my CPU and its main memory. AND latency, AND availability.
The fastest web apps TODAY are still slower than the native apps that shipped on the first iPhone in 2007.
Besides that, both kinds have their own unique advantages. The first two: web apps allow you to get at the data from any device with an Internet connection and browser, but native apps work when you don't have network connectivity at all. If neither of those is a make-it-or-break-it aspect of your app, then you look at all the other advantages each offers, which have been discussed ad nauseum elsewhere.
Re: (Score:2)
It's just that the bar to make web apps is a billion times lower than it is to write native code.
What do you mean by that? It's a hundred times easier and less complicated to make an app in, say, Lazarus or Qt than to create a working web app of any kind.
The bar is the cost of a Mac (Score:2)
It's just that the bar to make web apps is a billion times lower than it is to write native code.
What do you mean by that?
To make a web application, you can own any brand of computer. To make a native application for OS X or iOS, you have to own a Mac in addition to whatever computer you might happen to already own. And I can cite statistics that there's over a 90% chance that this computer that you already own happens not to be a Mac.
Do factor in Win-8 (Score:2)
Interesting bits are JavaScript bit bold and in your face.
This is much of the core issue that involved MS litigation and the browser wars.
As long as they play nice with standards this could prove interesting.
Native apps don't really add much (Score:2)
I understand the hopes of those that wish we'd move to native apps, but I just don't think those hopes will be realized.
One of the biggest advantages in using HTML/Javascript is that is provides a semi-nice way to talk to Windows' API. There's lot's of Windows boilerplate that disappears when using HTML/Javascript.
That's much of what HTML/Javascript is -- a nice veneer over a difficult API. But that veneer doesn't make the underlying system disappear. And many of the problems that HTML/Javascript appears to
Second-Class (Score:2)
Keyword: follow
So if you want cutting-edge apps, go native.
What if the server was on the device (Score:3)
Turning back the clock (Score:3)
Whether you want to call them web apps, thin clients, or terminal based apps - the premise is the same...the name just changes over time.
Web apps will succeed where users can tolerate the inherent limitations of the basic network-based thin-client app paradigm and are content accepting a limited or common native hardware feature set.
Native apps will succeed where people want the highest possible performance and instant access to the latest native platform features and are willing to sacrifice cross platform capability.
Yes, there are hybrid tools that try to bridge the gap...some are better than others. Still, you lose something in the translation when you try to be a jack of all trades and master of none.
To get the best of both worlds would imply that innovation has to stop until manufacturers all implement feature X into the common hardware feature set and the hooks in the "browser" to access them. And, you will need a persistent storage model that will allow web apps to have the same sort of performance that native apps possess. Only where the native app and web app are storing data on a server will that metric ever be even remotely close to a native, persistent store (unless we have FTL wireless networking).
I recommend advocating web-based apps and/or native apps when they are appropriate to the requirements from both a business and user perspective. Unless you can do that, you are little more than a fanboy for whatever paradigm you have locked yourself into.
Best part of it all? You can make money regardless of which way you to choose to go...Web, Native or Hybrid. That's what it's all about, right?
In the Enterpise? No-brainer (Score:2)
No (Score:2)
The answer is, of course, No. Because the answer to questions asked in headlines is always no.
The real answer is a bit more tricky. A simple no doesn't cut it, because for some use-cases, web-apps are really great. And for some, native apps are better.
Asking "web- or native app?" is like asking "hammer or screwdriver?" - well, it depends on what you're trying to accomplish.
Re: (Score:2)
You jest, but I know that my user base is more interested in and engaged with mobile apps than web apps. I see far more tablet+bluetooth keyboard cover combinations out and about than I do people lugging laptops. The one exception being coffeeshops where you can camp all day by an outlet.
Also, a native mobile app can deliver a better experience in many cases. How many people use the gmail web interface instead of the app on their phone or tablet?
Content-creation heavy jobs (and I include serious writing
Re: (Score:2)
It's the walling of the gardens that's going to do us in.
Userland rejected the walled garden in the late 90's, they'll reject it again.
Re: (Score:2)
oh wait
Re: (Score:2)
Which is actually the best answer in this case. No, they are not the future of the internet. No, they will not be forever a second-class citizen. They're a thing, that is useful sometimes, but not all the time, just like just about any other application paradigm/environment. There are times when you want a web app. There are times when you want a regular page. There are times when you want a thick client talking to a server. There are times when you want a thick client that works in offline mode most of the
grammar nitpick (Score:2)
Re: (Score:2)
Re: (Score:2)
Javascript in Google's V8 is never worse than 20 times slower than C and never uses more than 24 times as much memory.
That is really bad performance, though. Think about it: 20 times slower, 20 times higher memory usage... if you'd use this for anything serious, it would bring even the fastest home PC or laptop to its knees. The good news is that nobody really uses web apps for anything serious (except web mail), they are mainly used for wasting time and jerking around. In other words, web apps and native apps are two different classes altogether - different users, different purposes, different markets.
Re: (Score:2)
Re: (Score:2)
flew on hardware that was thousands of times less powerful (like scrolling through a very large source code file)
I doubt that Atari had an IDE that was constantly checking for code trees, pre-compilation analysis, syntax highlighting, etc. I can open up a 1GB text file in Sublime Text and scroll just fine.
Re: (Score:2)
If your user's browser doesn't support a feature (Score:2)