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?
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).
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!
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 here), are still generally done with native applications. I don't see that changing any time soon.
I suppose that lots of data-entry and retrieval line-of-business apps will be web apps by default, but let's face it: those apps sucked on a terminal, sucked as client-server apps, suck as web-apps, and suck as mobile apps. It's not the toolkit that's the problem.
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.
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?
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
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?
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:
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 time. There are times when you want a dedicated hardware box running your embedded system.
They all have their place; it drives me crazy when someone says something is "the future", like everything else will be instantly obsolete, because new thing must be shoehorned into *everything*. Why? Because it's "the future".
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.
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.
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.
Because so much of the world relies on Javascript, the browser vendors are in a performance war and keep upping their investment in Javascript just-in-time compilation. Have a look at this: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc&data=u64 in eight benchmarks, 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's a far cry from the "hundreds (or thousands) of times slower than native code" you state above. And the performance wars are far from over, especially since mobile devices are still resource constrained and people keep trying to do more and more things on mobile.
But the real problem is still that skilled developers are more expensive than throwing more hardware at a problem and using easier tools. If a company could feasible sell tablets and smart phones with a huge collection of cute and creative applications written in C, fortran, and assembly, it would have been done already and that company would have taken the world by storm when it let you run 20 times as many apps each 20 times as fast on smart phones that Android doesn't even support any more. The vendors are already taking the most cost-effective path - put some brilliant minds on improving the hardware, put some brilliant minds on improving the Javascript interpreter / Java Virtual Machine / PHP Hotspot / PyPy / etc... and let the hundreds of thousands of developers not brilliant enough to do either work with easier tools.
I don't see your do-over ever happening.
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.
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.
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.
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.
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?
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.
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.
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
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
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.
In most cases the performance difference is from 3-10x in speed or memory. But even at 20/20, that's better than Python, Perl, Ruby, and PHP, and those languages are used all over the place. Java has great performance when run for a long time because of the optimizations the HotSpot JVM applies to long-running processes, for those it can often match C++ performance speed. But Java even under the best circumstances uses 5-50 times as much memory as C++ for similar applications. Flash is used all over the web and in many downloadable games, and I believe its performance is somewhere in line with Javascript, or worse.
That won't bring a home computer or laptop to its knees for many applications. I wouldn't use Javascript for Call of Duty 5, or a Video Editing program, but for a chat client or a music player, what difference does it make?
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.
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".'
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
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
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?
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.
/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.