Cloud Zone is brought to you in partnership with:

A dedicated writing enthusiast who enjoys fishing and camping when not writing some tech stuff. Eugene has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

5 Reasons Why in 5 Years Desktop IDEs Will Be Dead

02.21.2013
| 24644 views |
  • submit to reddit

Yes, this is not a joke! In 5 years, all developers will code in the cloud. Not only will they code there, but also build, test, run, debug and deploy apps in the cloud. This is inevitable, although it does not seem obvious at the moment. Indeed, cloud based IDE projects are only emerging in the market as major players with serious intentions and a clear strategic vision. Yes, it’s impossible to make a 100% forecast on how this market will behave in 1-2 years. The recent trends in the software development industry speak for the need for a more productive way to code. There’s a huge increase in a number of apps developed worldwide, while the number of developers remains pretty much the same. What does it mean? It means that developers have to become more productive. While there are limits for human stamina and productivity, it’s possible to win some time by optimizing code-build-test-run-deploy process. This is exactly where a cloud based IDE comes into play as a serious rival for offline tools. Some of the most obvious advantages of online IDE include:

Increased productivity and easy onboarding. How much time does it take to install and configure environment, VM for testing and running, as well as plugins to deploy a simple Java application? What’s are your most conservative estimates? An hour? Take it up a notch! It’s four hours rough. A clean machine will need Java, Maven (or any other build manager), Tomcat, Eclipse, plugin for your PaaS of choice etc (the instruments have been chosen randomely). Isn't it much for a simple Spring app? Well, a cloud IDE is already configured and ready to start anytime. That's like a car with a driver who never shuts off the engine. A developer can use any machine, running any OS. There’s no need to download and configure environment and look for necessary plugins. Here’s the way to create a simple Spring app in Codenvy and deploy it to CloudFoundry.



Build, test and run in the cloud. A cloud based IDE hosts all necessary services side by side, so that they are immediately available on demand. Projects are built on powerful machines, which will off-load developers’ computers. In simple words, it’s possible to use desktops and laptops having mediocre specs. Builds are faster and do not require much resources (developers can perform other tasks while building projects).

Running and debugging apps in the cloud is another pivotal feature of a good web based IDE. Once the project is built, it’s ready to be run or debugged. Moreover, it’s also possible to update apps within the runtime, for example, by using JRebel plugin. With any changes made to the source code, developers can actually check out these changes in running apps. The same concerns a debugging mode. The app is started on the IDE server, while a developer can play with it by setting breakpoints, inspecting and changing variables, stepping through code, evaluating expressions etc.

Sharing and collaboration. Perhaps, this is one of the number one reasons while cloud based IDEs will move on. In today’s world of social media, it is totally unacceptable to be unable to share a project online. Cloud IDEs go even further. In addition to sharing features (just sending a link to a project is enough for a developer or a team to join a project), there’s a real time collaboration mode. Yes, it means that two developers located in the opposite part of the world can work on the same file or a chunk of code simultaneously. What about chatting right in the editor? That’s is totally possible in a collaboration mode that major cloud IDEs in the market have in their toolboxes (Cloud9 has real time collaboration while Codenvy is planning to release it soon). Have a quick look at social collaboration feature in Codenvy.


Administrative control and compliance. Managers overseeing dev teams (especially when it comes to outsourcing) will definitely appreciate having a simple control and monitoring mechanism to see how much code has been written and prevent leakage of code. Once project, one environment, many  virtual workspaces and one administrative dashboard.

Instead of a conclusion

Sure, web based IDEs currently lack some cornerstone features and capabilities that offline IDEs have, for example, the popular Eclipse. Still, moving at a high speed, cloud IDE projects are getting better and better with every coming day, freeing developers from boring installations and the fuss of setting up dev environment. Cloud IDEs are the future of web development. What do you think?

