×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Web Apps: the Future of the Internet, Or Forever a Second-Class Citizen?

Soulskill posted about 8 months ago | from the web-apps-aren't-citizens-at-all,-corporations-are dept.

Software 205

An anonymous reader writes "This article takes a look at whether web apps will ever match desktop and mobile apps in terms of performance and usability. Jo Rabin, who's leading the push by web standards body W3C to get web app performance up to scratch, is optimistic web apps will eventually be the default choice for building the majority of commercial and business apps, while the article weighs up just how much web technologies need to be improved before this could happen. Quoting: 'Native apps are generally first to gain access to new platform-specific hardware features — be it navigating using a phone's GPS and accelerometer or taking pictures with a phone's camera. But if a particular hardware feature becomes popular, standards to implement that feature in the browser will always follow, Rabin said. Work is taking place within W3C to standardise APIs for web technologies to access many of the features found on modern smartphones. Ongoing work this year includes setting out a system-level API to allow a web app to manage a device's contacts book, a messaging API for sending and receiving SMS and MMS, new mechanisms for capturing photos and recordings, new event triggers that could handle mouse, pen and touch inputs, a new push API to allow web apps to receive messages in the background, new media queries for responsive web design, an API for exchanging information using NFC and precise control over resource loading times in a web document.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

205 comments

Installed base, day one. (2, Insightful)

