Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Software The Internet

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

Posted by Soulskill
from the web-apps-aren't-citizens-at-all,-corporations-are dept.
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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • iOS/android app: installed base on day one: 0
    web app: installed base on day one: a hundred million +
    • by SuperKendall (25149) on Friday August 16, 2013 @12:29PM (#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?

      • 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.
        • by Jason Levine (196982) on Friday August 16, 2013 @01:11PM (#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.

          • If you discover a big bug/security hole in your web app, though, and make a fix, it is fixed

            And if you are hacked, EVERYONE of your users is hacked also, instantly. There is some value even in the small buffer an Android app store deployment provides.

            And if your web server goes down ALL of your users are down. A native app can keep on trucking and upload updates to you later.

            Plus, with a web app, you have one code base across Android, iOS, Blackberry, Windows Phone, etc.

            Holy cow is THAT wrong. You have n

          • Sounds awesome. Start up your browser one day, stupid web app got updated and now some feature you use doesn't work. Awesome.

            For example, when I was writing my thesis MS updated Office. Except my reference manager wouldn't work with the updated Office. What did I do? I didn't update Office

            Winner: native app.

        • Installation period: web app, PER page download time. native app, application download. Winner, NATIVE app. O(1) vs O(n)...

          Approval process: Yes there absolutely a web app is more flexible. So much more flexible that if your site is hacked everyone gets the corrupted version instantly.

          Chances that your app gets removed: Since I've never had it happen in scores of native apps I've worked on, I would say the chances of that are really low outside of certain categories, that I don't develop for anyway...

          Ef

          • by tepples (727027)

            Installation period: web app, PER page download time. native app, application download.

            For one thing, this applies only if your web application uses a "page" model, not an AJAX model. For another, most of a web application should stay cached for weeks on end.

            Approval process: Yes there absolutely a web app is more flexible. So much more flexible that if your site is hacked everyone gets the corrupted version instantly.

            The same thing can happen if your native application's version control server or backup server gets hacked.

            Meanwhile on iOS they don't use "real" money to pay you, just iTunes.

            If iTunes isn't real money, then why is PayPal real money?

            • For one thing, this applies only if your web application uses a "page" model, not an AJAX model.

              No, then it's even worse, because you are not obviously going to a new page, but you get the same annoying delay as if you had...

              The same thing can happen if your native application's version control server or backup server gets hacked.

              Come on. It would have to be hacked, then a change made with no-one noticing, then it would have to go out to the app store in an update. It's farcically far-fetched and even if i

            • If iTunes isn't real money, then why is PayPal real money?

              I regularly get iTunes gift cards at a discount off face value, so do lots of people.

              Meanwhile whoever gets discounts off the money they send through PayPal? I think there's on introductory credit for getting a PayPal VISA, and that is it.

              That's why I say iTunes is less like "real" money to people, because you can load it up at a lesser expense than using real money.

              But none of that affects the application developer, they get the same amount on thei

        • by epyT-R (613989)

          1. installation doesnt take much time at all. compared with the value of having direct access control of critical tools, this is a non issue.

          2. most software is downloaded anyway. web or desktop, the site sells the application to the user. it's a wash.

          3. webapps change their tos and featuresets all the damn time! at least with desktop applications, the user has the option of keeping the old binaries around (license be damned!) if they suit his purpose better than the less functional, more invasive current

        • Access to 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.
        • by murdocj (543661)

          Smoothness and responsiveness of application: web app, varies from ok to painful in jerky steps, depending on the Internet "weather", the load on the servers, etc. Native app usually be far faster and always smoother.

          Chance that app will disappear forever: web app, may disappear any time the supplier isn't making enough $$$. Native app, it's on your machine indefinitely.

        • 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?

      • by gwstuff (2067112)

        The comment was open-ended enough for the following interpretation: consumers are resistant to installing new stuff. They don't like to clutter their mobile device screens with icons, and they unconsciously fear security threats. If you have a web app, you bypass this installation step. Conversely, if you have a native app then just because it's installed doesn't mean people are going to use it. How many apps do you have on your mobile device, and how many do you actually use? The "install base" number is o

        • If you have a web app, you bypass this installation step.

          I would argue this is absolutely not the case.

          Security threats come MORE from the web than native application installs. So people are leery of clicking on links.

          The idea that a "web app is installed on every computer in existence" is an interesting perspective on that practice.

          If by "interesting" you mean "utter bullshit", then yes, that idea is "interesting". It means nothing until people run it. A native application downloaded is very likely to h

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

    • by sl4shd0rk (755837)

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

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

    • This must be a new definition of the word "installed" of which I have previously been unaware.
  • 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.
    • by gl4ss (559668)

      well, you could always go for canvas.

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

    • Re: (Score:3, Funny)

      by kthreadd (1558445)

      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.

    • by ackthpt (218170)

      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

      • 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.
        • by narcc (412956)

          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

          • Do you have any complaints about it that don't boil down to "I hate dynamic languages"

            Why should such boiling down be shameful? Fully dynamically typed languages impose substantial runtime overhead [slashdot.org] and require manual creation of even those test cases that would be implicit in a language that has even an option for static typing.

          • 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.
            • by narcc (412956)

              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

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

                • by narcc (412956)

                  I want broken classes??? How did you get that out of what I said?

                  Class-based systems are fundamentally broken. We've known this since the 1980's. Get with the time, man!

                  Your off your rocker pal. Protoypal inheretance my have its uses but it IS NOT OOP.

                  No surprise there. You'll find that there's no consensus on what "OOP" actually is or entails. It's an ill-defined and incoherent concept. It's funny, you'll find that there's a lot of disagreement even about what languages are and are not "object oriented" -- which includes languages like Java and C++. If you want to have an "x is not OOP" argument, you can have it with someone else. I'm sure someo

    • by ggraham412 (1492023) on Friday August 16, 2013 @12:30PM (#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.

    • by hackula (2596247)
      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
    • 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.

  • by Anonymous Coward on Friday August 16, 2013 @11:26AM (#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.

    • by gigaherz (2653757)
      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.
      • by Crimey McBiggles (705157) on Friday August 16, 2013 @11:58AM (#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.

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

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

      • by hackula (2596247)
        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.
        • Fishing and man -in-the-middle attacks are quite common w/html, I'm surprised you haven't heard of them.
    • by MightyYar (622222)

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

      That said, as web-apps become more application-like, the web browser becomes more and more like an unstructured app store. I don't think that web apps will dis

    • by Grishnakh (216268)

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

      However, what if you're building a custom application for use in a business to manage payroll, or handle sales contacts, or do some other highly specialized business function (that only people in that business would understand the need for)? A lot of people seem to want to make web apps for these things, but there's a lot of problems w

      • by hackula (2596247)

        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.

    • by Kjella (173770)

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

    • by Flytrap (939609)

      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

    • 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

    • I agree, except when they can make rational use of things like GPS, wifi, etc. to be more useful than they could be as a web app only.

      It has to be conceded that this exists.  I only install apps where this is so.  More often it is pointless, as you say.
  • 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.
  • GRRRR (Score:2, Interesting)

    by Anonymous Coward

    GRRR, this is STUPID!

    This drives me mad. Webapps have pushed usability a good 20 years back.

    Look at all the pb in desktop apps: we still don't have it "right", and now, there is an increasing tendency towards webapps that have even worse choice of widgets, and don't respect many usability issues that desktop had barely started solving... And don't get me started on the browsers compatibility issues!

    This is CRAZY! People are building GUI inside a medium that has never been designed for that, using always mor

  • by putaro (235078) on Friday August 16, 2013 @11:42AM (#44584831) Journal

    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?

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

    • by Type44Q (1233630)

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

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

    • 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/Windo
      • If every good native application in the iPhone app store, Google Play store, and Windows App Store has an equivalent web app version

        With WebGL disabled in Safari for iOS, good luck replacing every good native game with a good web application. And good luck being able to use a device's camera to take a picture in a web application.

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

    • by s122604 (1018036)
      No, we can't stop

      And that's actually a good thing. There are so many inherent advantages to web-based applications from a maintenance and overhead perspective, that businesses, large and small, are going to push more applications to them.

      Mobile apps exist because the capabilities of the hardware got so far out in front of browser software that a decent experience couldn't be provided. But, back to point 1, as the capabilities of browser based software inevitably improves, a lot of this development is g
  • Not as long as we have to write them in javascript. 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.

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

    • by hackula (2596247)
      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.
  • by msobkow (48369) on Friday August 16, 2013 @11:53AM (#44584951) Homepage Journal

    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.

    • One of the worst culprits for this is trying to implement drop down choice boxes that adapt their contents to previously selected data, such as country-state interactions. The only way I know of to do that with a web interface is to refresh the whole page, which is obscenely slow compared to the repopulation of the choice box data itself done by a custom interface.

      Then you don't really have much of a grasp on web development. It is trivial to create controls that update themselves with content based on a previous selection without round-tripping to the webserver - you just have to send the complete set of data with the initial pageload, and just operate on it - which, incidentally, is exactly the same way a native application does it: when you install a native application, it needs to either copy the entire dataset it's working on onto your local machine, or retrieve

  • Web apps are great. But then you get the W3C to try stuff a little bit controversial like DRM and everyone wants a "free web" and "they should make an app!".

    And then get surprised when developers do.

    The iTunes store is probably the best example of this - it's basically a few web pages strung together but which really wants to get you into iTunes. (Honestly - is it even possible to use iTunes preview? The only way I've seen it was through Google).

    The reality is, we're going to have to have some long and very

  • Generations... (Score:5, Insightful)

    by bradley13 (1118935) on Friday August 16, 2013 @12:00PM (#44585009) Homepage

    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.

    • by Bucc5062 (856482)

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

    • by Shompol (1690084)
      Most of these "cycles" overlapped and different waves existed simultaneously for different purposes. From today's perspective:

      - 2010: centralized computation (Web apps and cloud computing)

      Most computation tasks are performed locally. Only centralized tasks are the ones where functionality requires this approach, i.e. posting on Slashdot, checking bank account balance, etc -- you cannot perform these locally.

      - 2020: distributed computation (mobile computing)

      New pocket computers will eclipse today's PCs in almost every aspect (almost happened already), yet nothing will change in terms of paradigm: tasks that can be per

    • by Darinbob (1142669)

      I've seen this happen a lot. I see it as a tug of war between users and IT/IS management. You start with centralized computing and then the users have a valid need to have locally controlled management of their own resources, so they buy minicomputers owned and operated by their departments. Then the centralized priesthood steps in to say "we can handle that tedious work for you if you put your computers under our control", and the overworked departments agree.

      Workstations -- the priesthood controls acce

  • by crtreece (59298) on Friday August 16, 2013 @12:09PM (#44585065) Homepage
    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.

    • by Darinbob (1142669)

      Are they talking about extremely remote internet web apps (google docs), or instead local web apps that only go to the back office so that connectivity is fast and robust and secure?

  • by sootman (158191) on Friday August 16, 2013 @12:48PM (#44585495) Homepage Journal

    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.

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

  • 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

  • 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.
  • by wjcofkc (964165) on Friday August 16, 2013 @02:07PM (#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?
  • by Ronin Developer (67677) on Friday August 16, 2013 @02:11PM (#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?

  • 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
  • by Tom (822)

    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.

If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy.

Working...