Published at DZone with permission of its author, Eugene Ivantsov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Chris Travers replied on Thu, 2013/02/21 - 3:24am

 I usually find that predictions of the death of any sort of computing approach tend to be greatly exaggerated, this one included.  I do a fair bit of cloud computing and I find that there are a lot of cases where cloud-based computing applications are not necessarily the best fit for everyone for reasons inherent to the environment.  Building and testing are cases where cloud computing can help a great deal at least when looking at heterogenous deployment patterns (see PostgreSQL's build farm), but there are 5 reasons why locally run apps are still likely to be important in 5 years, and cloud computing doesn't change this.  They include:

1.  I can code on an airplane without either an internet connection or a
whole vm running.

2.  If the internet goes down I can still work

3.  A lot of workloads, such as long-running payment batch processing where existing approaches for cloud computing add needless overhead compared to a thick client connecting to a db.

4.  Cloud computing generally greatly increases the complexity of battery backup and infrastructure backup planning.  If your critical apps are not in the cloud, there are fewer things that can go wrong.

5.  Simplicity is golden.

Now the tradeoffs don't all go one way, and the simple truth is that an expanding market is usually a differentiating market.  As the market for software and software services continues to expand, it will differentiate.  New models will arise but will not extinguish the older models.

Eugene Ivantsov replied on Thu, 2013/02/21 - 4:05am in response to: Chris Travers

Hey, Chris! Thanks for your comment. Yes, I agree that cloud computing is not a nostrum that fixes all problems. Moreover, for certain purposes offline IDEs and tools are still the best.  And yes, a bit of exaggeration does take place ) However,  I do believe in the power of cloud.. It may take longer than 5 years, but eventually all developers will code in the cloud ) I think I will elaborate more on cons of the cloud sometime later. Good luck!

Jeroen Van Dijk replied on Thu, 2013/02/21 - 6:20am

I agree with Chris about exaggerating, but I understand Eugene also uses that word in order to generate readers. I do think 5 years is pretty fast though. For what I know is that e.g. many people still use SVN, eventhough GIT is there for some years now. The same will be true coding in the cloud.

Chris' first reasons about why not are in my opinion not that strong. In 5 years I really think airplanes without internet connection will be less in the air than the ones with built-in wifi. Internet will be more and more free and able to use. As a programmer, I guess we'll be one of the first people using that for work purposes, although I still hope that when I use an airplane, I can just fall asleep and not work... And the Internet will not go down. Too many computers hold it up, being the internet. Maybe a server could, but thé internet? Terrorists will love to, but they can't.

Other reasons I can understand why indeed you don't want to use a cloud, and especially the 4th reason Chris states is a good example. But even more, think about security in general. Proove me wrong, but my experience with most of the security in many companies are just fake, incomplete and based on "good feeling" of not putting it on the world wide web. (But who really did a security test in his company?)

I think for the last 10 years I heard all specialists tell about a thin client computer and putting everything in the cloud will be the future of the PC. I think not much has changed. Yes you can store your contacts and files in a cloud system, but still you're using your own operating system and you're using a thick, obese client. Your laptop is still a beast, and it can work without any connection. I dare to say, considering the last 10 years, this 5 year plan will not occur in this time period.

Greg Brown replied on Thu, 2013/02/21 - 8:35am

I agree that moving services like source control and compilation to the cloud might make sense. However, I'm not sure how many developers would be willing to trade Visual Studio or Eclipse for an HTML-based code editor. I wouldn't. But as long as the UI is as rich and capable as the current generation of developer tools, I don't really care where the "heavy lifting" happens.


Mason Mann replied on Thu, 2013/02/21 - 9:26am

Eugene forgot to read http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

This applies to every cloud service.

- I don't want my intellisense et.al to lag. Latency means lag.

- I want my IDE to work offline, at my cabin, when the ISP is down, etc, etc.

Also, Eugene seems to think that nobody is writing cross platform native apps anymore (no cloud IDE is going to support every combination.)

Yes, it means that two developers located in the opposite part of the world can work on the same file or a chunk of code simultaneously

What? That's what we have github and bitbucket for (heard about merging?). I certainly don't want anyone visually editing the same file as I. Google Wave failed for this reason.

5 years from now, Eugene will make another lame prediction. That's a safe bet.

Jason Pritchard replied on Thu, 2013/02/21 - 9:38am in response to: Mason Mann

Mason nailed it on the native apps thing. You may want to edit this post, and narrow down to 4th+ gen languages (though there are still plenty of reasons why it's not 100% true for those). The nature of lower level and embedded computing makes this unlikely in 5 (or very many more) years. 

Oh and I know this is hard to believe, but some people still develop for the desktop.

Eugene Ivantsov replied on Thu, 2013/02/21 - 9:48am

Yep, I have heard of GitHub and Bitbucket. The abovementioned cloud IDEs work just fine with these services :) The collaboration mode is something different.

John J. Franey replied on Thu, 2013/02/21 - 10:13am

That is backwards.  Cloud based development is going to be dead in 5 years.


