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?

Comments

See it before

[amalcolm]

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.

Re:See it before

[jythie]

Probably something similar. Like the 80s and 90s we will probably get another wave of upgraded desktops overtaking the server upgrade cycle, with desktop power and storage jumping ahead and making the shared resources seem constricting and economically inefficient, and then developers (and users) will rediscover how much better things run when utilizing the greater local resources.

We will then get a decade or two of young programmers rediscovering what that 'unhirable' older ones already knew, holding themselves up as visionary geniuses for realizing things that those 'behind the times' client/server developers were 'doing wrong', attracting hype and investment dollars while repeating the same mistakes people made (and learned from) 2 generations ago.

Rinse, lather, repeat.

Re:See it before

[buchner.johannes]

Problem 1)
Open-source desktop applications have is that the feedback loop takes forever. It is difficult to edit a GUI or modify a behaviour immediately. One has to find the (current) code base, compile, make sure one has the right libraries (which may be different to the system versions) and make a local installation.

I would like to see a program/framework/DE/whatever where you can, while you are in an interface, click "edit code" and modify the program on the fly. Sugar/OLPC began implemeonting such functionality for their Python programs. This would drastically speed up make scratching your itches much easier, as well as redistributing your modifications.

All progress comes from having fast feedback loops. Make it easy for users to play around (and exchange modifications).

Problem 2)
Another change I would like to see in Desktop Applications is that one does not have to program any UI logic (creating widgets, connecting events) at all, it just seems to be redundant. Why do we design a UI by writing *text* in 2015?
It should be possible to auto-generate a UI from the type of objects one wants to modify, from the constraints of the best practices in UI design, perhaps with a workflow definition. It's useless to have all this freedom when we always want it the same way (text boxes for text input, checkboxes for booleans, list for lists, buttons for actions) anyways. Why hasn't a library come along that does that. At least glade lets one draw UIs, producing a XML file that can then be loaded and populated by events. More work on making programming UIs trivial please.

Problem 3)
Deployment. It's ridiculous. Today we can easily install python/ruby libraries from git repos, but not programs that will run in user-space?
In fact, perhaps the whole packaging of Linux systems should be different. What if every user was running in a virtual environment where they can install any software they want, with the other users being isolated from those changes. In the days of Docker and KVM that should be quite possible.

Re:See it before

[Grishnakh]

Why do we design a UI by writing *text* in 2015? It should be possible to auto-generate a UI

Um, it is, and this has been possible for quite some time. Lots of IDEs auto-generate code for UIs. Qt's QtCreator comes to mind, and I'm pretty sure MS has had something like this for ages. I'm sure there's several others.

In fact, perhaps the whole packaging of Linux systems should be different. What if every user was running in a virtual environment where they can install any software they want, with the other users being isolated from those changes.

It's been like this for ages. When was the last time you saw a desktop Linux system where more than one person actually used it, and there were multiple accounts on it? Better yet, when was the last time you saw such a system where multiple people were using it simultaneously? Linux, just like any UNIX system, certainly has the capability built-in to have multiple simultaneous users (since it is a multi-user multi-processing time-sharing system), but in practice no one does that much any more because we use PCs now, not shared centralized machines. Servers are a little different of course, but even here people are frequently running VMs these days so they have a full Linux environment to themselves; the big exception I can think of is ultra-cheap shared web hosting, and there the capabilities available to users are limited.

Re:See it before

[Burz]

Anyone who looks back in my posting history will see that I have long, LONG advocated for tackling the UI and packaging paradigms on FOSS desktops because they choke-off interest from the type of creative person who develops apps. (Even worse, they scare away people who would like to experiment and become budding app developers, so those people cut their teeth on OSX or Windows almost as a rule.)

PC tools are supposed to link the user with the power and features of the underlying hardware, making them at least discoverable in the GUI; In other words, there must be lots of vertical integration. Also... the GUI must have a 'gist' or feel consistent because this is a sign of feature-stability in the OS.

What FOSS has is a bunch of developers who tinker with the OS itself (I include the GUI in this, as it rightfully belongs in the category of OS) and assume that anyone who understands how a system works internally can trivially design GUI features... a big, big flaw in what is not so much an articulated belief as an unhealthy attitude. This is part of the subconscious of the FOSS world, and it results in maladies like not being able to describe fixes and workarounds (or just general usage instructions) as GUI snapshots and walkthroughs (almost always, the user will be directed to the CLI); It means even seasoned tech support personnel will struggle to interpret DEs and other UI features they are not very familiar with. Just getting to the point where your cousin or boss can try out your creations is hell.

App developers should have the power to create exceptions for UI features in their *apps* (I said apps, not OS), because that embodies the two things app developers subconsciously look for: power and feature-stability. The default behavior is always the OS way (i.e. ONE way) out of respect for all users in general; If the default behavior/appearance is ten possible ways, then the app developer feels like they are managing chaos instead of power.

My 'remedy' for the FOSS OS problem would be for a distro like Ubuntu to shed its identity as a "Linux distro" because the Linux moniker just confuses people at this point; and to take full control over the UI design so that it conforms more to a single vision (something that is apparently already under way). Pretty much all of the OS except the kernel should be original to the project or forked and, as Google did for a while with Android, Canonical should threaten to fork the kernel if that is necessary to improve the UX.

I'll also point out that Ubuntu has gotten some meta-features that were typically missing from a Linux distro, like a full-blown SDK and extensive whole-system hardware compatibility tests and searchable database. What would remain to be done beyond this is to standardize on a GUI IDE (with capabilities like Xcode) and extend the hardware program to include a certification process (with licensed emblem) that system and peripheral manufacturers can use in a straightforward way.

Also, packaging is a whole other cup of worms, though I personally think emulating OSX app folders would be a good foundation for easily-redistributed apps. This means that an OS repository would have to stop at some well-defined point instead of trying to mash all the apps and OS together along with the kitchen sink.

There will always be a need...

[Endloser]

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.

Re:No

[sribe]

The fact that this question gets asked basically every year should more than sufficiently answer the question.

Exactly.

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.

Oh, bullshit. Millions of people in developed nations (particularly the U.S.) have "broadband" that is a few hundred Kbps, or a couple of Mbps--let's just call it 3 orders of magnitude, or more, slower than a spinning disk. And of course there's an order of magnitude difference, or more, in latency as well. And of course, absolutely nothing about the deployment of high-speed internet access deserves to be called "rapid"! Remember, we were hearing about how the rapid rise in internet access speed was outpacing CPU speed increases and would soon make data transfer times irrelevant in the 1990s!

And that's before we even get to the performance difference between JavaScript DOM manipulation vs compiled C manipulation of native view/control hierarchies. Yes, I've heard about how much faster JavaScript has gotten. I use it. I also use native toolkits. You can show me the micro-benchmarks all day long; doesn't change the fact that a complex UI in JavaScript is vastly slower.

And that's before we even get to the performance difference when dealing with more intense data manipulation.

And that's before we even get to the higher memory usage for a control in the DOM than for a native widget. (Don't believe me--inspect an input element, and tell me how many pointers it holds to objects & prototypes...)

Why we targeted the browser...

[rockmuelle]

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