Coding in the Cloud

Web-based development tools for coding on thin-clients

Recently, I wrote about the options I’ve found for coding on a Chromebook that provide a similar experience to a laptop running a more conventional Operating System. There’s a lot of reasons why you would want such a setup; chief among them being that you can’t be assured of a stable, always-on Internet connection in every part of the world.

What if that’s not a concern for your use case, though?

It’s worth considering that while primarily we see our development environments as something that should live locally on our systems, there are some scenarios where it may be worth embracing a remotely-hosted solution that provides your tool-set over the web.

In this article, I want to discuss a few of the benefits and drawbacks that you can expect to encounter, and highlight a few of the better services I’ve found that fulfil this niche.

How connected am I?

This is probably the biggest elephant in the room when it comes to embracing cloud-based tools. If you can only be connected to the Internet at a time of the day that sits outside of your main workflow, or your connection is as hit-and-miss as Coldplay’s back-catalogue, then this option is really a non-starter for you.

I’m better connected than Tony Soprano. Now what?

Simpatico. The next thing you may want to consider is the nature of the development work you’re doing.

If you’re working on embedded projects or those that otherwise require direct-to-metal connections then this is most likely not for you. Examples of this kind of work might be programming over serial connections to controller hardware, or working on the next hit Xbox game with a physically connected dev-kit. Those are pretty solid examples of poor fits for a web-based development environment.

If you’ve still not ruled yourself out of this kind of setup, let’s move on to looking at where an environment like this really shines.

Have browser, will travel

In recent years, it’s become increasingly practical within the technology industry to work remotely from anywhere, simply by opening your laptop wherever you happen to find yourself. In many cases your current circumstances may prevent you from actually doing so, but in the instances that you can enjoy this freedom, it can be deeply liberating.

Look at this uplifting photo of someone on a beach, gazing into the distance. That could be you.

What’s even more liberating is not needing the laptop at all. Being able to jump into your work from the nearest web browser (while knowing that your system setup will be just as you left it regardless of your previous device) is a big reason to consider moving your workflow online.

Consistency across your devices

This is probably the most under-appreciated aspect of a cloud-based development environment, and one which is not immediately obvious until you’ve experienced it first hand.

If you don’t work on the same computer all the time, or switch between a mix of systems throughout the day (e.g. a desktop at home and a laptop on the move), you’ll eventually find yourself dealing with the problem of keeping your environments and their dependencies consistent enough to sufficiently get your code to build across all of them. It’s true that technologies like docker help with this problem to an extent, but ultimately the burden is on you to replicate and maintain that setup in several places.

This just isn’t the case with a cloud-based environment, as this will be entirely abstracted to the remote side, letting you forget about local configuration entirely.

Zero local footprint

For thin-client devices like Chromebooks, tablets and docked phones, the on-board storage capacity tends to be minimal compared to that found on a standard computer.

A tool-set in a remote location has no footprint outside of the web assets required to render the IDE in the browser, meaning you won’t need to concern yourself with whether or not you can afford the storage space to clone large, unwieldy remote repositories to your local device.

Multiple simultaneous cursors

To be fair, this is a premium feature on each of the options discussed below and as a result is only available to paying customers, but it’s worth calling out here as I’ve found it’s exceptionally useful to have for two primary scenarios that come up quite a bit in the course of my work.

“Thanks for the help, but would you mind exiting my personal space?”

Pair programming

Being able to “virtually” code alongside someone else is fairly seamless with these platforms — generally the only identifiable marker you’ll see is one or more labelled cursors of a different colour showing you where the other developers are in the file. The impact, however, is profound.

You can reap the benefits of a pair programming environment (like a second set of eyes to check the code as you write, and the camaraderie of seeing you and your team-mates working together) without the existential creepiness of someone literally breathing down your neck while you work.

Teaching and coaching

Of all the features of these environments that never get a mention in the discussion about online coding environments, this is the most critical for me personally.

I’ve long had an interest in the teaching of programming (even going so far as to make it a top priority when selecting our son’s school).

The ability for an instructor to “jump in” to a coding session to help a student in need during a lesson cannot be over-stated, and the friction-less nature with which it can be done quickly in these environments makes it much more likely to happen in practice.

Coupled with the ability for teacher-led coding inside the editor, some of these services make fantastic tools for collaborative learning.

What options are out there?

There’s a few different services in this space, and each have their own unique set of trade-offs that are worth thinking about. I’ve presented three of the major players below, with a brief discussion of the pros-and-cons I’ve encountered when working with each of them.

Codeanywhere is a tool I discovered only relatively recently while comparing options for fixing some bugs in a legacy C# project (for which I no longer have a local environment configured).