1) Security.  Many enterprises will never feel safe with its revenue generating applications and data in control of a third party.  This demands too much trust.  Some are ok with it, but shhould not be extrapolated to mean that every enterprise will trust a third party to this extent.  Consider government or defense agencies, operators of core utilities (water, electric), medical services, financial trading, telecommunications, and then every dick-n-harry enterprise who wants to protect competitive information.  I notice in your ideas above, you left security out of consideration.  If security is not an issue, everyone would be in the cloud right now.  You ignored a big one.

2) Stability of the offered platform (not the availability of the application).  Cloud based services are run by businesses that can fail, sometimes abruptly.  What contingencies are available to customers?  Do they get their data/applications back to their control?  While some web applications created over 5 years ago are still operating, there a many that have shut-down.

3) The benefits above are overstated or not important.

3a) Costs of on-boarding saved by cloud: several hours.  Meh.

3b) Build and test in the cloud.   A cpu in the cloud tops at the same physical limit as any other, so the advantage here, based on the story that a developer has a sub-par desktop, is a mirage.  And let me vent: developing software with a powerful backend and a weak front end is a sweatshop experience, like working in a mill barefoot and without breaks.

3c) Sharing and collaboration.  I've heard of this tight collaboration, in different forms, over the last 25 years and haven't seen it adopted.  Maybe there are enterprises working this way.  What evidence is there that this practice is waiting only for the right cloud based service? If this  really is the main reason to use a cloud based IDE, as you state above, then it is the death of cloud based development: it won't match the development process of many other enterprises.  

3d) Administrative control and compliance.   I'm not a manager, I'm a developer, but while I see this feature as being useful, I haven't seen many managers raise this as necessary.  Also, this control and compliance is not unique to cloud based development services.

Good luck on your new venture.


Xavier Callejas replied on Thu, 2013/02/21 - 1:35pm

 Hi.

Maybe you are thinking in social consumer apps, but in serious enterprise development is another history.

Regards.

Xavier.

Eugene Ivantsov replied on Thu, 2013/02/21 - 2:03pm

5 years is meant more metaphorically. It may take longer or the industry might make an unexpected twist. 2-3 years ago cloud based IDEs looked like student's projects. Now they are much better. It's logical to assume that in future cloud influence will only grow.

Fabrizio Giudici replied on Thu, 2013/02/21 - 2:14pm

I was undecided on the vote on this post, because on one side it's true (but also easy) to predict that the cloud will expand, but on the other hand there are too many exaggerations, so, sorry Eugene, I voted down.

In addition to remarks done by others, I add that it take a few minutes for me to set up a Linux development machine, either with a sample script that downloads and installs everything (in a physical or virtual machine), or a Vagrant setup (in a virtual machine). Indeed, the bottleneck here is the network speed to download stuff. And if the network is not super-fast, bye bye developing in the cloud.

I'd only add that saying that in the foreseeable future the cloud will expand doesn't mean that the trend will continue forever. The first massive security problem - that is just waiting to happen - could dramatically change things.

Lund Wolfe replied on Sat, 2013/02/23 - 3:08am

I already have to do all of my connected development work by remoting in to a VM, which is a joke.  This sounds like 4GL, as someone mentioned.  You just need to know one tool.

You are trading client developer power for server deploy speed and standardization.  You are trading a rich IDE for a browser based app.  There is a place for dumbed down development and dumbed down developers, but it won't work everywhere for everyone.

With ever cheaper memory and processing power on client devices and faster internet access we could move in the opposite direction with more powerful client applications for developers and users and higher user expectations.

Chris Travers replied on Sat, 2013/02/23 - 4:45am

 Actually the point about git is interesting because if you think about it, svn -> git is actually a way of moving a lot of stuff away from the cloud.  With svn your repository exists in the cloud and you maintain a local copy.  With git, your repository exists on your own machine and you exchange changesets with everyone else over the cloud (you may also have a copy in the cloud but you don't work off it).

Also a note on security.  The fact is that security involves two things:  Managing exposure/footprint and containing damage.   Cloud computing is a game changer in both of these areas, and not in a good way.  It doesn't have to pose insurmountable problems but there are problems and one has to accept that they exist.  I am in the process of starting Efficito (our web site is entirely under construction at the moment, please do not read anything into the current state, as it's just there for people we can walk through right now while we build something better) tries to address both of these.  Our solutions I think both highlight the problems that occur with cloud computing and also discuss why security is more difficult in these cases.

