-- Leo's gemini proxy

-- Connecting to circadian.gemlog.org:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

I Didn’t Want To Like VSCode


VSCode is amazing. It’s really, really good. But I’m getting ahead of myself; let me back up a bit.


How I Got Here


I’ve been coding for a little over 30 years, and of course through that time I’ve been through a succession of languages, editors and IDEs.


First, BASIC on the Amstrad CPC 464: line at a time editing with line numbers.


Locomotive BASIC


Then, Microsoft QBASIC. An actual editor. What a revelation!


QBASIC


Next, Borland Turbo C. My first “real” language—and available to “play” at the Internet Archive:


Borland Turbo C

Borland Turbo C in DOSBox


Then RHIDE, which has a very similar look and feel, with the DJGPP compiler; and after that, my first graphical mode IDE with Delphi.


Delphi


When I learned Java I used Emacs, and then for my first coding job, and many years after that.


I won't include a screenshot of Emacs.

Y'all know what it looks like.

Ending up at a big tech company and spending many years in Java land, I gravitated towards modern graphical IDEs. At the time Eclipse was dominant; it was also, for the size of codebases we were using and the speed of computers at the time, incredibly slow. I logged hundreds of milliseconds to respond to a keypress.


So it was with joy that I discovered IntelliJ, and that they had engineered it so that responding to keypresses was a priority—leaving all the IDE goodness to later frames.


IntelliJ


I was hooked, and stayed with IntelliJ for about ten years.


Over those years I switched primary language, from Java to Dart. Fortunately IntelliJ had, and has, first class support for Dart.


My job changed, from product-focused to software infrastructure. That meant that I might have to edit any line of Dart code across a sprawling, big-tech-company-sized codebase; startup time and speed of interaction became essential.


IntelliJ was still doing a good job, but...


Work From Home


Like many during the Covid pandemic, I switched to working from home. We aren’t allowed to pull proprietary code to unmanaged machines for (very valid) security reasons, so the only supported option for my role was to work remotely over SSH or Chrome Remote Desktop.


For a long time I worked with Chrome Remote Desktop. Even with a very fast internet connection and all the will in the world, there is still a tiny noticeable lag on keypress. It was workable, but not quite enjoyable.


And that’s when I tried `code-server`:


code-server


It lets you access VSCode via a web browser, meaning the graphical part—the part that needs to be fast—is running locally.


My daily coding experience instantly got more enjoyable; I hadn’t realized just how much I had been suffering under those handful of milliseconds of latency. I was sold.


Dubious Ownership


I didn’t want to like something from Microsoft.


I got into coding, and then into Linux, and then into web development, at just the right time to really feel the negative effect Microsoft had on the whole ecosystem. I believe that by taking aggressive ownership of the desktop platform and then the web, they slowed the progress of both by five years or more.


These days the situation is much improved; the Android/iOS landscape for phones is not perfect but it’s vastly better than what we had for the desktop in the 90s and 00s.


The desktop itself, of course, is still dominated by Microsoft but iOS and Linux are now often mentioned in the same breath; and cross platform support is much more common than it was.


The web is far from perfect but in terms of standards and compatibility it’s vastly better—remember IE6?


And so while using something from Microsoft is far from my first preference, it’s no longer something I feel I have to rule out on principle.


To be fair to them—and why not be fair?—Microsoft produces outstanding developer tooling. I hadn’t realized before writing this article, but my journey in this space was from Microsoft QBASIC to Microsoft VSCode.


Dubious Technology


I didn’t want to like a desktop app written in TypeScript.


For the web, the case for TypeScript is easy to make; it’s a good set of design choices addressing what the ecosystem wants.


But the web as a platform is terribly limited. In my job I’ve worked on sites that push the boundaries of what the web can do in terms of complexity and scale; it was always a fight. I felt cheated that we had to spend so much effort trying to attain latency, performance and features that native desktop apps had had for free for years.


And using javascript on the server just feels like giving up.


So what happened in the end? I gave up. It turns out that because I was working from home, and because of the code security requirements of my job, a web app was and is exactly the solution that works in this space.


VSCode is Excellent


And so here we are; I like VSCode so much that I’m using it now to write this post.


VSCode


Here are the main things it got right.


Fast and Responsive


It’s really, really fast; and completely responsive.


I know that it could be faster if it was a native desktop app—but I also know that there are plenty of slow desktop apps, native or otherwise. What matters is the design philosophy, and VSCode has clearly made the right decision.


Buckets of Features


Historically, IDEs have a problem that more and more features keep being added; and as each is added, an attempt is made to put it in some logical place. This ends up creating an onboarding cost for new users: they have to learn the carefully crafted logical structure that has emerged.


Instead, VSCode makes the structure flat: features in buckets, not structured menus.


Want to find a feature? Ctrl+Shift+P brings up the command palette, and you search for it.


Looking for configuration? Search for it.


It makes the UI easy to pick up without sacrificing power.


Excellent Interaction Design


UI design is hard; excellent UI design is really hard.


VSCode has definitely hit the bar for what I’d call excellent UI.


The search and replace widget, for example, is a study in minimalist perfection. When you first trigger a find, a tiny bar appears that gives all the options you need; and then a single click expands it into the more complex—but still minimal—replace widget.


VSCode Find

VSCode Replace


“As simple as possible but no simpler” is a fantastic target if you can hit it—and VSCode does.


Extensible


I haven’t really explored the VSCode ecosystem, but it has everything I need for Dart and Gemini; and setup is a breeze.


In particular, for Dart it can do what IntelliJ does: it has fast and powerful integration with the Dart Analyzer for lints, warnings, suggestions and fixes.


Terminals Are Cool


Of course IDEs aren’t for everything.


I do, in fact, use terminals and the command line extensively.


If you must know: should I need to edit something quickly in a terminal, my go-to editor is `nano`. It gets the job done with absolutely minimal fuss.


For everything else—now—I use VSCode.


Lock-in Isn’t Cool


A big part of what’s going on here is that the success of the Language Server Protocol means the Dart-specific functionality I need can be plugged into any modern editor or IDE.


Language Server Protocol


In one final twist to this story, the protocol came out of the VSCode project, and so all roads lead back to Microsoft. Fortunately, by this point it’s convincingly open and sufficiently widely adopted that lock-in is not a concern, at least not for the short to medium term.


Feedback 📮

👍 Thanks!

👎 Not for me.

🤷 No opinion.

Comments.


So far today, 2024-05-13, feedback has been received 2 times. Of these, 0 were likely from bots, and 2 might have been from real people. Thank you, maybe-real people!


   ———
 /     \   i a
| C   a \ D   n |
   irc   \     /
           ———

-- Response ended

-- Page fetched on Mon May 13 11:36:39 2024