To that end I found it was stable, and the lexer seemed to do a solid job of understanding the files — beyond that though there wasn’t much I could see in the way of support for older pre-.NET-Core solutions (please someone correct me if its there and I’ve missed it!), but to be fair I had expected as much as it’s not really the kind of project they are targetting with the service.

The pricing structure is tiered based on the quantity and capability of underlying containers, which are minimal Linux environments connected to the web interface via SSH. The containers are spun-down when the user logs out, to save resources (there are paid options that support keeping your containers on constantly).

There is a free tier, which allows for a single container (which broadly equates in this case to a single project) at a time, with a single connection at a time. This should be fine for most users who aren’t splitting their time among multiple projects concurrently.

Benefits

CodeAnywhere has broad language support (75 currently), which means it’s very likely that there will be at least some support for whatever stack your project is rolling with. The service also has a lot of integrations, and the usual suspects are supported (GitHub, BitBucket, arbitrary Git endpoints, Google Drive, OneDrive, and more), so it’s very likely you can get it hooked up to wherever your code sits currently.

The CodeAnywhere editor. Your eyes will thank you for dark colours.

I’m also quite fond of the interface CodeAnywhere uses — I code exclusively in dark mode within my local editors so it suits me very much that they’ve adopted a similar colour scheme by default.

Mobile apps are also provided for Android and iOS, which (to the best of my knowledge) is a unique offering in this space that comes in really useful for quick-fixes when you can’t get to a computer right away (this has saved my bacon during my commute more than once!).

Drawbacks

The price tiering of connections can be somewhat problematic depending on your use case if you need to connect multiple remoting clients (pair programming, to give one example), but it makes some sense in the context of their business model.

The pricing documentation doesn’t explicitly state that a single container equates to a single project — and it doesn’t necessarily, if you want to get creative about how you organize your files. Realistically though, the containers are so closely related to the stack you’re using that the relationship is effectively one-to-one for the most part.

Two-factor autentication as an upgrade. I challenge you to justify this.

What doesn’t make any sense at all to me is that two-factor authentication, which is increasingly accepted to be a security best-practice these days, is a paid feature on Codeanywhere. It’s good that they support the feature where some others do not, but they should really think about making this available at all tiers.

Cloud 9 was the first real entry I experienced into the world of cloud-based code editors, and I’ve still got a pretty deeply-set affinity towards it.

In a feature-comparison chart Cloud 9 might seem slightly light on content relative to competing services, but it’s only when you really get into just how much is hiding under the hood that you come to appreciate what’s really being offered here.

Like CodeAnywhere, the service has a free tier that will cover a single user connecting to a private repository, but will also allow workspaces for unlimited public repositories. This makes it quite a strong choice for open-source projects hosted somewhere like Github, as the fact that you are working on a public repository will be picked up automatically during workspace creation to ensure you never even see a bill— so it’s quite fast to get a rolling environment that you can dive into.

Benefits

Cloud 9 has strong language support (40+). This may not be as extensive as CodeAnywhere’s catalog of 75 on paper, but in reality it’s very likely that either platform has at least considered the stack that you’re building with. In addition to this, the open-source Ace editor that Cloud 9 is based on supports more than 100 languages, so I suspect there may be some difference with regards to features in what each platform considers “officially supported”.

Cloud 9’s integrated debugger. With immediates. And watches. And a click-to-jump call stack. In a browser.

Cloud 9’s biggest stand-out feature for me is the integrated debugger. If you’re working in a stack that the debugger supports, I thoroughly encourage you to take a look at this tool. At first, I expected that many features I took for granted in traditional IDE’s would be missing, but all the standard debugging tools I’ve come to take for granted over the years are just.. there. Not just present, but where I expect them to be. The debugger even has extensive support for walking the call stack and analyzising scope variables.

While it’s not directly relevant to a normal user, it’s reassuring to know that Cloud 9 also provides a lot of their technology as open-source components, including some that they’ve developed in-house to contribute back to the community. This means that if the service ever shuts down in the future (I’m looking at you, Nitrous.io), you’ll not be left stranded without a version of the editor you can fork and continue working with.

Finally, Cloud 9 also includes a surprisingly feature-rich image editor, which for quick graphics work is actually really useful, not least because it saves you jumping into another cloud service like Pixlr for every small correction.

Drawbacks

The biggest drawback I’ve found with Cloud 9 is that it’s grown to such an extent that it can sometimes be difficult to find your way around the editor relative to simpler solutions. As a developer you should really be reading the manual of course, so it’s not really much of a criticism.

There’s a lot going on here to figure out

This complexity extends to my actual workflow though. Cloud 9 is about the closest I’ve come to a classic IDE experience in a browser, but it so convincingly replicates some of the deeper features of heavier traditional IDEs that I continually find myself reaching for the tools that aren’t there, just because I’ve become accustomed to such things being present.