The first problem is that cloud computing services fundamentally have more security exposure, even in an ideal setup, when compared to self-hosted solutions.  We attempt to address this by offering, for our vm-based hosting solutions, firewalling to limit access to whatever locations a customer wants.  The software does not need to be generally web accessible, and we can support vpn interfaces as well.  This brings down the additional exposure to the point where it may actually be lower than what a small business might be able to do on their own, but it still means someone outside their business has to have access (us), and that does change the security considerations significantly.

The second problem is damage containment.  If someone were to hack a general multi-tenanted application, the question is how much data they could compromise.  Many, many cloud applications here have real problems here.  This means that you have more brittle security combined with a larger level of security exposure.  This is not a security win.  We have an approach which says that if you want extra security, get a VM and we'll help you lock it down.  We pay close attention to questions of backups and the like (backups are encrypted).  A great deal of attention is spent on security but the fact is there are more options to secure on an internal network than on the cloud and so the only way it can be a security win is if the cloud hosting provider is significantly better at security than your inhouse team.

Again, at the end of the day I think cloud computing will continue to expand.  I don't think it will expand at the expense of desktop applications as much as some might think.

Fabrizio Giudici replied on Sat, 2013/02/23 - 6:31am

"Actually the point about git is interesting because if you think about it, svn -> git is actually a way of moving a lot of stuff away from the cloud.  With svn your repository exists in the cloud and you maintain a local copy.  With git, your repository exists on your own machine and you exchange changesets with everyone else over the cloud (you may also have a copy in the cloud but you don't work off it)."

I disagree and the problem is that the word "cloud" is contrived and means everything, so it probably means different things to us. For instance, the experience cited by Lund just the comment above is not cloud - if you just have a dummy client connected to a remote VM, this is client-server. Perhaps the server is immersed in a cloud and this delivers high availability, scalability and lower cost of ownership, but I say that if I'm working with a dummy client I don't enjoy a cloud. My local node should be an equal peer on the cloud: why should it be just a dummy client?

A cloud to me is extreme peer-to-peer, where every piece of stuff stays in the optimized place, to maximize the user experience. Thus to me Git/Mercurial are the best example of cloud, because I enjoy data replication and backup on the remote notes, sharing offered by the remote notes, but at the same time maximum working speed because I have also thing locally - and I still can work in disconnected mode, which is something that will never go away, even though many cloud advocates keep saying the opposite.

There's a fundamental principle of engineering that most same to have forgotten, which says that things must be designed in the simplest possible way and avoid waste of resources, and being forced to always operate remotely contradicts this principle.

Security on the cloud is just a nightmare.

Raging Infernoz replied on Sat, 2013/02/23 - 8:15pm

I have some specific issues, and many of my other issues have been already covered e.g. security, latency, availability etc.:

  1. I really don't want management looking over my shoulder, it is rude, overbearing, and invasion of privacy, and will be destructive if management try to micro manage work in-progress.
  2. I bet there is no facility for flexible multi-screen.  Single screen development is so 20th century.  A poor spec. machine won't do multi-screen well, if at all, and will probably have poor rendering, especially on AJAX or HTML5 heavy sites.
  3. It is a fantasy to think that every IDE environment can be the same; some work can require changes to the environment, which you don't want replicated yet, or ever.
  4. Licensing of servers may become a costly headache, if the scoping changes.
  5. If the WAN link or Cloud service becomes compromised, or Cloud storage is not properly recycled or retired; kiss goodbye to source and resource security.
  6. What happens when your business shrinks and you can no longer justify the Cloud rental? Oh dear, you suddenly have the cost of bringing all the resource back in-house, if you can afford it!  This sounds rather like the ironic trend for in-sourcing.

John J. Franey replied on Sun, 2013/02/24 - 11:13am in response to: Fabrizio Giudici

I remember first seeing a 'cloud' many years ago (before it became a common marketing term) in an architecture diagram.  It was used to represent the network between the components of the architecture.  The internals to the 'cloud' was not important.  The internals of the network cloud (protocols, addresses, configuration, bandwidth, connections, administration, security....) were all tucked away, or abstracted, away from the salient ideas expressed in the diagram.   This is one understanding of 'cloud' that I have.

Another image is the physical cloud in natural setting.  It hangs above us, occluding the blue sky, and its contents are mistery (pun intended).  From where I sit, on the ground, I have no idea what is inside.  I can imagine pilots fly into it without knowing what is inside either.

My software cannot connect to such a thing. My software uses a socket library, specifies an ip address, and if a failure is not returned by the connect request, sends and receives data on that socket.  The physical problems of making this work is not misty neither is the mechanism vague.

