Stephan Sokolow (He/Him)

201 points
User profile image.
Ontario, Canada

Stephan has an interest in software freedom, human-computer interaction, user interface/experience design, programming, and Linux... but he prefers to leave graphic design to the experts.

Authored Comments

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.

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