noh8rz10 (2716597) | about 8 months ago | (#44584577)

iOS/android app: installed base on day one: 0
web app: installed base on day one: a hundred million +

In what way did that make any sense? (5, Insightful)

SuperKendall (25149) | about 8 months ago | (#44585287)

iOS/android app: installed base on day one: 0
web app: installed base on day one: a hundred million +

What are you getting at here?

Let's say you launch a new website/web app. How is your install base not ALSO zero?

It doesn't matter how many devices CAN run what you have built. What matters is, WILL they...

With either an Android or iOS app, your POTENTIAL install base is in the hundreds of millions. Furthermore, there's a huge increase in the chances of you getting paid for some of that work, which you can use to develop it further. With a web app chances are good you launch it, zero people notice, and you fade into obscurity.

Lastly, compare how many applications there are in the iOS/Android app stores, vs. how many web sites exist. Which has better odds of someone using what you have created?

Re:In what way did that make any sense? (4, Insightful)

DuckDodgers (541817) | about 8 months ago | (#44585433)

There are other reasons to prefer a native application, but I'm not sure your argument is one of them.

Installation period: web app, page download time. native app, application download. Winner, web app.
Approval process before you are in front of potential customers: web app, instant. native app, depends on the whim of the store curator. Winner, web app.
Chances that your app gets removed by a change to the terms of service: web app, zero. native app, depends upon the whim of the store curator. Winner, web app.
Effort for end-user to update their copy of your application to the newest: web app, none. native app, some to none (depending upon preferences set in app store application). Winner, web app.
Competitors in the market: web app, millions. native app, hundreds of thousands, rapidly climbing towards millions. Winner, native app - but only for the moment.
Restrictions on in-app purchases, restrictions in terms of use, requirement that you have to share revenue with mobile OS developer: web app, none. native app, some. Winner, web app.
Effort to make your product available on iOS, Android, Blackberry, Tizen, Windows Phone, Windows Mobile, Firefox OS, Ubuntu Touch: web app, none. native app, none if you use a cross-platform development kit. Winner, none.
Chances the end user deletes your application to save storage space on their device: web app - only if you use offline storage. native app, some. Winner, web app.

Again, I'm not saying web app is clearly the way to go. I'm just saying it has advantages.

Re:In what way did that make any sense? (1)

Anonymous Coward | about 8 months ago | (#44585749)

The OP and you are both obvious fans of webapps, but his single argument and your multiple arguments
are completely irrelevant to the point of this article. They are discussing "performance and usability"

Re:In what way did that make any sense? (1)

DuckDodgers (541817) | about 8 months ago | (#44586317)

I wasn't responding to the original article, I was responding to SuperKendall.

But - maybe this makes me boring - the most common feature I use on my Android phone is bookmarks. I have my movie theater ticket purchase site bookmarked, the local weather site bookmarked, and a few others. I don't use many native apps. So the "performance and usability" advantage of native apps is meaningless to me, the only native app I installed is Firefox browser.

Re:In what way did that make any sense? (3, Informative)

Jason Levine (196982) | about 8 months ago | (#44585757)

Effort for end-user to update their copy of your application to the newest: web app, none. native app, some to none (depending upon preferences set in app store application). Winner, web app.

This alone is a big plus in the web app category. If you discover a big bug/security hole in your app and make a fix, for a native app you need to submit this fix, wait for it to be approved, and then wait for your user base to upgrade. This means that many users will continue to use your buggy/vulnerable app for awhile both putting them at risk and hurting your image.

If you discover a big bug/security hole in your web app, though, and make a fix, it is fixed. Everyone immediately sees the fixed version and (hopefully) will notice how much better it is.

Plus, with a web app, you have one code base across Android, iOS, Blackberry, Windows Phone, etc. One code base means less chance that the port to platform X resulted in a horrible bug and it means that all of your resources can go to making that one code base as good as possible. Which means less bugs/vulnerabilities to fix in the first place.

Re:In what way did that make any sense? (2)

gwstuff (2067112) | about 8 months ago | (#44585619)

The comment was open-ended enough for the following interpretation: consumers are resistant to installing new stuff. They don't like to clutter their mobile device screens with icons, and they unconsciously fear security threats. If you have a web app, you bypass this installation step. Conversely, if you have a native app then just because it's installed doesn't mean people are going to use it. How many apps do you have on your mobile device, and how many do you actually use? The "install base" number is often abused by mobile developers, as they boast about "millions of downloads", to suggest that it corresponds to the number of users. But in practice, the latter is a small fraction. The idea that a "web app is installed on every computer in existence" is an interesting perspective on that practice.

Re:Installed base, day one. (2)

sl4shd0rk (755837) | about 8 months ago | (#44585411)

web app: installed base on day one: a hundred million +

first time someone doesn't have/has crappy network access: install base -= 1

Could Browsers Settled on an Alternate Language? (1)

glennrrr (592457) | about 8 months ago | (#44584605)

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.

Re:Could Browsers Settled on an Alternate Language (1)

gl4ss (559668) | about 8 months ago | (#44584673)

well, you could always go for canvas.

not so sure really if that's an option for mobile browsers though..

Re:Could Browsers Settled on an Alternate Language (1)

gwstuff (2067112) | about 8 months ago | (#44585529)

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.

Re:Could Browsers Settled on an Alternate Language (2, Funny)

kthreadd (1558445) | about 8 months ago | (#44584807)

The primary problem is not JavaScript, but that so few web apps are licensed under AGPLv3+ and thus are not suitable for any kind of serious use.

Re:Could Browsers Settled on an Alternate Language (0)

Anonymous Coward | about 8 months ago | (#44584979)

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.

Re:Could Browsers Settled on an Alternate Language (0)

Anonymous Coward | about 8 months ago | (#44585355)

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.

Re:Could Browsers Settled on an Alternate Language (0)

Anonymous Coward | about 8 months ago | (#44585881)

You're implying that Slashdot is a "web app".
Stop that. It's stupid.

Re:Could Browsers Settled on an Alternate Language (0)

Anonymous Coward | about 8 months ago | (#44584823)

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.

Re:Could Browsers Settled on an Alternate Language (1)

hackula (2596247) | about 8 months ago | (#44585773)

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.

Re:Could Browsers Settled on an Alternate Language (2)

ackthpt (218170) | about 8 months ago | (#44584891)

It seems like some of the problem here is that Javascript is the Lingua Franca, and also that it has to use the web pages DOM. If the system were being designed from scratch, it seems unlikely this would be the choice.

Javascript is a very sloppy language for doing anything in. People, like me, continue to write in it because there's little alternative.

Writing in javascript drives people insane.

sent from my padded cell

Re:Could Browsers Settled on an Alternate Language (1)

interval1066 (668936) | about 8 months ago | (#44584941)

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.

Re:Could Browsers Settled on an Alternate Language (0)

Anonymous Coward | about 8 months ago | (#44584973)

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.

Re:Could Browsers Settled on an Alternate Language (5, Interesting)

ggraham412 (1492023) | about 8 months ago | (#44585295)

It seems like some of the problem here is that Javascript is the Lingua Franca, and also that it has to use the web pages DOM. If the system were being designed from scratch, it seems unlikely this would be the choice.

I think there is a Peter Principle for technology: Every good, proven technology gets extended, extended, and extended until it breaks. Back in the day, the web was a fast, simple, stateless request/response document retrieval system. Then some markup was added to make the documents look pretty. Then CGI and server-side processing were added to make the content more dynamic. Then tricks were applied (eg- cookies) to break the statelessness, albeit in a limited way. Then the prettiness of documents were improved with CSS and liquid design. Things got slow. Then the scalability of the server side was improved with various frameworks like JSP, Struts, Rails, etc. Applets had been tried, but they didn't take off because security and version control turned out to be much bigger problems than anyone realized at the time. Then JavaScript was extended and made to do all sorts of unsecure things. AJAX came along and broke the request/response document retrieval model for good. Things got slow again, especially on newer mobile platforms. Now the w3c wants to figure out how to run fat applications on this platform, ostensibly because it's shared in common across OSes.

Rinse, Repeat. Everything old is new again.

Re:Could Browsers Settled on an Alternate Language (2)

hackula (2596247) | about 8 months ago | (#44585703)

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.

Web app? What's that? (5, Insightful)

Anonymous Coward | about 8 months ago | (#44584637)

Do you mean a website?

Do you mean a website that has been optimized for mobile devices with a small screen and minimal javascript capabilities?

The reason the internet became popular is because of standards. Any web browser can connect to any web site, issue client http requests, and get an http response.

The web browser/web server is the better way to go. I don't need to download & install a program on to my laptop to bank online. I don't need to download & install a program on to my laptop to read the news.

I just just my web browser. It's the better model.

Re:Web app? What's that? (1)

gigaherz (2653757) | about 8 months ago | (#44584733)

I agree, except where the current standards are HTML, CSS, and Javascript, and as much as they try to make them better, as long as they keep backwards compatibility, they will continue to suck in the future, and web apps will continue to suck because of that.

Re:Web app? What's that? (4, Insightful)

Crimey McBiggles (705157) | about 8 months ago | (#44584977)

You know what would really suck? If we decided to drop backwards compatibility simply because what was originally intended as a document sourcing and navigation solution has ended up in the hands of profiteers who want this document-oriented system to be used for 3D rendering. Yeah, HTML/CSS/Javascript can do that, but why use a screwdriver when a jackhammer is more appropriate?

Instead of saying "oh the web sucks because it's old, let's make it new", why not look at what the desktop environment has yet to deliver due to market fragmentation and misguided creative direction? There is much more to the Internet than what traverses ports 80 and 443, and it boggles my mind to think that instead of inventing new protocols and applications (not "apps") to get the job done in a better way - Steam is a great example of this - the popular idea is to say "well everyone has a web browser, let's find new ways to exploit it". It's lazy, uncreative thinking, like standing on the shoulders of giants and then deciding the giants need to be put to sleep because their clothes are no longer fashionable.

Re:Web app? What's that? (2)

i kan reed (749298) | about 8 months ago | (#44585363)

Steam, is, in fact, mostly just a web browser. It has a few other things it can do, like start games, and install things. The vast vast vast vast majority of the interface and design is just a web browser, hitting a web-app the steam devs created.

Re:Web app? What's that? (1)

interval1066 (668936) | about 8 months ago | (#44584949)

I don't need to download & install a program on to my laptop to bank online.

No, you just need to ignore the inherent insecurities that go with using html apps. How nice.

Re:Web app? What's that? (1)

hackula (2596247) | about 8 months ago | (#44585795)

Such as? The web has plenty of security holes, but I can think of pretty much zero that are inherent to HTML and that could not also be present in a desktop app connected to the web.

Re:Web app? What's that? (1)

MightyYar (622222) | about 8 months ago | (#44585041)

When 90% or more of the computers accessing the internet were running Microsoft Windows (and then later almost all running IE), I don't think standards had much to do with web adoption. It was adopted because it was really, really cool. I don't mean it wasn't important at all, but I think standards were just one of many items in the WWW's plus column.

That said, as web-apps become more application-like, the web browser becomes more and more like an unstructured app store. I don't think that web apps will displace native apps so much as the two will converge toward a similar model.

Re:Web app? What's that? (1)

Grishnakh (216268) | about 8 months ago | (#44585203)

It depends on what you're trying to do. For online banking and stuff like that, sure, you don't want to have to download some stupid proprietary application just to do that.

However, what if you're building a custom application for use in a business to manage payroll, or handle sales contacts, or do some other highly specialized business function (that only people in that business would understand the need for)? A lot of people seem to want to make web apps for these things, but there's a lot of problems with that approach, as web apps simply don't offer the performance and functionality that native apps do on a desktop PC/Mac platform.

Re:Web app? What's that? (1)

hackula (2596247) | about 8 months ago | (#44585807)

or handle sales contacts,

Salesforce seems to be pretty popular, flexible, and powerful from where I am sitting. Our sales team switched over a while back and has not looked back.

Re:Web app? What's that? (0)

Anonymous Coward | about 8 months ago | (#44585853)

Why the hell would you care for performance in those cases, when most of those apps are basically "present a table -> fill in the form -> make a request to server -> format server's response" or "search for a record -> fill in updates in the form -> etc."?

Why the hell would it not provide "functionality of native apps" when those are custom apps built by in-house or, at least, specifically contracted developers and there are no "native apps" to compare to in the first place?

Did you ever see apps for highly specialized business functions?

Re:Web app? What's that? (1)

Kjella (173770) | about 8 months ago | (#44585231)

Web apps are the world's biggest inner-platform effect, create an OS-like environment except you're tied to HTML and CSS for rendering and JavaScript and XML (AJAX) as your client-server protocol. Every website tries to reinvent every standard desktop UI component (menus, dialogs, tabs etc.) and poorly I might add. Don't get me wrong, a lot of business and administration applications, online banking and whatnot that only need a standard toolkit are better off as web apps but no, turning everything into a "web app" is a horrible idea.

Re:Web app? What's that? (1)

Flytrap (939609) | about 8 months ago | (#44585381)

Do you mean a website?
:
:

No... He does not mean a web site...
He actually means what he says... a web app[lication] - an application written using the latest web technologies (JavaScript, CSS, DOM and XML/HTML), downloaded from a web site to execute within a browser environment that supports the HTML5 API and standards against which the application has been coded.

A web app is as real an app as any of those that you say you "... don't need to download and install ..." You can even choose to save a web app locally on your phone or desktop (just like any other application that you download off the internet) so that you do not need to download it every time you need to use it - fortunately, web and browser caching technology makes this a non-issue.

Do not confuse a web site with a web application or a web page.
Web pages, however interactive, are not necessarily the equivalent of web applications... however both are downloaded from web sites (technically a web server).

Wrong way around (1)

Anonymous Coward | about 8 months ago | (#44584639)

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.

Re:Wrong way around (1)

interval1066 (668936) | about 8 months ago | (#44584959)

It's the walling of the gardens that's going to do us in.

Userland rejected the walled garden in the late 90's, they'll reject it again.

Re:Wrong way around (0)

Anonymous Coward | about 8 months ago | (#44585305)

And, you won't be allowed access to your local file system.

An enormous security risk (1)

Anonymous Coward | about 8 months ago | (#44584643)

Expose hardware capabilities to the Internet? Didn't we just go through why this was a bad idea with WebGL?

Didn't you get the memo? (0)

0123456 (636235) | about 8 months ago | (#44584649)

Web apps are so, like, 1999. Phone apps are now the future of computing.

Re:Didn't you get the memo? (1)

BaronM (122102) | about 8 months ago | (#44584805)

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.

Re:Didn't you get the memo? (0)

Anonymous Coward | about 8 months ago | (#44585123)

How many people use the gmail web interface instead of the app on their phone or tablet?

To me, gmail is about email. So I use it through IMAP. Well, did. They became fascist about mixing IMAP and tor. Moved my mail elsewhere because of that. Turned out a good move anyway, since they think they can open the mail (well, at least the postcards, the important stuff needs a cryptographic enveloppe), analyze it, and so on, comparing themselves with your secretary when in fact they're the postman.

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 shape of the toolkit isn't, but the fact that we still haven't managed a well-regulated toolkit, is. Something to do with aiming for "intuitive" and "no training needed" and out of necessity focusing on the single entry. When the problem with data entry is the grind of the many, not the coddling the user for entering just the one.

Even now internet isn't always there (1)

Urd.Yggdrasil (1127899) | about 8 months ago | (#44584655)

When more of them can be used offline (when it's easier to make them work offline), then they will be more prominent.

First World Problem (1)

Baby Duck (176251) | about 8 months ago | (#44584661)

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.

Performance, cause Email needs the 3Ds (1)

Bradley Meck (2961599) | about 8 months ago | (#44584697)

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?

Re:Performance, cause Email needs the 3Ds (1)

hackula (2596247) | about 8 months ago | (#44585903)

Not to mention well written js is insanely fast with V8. On some metrics it can actually beat C with both using their respective standard code idioms (of course, C will always be faster with enough optimisation).

GRRRR (2, Interesting)

Anonymous Coward | about 8 months ago | (#44584725)

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).

Browser is an app not an os (0)

Anonymous Coward | about 8 months ago | (#44584739)

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?

Adoption will decide. (1)

intermodal (534361) | about 8 months ago | (#44584743)

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.

Can we please stop reimplementing the wheel? (4, Insightful)

putaro (235078) | about 8 months ago | (#44584831)

From the article: "...today web browsers are capable of supporting sites that are getting close to the look and feel of apps we run directly on our phones and computers."

Great. So with a lot of work we're almost BACK TO WHERE WE WERE! How about some innovation and making better, more usable UI's rather than just trying to catch up with what we already have?

This is the same problem I have with Linux - constantly reimplementing things we already had. At least Linux is replacing closed software with open software. What's your excuse with webapps? Is MS Word in a browser inherently better or just different?

Re:Can we please stop reimplementing the wheel? (1)

xxxJonBoyxxx (565205) | about 8 months ago | (#44584935)

>> Is MS Word in a browser inherently better or just different?

When it's Google Docs vs. MS Word, it's better: 1) I can view or edit it from anywhere and 2) if someone else is working on it with me we can both edit (and see where we're each working) and 3) it's free.

Re:Can we please stop reimplementing the wheel? (0)

Anonymous Coward | about 8 months ago | (#44585045)

You forgot:

      and 4) the NSA keeps a backup.

Re:Can we please stop reimplementing the wheel? (1)

hackula (2596247) | about 8 months ago | (#44585955)

Host your own then. There are some oss google docs replacements out there. Even easier might be an oss dropbox alternative.

Re:Can we please stop reimplementing the wheel? (1)

bad-badtz-maru (119524) | about 8 months ago | (#44585373)

If those are the only two features you need, yes. Otherwise, web Word and Google Docs's featuresets are eclipsed by software packages so old that it isn't even around anymore.

Re:Can we please stop reimplementing the wheel? (1)

Type44Q (1233630) | about 8 months ago | (#44585441)

Is MS Word in a browser inherently better or just different?

For who? For us, not necessarily; for MSFT, probably...

Re:Can we please stop reimplementing the wheel? (1)

DuckDodgers (541817) | about 8 months ago | (#44585553)

The point with webapps is the same as replacing closed source with open source. 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...

If every good native application in the iPhone app store, Google Play store, and Windows App Store has an equivalent web app version, then it's much easier to convince people to ditch their iPhone/Android phone/Windows phone and replace it with something running Firefox OS, Tizen, Ubuntu Touch, WebOS, or whatever. The average person has made it crystal clear that they'll accept a nice garden with walls over a wide open range that's a desert. We have to create an awesome garden outside the walls, and then maybe people will start leaving their walled gardens.

And if the only thing this effort really accomplishes is forcing Apple, Google, and Microsoft to continuously innovate so their walled gardens are constantly a better place to play than the web app world, that's still a tremendous achievement.

short answer (0)

Anonymous Coward | about 8 months ago | (#44584833)

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 (2)

TheSunborn (68004) | about 8 months ago | (#44584879)

Not as long as we have to write them in javascript. javascript might be an ok language, but it is not designed to help with development of large projects. The type system, and the prototype based objects are not good at doing that.

Re:Not as long as we have to write them in javascr (1)

Warbothong (905464) | about 8 months ago | (#44584965)

Many languages now compile to Javascript. Some are specifically designed for this (TypeScript, Dart, Elm), others have gained it later, especially thanks to emscripten.

The DOM can still be a pain, since it's difficult to abstract away. There are those who abandon the DOM altogether, eg. using Canvas or WebGL. That brings its own concerns though (especially accessibility).

Re:Not as long as we have to write them in javascr (1)

bad-badtz-maru (119524) | about 8 months ago | (#44585415)

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.

Re:Not as long as we have to write them in javascr (1)

hackula (2596247) | about 8 months ago | (#44586031)

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.

Re:Not as long as we have to write them in javascr (1)

hackula (2596247) | about 8 months ago | (#44585993)

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.

Re:Not as long as we have to write them in javascr (1)

thelukester (2722207) | about 8 months ago | (#44586285)

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.

To The Metal? (0)

Anonymous Coward | about 8 months ago | (#44584911)

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.

Re:To The Metal? (1)

DuckDodgers (541817) | about 8 months ago | (#44585741)

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 [debian.org] 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.

Re:To The Metal? (1)

aaaaaaargh! (1150173) | about 8 months ago | (#44586513)

Javascript in Google's V8 is never worse than 20 times slower than C and never uses more than 24 times as much memory.

That is really bad performance, though. Think about it: 20 times slower, 20 times higher memory usage... if you'd use this for anything serious, it would bring even the fastest home PC or laptop to its knees. The good news is that nobody really uses web apps for anything serious (except web mail), they are mainly used for wasting time and jerking around. In other words, web apps and native apps are two different classes altogether - different users, different purposes, different markets.

Re:To The Metal? (1)

hackula (2596247) | about 8 months ago | (#44586081)

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.

Well, (0)

Black Parrot (19622) | about 8 months ago | (#44584915)

Web Apps: the Future of the Internet, Or Forever a Second-Class Citizen?

According to Betteridge's Law, the answer is 'no'.

Re:Well, (1)

neminem (561346) | about 8 months ago | (#44585105)

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".

Yay! (0)

Anonymous Coward | about 8 months ago | (#44584927)

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...

"Apps" are not web interfaces (2)

msobkow (48369) | about 8 months ago | (#44584951)

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.

Don't forget stuff like DRM (1)

tlhIngan (30335) | about 8 months ago | (#44584967)

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?

Forever 2nd class due to failure (0)

Anonymous Coward | about 8 months ago | (#44585001)

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.

Decades of crappy Software-Design (1)

Anonymous Coward | about 8 months ago | (#44585003)

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.

Generations... (5, Insightful)

bradley13 (1118935) | about 8 months ago | (#44585009)

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:

  • - 1970: centralized computation (mainframes)
  • - 1980: distributed computation (first PCs)
  • - 1990: centralized computation (Servers and thin clients)
  • - 2000: distributed computation (next generation of PCs)
  • - 2010: centralized computation (Web apps and cloud computing)
  • - 2020: distributed computation (mobile computing)

The pendulum swings back and forth, but you only start to recognize the pattern after you've lived through a couple of cycles. In fact, it seems that by the time one trend has established itself as inevitable, the next (opposite) trend is already well underway. Right now, Web-apps and Cloud computing are the buzzwords, but mobile computing is already well underway for dominance by 2020.

So, if I may answer the question posed in the title: Web Apps: the Future of the Internet?

No.

Re:Generations... (1)

Bucc5062 (856482) | about 8 months ago | (#44585735)

It is nice to see I am not the only one to recognize this pattern. I chuckle at all the market speak buzz words that surround "new" technology, but is in fact, a rehashed version of the same old stuff (I cut my teeth on a smaller cousin around the same time). As I have had to re-invent myself three times over I keep getting asked questions like "what language do your write in?" or "What experience do you have in developing applications?" Really? I've coded in languages I've now forgotten and written more "apps" then I can remember and yet I am asked "What experience do I have...." (sigh).

I sometimes hope the singularity will come soon so I can retire (who needs programmers anymore) and take care of horses. Till then I remain on the marry go round.

couldn't figure out how to vote (4, Insightful)

crtreece (59298) | about 8 months ago | (#44585065)

So I'll post a comment instead, Forever a Second-Class Citizen?

Seriously, to add some content to my snark. Until internet speeds reach parity with access to local resources, web apps will always be second class compared to a similar application running locally.

Re:couldn't figure out how to vote (-1)

Anonymous Coward | about 8 months ago | (#44585239)

this isn't a poll, faggot

you see where the url says /story? that's a tip off. it would say /poll if it was a poll.

fucking niggers can't even read the URL these days i don't know why I even come to slashdot anymore

Re:couldn't figure out how to vote (0)

Anonymous Coward | about 8 months ago | (#44586103)

To be fair, speed is always relative and today's internet speeds (for many) and personal computing device processing power (for most) mean web apps will handily run as fast as they need to and still leave room for more bloat.

Internet speed isn't what makes web apps a second-class citizen, web designers who think they're software developers are what make web apps second-class citizens. And it's a huge mountain to over come.

Be wary of the pitfalls of using web apps (0)

Anonymous Coward | about 8 months ago | (#44585235)

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.

grammar nitpick (1)

jabberw0k (62554) | about 8 months ago | (#44585673)

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.

Re:grammar nitpick (0)

Anonymous Coward | about 8 months ago | (#44586387)

You must be fun at a parties.

Second-Class Citizen? (0)

Anonymous Coward | about 8 months ago | (#44585255)

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.

Re:Second-Class Citizen? (0)

Anonymous Coward | about 8 months ago | (#44585503)

You should probably stop visiting /. then

Firefox OS phones are NOW selling (0)

Anonymous Coward | about 8 months ago | (#44585487)

Right now the Firefox OS phone is on sale at the ZTE Ebay stores in the US and UK:
anywhere in Europe [ebay.co.uk]
and
US and Canada [ebay.com]

For those of us that genuinely want to test webapps on a device designed specifically for them.

Why does this get asked every N months? (4, Informative)

sootman (158191) | about 8 months ago | (#44585495)

The answer will forever be NO, until the bandwidth between me and the server == the bandwidth between my CPU and its main memory. AND latency, AND availability.

The fastest web apps TODAY are still slower than the native apps that shipped on the first iPhone in 2007.

Besides that, both kinds have their own unique advantages. The first two: web apps allow you to get at the data from any device with an Internet connection and browser, but native apps work when you don't have network connectivity at all. If neither of those is a make-it-or-break-it aspect of your app, then you look at all the other advantages each offers, which have been discussed ad nauseum elsewhere.

Re:Why does this get asked every N months? (0)

Anonymous Coward | about 8 months ago | (#44586245)

99% of the time your CPU and main memory are playing solitaire waiting for you to stop picking your nose and press a key. Unless you're typing from home with a TRS-80 and a dial up modem (then your CPU and memory are sweating to the oldies trying to keep up).

Web apps can be fast and latency free, just as native apps can be bloated pigs that take 3 minutes to load. It's just that the bar to make web apps is a billion times lower than it is to write native code. That's a godsend for web designers who can't grow a pair and learn how 'real software' works and crappy web app quality is the result.

But you know, some times 'good enough' really is 'good enough' and most of the time web apps are good enough. Many more times web apps 'could'
be good enough if done right.

Re:Why does this get asked every N months? (1)

aaaaaaargh! (1150173) | about 8 months ago | (#44586551)

It's just that the bar to make web apps is a billion times lower than it is to write native code.

What do you mean by that? It's a hundred times easier and less complicated to make an app in, say, Lazarus or Qt than to create a working web app of any kind.

Pry it from my cold dead hands (1)

Taantric (2587965) | about 8 months ago | (#44585527)

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.

The biggest issue by far: local file/device access (0)

Anonymous Coward | about 8 months ago | (#44585737)

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.

The question (based on RTFA) (1)

gwstuff (2067112) | about 8 months ago | (#44585789)

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.

Do factor in Win-8 (1)

niftymitch (1625721) | about 8 months ago | (#44585819)

Do factor in Windows-8.
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.

Slashdot is a web app (0)

Anonymous Coward | about 8 months ago | (#44585849)

you insensitive clod!

Native apps don't really add much (1)

mc6809e (214243) | about 8 months ago | (#44585867)

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.

Second-Class (1)

wzinc (612701) | about 8 months ago | (#44586237)

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.

What if the server was on the device (2)

wjcofkc (964165) | about 8 months ago | (#44586369)

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?

Turning back the clock (2)

Ronin Developer (67677) | about 8 months ago | (#44586445)

Whether you want to call them web apps, thin clients, or terminal based apps - the premise is the same...the name just changes over time.

Web apps will succeed where users can tolerate the inherent limitations of the basic network-based thin-client app paradigm and are content accepting a limited or common native hardware feature set.

Native apps will succeed where people want the highest possible performance and instant access to the latest native platform features and are willing to sacrifice cross platform capability.

Yes, there are hybrid tools that try to bridge the gap...some are better than others. Still, you lose something in the translation when you try to be a jack of all trades and master of none.

To get the best of both worlds would imply that innovation has to stop until manufacturers all implement feature X into the common hardware feature set and the hooks in the "browser" to access them. And, you will need a persistent storage model that will allow web apps to have the same sort of performance that native apps possess. Only where the native app and web app are storing data on a server will that metric ever be even remotely close to a native, persistent store (unless we have FTL wireless networking).

I recommend advocating web-based apps and/or native apps when they are appropriate to the requirements from both a business and user perspective. Unless you can do that, you are little more than a fanboy for whatever paradigm you have locked yourself into.

Best part of it all? You can make money regardless of which way you to choose to go...Web, Native or Hybrid. That's what it's all about, right?

In the Enterpise? No-brainer (2)

Lost Spirit 67 (3021893) | about 8 months ago | (#44586533)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...