Stephan Sokolow (He/Him)

<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.

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.