So as of version 1.3 of Tyk, I decided to give coding in the cloud a try. There’s been plenty of experiments like this, the most notable might be the fella coding on an iPad with Vim and a little bluetooth keyboard, which worked really well for him. So I thought I should give it a try, I have multiple machines that I work across, and one of them is a Chromebook (which I love, mainly for it’s battery power, lightness and low cost).
Seriously, for £120 having a fully-fledged development environment is worth the experiment.
So a primary requirement when working across this project is to be able to work across many projects, for example: the core tyk project on github has an external library dependency called tykcommon which is shared across a few projects, in a traditional IDE environment, I’d have several editors open and jump through them, multiple terminals and a browser quite often.
Since Go is statically typed, one of the greatest things an IDE can do for you is type checking and allowing you to click-through to type definitions so you can quickly reference core docs, interfaces and usage patterns without hitting up a web version of the documentation on GoDoc or Github.
Lastly, since there’s quite a few servers running at one time to test a feature or a stack, I need many, many terminals.
How does a cloud IDE work?
Nitrous gives you a base VM, a web-based terminal (multiple terminals if you wish) and a browser-based IDE with a file-browser. It basically runs a docker container which can be scaled up with credits you can buy on the site.
The experiment was to use this cloud IDE to build version 1.4 of Tyk.
- Language aware IDE’s really make a difference – not being able to click-through definitions or having auto-complete at hand for function names etc meant that my accuracy improved when it came to typing method names, but it also really slowed me down as I’m so used to the shorthand of function names.
- On the fly debugging by the IDE is also a serious boon, and you really miss it as once it’s gone since you rely exclusively on the compiler to find your bugs, meaning you are switching to the terminal and running go build over and over again, mind you, I could just be a more rigorous developer, no arguments with that, but in terms of speed, you really low down.
- Context switching is key – I ctrl-tab (or cmd-tab, depending on my system) between windows all the time, I found Nitrous trapped keyboard short-cuts, sometimes to the chagrin of the user as stuff doesn’t happen as expected, unnecessary clicking ensues.
- Web based terminals aren’t great, there’s expected support for a terminal to behave a certain way, and no matter how much you try to cram into a web interface, it still doesn’t stack up, simple things like being able to copy stderr output into a clipboard really become irritating
- Connectivity – if your internet connection is flaky and you’re in the middle of a git commit, if your connection drops on a web IDE, the terminal actually kills the process, which leaves you with a hanging commit which is a supreme pain to resolve.
- Connectivity pt 2: This became even more of an issue when the connection reset and I was locked out of saving files, I would have to refresh the window in order to regain access to those files (they grey out). Thankfully this didn’t happen often, but given the below, it became quite frustrating.
- Consistency – My desktop IDE will reopen exactly as I left it, with Nitrous I found I had to constantly reset it to the way I needed it (three terminals, root folder locked on my Github repository and manually opening my last opened files). It’s not much to do, but if your connection resets and you are locked out of editing a file, then it becomes something of a hated ritual.
I managed to use the cloud IDE successfully for most of the build time for Tyk 1.4, but when it came to the crunch and doing core debugging pre-release, I found it insanely frustrating to get things done using it, and went back to familiar territory.
I may get maligned because I’m not a Vim/Emacs developer fanboy, and Vim-Go is incredible, but I like my dual-screen, multi-terminal, multi IDE setup that lets me work across 3 projects at once, crushing all of that productivity into a web view or a terminal is just painful, so to each their own.
My conclusion is that, basically, these cloud editors are great for on-the-go stuff, and I will be keeping my Nitrous.io subscription, but ultimately the problem they need to solve is not giving me a development box (I can install vagrant and build in that just as easily), but making the web-based IDE compete well with more advanced editors, as this is where the most time is spent and the biggest benefit can be had.
Being able to code on a Chromebook is pretty amazing, and Nitrous did make it very easy to get started with minimal teething pains.
Nitrous make the point that I could use whatever IDE I like and store files in Nitrous via a tunnel, but then I ask myself how is that different from running in Vagrant and using Git to backup regularly? The only benefit is the ability to switch from machine to machine without core dev tools,which indeed is a benefit that I used often while working remotely or form odd locations.
I feel that if you have a traditional build, specifically a single-project / web build using some kind of auto-refreshing server, and have a steady internet connection, cloud IDE’s are for you – working with Hugo was lovely since I just had to hit save and switch tabs to edit my site. For a slightly more complex build or something with many many components, you may get quickly frustrated.
Some key things I would like to see to make things seamless an cloud-y:
- Dropbox / Skdrive / GDrive integration – If I save an image file on my chromebook to my local drive, why should I have to go through the process of re-uploading it? I hsould just be able to copy those files across
- Better file management: that file view is important, and gets misused a lot in IDE’s
- Tighter language integration – This is a long-shot, especially in a browser, but it’s what always brings me back to my local box
- Workspace retention – resetting my workspace every time I returned really bugged me
- Symlink support: This is golang-specific, in a typical go workspace, your files are burried in a long folder heirarchy (~/workspace/go/src/github.com/username/repo-name), creating symlinks make it easy to jump right in, but the we IDE didn’t follow symlinks which meant that I needed to manually open those folders every session
As I said, I think Nitrous.io have a great product, and with a few tweaks it would be great to work with more. Will most certainly be keeping my subscription.