Open source browser based code editors

No readers like this yet.
code editors
Image by:

Opensource.com

The humble browser. Its main purpose, for many years, was to serve up simple HTML documents and provide information on just about any subject you could think of. In the last decade, with broadband taking over from dial-up, and net connections getting ever quicker, websites have increasingly provided applications usually restricted to the desktop.

With the evolution of languages such as HTML, CSS and JavaScript helping push the limits of what could be done, we find in turn it provides new opportunities in openness and sharing. This has evolved to the point where there's really not much that can't be done or opened up online now.

Everything online?

Take a moment and think about it. Document editing, file sharing, image manipulation, server backups, 3D rendering, music production, and just about any other work traditionally done in desktop software can now be handled by a web service. Web development however has been one of the last areas to truly get with this trend, as web developers themselves have stuck with the theory that it's best to code offline and push code online when it comes to launching.

This has always been a sensible way to work and is built on sound logic and experience. Working offline was fast, your code is pretty safe, and desktop editors generally very good. So why make the change? Well, a new era has been quietly growing and over the last few years, web based editors have evolved hugely, almost now equalling their desktop rivals. Today, they're fast being seen as viable solutions to coding, bringing new possibilities to share code and the development of sites with others. From quick experimentation on websites such as jsbin.com and jsfiddle.net thru to full blown coding environments such as codeanywhere.net and c9.io, there's a solution for just about any level you'd like to work at.

Open source editors

One of the latest trends in this new frontier has been to share these online code editors and IDE's themselves thru open source.

The benefit here is that you can see exactly what the editor is doing and as they're written in familiar languages such as PHP, Ruby, and JavaScript, you can customise them to your liking. Don't like how the editor works? Change it. Want to connect it to a specific service? Integrate it. It's very rare you find a desktop editor that's exactly as you'd like, there are often small irritations or limitations meaning you have to work with them or use other services, taking extra time and effort away from your coding efforts.

ICEcoder

This is where ICEcoder steps in. It's a fully featured, browser based code editor that allows you to code online or offline in the web browser. It contains just about everything you need by supporting many common languages, comes with an image viewer with hex & RGB eyedropper, full 16.7m colour picker, Linux terminal, backs up every 30 mins, you can push & pull files to/from Github, is Emmet enabled, has type boosters, advanced find & replace, MySQL management, JSHint linting, live editing, and more.

However, because it's open source, you can take it and make it your own, no more having to fight your editor to get the job done. It can fit to the way you want to work and connect to anything web based. The web effectively becomes your toolbox.

An open source future

Having truly open source solutions like this seem to be paving the way towards a more shared and open future where everything can be integrated, mixed, and reworked on our own or in teams, with the safety of knowing code can be rolled back, bugs tracked, and solved from anywhere if there’s a problem. It allows you to share code examples and prototypes easily as you work collabortively with others plus coding in a similar environment to where you'll deploy also helps avoid the headaches caused by going live and new bugs emerging. You also have the opportunity to create fixes at any time and push from development servers to live servers all from the comfort of your home, local cafe, beach, or wherever you may be. No more being restricted to the office.

With everything ultimately moving to the cloud, browser based editors and web IDEs will undoubtedly become the defacto way of coding, and I welcome this bright new future. If you’re still coding offline, why not give one of them a try?

Tags
Programming
Matt Pass
User profile image.
I'm a freelance web designer & developer with over 14 years commercial experience in creating web sites, apps and eShops for companies large and small around the world. My focus is to drive the web forward with great new solutions to make everyones life better and find the best way to achieve this with open source solutions. Community power FTW! :)
More about me

7 Comments

Avatar
Stephan Sokolow | May 21, 2013
No readers like this yet.

<strong>On the one hand, I always love seeing more options for in-browser text editors.</strong> Not only do they make the geek in me squeal with delight at seeing a new toy, they're an excellent option for engaging users who either won't be around long enough to justify installing a custom tool (eg. almost everyone who clicks a jsfiddle link) or aren't yet committed enough to be willing to.

<strong>On the other hand, I strongly disagree with this whole "in the cloud" movement for a variety of reasons.</strong>

<strong>First, I think it's demographically naive.</strong> I live in Canada. A lot of us still have to choose between dial-up and some of the most expensive 3G cellular service in the developed world... and some of the developing world. I'm lucky enough to live in a place where I get 5Mbit/800Kbit connectivity and, as far as I know, Bell Canada currently has no plans to upgrade our sleepy little village to fiber-to-the-node. (Which is required to upgrade to faster DSL speeds. The only TV service here is via satellite so no Cable Internet.)

