Slashdot Mirror
Web Apps: the Future of the Internet, Or Forever a Second-Class Citizen?
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.'"
iOS/android app: installed base on day one: 0
web app: installed base on day one: a hundred million +
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.
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.
It's the web apps that are going to make, then keep, us second-class citizens.
Along with smartphone apps, cloud subscriptions, and so on. It's the walling of the gardens that's going to do us in.
Expose hardware capabilities to the Internet? Didn't we just go through why this was a bad idea with WebGL?
Web apps are so, like, 1999. Phone apps are now the future of computing.
When more of them can be used offline (when it's easier to make them work offline), then they will be more prominent.
It's a silly conversation. Let's say we all concede all web apps are forever doomed to be second-class citizens. As far as second-class citizens go, they have it freaking awesome! People don't just want them, they clamor for them! They are lauded and keep getting better and better. Even when you do use a native application for better performance or to fulfill a niche need, you can't help but wonder in the back of your mind how soon before you can do this with a web app, too.
"Love heals scars love left." -- Henry Rollins
well, you could always go for canvas.
not so sure really if that's an option for mobile browsers though..
world was created 5 seconds before this post as it is.
How many average people use applications that need high performance? Twitter is the top end of performance with realtime data applications for most people I know, games usage does not occupy enough people/time to be near the amount of time that people spend doing email, twitter, travel booking, coupon hunting, review finding, etc. Who the hell needs C level performance on most daily needs?
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 more complex layers for a worse user experience (and don't get me started about the performances loss).
Its great that many things can be done in a browser. I had even thought how cool it would be if everything could be done in a browser back when I was using the iComm Shell browser on a unix account in the mid 90's. I got over it, the browser is an app, it can be used as, or as part of an OS shell, but does it really need to be extended to have hardware access and interop with other apps/data stores on the device? Isn't the internet insecure enough as it is?
This argument will be settled in the marketplace, and it is either side's battle to lose. All it takes is consistent frustration with one side to become a proponent of the other. Barring that, people will use whater works and/or is cheaper.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
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.
1) Leadership in development tools
2) Commitment to quality
No scattershot development and headless API development. No myriad of partially broken tools and incomplete platforms. No perpetual betas.
On Windows you use Visual Studio, on Mac you use XDevelop, on the web you use bleh whatever and the majority of it is constantly broken in interesting ways. Fix this part first and the applications will follow. Think Steve Ballmer and the monkey dance.
Until this is fixed I won't even regard webapps as a 2nd class citizen - I regard them as that guys that turns up at your house, barges in, shits on the carpet then drinks all the beer in the fridge before passing out on the couch with a bucket on his head.
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?
mobile apps will always be below desktop apps, common sense it a small device can do 'N' a large device can do 'N+C', even if C is small. However, both will advance in tandem
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.
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
A feeling of having made the same mistake before: Deja Foobar
While Web apps are proud to run hundreds (or thousands) of times slower than native code sanely created for the device, web apps deserve (beyond light cases that don't matter) ZERO success. For all you liberal 'green' types, web apps are the greatest waste of energy on the planet.
In Computer Science, there has to be a good reason to use systems that have extreme amounts of abstraction between the 'code' and the 'hardware'. Such reasons and use cases do exist, but unfortunately once a highly abstracted infrastructure is developed, too many programmers start to use it for completely the wrong types of project.
Anyone who has used home computers since the early microprocessor designs made them possible will be constantly amazed to see their current PC often struggle on tasks that positively flew on hardware that was thousands of times less powerful (like scrolling through a very large source code file). On my Atari ST I had just 512KB of RAM connected to a 1MB floppy, but could run a full blown C development system with compiler, editor, and runtime abilities. ONE HALF OF ONE MEGABYTE and this had to serve the OS as well.
Today, we have GPU benchmarks on our browsers where we are supposed to be wowed because they render a few objects at handfuls of frames a second. Literally less than ONE THOUSANDTH of what our GPU can achieve in native mode. This is insane- absolutely insane. Even AAA games often lose 50-66% of the potential of the hardware, because of the lousy interfaces Microsoft provides (and THIS is the reason the very best coded games of the Xbox360 and PS3 kinda keep up with current PCs- they are coded to the metal in ways the PC cannot match).
We need a do-over. A new generation of ultra-light layers of abstraction, making most coding easier, but keeping most of the performance of the hardware. Tablets lead this initiative, of course, because they need to preserve their battery power as much as possible. Sadly, we get the usual dribbling shills screaming "security, security- efficient apps are unsafe apps". This is BS. Ultra abstraction provides infinitely greater numbers of vectors for attack.
Web Apps: the Future of the Internet, Or Forever a Second-Class Citizen?
According to Betteridge's Law, the answer is 'no'.
Sheesh, evil *and* a jerk. -- Jade
Just what we need, a return of ActiveX reaching deep into OS system calls...that proved so wonderfully feature-rich and secure the last time it was tried...
Javascript is a horrible language. But we're locked into it now becuase for whatever reason every browser maker decided to buy into it, and then you get great tools that make diamonds out of shit like Node.js and etc., so here we are.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
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.
I do not fail; I succeed at finding out what does not work.
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).
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 difficult discussions on what to do. Ideally we wouldn't need the discussion period, but since that doesn't seem realistic at all, we're going to need to see what the real solution is. Do we allow DRM and thus DRM content on the web? Or do we say no and end up in an app-universe where web sites are merely conduits for providing the app?
I think this is only true if you have experience in a "better" language. If all you know is JavaScript then these comments about it being sloppy/horrible/able to drive people insane comes off as... insane.
so few web apps are licensed under AGPLv3+ and thus are not suitable for any kind of serious use.
You're confusing the cause, there.
The unsuitable for serious use has nothing to do with the licensing and everything to do with them being web apps.
If a company i bought software from goes bust, I don't lose the software I bought from them. i may not get updates, but i still have the bloody thing and can continue to use it.
How's that work with your web apps in the cloud? Oh it doesn't. They go, your app goes, and you waste time finding a replacement and learning its nuances, get comfy with it and then it goes too, and you have to do it all over yet again.
Dependency on you not screwing up your business and leaving me without your product. For games, its kind of acceptable. For business and productivity, its dead in the water. So yes, web apps will forever be second class citizens because they fall, fail, or get eaten up by morons on a daily basis.
http://bokardo.com/archives/7-reasons-why-web-apps-fail/ that's from 2006. Take a look. Has literally anything changed between now and then that makes those points moot? No. So yeah, web apps are still gonna be crap for the most part in most people's eyes.
Let's face it. Most capable Software Developer are either dead or retired. Because of the incompetent Successors the Software and everything necessarry to Develop it is crap, I might even say it's plain madness.
What's happening is, we see that people give up. "I don't want to develop Software anymore" they say "it hurts my head to think about maintainable Design" they continue. Thus, WebApps are born.
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.
Enjoy life! This is not a dress rehearsal.
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.
file:
Add a silly social sharing feature, and a software justifies its existence as a web app instead of a desktop app.
If we embrace webappification too fully and quickly, we'll lose our privacy, ownership and control of data and hardware, and be held ransom by fees. It could end up with the disadvantages of "trusted computing".
FOSS might be our hope for this future.
More like UNPERSON. The day I want to be using bits of HTML and Javascript tied together with string to run my things is the day I unplug.
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?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
I guess this means Slashdot is not suitable for serious use.
So JS is the web's assembly language? Cause I want to read and write JS as badly as I want to read and write assembly.
Right now the Firefox OS phone is on sale at the ZTE Ebay stores in the US and UK:
anywhere in Europe
and
US and Canada
For those of us that genuinely want to test webapps on a device designed specifically for them.
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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
You can pry desktop apps from my cold dead hands. I'll switch to web apps aka cloud apps when the NSA is a long forgotten memory and we are all singing Kumbaya in the streets while holding hands.
Canvas works perfectly fine on Safari for iOS and Chrome for Android (we use it in a production app). So you are suggesting that instead of using DOM, you just draw widgets natively on the HTML5 Canvas. That's a pretty neat idea :-) It doesn't address the JS being the "Lingua Franca" issue though. Google's GWT compiler lets you write your code in Java and then targets Javascript as a back end. But that wires you to Java.
Another technology that makes for a multi-language environment is Google's NativeClient. But that has too much dependence on the underlying architecture for isolation, so it's probably going to be hard to keep it portable across all the platforms out there.
you meant, "a piece of software" -- there is no such thing as "a software" or for that matter "a hardware, a clothing, an information" -- you have a piece of hardware, a piece of clothing, a piece of information. Thank you.
Most of the criticism I see around javascript comes from people who know almost nothing about javascript, much less writing quality javascript. Read "Javascript, the good parts", and js becomes an extremely powerful and flexible language. Trying to cram OOP into a language centered around functional paradigms seems to be the source of most people's issues with the language. As for the DOM... the DOM is a pretty sane system, until you need to support 3+ browsers of differing quality. The language is really not that big of deal anyway. Look at iOS, which uses a language many would say is no where up to snuff with other modern languages.
For me, the biggest missing feature for Web apps is local file and device access.
And no, we're not going to "just store everything in the cloud". The fact is that the industry pumps out a huge number of HDDs, SDD, flash drives, SD cards, etc., and those devices will always need a way of storing content onto them. Web apps have a very poor interface for reading those devices, and a truly awful interface for writing those devices.
My prediction is that security concerns are going to prevent deployment of any truly flexible JavaScript APIs for accessing the local system. We've got some proposed APIs now, but they're badly crippled due to security concerns.
Microsoft Word is probably the single most popular productivity app. It can access any local file / printer / etc. on my system. Until web apps can do that, they will be completely shut out from replacing Microsoft Word. Creating content locally will always have significant advantages over creating it in the cloud. (Mainly, all the big ones: performance, security, and flexibility.) Security concerns will prevent web apps from ever touching the local disk / printer / GPS / etc. without forcing the user to go through awkward and annoying GUI steps that are specifically designed to be intrusive for the sake of security. That fact alone will kill a huge swath of potential penetration for web apps.
I will become an accountant before I have to go back to using .Net and Visual Studio again. Everything works like a dream... until it doesn't. The Law of Leaky Abstractions was enough to move me to commit to learning a language that did not implicitly require an IDE.
The question in the post "Web Apps: Future of the Internet or forever second class citizen" amounts to:
"In the future, are people going to predominantly build consumer software applications using web technologies such as HTML5 and Javascript, which are ubiquitously supported across all platforms, or are apps mainly going to be built in platform-specific environments."
not:
"In the future, are apps going to sit locally on 'mobile devices and computers' (from the article) or are they going to be accessed via websites always."
This is probably the single biggest question every mobile developer faces early on. Do you build your app separately for every platform, so use XCode, Quartz etc. on iOS, do you use a cross-platform development environment such as Xamarin which targets the OS natively, OR do you just target the browser "as the OS" and as a result run across all platforms.
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.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
you insensitive clod!
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 have are really the fault of Windows. Many of those problems don't go away with native apps with the additional hassle of adding all kinds of boilerplate.
Of course that all applies to Windows PCs. Native apps are much more successful on an IPhone, for example, because the underlying API is much more sane. Microsoft has tried many times to make it easier to write for its OS -- MFC, .NET, etc, etc.
Think about how quickly apps appeared for the IPhone and consider how few native apps exist for the PC relative to the total number of PCs out there.
You're implying that Slashdot is a "web app".
Stop that. It's stupid.
AMD, CommonJS, requireJS, and many others allow you to write modular js. Take your pick. npm is the major selling point for me on js. None of the dll hell I had on .Net with large projects.
Sure, if assembly was trivial to read and understand. Coffeescript is about as nice looking as languages get. Use that. With new code mapping capabilities being released, you could probably get by without really understanding any js.
As much as I like the idea, Rabin said, "But if a particular hardware feature becomes popular, standards to implement that feature in the browser will always follow,"
Keyword: follow
So if you want cutting-edge apps, go native.
JS/CSS/DOM are terrible technologies for producing heavy weight applications. JS is a slow prototyping language, CSS can't even vertically center without hacks, and DOM works fine for documents but is terribly slow for trying to make responsive interactive applications. I don't see this changing until (P)NaCl or some other tech comes along with a nice UI toolkit that's designed for applications and not documents.
I've wondered if there could be a scheme where you have an app that in installs say, the sproutcore framework, server, and a minimal web server on a device. Further, use a rendering engine in such a way that you would not have to run it in a full browser. It would look just like an app and you could use it offline. Of course there is a matter of how to make something so crazy secure. Then I suppose the question is why do it at all. Fact of the matter is: I have no idea what I'm talking about. Any input from someone who does know what their talking about?
Brought to you by Carl's Junior.
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?
I develop web apps for the enterprise, and have for well over a decade. In the past few years tools like AJAX and HTML5 have made the user experience much richer, but in general even these weren't needed for web apps to take over the enterprise. Bulky, finicky fat-client apps were always a pain, which was why technologies like 5250 and VT220 were popular so long past their expected life spans. Many many businesses still run back end systems with these interfaces because they are simple to deploy and simple to maintain. Web apps are the best of both, and performance is more than good enough these days. For games, maybe not, but for the enterprise we're already there.
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 been told to just "edit the css to make it flexible" is almost the same as saying "fuck you and the horse I put under you", and a widget system built for it would take care of most things. I suppose for input you'll have to either do a lot of work or hack in some html parts to take care of that.
yeah, logically, the thing is to just go around the dom - it was never intended for application development. if web apps try to be first class apps that's pretty much the way to go... problem with html+css is usually that people who aren't executing things just see some css trick or another and then just want that implemented in something where it just doesn't work by adding two lines of css.
native client & etc are really just about launchers. kind of defeats the purpose as run anywhere for now.
world was created 5 seconds before this post as it is.
Auto-translated code is not going to look anywhere near that nice. For performance, it'll probably look more like ASM.js to work around Javascript's many difficult-to-optimize constructs.
I don't need to download & install a program on to my laptop to bank online.
No, but your bank is convinced that they can make more money if they can get you to install an app, by reinforcing their brand and deploying hooks into you that web apps don't facilitate. And as soon as the possibility of making additional money was hypothesized, collecting that money became their need.
I short, apps are not about you. They are about achieving the goals of the app makers.
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...
Effort for end-user to update their copy of your application: Web app: Have to remember you even exist. Native app: Update reminder.
Competitors in the market: Come on, no way will native applications ever lose to web apps on this category. Native app development is inherently harder, and always will be, reducing competition.
Restrictions on in-app purchases: totally with you on a web app being the most flexible... BUT will they submit payment info with you? Meanwhile on iOS they don't use "real" money to pay you, just iTunes. Which do YOU think is more likely?
I've done in-app kinds of things on the web before and the conversion rate is an order of magnitude worse for web purchases than it is for native.
Chances the end user deletes your application to save storage space on their device: They may - but it also means they saw my apps name again. With a web app you just fade into obscurity, if you are REALLY lucky stuffed into a bookmark folder that no-one looks at for several years.
I'm nto saying there's no point to doing web development, there are lots of things I think belong on the web. But for real "applications" you are glossy over some huge advantages native applications have.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
TLDR; multi platform dev is getting more expensive every year; web tech is getting more powerful every year; this internet thing isn't going anywhere and companies that can put their apps in browsers/webviews and give adequate experiences will do so.
#1 Development in multiple platforms is expensive as hell, businesses that can take advantage of a single codebase written in HTML/Javascript and just executed in webviews on mobile/dev will do so and they will save tons of money. Phonegap, node-webkit, etc are all examples of where this is going.
#2 Web application technologies aren't a one size fit all ordeal. Some apps are easy to make these days, list based apps, etc in javascript on mobile and desktop. Some web applications aren't: graphics, intense amounts of math, sound. But new technologies are coming in to fill the gaps every year, making the proportion of things that can be made in web technology larger and larger.
#3 The biggest limitation to web apps right now isn't technology IMHO, its that people aren't trained how to give a lot of money to their web apps. There's no app store or in-app payment of the web that everyone knows of. Google is trying to change this with the Chrome webstore. People will dump dollars after dollars into Plants v. Zombies 2, but look at giving a dime to a website like it was asking for your first born.
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 never done serious mobile web development.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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 a few talks by Doug Crockford on youtube. Just search for "Crockford JavaScript". Don't assume that you know JS just because you've used it for years!
It really is the worlds most misunderstood language.
Required reading for internet skeptics
Obligatory: Was it ever suitable for serious use?
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, PayPal, and Dwolla charge transaction fees. Apple, Google, Microsoft, OUYA, and the like charge bigger transaction fees.
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.
Assorted stuff I do sometimes: Lemuria.org
Access to input and output components like camera, joystick, and 3D graphics is not guaranteed in a browser. Apple, for example, refuses to open WebGL to anything but iAds. Winner, native.
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.
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 and require manual creation of even those test cases that would be implicit in a language that has even an option for static typing.
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 is lacking.
I don't need to download & install a program on to my laptop to read the news.
In your opinion, should one have to download and install a program to play a video game that isn't turn-based? Safari for iOS doesn't allow web applications to display 3D graphics.
1) The fat arrow indirection pointer is a huge interpeter hole depending on how its implemented 2) Prototypal inheretance (need I say more?) 3) Code reuse in javascript is fake and dumb 4) protoypical behavior in js is very bad, almost as bad as PHP 5) only functions can create scope, making js a not very well implemented OOP language 6) No type security, again, almost as bad as PHP There are more, but I'm bored.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
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.
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.
Brian Fundakowski Feldman
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.
Go to caniuse.com and find a feature that would prove useful to a particular web application. For example, look up camera and microphone access or 3D graphics. As long as a widely used browser (such as IE one version back or Safari for iOS) shows a red box for this feature, you have to build the application separately for each platform in order to avoid loss of business when users get an error message that a particular browser feature is absent.
Agreed, time for a new GUI-friendly and CRUD-friendly browser standard. JS/CSS/DOM fans keep telling us "it's just around the corner", but the corner is still fucked up.
I suspect they keep backing it for job-security reasons: it takes a lot of skill to get a desktop-like feel, and they want to be in demand so that they get big bucks. As long as web GUI's remain a dark art that runs different on every version and vender, a selfish cabal of experts will make excuses to keep things as they are.
Fuck your bucks, I want a decent GUI standard to work with to make useful browser-based tools without breaking the bank; and you greed-bags are standing in the way. Damned be you!
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. (I would also like to note that problems caused by "how its implemented" applies to every feature of every language ever.) I don't think you've thought this through.
Prototypal inheretance (need I say more?)
It's much much more powerful and flexible than class-based inheritance. Class-based inheritance is fundamentally broken. Just one example, the diamond problem simply doesn't exist with prototypical inheritance. If you really want to force yourself to use a broken and inferior model, you can very easily implement "traditional" classes in JavaScript.
I blame the "new" keyword on this bit of absurdity. JavaScript included the new keyword, as far as I can tell, to make the language seem more familiar to people coming from C++ and Java. (A big mistake.) It was just too easy to pretend that objects in JavaScript were like objects in those languages. This lead a lot of people to think that objects in JavaScript were "broken" when in reality they're simpler, more powerful, don't suffer from the same problems as class-ical objects, ... I could go on.
Code reuse in javascript is fake and dumb
This makes absolutely no sense. While it could benefit from a proper module system, code reuse is still significantly simpler in JavaScript than it is in languages like C# and Java. I don't know what you mean by "fake" and "dumb" -- and I suspect that you don't know either.
only functions can create scope, making js a not very well implemented OOP language
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.) I'd ask you what bizarre reasoning brought you to that conclusion, but I suspect that you're just repeating something you heard and haven't actually thought it through yourself.
Required reading for internet skeptics
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.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
it is not designed to help with development of large projects
It is easy with the right framework. I use Ext JS at work. It uses an MVC pattern and provides a fantastic class system. It also comes with with a very full featured collection of widgets and data package. I can understand where you are coming from if you are thinking pure JS or jQuery, but Ext makes my life much much easier.
As far as native support for classes/types, it is coming. ES6 will have classes and ES7 will have guards. As many stated below you can accomplish this today with a transpiler.
I responded to the parent regarding a JS framework named Ext JS. It also handles your concerns. Much of the dom work you would do in a traditional application is completely abstracted by a very robust and full-featured set of widgets. You can build your own components with an HTML template by extending a base class, but almost everything you should want to accomplish is already available as a component. You don't touch HTML/CSS very often. It is very object-oriented and contains a layout system that makes positioning components simple.
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
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 - because Safari actually has lower level access into the system in terms of running a more powerful javascript engine.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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 their end...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
However re-read the admission that native apps get the features first, then if they prove popular, the web standards get support for those.
First, this adds an unavoidable time delay.
Second, what if the feature you love or rely upon, is never deemed "popular"?
Third, how long has this Jo Rabin been around? Have they never seen the standards committees tied up in knots, unable to even agree on what beverages should be served at meetings?
Fourth, ever seen those standards that emerge into the world, all proud and shiny, only to be ignored by the vendors?
The web today is something of a miracle. We've got standards that basically work, and enough agreement and practical support that they get used. Even HTML 5, which looked pretty shaky early on, seems to have finally gained traction. It's good.
That said, don't be a pollyanna. Web standards are slow to emerge and never make everyone happy. Native support will always be better than the web standards that must codify them.
If none of that convinces you. Here are just a small sampling of standards that failed, or never lived up to their potential:
SGML
XHTML
XML (arguable I know)
WS-anything
SOAP
ISDN
SVG
SMIL
Semantic Web (don't get me started)
Now watch the excuses flow! I'll get you started too: But but but... ISDN wasn't a Web standard! Except that it was the first serious, standardized effort at merging voice and data. As such it was a precursor to such things as DSL lines and, had it taken off, might have accelerated high speed internet access 2 decades before that finally happened.
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 someone just loves that sort of thing, but it's a silly waste of time, as far as I'm concerned.
Still, as I pointed out earlier, it's trivial to implement a class-ical system in a language like JavaScript. It would be stupid, of course, but if you want to use a fundamentally broken system like you find in languages like Java and C#, that's your business.
As for the rest, it doesn't appear that you have the necessary background to make further discussion valuable for either of us.
Required reading for internet skeptics
The fact that coffeescript exists and popular libraries like JScript change basic operators speaks volumes.
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?
Lately I have been developing a rendering pipeline and for years I had been oblivious to what has been going on in the mobile world. At a very basic level something running in a sandbox and/or VM still to this day has a hard time dealing with real memory address requests. This! Build a better mousetrap or GTFO. So again we start at the most basic level which is C. Higher level langs like .NET use a combo of interop and IDL to achieve results while the GC has become all important. The reliance on effective GC is the weak point. No one has time to hack on a custom managed stub or wrapper these days either. Perhaps it is time to innovate on the hardware- that's right I said it. Ferinstance what if your cellphone had a reflashable burner phone inside it? It would run essentially in a jail (y'know like BSD jail) with the intention of being rapidly disposed of. Hmm, too many cycles? Not the model of efficiency? We need to progress to the point resources are superfluous and ubiquitous. In order for the marriage of native and web to completely occur we need dedicated hardware for both to run side by side. Those aghast at this idea consider the innovation for the FPU it was dedicated and modular much like this approach. So many other things like this are now in all hardware so where is the dedicated web hardware? For now I will settle for superglueing my mobile device to my desktop because I find myself actually on both at the same time. Glue is no real replacement for an effective thin client but it will have to do until they hash out the licensing.
Web apps are just like native apps except they have to run under a comparability layer called a browser, have to be written in a shitty (for larger projects at least) language, can only do things some standards board has decided on, a decade or two after they became routinely available to native apps, and pretty much require that you have a network connection, at least some of the time, so they can talk to a third party frequently.
You could have all the same "benefits" of a web app with a native app if you just gave your root password to the vendor. All the same data security too.
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.
Ok, so far, so good.
Then tricks were applied (eg- cookies) to break the statelessness, albeit in a limited way.
Cookies don't break statelessness. Every transaction is still defined only by the state provided by the client. Cookies don't "break statelessness" any more than the query string does - anything you do with cookies, you can do with the query string.
Then the prettiness of documents were improved with CSS and liquid design. Things got slow.
Actually, things got faster because CSS let you abstract out a bunch of stuff into a file that was downloaded once, then cached, rather than bloating out your HTML with style instructions on every single page. The thing that "slowed" the web was the increase of rich media - images, sound and now video. But even then, those increases have been outperformed by available bandwidth.
Then the scalability of the server side was improved with various frameworks like JSP, Struts, Rails, etc.
Frameworks generally weren't created to increase scalability; they were created to reduce turn-around time for development. Because frameworks (supposedly, anyway) implement best-practices as part of their base install, it's frequently easier to make them scale than something hacked together entirely in-house, but scalability has been achieved by things like caching systems, load balancers and on-demand virtual machines, not frameworks.
Then JavaScript was extended and made to do all sorts of unsecure things.
Uh, like what? Javascript (or more accurately, the DOM model) doesn't really have that many more features than it had initially. It'd be more accurate to say that as development in javascript accelerated, and people did more complicated things with it, we found new vulnerabilities.
AJAX came along and broke the request/response document retrieval model for good.
How does requesting a document via javascript break the document retrieval model? HTTP doesn't care if you request a document by typing in the URL, clicking a link, or clicking a button that fires off a javascript request. You make the request, you get the document.
Things got slow again, especially on newer mobile platforms.
Things got faster. AJAX means you don't have to reload an entire page for a minor content change. Things were slow on mobile platforms, but that's not because of AJAX, it's because they were (for a long while) underpowered machines connecting along crappy connections. That's not due to any issue with HTTP, HTML, Javascript, CSS or anything - it's purely an infrastructure issue.
Now the w3c wants to figure out how to run fat applications on this platform, ostensibly because it's shared in common across OSes.
What exactly is a "fat" application? And who cares what the W3C are figuring out - people are already running applications on the platform. W3C have, at best, only ever codified existing practice. They've never been the ones pushing the envelope.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
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".
Maybe he does, but he doesn't need any, because those two reasons are more than enough.
Back in the day, the web was a fast, simple, stateless request/response document retrieval system.
You forgot "and useless for anything but looking at plain text documents". On today's web, almost nobody ever looks at a plain text document, so it strikes me as pretty silly to pine for that web.
1) solve the communication issue. Push messaging.
2) solve the background processing problem like background uploading of photos while new content loads.
/securityConcerns
If web pages could ever gain the same access to local disk that say, notepad.exe enjoys, then they would eventually have a shot at dominance.
Apple [...] can't ignore a technology that the other 60% use, no matter what it is.
For the first five versions of iOS, Apple ignored RFC 1867 uploads (<input type="file">) entirely.* Even in iOS 6, it's unavailable for content types other than photos and videos. In iOS 2 through 5, the only way to upload a blob of data from an iPod touch, iPhone, or iPad was through a native application developed on a Mac and approved by Apple.
sooner or later
Herein lies the problem. Apple can ignore a technology for long enough to move the rest of the market away from that technology. Case in point: The iPad led the way in abandoning Adobe Flash. And when the original iPhone came out in 2007, the RFC 1867 upload spec was already nearly twelve years old.
* The fact that iOS has no traditional "file system" isn't entirely relevant. The uploaded data consist of a name and a blob and need not (and for security's sake should not) refer to any local path. The RFC specifies "a file selection mode appropriate for the platform", which on a mobile device might first present a list of applications that can provide blobs of the appropriate content type, as specified by the input's accept= attribute, and then present a list of blobs that the selected application can provide.
This is why web apps will never be as good as or exceed native apps.
Web "standards" are committee driven and as such are prone to in-fighting and lack of universal and consistent adoption of those standards. I mean most browsers just achieved 100% w3c compliancy in the last year or so and none are HTML5 compliant, largely because HTML5 is still not fully ratified and is prone to different interpretations.
So Web apps are always going to be a step or two behind native because the people creating the OS'es also create the toolset and API's to support the OS and they are always lock-in-step with the OS features. If there is a new powerful OS feature that is released on OS X or Android or Windows its going to take years before the web catches up and creates a standard to support it.
That isn't to say that you can't build a good Web App. You may not need the state of the art OS features to create a good web app experience, but web apps will never be on par with native apps because you will never have multiple vendors coming to a quick consensus on what standard featureset a web API should have.
I haven't thought of anything clever to put here, but then again most of you haven't either.