I know a lot won't agree, but seriously Cloud IDEs can be very useful. Especially If you are a Web Developer, so if HTML, Node, PHP is you thing I would definitely recommend try them out.
Of course I am biased as I am the cofounder of Codeanywhere.com which is a Cloud IDE its self.
But just to make a point we actually built all of Codeanywhere inside Codeanywhere. Welcome any comments...good or bad :)
Being cloud based is this "Code Anywhere", or "Code anywhere where you have Internet access"? The latter, in my case, would be "Code in less places than you could with your laptop and standard offline dev tools."
As Yoda would say, that is why you fail. I've spent entire months traveling with a laptop through places with no internet access. I've planned entire trips around the idea.
Coding from a hammock on a tropical beach with nothing more exotic than a generator running for a few hours in the evening to keep the lights on and the beers cool in the bar (and your battery topped up). Sailing in remote parts of the Caribbean, with a little wind turbine on the boat to charge your machine (and again keep the beer cold). Hell, even trying to work from a coffee shop in England with their quaint idea of "internet" and "wifi" even in 2015.
Your laptop weighs three pounds. Take it someplace nicer than your living room!
I travelled in a motorhome full-time for four years and have returned to that lifestyle again recently. But, I still rarely write code when disconnected. I don't know how to code without the internet to answer questions, show me API examples, etc., anymore.
I'm so much less productive when I try to work without internet, that I don't try. I can read, write, play games, or get off the computer and get my head right for work, during that downtime, but the idea of writing code without internet just doesn't appeal to me. We are beyond that point in terms of software complexity. Building things of value is no longer simple enough to do all on your own, a lone coder in the woods (or on the beach or on a boat).
I'm curious how many of the things you've suggested are activities you've actually done while writing code? Sounds like a Corona commercial...not really a software engineering story.
Sorry if I wasn't clear that those were all real world examples from personal experience.
Arusi, Columbia (a tiny fishing village a 2 hour launch from the nearest town where you can get an overnight boat to a city connected to the rest of the country by a road), Tonsai Beach, Thailand, back before they had power or internet. And a couple months sailing in the San Blas islands off Panama. Parks, campsites and random comfortable boulders in the forest are pretty regular worksites, even building real shipping products with paying customers.
Even the dreaded English Coffee Shop really happened (I live there half the time and have a hard enough time getting BT to deliver internet to my house with any reliability).
I find that a good IDE removes pretty much all the Googling from my life. I know what you mean though, having written my share of Ruby and Python, where you're constantly on Google trying to remind yourself what order to pass parameters to File.Open(), and completely aswim with a 3rd party API. But Intellisense knows everything there is to know about C#, Javascript, CSS, etc. and will either tell me about it or just finish writing my line of code for me with a quick key chord.
I tend not to rely on 3rd party code for simple things I can write myself, so I don't spend as much time Googling React or Angular into submission as your average modern dev. For genuine 3rd party APIs like AWS or Stripe, you're right. It's hard to test that stuff until you're back online. They all have libraries though, and again the IDE has your back as far as implementation is concerned.
1) Airplane?
2) On the road traveling in a far country where 4G(or any data) is still too expensive?
3) Train from Amsterdam -> Paris, worst data ever.
4) etc..
Would a Offline/Cache mode solve this? Most places now (including planes) have Internet, it can be spotty, but I mean a lot of Browser based apps today continue working even if you're not online and then sync everything you have done once Internet is back. In these situation you won't even notice if your link drops here or there.
I am still not sure what problem this is trying to solve. I can imagine that for beginners, not having to set up a development environment is an advantage of a web app.
But setting up JDK and IntelliJ|Eclipse|NetBeans typically takes five or ten minutes. After that you can use your environment everywhere and have a native experience (as far as native is possible using Java ;)).
It will be fast with or without internet, it will continue to work as-is when the company creating the IDE goes under or decides to double prices, I can use it with local tools (Git, Mercurial, JVisualVM), and my secret sauce does not end up on somebody else's server.
Everyone asks what the core value proposition. In a distributed cloud environment, it's developer bootstrapping, securing distributed workspaces, and moderning legacy build processes. These are capabilities that only exist when you have a shared distributed server system.
We took the kernel and created a new IDE out of it to demonstrate a couple things:
1. Environment & workspace portability
2. RESTful services on top of language tools like JDT
3. Production / development container interoperability
4. Extension framework for a cloud IDE
We haven't launched Che yet becuase the legal & branding review process at Eclipse is extensive. We hope to finally be done within 3 more months.
But we encourage everyone to check out 4.0 branch of git and then build that.
It is doing a few things:
1. Worksapces are quietly powered by environments, backed by machines which are docker or localhost. This enables each workspace to be isolated with a stack apart from others.
2. We will also demonstrate workspace portability. You can move an entire workspace and all of its tools from Che to Che, or from Che to cloud. And the environment will continue to run identically in each location.
3. We are running the full JDT and other language services inside of the machine. We wrap these with RESTful wrapper. And then it allows the browser to gain capabilities for maven, refactoring, and a variety of powerful intellisence, and it's generally the same speed as localhost.
4. You can then exec commands, debuggers, and ssh into the workspace machines.
5. We have also done a project with Red Hat to enable your workspace environments to have the same docker container structure as production. We will shortly release a plug-in for OpenShift and Kubernetes that let's projects move back and forth with limited configuration. Becuase they are both running on a common container architecture.
While we can solve workflow problems in our distributed system, such as a workflow we call continuous development, we wanted to have a fully fledged desktop IDE to demonstrate that this could have the performance and security of other types of tools. So we are working to have this installation be very fast and lightweight.
You guys are seeing the intermediate builds so it's got a lot of rough edges.
Note: Please if you are going to do some testing, try it on the 4.0 branch. The design is much better and the performance is very good. The 4.0 branch is when we started embedding the JDT services into the mini Che that runs inside of the workspace machines.
git clone https://github.com/codenv/che
git checkout 4.0
cd assembly-sdk
mvn clean install
It's complementary. Both Eclipse Che and Eclipse Orion are part of a new top level project called Eclipse Cloud Development. There are other technologies that are being consolidated together.
Collectively, we are working on a broader platform that has a goal of letting anyone anywhere make contributions without first installing software.
Orion is primarily a client-side technology. It's designed to offer a multi-page browser experience that has simple plug-in approach for customizing the client side experience.
Che is primarily a workspace server, with a focus on workspace portability and interoperability.
In fact, Che embeds Orion as the core editor, the diff editor, and some other components.
Che has a browser IDE that we have built that embeds Orion on the client side, along with adding in additional constructs that we needed for debugging, single page management in the browser, and some other items.
But isn't your "secret sauce" already on some else's servers? Like GitHub or BitBucket? What would be the exact difference here? Really and honestly interest in your thoughts. Thanks :)
No. In addition to what saurik said, setting up a full-blown GitHub-like service for your own company/institution is not that difficult.
We use Gitblit. Since it is self-contained application, it (literally) takes just a few minutes to set up [1]. After that, the number of repositories, users, and repository size is only bound to technical limitations. I get the impression that GitLab is also pretty simple to install these days with the GitLab Omnibus packages.
And even if you want to use GitHub or BitBucket for your proprietary code, adding yet another company to the loop only increases the probability that your code will be stolen in e.g. a security incident.
[1] Perhaps also important: it integrates with internal authentication servers (LDAP, etc.).
You make it sound like hosting a git repository is hard or something and so the basic assumption is that obviously anyone using git is going to be using GitHub... if you have ssh access to absolutely any server you can just do a git init --bare on the server and a git remote add on the client to let you do a git push, and with a single file rename to activate a default provided post commit hook you can turn on remote access if the folder is accessible via HTTP. You might not even need a server: the fundamental beauty of git is that it is a distributed resource. What value is GitHub adding? It would be one thing if they offered good services surrounding git (such as an issue tracker that was worth using), but they don't.
No, it is hosted on servers I own, or in a portable small repository (like Fossil, for example).
Microcomputers solved the problem of portable powerful processing, so I do not see why I would defer the processing elsewhere. It isn't a problem that needs solving.
I like the idea of a cloud-backed IDE that has an Offline/Cache mode, but is it even possible to provide the non-editor part of the dev environment (things like the terminal and all of the associated state in the container) while offline when they live on the server? That non-editor part of the dev environment is really the main appeal of a cloud-backed IDE for me.
Also, I have yet to find a cloud IDE that has proper support for building iOS apps. Sure you can delegate the builds to some external build service, but sometimes you do need the flexibility of a local build environment for advanced debugging and working around certain issues.
Good point...I don't think its feasible currently at all to have the non-editor parts work with the remote dev enviroment. There are things we can do but this is still in the early stages so we will have to wait and see on that one :)
Please don't assume that internet is there always. Lots of regions in the world don't.
Further, even if it is there, if you have bad reception, assuming a good connection is in place hurts the experience. If you design your product as "connection is needed for some things", it will be way better than "connection is always perfect".
As an example, I hate when I'm about to read a webpage opened previously on my browser, and then somehow, something triggers a refresh, I don't have good reception, and I need to wait minutes for the page. One person assumed connection will be quick and it is ok to discard my copy and wait with a blank page until the next one loads; another assumed that huge pages are ok, and putting the content last in the html is also ok, and then, I end up without the content.
Totally agree, and although Codeanywhere is not there yet. We are currently taking steps to enable this exactly. If you internet "breaks" that Codeanywhere won't it will just work (sans things a connection is needed for) and when ist back it will just continue :)
While in the air, or at a field location, or any of a hundred cafes, restaurants, even the occasional conference venue. Downed internet connections, and unavailable hotspot passwords are a real thing. I probably log a reliable 10 hours a months of offline work, though have had occasion to do much more than that at a single stretch.
As someone who isn't a web developer, the question seems ludicrous to me.
It's important to note that when you need to do offline development, you need to do offline development. A toolchain that requires an active internet connection is still fundamentally unreliable, even in 2015.
I do personal projects on the train mostly. The only nuisances are obscure programming references and pip. Can generally move to another problem if I'm blocked though.
I'm lucky, work for smart people who realized that if they wanted me to sign they had to yield on where. (Or as they put it: we don't understand what you do anyway and we trust you, so whatever you want as long as you show up most of the days.)
Edit: Used to work on personal projects in a previous job that included long commutes. For me it is often the best time of the day for programming: Nobody to interrupt, few distractions, a very specific start time and stop time.
My current IDE works just fine with or without internet access. I don't remember the last time I needed to code on a computer besides my own (which is the only use I can think for this, or maybe on something like an iPad Pro).
Hacker News is kind of funny, in that is it full of the developers that are those who do exactly that! Though, you're right: in your target market (HTML, Node, PHP devs) it's a much safer assumption that they'll be developing with internet access.
When I need to hunker down and get things done, I turn off network, etc. It really isn't that important to development. Only checking in changes and you don't have to do that every five minutes no matter what some blog says.
Sitting in a coffee shop in a tiny town while visiting my inlaws... granted I did work for about 2 hours offline, then used my phone to connect and check in what I'd done....
edit: Wait, nevermind. I edited out my response. I was trying to have an honest conversation. I didn't know you had a product that you had to stick up for the usage model of.
Always-connected working is widespread enough that you can sell the product you sell, but pretending like it's a well-established hard requirement everyone easily meets is bullshit.
Codeanywhere looks nice! I have been using nitrous.io for a long while, very similar to your product. Having an IDE in the cloud offers a lot of conveniences: large builds without heating up your laptop, easy to try different server setups, makes my chromebook and iPad more useful, etc. Of all the cool tech at Google, one of my favorite things was their web based IDE with very nice integration with Perforce, build systems, etc.
I don't understand the "must be on the Internet" complaint. As someone else said, other online resources are large parts of developer workflows - it has been a long time since I have coded without an Internet connection (perhaps a few times a year on an airplane, but I am happy enough writing (I am also an author) or reading on planes).
Can you elaborate why I would want to use a service like codeanywhere instead of usual git workflow through my terminal app? Is this aimed at people who don't use laptops, those who don't use a DVCS?
You still ca use GIT and your terminal inside of Codeanywhere. We actually encourage you to use them, if you connect with your GitHub or Bitbucket account, Codeanywhere will list all your repos, so you can spin up a environment with them in just a couple of seconds.
Codeanywhere is an Editor just like Sublime, Atom and so on. It's just available everywhere and just how you configured an left it.
One neat feat of services like CodeAnywhere is definitely that you can go cheap on hardware and buy a Chromebook as long as it allows you to execute and test your code on the server.
One of the key objectives that we are exploring with Eclipse Che is the idea of workspace portability. The workspace itself is composed of two things:
1. The projects (and their source bindings), and:
2. Their environments, which are the stack of tools and runtimes that you need to perform work on the code such as refactoring, debugging, compiling.
We have created an abstraction of the worksapce to the environment that it is bound to. And then this entire definition is exportable and movable between Che instances or to a cloud that is supporting Che, such as what Codenvy will run.
Because the workspace definition defines its machines in the workspace object, then we can recreate the exact machine you need to do the same work on another node.
We use docker to implement this behavior.
We are not fully done with all of this work, but we have a lot of prototypes that prove this can do well.
There are some challenges - if you want to "save" your workspace, do we snapshot the machines every time, or only sometime? Do we force a remote commit & push? it'll be up to the user. But once all of the commits are done, then we have to push the images into a shared registry and ensure that everything is remotely accessible.
Once all of this is done then any other machine can reproduce an identical workspace.
Well it give lets say a SublimeText users the advatage that you get using ssh+vim. Not everyone is a VIM user and not everyone wnats to be one. There will always be people that will stick with vim, but some people what the flexiblity that vim gives them but in a sublime like interface that they are used too.
Of course I am biased as I am the cofounder of Codeanywhere.com which is a Cloud IDE its self.
But just to make a point we actually built all of Codeanywhere inside Codeanywhere. Welcome any comments...good or bad :)