<strong>Second, I think it's overly optimistic.</strong> "The cloud" is still a single point of failure for end users since we rarely have redundant connections and, even when we do, we still see the occasional GMail or Google Docs outage. This is why I was so happy to discover git and TiddlyWiki. The "work offline, then merge later" model provides that redundancy while, at the same time, allowing the end user to transparently become part of plan B if the backups are lost, useless, or were never being made, as was discovered to be the case with Ma.gnolia in 2009.

(My preferred approach to things like GMail, Google Docs, and full in-browser IDEs is to use things like appcache manifests and IndexedDB to support seamlessly going offline and coming back no matter which URL it was loaded off.)

<strong>Third, data portability in "the cloud" isn't yet a solved problem</strong> and there's plenty of room for companies to pull shenanigans and leave the user holding the bag. With a tool like git or TiddlyWiki (or watching streaming videos by running a script which calls youtube-dl and then points MPlayer at the file within seconds of it appearing), the power is in your hands. "Having a copy" means "having a copy" in the same sense as with physical objects, rather than "it worked last time I tried, but something changed unexpectedly".

(<strong>It also often means trusting your backups to a single point of failure.</strong> See my comment about Ma.gnolia.)

<strong>Fourth, it's wasteful.</strong> I have an Athlon II X2 270 with 16GiB of RAM (fastest non-Intel 65W TDP chip I could find), but I run LXDE on it and test my desktop on my old 2GHz Celeron with 1GiB of RAM. The only things that don't run comfortably are browsers... so why would I essentially run my nice, lightweight copy of Vim inside something that slows it down about as much as a full-blown x86 emulator? I bought a fast computer because i want to do more... not because I want to do the same things in a trendier way.