If you’re not used to heavier IDEs, or you intend to move your work completely to Cloud 9, this is unlikely to be a problem for you at all.

As a side note, I’d really like to see Cloud 9 take their downloadable SDK a step further and make the whole system runnable locally. I completely see that what I’m basically suggesting is that they take their core product and make it freely available for self-hosting, but bear with me on this one. The c9sdk is downloadable at Github already which seems to be at least most of the hosted content. I believe it would win people round to the idea of a cloud-based editor if they knew they could host it on their own network should they need to in the future, and I would hope it would lead to broad increases in community support for extensions, akin to the massive boost VSC received by being developed completely in the open.

Azure App Service Editor (preview)

In all the years I’ve worked on the Microsoft stack, the single biggest (hopefully constructive) criticism I have as a developer and a customer is that it can sometimes be difficult to find out exactly what services they have in a given space.

I sort of understand why it is this way — they’re operating at a scale that sees them work on so many different projects that it can be hard to get all of it into an elevator pitch. I kind of feel like more niche offerings like the App Service Editor (ASE) are casualties of this.

Here be dragons!

First, a word of warning on this one. ASE is in a preview state currently and it’s probably going to evolve quite a bit before it’s considered “done”. That being said, I’ve found it to be a polished and smooth experience so far, and have had no issues whatsoever with performance or stability — just bear in mind this is not yet a final product.

So what is it?

It’s a small part of the larger Azure set of services that combines source hosting with project management with a build system with a code editor with many other things. Azure has had whole books written about it on its own so there’s little point in my trying to summarize what it encompasses in a few sentences here. We’re just going to look at this little-known code editor that sits inside the Azure portal for now.

Visual Studio Code in the cloud. Sort of.

The code editor inside Azure is actually the very same “Monaco” editor that currently powers Visual Studio Code (VSC).

The key difference between using the editor inside Azure and running VSC locally is that with the latter option you’ll have an underlying system console that you’ll use for your commands (depending on the operating system you’re running on).

Do I look familiar? I should.

With ASE, you’ll still have a console (see pic above), but that console will be a simulated environment with a specific set of tools that are most commonly used. In my experience this works well, and it certainly mimics the feeling that there’s a real underlying shell like bash, but you obviously can’t just install a package for a new language and start executing commands against it in the console (although you can create *.ps scripts inside your projects that will then be available to execute inside this console — I’ve found this expands the capabilities of the system greatly).

The impact this has on your workflow will depend on the stack you’re developing in and how dependent you are on VSC’s extensions. Generally, you won’t be able to directly compile or test the code you’re editing manually in the console, and you should expect to handle this seperately by way of off-loading this work to the build system for continuous integration (which you’ll want to do sooner or later anyway).

I actually find this fits my own workflow quite well, but your mileage may vary with this, especially for small chunks of work or hobbiest projects.

Benefits

The biggest headline benefit to note here is that you can get unlimited free private repositories for up to five users on a single team, which exceeds any other offering I’m aware of in this space. This not only includes cloud-based editing, but source control hosting too (git and tfs).

As you might expect, it has best-in-class support for projects running on TypeScript and/or the .NET stack, and developers that are used to developing inside Microsoft’s offline tools will feel right at home here. Likewise, if you’re used to working on Node.js projects in VSC, the layout and tool-set will be instantly familiar.

The performance of the editor has really impressed me, with no perceptible lag on my Chromebook Flip that I could pick up on.

If you’re a Visual Studio user during the day working on .NET projects then this is definitely the solution to go for — the seamless integration between this service and Visual Studio makes jumping between the two about as quick and painless as it can be. Yes, it’s not yet final, but even in it’s present state I’ve found that it’s the best option available for .NET-coding-in-the-cloud out there.

It also helps that ASE is available as open-source software on Github as Project Kudu. This gives me confidence in the future of the platform for the same reasons as Cloud 9 — having these projects out in the open is a guarantee on your time invested in them.

Drawbacks

There’s not much to complain about here. What this editor does, it does very well indeed, but it highlights the different philosophies of what a web-based coding environment should be.

Using the right tool for the job extends to cloud-based editors, too.

The key difference here is that in our case we’re comparing a source-control server with a coding editor attached, to coding editors with virtual machines attached.

For heavily command-line driven workflows outside of Node.js and npm, you’ll quickly miss not being able to just pull up bash and spin up arbitrary tools.

For most of the actual target developers of this editor though, the idea of a source-control server with code-editing on top makes a lot of logical sense.

It expects the code editor will be used on a secondary device to a system running either Visual Studio Code or the full edition of Visual Studio (which is very likely the case), and so you’ll really only want to make quick edits and check back-in. For these quick changes, ASE is actually much faster than other services in this space, and it’s clear that someone has thought long and hard about exactly what ASE should and should not be during its design.