Today, I think 'cloud' must be a salesman's dream.  It is abstraction that solves all problems.  The salesperson can avoid or isolate all these messy, dirty details that can scuttle a sale.  The sales person can draw a cloud in the customer's IT solution, stand there with a straight face, without risking any credibility and say: "Miracle happens here."

That is complete nonsense, in my mind.

Michael Kimsal replied on Sun, 2013/02/24 - 1:52pm

Big reason why it'll never be dead is security/proprietariness.  There will always be some industries where the source code being developed and hosted outside 'in the cloud' someplace will not be an option - I'm thinking defense stuff for one.  Financial and other government stuff might be another.

Benjamin Mestrallet replied on Tue, 2013/02/26 - 5:28pm

Some news on Codenvy: 

Codenvy Raises $9M For Developer Platform To Code, Build And Test Apps 

There are obviously some believers and visionaries ...

Cho Hyun Jong replied on Wed, 2013/02/27 - 6:04am

Tadpole for DB Tool is a very easy to use SQL Client which allows users to connect and query various relational and non-relational databases right in a Web browser. No installation is required. Simply download Tadpole for Windows/Linux/Mac from its Github project, extract and launch it. Done! No special Web server or configuration is required. Most interesting of its features is that its ability to create or generate Entity-Relationship Diagrams. 

Support DB is  MySQL(MariaDB), PostgreSQL, Cubrid, Oracle, MSSQL, MongoDB.


see : https://github.com/hangum/TadpoleForDBTools/wiki

Gonzalo Arrivi replied on Wed, 2013/02/27 - 9:16am

I think it's an interesting article and you have some nice points, but as I have always said, future is uncertain and the only thing we can do is to try to be prepared for whatever comes.

My brain says that there are many really good reasons (actually mentioned in a lot of other comments here) to think that there is no way local IDEs could be abandoned, but my instinct says that something along your line it's not so impossible, and stranger things happened under the sun.

I'm voting up your post only because it's interesting, made us think (and talk, and argue, and...) and you have had a really open mind (and cold blood) with every reply posted back to you, no matter how offensive has been.

Keep on. I'll keep reading and commenting.

A Johny replied on Wed, 2013/02/27 - 9:17am

in 10 years human developers will be dead,robotic coders replaces them:D

Daniel Sobral replied on Wed, 2013/02/27 - 3:33pm

You start out by saying desktop IDEs are going to be dead in five years. That seems a perfectly defensible position, whether it pans out or not. But then you end by saying cloud IDEs are the future of web development... wait a second, what about all the rest?

Henri Gomez replied on Thu, 2013/02/28 - 5:04pm

 Even equiped with latest generation crystal ball, it's hard to predict Deskop IDE death in 5 years.

There is still developers using vi and emacs, venerables editors of 40y. And still applications requiring COBOL, PL1, ASM, C, C++, Make/autoconf.

Regarding IDE move to Cloud, following infrastructure, I found really interesting to see this "Back to the Future", good old day with PDP11, VT100, everything was hosted on mainframes, from dev to run environment.

I strongly think there will be 2 worlds, on-premise apps and desktop devs and cloud based and integrated solutions, question is how this ratio will be in 5 and 10y.

Guido Scalise replied on Fri, 2013/03/01 - 6:55am in response to: A Johny

Someone will have to code and mantain those robotic coders, right? RIGHT?

John Luce replied on Fri, 2013/03/01 - 11:34am

 As someone who works in small companies, the issue is that when you want to no longer use the cloud based tools, my assets will be returned to me, possibly having used a set of tools that are advanced from what I have. I would then have to pay for a complete set of new tools doubling the cost of what I paid for the online tools.


As an example, Adobe Creative Suite Cloud ... Dreamweaver, Fireworks, etc...


I also do not want to have my assets in a third party's hands.


This all might work for large corporations that control the tool sets and own the cloud storage but really had more downside than upside for smaller companies..

Michael Je replied on Fri, 2013/04/05 - 7:45am

 This all might work for large corporations that control the tool sets and own the cloud storage but really had more downside than upside for smaller companies..

Babul-ilm

Allan Rich replied on Thu, 2014/05/29 - 12:32pm

 Some of us will still be more comfortable working on a desktop computer. I've recently got mine on http://www.perfdata.com/ and I intend to use it for years before switching to another device. Working on a desktop is making me feel more inspired about my work.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.