Slashdot Mirror
Ask Slashdot: What's the Future of Desktop Applications?
MrNaz writes: Over the last fifteen years or so, we have seen the dynamic web mature rapidly. The functionality of dynamic web sites has expanded from the mere display of dynamic information to fully fledged applications rivaling the functionality and aesthetics of desktop applications. Google Docs, MS Office 365, and Pixlr Express provide in-browser functionality that, in bygone years, was the preserve of desktop software.
The rapid deployment of high speed internet access, fiber to the home, cable and other last-mile technologies, even in developing nations, means that the problem of needing offline access to functionality is becoming more and more a moot point. It is also rapidly doing away with the problem of lengthy load times for bulky web code.
My question: Is this trend a progression to the ultimate conclusion where the browser becomes the operating system and our physical hardware becomes little more than a web appliance? Or is there an upper limit: will there always be a place where desktop applications are more appropriate than applications delivered in a browser? If so, where does this limit lie? What factors should software vendors take into consideration when deciding whether to build new functionality on the web or into desktop applications?
The rapid deployment of high speed internet access, fiber to the home, cable and other last-mile technologies, even in developing nations, means that the problem of needing offline access to functionality is becoming more and more a moot point. It is also rapidly doing away with the problem of lengthy load times for bulky web code.
My question: Is this trend a progression to the ultimate conclusion where the browser becomes the operating system and our physical hardware becomes little more than a web appliance? Or is there an upper limit: will there always be a place where desktop applications are more appropriate than applications delivered in a browser? If so, where does this limit lie? What factors should software vendors take into consideration when deciding whether to build new functionality on the web or into desktop applications?
In the 80s and 90s. X terminals and the like. Sooner or later the users want their power back. It will be interesting to see what happend this time around.
Time for bed, said Zebedee - boing
There will always be a need for those who want to keep what they are doing private. It's not private if it's not local and even then it may not be private.
The fact that this question gets asked basically every year should more than sufficiently answer the question.
Sorry, in my experience these web based applications are crap, and they started around the .com era where suddenly everybody thought everything belonged on the web.
The "problem of needing offline access" most certainly has not been solved, and not all of us want our data in the cloud.
If the web browser is going to become our operating system, we're fucked -- because we'll all be running garbage code which covers some of the use-cases, but which generally has terrible interfaces as we try to shoehorn every problem into something which doesn't lend itself to the web.
Many of us have lamented the move to web-first technologies as a byproduct of lazy corporations writing mediocre software.
If you think the end of desktop applications is nigh, I sincerely hope you're wrong -- because the endless stream of crap web pages which almost work is getting tedious.
And it mostly ends up in greedy corporations more worried about analytics and advertising, than writing usable software which actually solves the problems.
Lost at C:>. Found at C.
Stuff like this is marketing people's dream: dependence. Though, seen through the eyes of marketing people, they only consider the small select applications they use, but those office applications are only a small part of what people use.
Applications like CAD, Design, Bitmap Editing, 2D vector art applications would run terribly slow over the net.
The things people use to make your stuff would become more expensive as it is starting to happen, and those costs will be passed onto you.
It would be a bad computer world where would could not afford a company to throw the switch, and discontinue your product in one day with no warning.
If there was a disaster or real war (on our soil), no one would be able to work, at all, because there would be concentrated central points of failure.
https://www.youtube.com/c/BrendaEM
Again this bullshit?
- Flawless 24/7 connection to the internet is plain impossible and any application that does not take this into consideration is a piece of shit;
- Your data on a third-party server is always a security problem waiting to happen;
- Browsers cannot provide the exact same features of a native application without the idea of them being completely rethink;
- When a web application has successfully emulate a desktop application it usually costs double or triple in computational resources to do the same thing as a native application;
- HTML is not designed for making desktop GUI applications, it need a ridiculous amount of very ugly hacks do to things that are done easily using native GUIs;
That said, of course there are tasks where a web application is useful... But it is foolish to believe that so any task task can be done in a web application.
Religion: The greatest weapon of mass destruction of all time
I run a company that develops a laboratory informatics platform for data intensive science applications that mix wet lab and analytics operations into single workflows, with gene sequencing as the motivating application - think LIMS with a pipeline and visualization engine, if you're familiar with the space. (Lab7 Systems, if you're curious - http://www.lab7.io/
When we started development a few years ago, we had to make the decision as to whether or not to build a desktop application or a browser-based application. At the time, this wasn't an easy decision. Some aspects of the UI are straightforward form-style interfaces, but others are graphics heavy visualizations of very large data sets (100+ GB in some cases). Scientific and information visualization have almost always benefitted from local graphics contexts and native rendering engines. In addition, the data decomposition tasks often require efficient implementations in compiled languages. Our platform also controls analysis processes on large clusters, another task not well suited for the browser.
We gambled a bit and decided that the browser would be our primary user interface. Two trends at the time helped us make the decision (and luckily they both held steady):
(1) The JavaScript engines in all the major browsers get faster with each new release and now outperform other scripting languages for many tasks.
(2) The JavaScript development community is maturing, with more well-engineered and stable libraries available
As few other considerations helped us make the call:
(1) Our platform is a multi-user system. A desktop client would add to the support burden for our customers.
(2) Our backend needs to integrate with compute clusters, scientific instruments, and large, high-performance file systems. It is server-based, regardless of the client.
(3) The data scales we were dealing with also required "out-of-core" (to use an older term) algorithms for redenering, so the client would never get entire data sets at once.
(4) REST/json... XML, XMLRPC, SOAP, and all the others are a pain to develop for (I speak from experience), REST/json significantly reduced the amount of code we needed to maintain state between the client and server.
Since we made the call to use the browser, we haven't looked back. Early on there were some user interactions that were tricky to implement across all browsers, but today they've all caught up. Our application looks much more like a desktop or (*shudder*) Flash application, with a very rich UI (designed by an actual UX team that gets scientific software ;) ) and complex visualizations. It's also been relatively straight-forward to implement, thanks in large part to the maturity of some JavaScript libraries (we use jQuery, D3 (for complex filtering, but not for visualization), Canvas, Backbone, and a few others).
Personally, I can't imagine ever writing a desktop application again. The browser is just too convenient and, in the last few years, finally powerful enough for most tasks.
-Chris
Please, understand this categorical statement: I DON'T WANT YOUR FUCKING CLOUD SERVICE.
I do not want to rely on an internet connection to generate any trivial document.
I do not want even my meaningless documents stored "in the cloud", much less anything any private or commercial value.
I'm uninterested in making something simple, quick, and reliable into something complicated with more points of failure, slower, and unreliable (that in the meanwhile makes me dependent on you, and paying you for the privilege).
So no, stop asking.
-Styopa
Richard Stallman covered this subject in detail, it is important reading: http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
I am surprised this would even be asked here. The fact is, if you care about security and privacy, you dont want to use anything other than desktop apps. You want to avoid anything such as Google Docs for your normal letter writing and so on. One area of confusion is that people have problems drawing a distinction between which is where you share things that you want other people to see, versus a tax spreadsheet that no one else should see. With the social networking the material is sort of not private anyway and you want to share it so little is lost by putting it on a server farm, and it is necessary that it be shared with others so the server farm facilitates the communications.
With a desktop application where you are working on tax spreadsheets or working on other things that will not be shared, there is no need to put it on a server some place else, so why do it? In so doing you give up a huge amount of potential privacy, increasing the technical possibilities of a possible access of the material on the server farm by other entities.
Using this cloud stuff you lose control of your data. The cloud provider could pull the plug on the service at any time (and it happens, look at Google Code and Geocities and the vast store of information that was lost with that).
Using the cloud for office apps is basically not necessary for what you are doing, since when you are writing a document for local use, or working on spreadsheet data, there is no technical need to use a cloud service to do this, and by doing so you endanger privacy and your control over the data.
Whats really going on here is an attempt for large corporations to nickle and dime you and monetize you, perhaps by the minute, to use their software, while if you use an open source desktop app, you have unlimited use of the software for as long as you need at no charge.
Secondly, open source is all about users being able to control, modify, run and expeiriment with the code they use, and being able to read it. Using apps on a server farm takes away the users control over the software they use, as it does with taking away users control over their data.
Avoid Software as a Service like the plague.
No. And the "trend" referred to here is 99.999999% junkware. Slow junkware. Junkware that typically invades privacy and/or bombards with ads. You can't compete with my image editor. You can't compete with my word processor. You can't even compete with my text editor. You can't compete with my SDR software. You can't compete with my database. You can't compete with my media center. You can't compete with my fish tank controller. You can't guarantee that you, your ISP, my ISP, the connection(s) between them, the name servers, the competition for bandwidth at any one (or more points) will work to my satisfaction. Or at all. You can't even promise the app will BE there (cough, Google, cough) when I need it. Or that it will work properly in my chosen browser. And you're almost *certain* to screw it up so badly that it does all manner of things with rollovers, popping up garbage ads and menus without an instantiating click or drag or keypress from me.
And the other .000001% ??? Minimalist web-apps that never, ever hold a candle to a real app running on your own hardware.
Seriously, even the *speculation* is ridiculous.
I've fallen off your lawn, and I can't get up.