(Even if the already limited GUI API weren't further crippled by my tweaks to neuter things like <em>window.open()</em>, I'm a firm believer that, if an app doesn't inherently require reinventing the browser's HTML/CSS renderer or network stack to be written standalone (and "zero install" isn't absolutely essential to the intended use case), then writing it in the browser is like buying a big, heavy, hot-running refurbished Pentium 4 for $100 because you already know how to bit-bang the parallel port and don't want to learn Arduino programming.)

<strong>Finally, it's uncomfortable to me, personally.</strong> My Vim uses quite a few plugins and I'm quite used to Vim motions. I don't have problems using non-Vim text editors, because I made sure to train myself to be comfortable in both Vim-style and CUA-style key schemes, but the basic, common CUA is too slow and inefficient for coding and nothing else on my desktop runs in "Vi mode" because I've yet to find an application which implemented enough of a Vimscript runtime environment to parse the keybinds from my .vimrc and run all my plugins.

<strong>That's not to say I don't use in-browser code editors myself,</strong> but I use them much less as full blown coding environments and much more as lightweight widgets complementary to TinyMCE. There are tons of places on the web where a textarea with syntax highlighting, line numbers, and search/replace is a good thing to have.

Avatar
Matt Pass | May 21, 2013
No readers like this yet.

Hi Stephan

Some good comments here, tho a few responses on your points. ICEcoder is different because you can run it online or offline. You of course miss out on the benefits of connecting to web services or coding from anywhere, but if you don't want to, or it's not really practical to work online, no worries, it runs quite happy locally. It also means you have a local copy of your files.

Another key point of ICEcoder is that it's not exactly working in the cloud (I believe) because you're not working in your set account like you would with, say Google Docs, you work on your web server/hosts. I hear what you're saying about dependancy tho and may look into pushing/merging files to a site when you're ready to deploy.

I wouldn't say this is about working in a trendier way, it's about working smarter. Plus, if you have a many programs open (text editor, DB software, image viewer, graphics editor, Github etc) you're likely to be using more rources (RAM, CPU etc) than just a web browser.

Lastly, I agree Vim and Emacs keybindings would be nice. They're being worked on extensively at the moment by open source community and when they're ready (hopefully next couple of weeks), they'll make their way into ICEcoder. This hopefully shows that if you want it, you can build it. Being open source means it's highly customisable. Another example - last week I decided I wanted an eyedropper tool on the image viewer, wrote it in 2-3 hrs and is now instantly available.

May not have convinced you on these points but it hopefully goes some way towards showing how ICEcoder is more open source and different than the others.

Avatar
Stephan Sokolow | May 21, 2013
No readers like this yet.

I was aware that ICEcoder could be run locally but that still ties into my point about browser-based apps being heavier.

The whole point of using things like Vim and urxvt is that they make it easier for me to have "many programs open". Hence why I think that using tools like Vim is "working smarter". I get the same functionality but waste less CPU and RAM, which means it's easier to do things like having copies of of Firefox Aurora, Firefox Stable, Chrome, Opera, Midori (GTKWebKit), Arora (QtWebKit), and three or four of the http://www.modern.ie/ testing VMs just sitting open in the background for quick-access testing.

Naturally, I couldn't do that on the 2GHz Celeron but, if I just got lazy and let my desktop grow a beer gut, I might have trouble doing it on the dual-core Athlon too... especially if I'm developing and testing something that is, itself, CPU- and RAM-intensive.

(I actually didn't plan to upgrade to a 3.4GHz dual-core Athlon II with 16GiB of RAM. I was perfectly happy with an Athlon64 X2 5000+ (2.6GHz, dual-core, also 65W TDP) with 4GiB of RAM that I bought about 5 years ago but my old motherboard died back in January. Since I was buying new kit anyway, I decided to make room to run more than one IE testing VM at once.)

You also seem to misunderstand my point about Vim. Even if you implemented Vim keybindings, it wouldn't interest me because I don't use Vim keybindings. I use <em>custom keybindings and plugins within Vim</em> and the amount of effort required to port my <em>.vimrc</em> and chosen plugins over to <em>any</em> other application just isn't worth it.

Avatar
Matt Pass | May 21, 2013
No readers like this yet.

Not sure I'd agree. On filesize, software based editors are heavier. Sublime (5.3 mb), Brackets (28.8mb), Textmate (12.3mb), Vim (9.1mb) and more are all way above ICEcoders 1.1mb. It's naturally going to be lighter because most of what you need is already provided by the browser. It just builds ontop of what's already open, the browser.

On resource usage too, it boots in 1-2 seconds and barely scratches the CPU or RAM. I run it quite happily on my 2.6Ghz with 4G RAM and used to run it fine on a 1.4Ghz with 2G RAM. Have tried so many desktop editors that take ages to boot and then are resource hogs. Don't get any of that anymore.

I like Vim too, mainly for the keybindings, but doesn't do everything I want. That said, browser code editors aren't for everyone, but there's a growing movement towards them. You've just got to work the way that suits you and it sounds like Vim is best for you. For me it's ICEcoder. The next guy may insist it's Sublime.

Whatever works for you is the 'right way' to code :)

Avatar
Stephan Sokolow | May 21, 2013
No readers like this yet.

True. I know browser extension load-outs and the design trade-offs between Chrome and Firefox make a big difference.

Chrome is memory-heavy but responsive because of its multiprocess design (though <em>window.opener</em> support causes multiple tabs to share the same process) and I can't stand a lot of the design decisions that went into its extension API.

Firefox's single-process nature helps it to be memory-light and its approach to extensions makes it easy to implement things like HTTPS Everywhere and RefControl, but they push so many things Chrome does naturally (like matching the system's native scroll-wheel behaviour for tab bars) into extensions that said lightness is a bit deceptive... and I'm still trying to track down the last of the slow extension memory leaks

Worse, and more relevant to this case, a messy site in one tab can bog down every other tab.

Given how I find Opera to be unacceptable for being closed-source and Chrome for making various design decisions I dislike and can't override with extensions, I'm stuck with Firefox, which means I'm effectively stuck with Ye Olde Windows 3.1 Cooperative Multitasking.

Basically, I'd have to run a separate Firefox or Chrome profile just as an application runtime environment and doing that just for ICEcoder doesn't make it feasible.

Perhaps in the future, but I just don't see the web runtime environment (or whatever you want to use as a general term) being mature enough to satisfy me right now.

Avatar
Steve Hamblett | May 21, 2013
No readers like this yet.

Its not really code editors that dictate development environments, its more the IDE used. I for instance use a combination of VS2012, Netbeans and Eclipse depending on what project I'm working on at the time.

Things like Cloud9 IDE are OK as far as they go but are still a long ways away from the tools above.

Avatar
Stephan Sokolow | May 21, 2013
No readers like this yet.

I've tried to use various IDEs throughout the years but every one I've tried has just caused me more distraction and bother so I kept coming back to something visually minimalistic like Vim (with various plugins for static analysis and the like) combined with <em>git gui</em>, a Quake-style terminal for various command-line tools, and, for web apps, something like Firebug or the Chrome developer tools.

I do see your point though. Tools like Cloud9 are sort of in an uncomfortable middle ground. Too IDE-like for some, not complete enough for others.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.