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.
Office 365 is a poor example. The web interface has definitely come a long way, but any serious work falls over. Maybe they'll get there, but for now, local apps integrated with the cloud backend seem to work better.
Write now I definitely wouldn't want to try working with RAW photos from a DSLR or edit high bitrate 4K video using a web app. Maybe in ten years, but then again, those digital formats will probably have moved on to another level by then too.
Oh and email: there's still definitely a need for offline access. Be it a tradition MUA or when on a mobile phone. Online isn't online enough even for this.
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...)
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
Gamers will attest to running game logic server side not working for certain types of games because latency is too high. Going forward augmented reality and virtual reality have even lower latency requirement. With some latency requirements getting under 5 ms the actual physics (speed of light) starts to prevent everything from running remotely.
Perhaps even more important is the further you send bits the more power it consumes. Bits in registers use the least power. Bits in cache are still low power. Bits in memory start to consume lots of power. Going all the way out to flash is really getting bad. Then going over a network -- forget about it. Very roughly speaking each one of those steps is an order of magnitude more power today. The power consumption over a network will certainly be reduced in the future. However, it will be a long time before we get to the point where high bandwidth consumption over a network is low enough power that there won't be important cases you want to optimize by bringing data frequently used data locally and have some significant processing of it.
You can show me the micro-benchmarks all day long; doesn't change the fact that a complex UI in JavaScript is vastly slower.
You're conflating JavaScript and DOM. With FTL, JavaScriptCore can run C code compiled via Emscriptem to JavaScript at around 60% of the speed of the same C code compiled directly. That's not a huge overhead (40% is a generation old CPU, or a C compiler from 5 years earlier). Transitions from JavaScript (or PNaCl compiled code) to the DOM, however, are very expensive. This is why a lot of web apps just grab a canvas or WebGL context and do all of their rendering inside that, rather than manipulating the DOM. Optimising the DOM interactions without sacrificing security is quite a difficult problem.
I am TheRaven on Soylent News