I use an ErgoDox EZ, but I’m not happy with the number of keys. I think it could be easily improved by adding one more row to each side which would get rid of all of the awkward key placements (e.g., brackets, backslash)
I use an entirely custom layout, that’s based on the Planck layout. Here’s a list of things I think most keyboard layouts for “alternative” keyboards get wrong that I’m compiling here because why not. I’ve never had serious RSI, and I’m not an expert on it, these rules come from me having minor aches and pains and looking at what was causing it and making adjustments until they went away.
Do not have only one thumb that can access the space key. The spacebar is by far the most used key, make sure both thumbs can access it.
Do not use the left caps lock for control. I did this for years, and I used to love it, but it promotes bad keyboard habits. You’re supposed to hold down the modifier with one hand, and press the key with the other. That’s why the shift key is on both sides of the keyboard. Using caps lock for control encourages key chording, which forces your hand into unnatural positions.
Make all of your modifiers accessibly via both thumbs. The thumb is the strongest finger, and holding down modifiers puts the most strain on a finger. So use your thumbs to hold down modifiers if possible, and have your modifiers on both sides of the keyboard so you can avoid key chording and distribute the work between both thumbs.
The guiding principle of your layout should be to minimize key chords. This means keyboard layers are bad, because they promote using additional key chords. If you have to have layers (I do myself), use your thumbs to activate them, and try to avoid key chording as much as possible by having one hand hold the modifiers and the other hit the key.
I haven’t found the perfect keyboard and layout yet, so half of these I still violate myself all the time. These are aspirational goals.
These are really good points. It’s interesting that on Maltron keyboards the ‘e’ key was typed with the left thumb as it was the mosted used letter and that way one of the strongest digits was used for typing it. I think thumb clusters are really useful, but I’ve not come across a perfect number of keys for my thumbs yet :~)
Another point I would add to the list is why do only two of the keys have rasied bumps - to locate the home keys F and J? Our fingers are super sensitive - one of my design ideas is to put the braile dots on each key to represent it’s letter / symbol in braille as even if you didn’t know braille your muscle memory and touch sensitivity would allow your brain to know where your fingers are without looking - which would aid in learning touch-typing.
I find it weird of the author to pick “the most popular” as criterion for the longevity of software while at the same time showing how time and time again the popularity of once popular editors has waned. And the reasons why this will not repeat with VS Code are partly debunked by the extensibility of Emacs and partly by showing how many IDEs used to be based on Eclipse back in the day, which also has been, erm, eclipsed, since its heyday.
And at the same time, noted the existence of Emacs and Vim (both essentially originating in 1976) and dismissed their continued use as not relevant to longevity. I don’t know about VS Code, but I am pretty sure that even in 10 years people will write Emacs extensions and I am pretty sure that some form of (Neo)Vi(m) will continue to exist.
It is actually even more baffling how the author mentions Ctrl-C/Ctrl-V as important, while completely dismissing that just about every extensible editor (or browser) has a plugin that more or less well emulates Vi, including VS Code.
Personally I think Stack Overflow is the fairest poll I’ve found, because it has the least obvious bias, but I would love to ear any and all data available on this subject.
Anecdata, but I’ve never participated in any SO poll as far as I can remember, and neither has one of my team mates (most don’t even have an account, only use it when googling for stuff).
While it ranks very highly and is frequently read, the amount of people actively participating is -imho- not representative of developers at large. Also the VS user base is still a bit skewed towards front end and web development, as far as I know - for example the non-Windows C/C++-developers I know mostly don’t.
I simply refuse any online poll to be an authoritative “that’s what developers want”, the participation is usually just too low. Not really worth fighting over though.
I don’t have a better one. But I remember that SO survey, and I can tell you for certain that the way that’s worded, if I answered today, I’d check VSCode, Emacs, IntelliJ and Notepad++.
I use VSCode for PlatformIO because that’s the least painful way I’ve found to build/load/debug code for things adjacent to Arduino, which I use for fun regularly. I use Emacs (with evil mode) for most of my regular editing for which I don’t need tight debugger integration. Todo lists, editing README files, quick and dirty C++ tools, small scripts, etc. I have a subscription to the JetBrains toolbox because I find that its refactoring tools and good build/debug integration make me more productive on things that pay my bills. And I use Notepad++ whenever I’m stuck on a windows box and need to do some nontrivial config editing.
If the question asked what was important to me for productivity, both Code and Notepad++ would fall off. IMO the wording of the question makes it likely that VS Code gets over-reported given the current environment.
Also, I don’t think the notion that backing of a large corporation prevents stagnation holds any water. This is the same large corporation that backed Internet Explorer, which stagnated for years before being replaced with Edge, which stagnated for fewer years before being replaced with a chromium wrapper. Office also had a long period of stagnation (I’d say 1997 - 2013, but others might argue that window down). As did Windows.
I think I could argue that stagnation is not fatal to some software packages, but not that corporate backing prevents stagnation.
But I also think that editing text is not a very “sticky” activity compared to editing vector graphics or spreadsheets. I can switch to any editor that can handle large files and I can come around to like any editor that provides half-assed decent vi emulation. Even emacs, as I mentioned. If MS puts VS Code into IE 6 mode, the ecosystem can move on rapidly.
But I also think that editing text is not a very “sticky” activity compared to editing vector graphics or spreadsheets.
I think you’re onto something here. For the vast majority of people who edit text, Notepad.exe suffices - in that they simply don’t bump up against its limitations. VS Code covers everyone else, up to the tiny minority who obsess over latency, licensing, and ligatures, and who won’t settle for anything lesser.
I agree with all of your points about corporate management, but the problem is there isn’t much point in evaluating corporate management in a vacuum. Essentially there are three models for managing a text editor:
Corporate (Atom/VS Code)
Indie/Solo Developer (Sublime Text/TextMate)
Open Source (Emacs/Vim)
I work on a Mac, so I can’t comment on other platforms, but for the Mac, the problem with #3 is that it hasn’t produced a post-1985 (when many of our current UI conventions were solidified) mainstream text editor. So #3 gets cut off for a separate reason than stagnation, it just hasn’t produce a text editor that works within modern expectations.
We’ve tried #2, and that’s resulted in stagnation (as perceived by the community), with it being a major complaint about both Sublime Text and TextMate.
So #1 is the only option left.
In other words, the question isn’t whether corporate management is reliable in a vacuum, it’s just whether it’s more reliable than #2. It the end of the day, this is all just guesswork, but given the experience myself, and many others in the developer community, have had so far with #2, I’d place my bet today on #1.
(I’ll skip the polling stuff because it essentially boils down to whether you think that polling data is useful or not. I think it’s flawed but useful, but wouldn’t fault anyone for coming to a different conclusion.)
It’s a bit weird to say TextMate originated extensions in a text that also mentions Emacs, the proto-example of a scriptable text editor where nearly everything can be overridden and changed. Of course, vim was scriptable way before TextMate as well with vimscript, albeit in a somewhat more limited way (but the text states clearly that TextMate scripting was rather limited as well)
It doesn’t quite say that TextMate “originated” extensions, but rather that it was “the first popular text editor that was primarily built around extensions”. I’m not very familiar with Emacs, but while it’s very customizable I don’t think it was “primarily built around extensions”? Vim certainly wasn’t around 2004 (although extension usage since then has increased by a lot).
Emacs is very much “built around extensions”, it just calls them modes (edit: some of them – see @zge’s comment below!), and at least one is guaranteed to be active at any time. It’s also the first thing in the “official” description: “the extensible, customizable, self-documenting editor”. In fact, if you squint a bit, even the editor itself is just a bunch of extensions on top of a text processing core.
(Edit: to elaborate a little on the squinting part. Except for a tiny (well…) core, most of Emacs’ interactive functionality is written in Emacs Lisp, which is what you use to write Emacs modes extensions, too.
When you open up a regular .txt file with Emacs, that buffer will have the plain text mode enabled by default – that’s a primary mode which is written in Emacs Lisp and is very much an “extension”, it’s just one of the (hundreds, if not thousands) that come with Emacs by default.
If you enable line numbers display on the window’s left/right side – that’s a minor mode, also written in Emacs Lisp. It’s also one of the modes that ships with the editor nowadays, but there was a time when it didn’t, so it was even more obvious that it was an “extension” :).
Most of your interaction with Emacs happens via primary and secondary modes – which is why I’m saying that, if you squint a little, the whole editor is an extension on top of a text processing core. It’s also the gist of the famous “emacs is a great operating system, it just needs a good text editor” joke – under the hood, emacs is pretty much a Lisp machine environment with a good text processing API and a GUI bolted on top :) ).
Vim certainly wasn’t around 2004
vim’s first release was in 1991! (Edit: but I think you mean it wasn’t built around extensions back in 2004, right? I wouldn’t know :D)
vim’s first release was in 1991! (Edit: but I think you mean it wasn’t built around extensions back in 2004, right? I wouldn’t know :D)
In 2004 you would use stock Vim with maybe a few fairly simple “scripts” which enhance it in some way. That’s not really the same as “built around extensions” where 3rd-party – both large and small – being in common use and core to the “Vim experience”.
Emacs is very much “built around extensions”, it just calls them modes, and at least one is guaranteed to be active at any time.
That’s not quite right, major and minor modes aren’t really extensions, in the sense of a plug-in. For example, not all packages have to be either minor mode major modes, but they would be considered extensions. They might just provide a function, that integrates into a subsystem (think of an xref or capf backend) or create a whole new sub-application (think of Gnus).
There’s actually nothing special about major and minor modes, they are all convention – that separates them from plug-in system provided by other programmes, that have a strict specification of what can be done or not. Packages are just a collection of functions and variables, that are added to the current environment.
Ah, indeed. There are plenty of packages that don’t ship (only) as major modes – I was thinking mostly about the limited scope of editor functions. You’re right!
That’s not quite right, major and minor modes aren’t really extensions, in the sense of a plug-in.
I think instead of framing it in terms of a plugin it makes more sense to say Emacs is a platform, and major modes are applications that run on the platform, with minor modes being smaller tools or utilities for the platform.
M-x tetris is a major mode; M-x eshell is a major mode. The various IRC clients and mail readers are as well, though sometimes they’re more than one.
This is a common source of confusion, with good reason, because perhaps it’s a smaller distinction than I make it out to be? The difference between Emacs and TextMate is that Emacs is an extensible text editor, and TextMate is an editor that can be extended through extensions. In other words, the concept that’s at the heart of TextMate is that providing things like language support and other features should be done by bundling a bunch of source code files that are imported as a package created by an extension developer, then added as a package by a user.
Emacs comes from a tradition of shared scripts, as an extension of personal scripting by users. It’s a subtle difference in theory, but in practice it’s gigantic, because personal scripting by users is (unfortunately) not very popular. My anecdotal observations puts this at about 10% of programmers, generously (I wish it were more popular, I’m a huge scripter myself https://github.com/robenkleene/dotfiles/). But using packaged extensions for language support and others features is incredibly popular, approaching 100% of programmers.
This concept, that the base unit of customization for text editor, isn’t shared scripts stemming from personal customizations, but bundled packages shared by extension developers, is what was popularized by TextMate, and that each of the major subsequent popular text editors built on.
Of course Emacs has largely gone in this direction as well, first with the package.el script from ~2009, which was eventually built-in to Emacs 24 in 2012, along with the rise of the ELPA package repositories.
It’s the final form of progression towards maximizing the power and visibility of extensions, making it immune to being leapfrogged by a new text editor with a more capable extension model.
is such a guarantee to longevity simply by making VS Code “immune to being leapfrogged by a new text editor” :). The author does mention Emacs in their post. It’s been arguably leapfrogged by a bunch of other editors and I don’t know why they think VS Code qualifies as “the final form of progression towards maximizing the power and visibility of extensions”, when Emacs is basically a Lisp interpreter that just happens to ship with a text editor in the default image for some reason.
Extensions aren’t a guarantee that an editor won’t get leapfrogged by others. Emacs has great support for extensions, but they’re written in (what today is) an obscure language and the technology around it (the Emacs equivalent of Electron, if you will) isn’t exactly easy to wrap your head around it in 2020.
Languages and frameworks get obsolete all the time. If the hive mind moves to something else fifteen years from now, VS Code won’t fare much better than Emacs does (in fact, past history of open source corporate projects getting abandoned mostly teaches us that it will fare worse).
(This is in no way specific to VS Code, although I will admit that VS Code’s success is very baffling to me. Years of exposure to embedded programming and bastardized Eclipse IDEs have made me pretty tolerant to these things and still I have no idea how its users manage to put up with VS Code’s latency, for example – I’ve seen remote ssh sessions over very respectable distances with less lag).
(Later edit: also note that I’m saying all that stuff about Emacs with all the sympathy that I’m capable of: I’m using it today, I’ve used it for a very long time, and I’m pretty comfortable with Emacs Lisp!)
I’m using VSCode primarily due to rust development. And I don’t see how it’s slow in any way. It’s still much faster than it takes for me to recompile my stuff ^^ And it’s still faster than eclipse..
I don’t mean it’s slow in terms of “bandwidth” (e.g. how long it takes to open a settings window) – I mean it’s slow in terms of latency. Even on Windows, which I imagine is the platform where it sees the most testing and optimization, and on a pretty fast machine, there’s a very noticeable delay between the moment I press a key and the moment when the character shows up on the screen. On the one hand, I am a very fast typist (I easily get to 110-120 wpm on a good keyboard, and I do 120+ if I’m really trying). On the other hand, it’s ridiculous that I can get one character ahead of a local application! A 3 GHz machine with more VRAM than a thousand Amigas should be no match for puny human fingers!
Last time I tried it on Linux it was way worse than that, I could get ahead of the cursor without even trying, but it was one of the pretty early versions and, okay, it’s Linux, I’m sure there’s some magical Electron setting that you can poke and it works fine afterwards.
This is true of other aspects of the interface, but I guess it’s more understandable there (e.g. opening the “Settings” page results in some pretty visible effort that takes maybe half a second on a slow enough machine? Also, I have no idea how to disable that fading effect in menus and I really don’t understand why that is a thing…).
As I get mildly annoyed every time someone mentions VS Code latency without any numbers (which is every time so far), I’ve went ahead and run some light latency benchmarks:
Would it require significant effort for you to try that with mlterm or uxterm on the same system? Those are the current two champs for me both by feel and as measured using typometer some time ago.
It won’t run with VSCode or with kitty on my current laptop setup, my Emacs times are far off yours for the worse and my jetbrains times are slightly off yours for the better. VSCode feels broadly comparable to emacs on this box, and I’d be curious to see another tool or two that we have in common.
I don’t have Java on this machine – I’ll try to get it later – but from what I recall, the numbers I used to get were definitely worse last time I tried it (1.5 years ago?). Typing lag was very frequently brought up in various forums when I was looking into VS Code back then. Maybe it’s been improved in the meantime.
Reading around the interwebs, it also looks like some extensions can have an impact on typing latency. The Emacs keybindings extension I used (go figure) could have made those figures even worse.
Anecdotally: I switched from plain Vim to VSCode (with the Vim plugin) a couple years ago as my main “code” editor on Linux. I’m on a pretty mediocre laptop and have never experienced any of the input lag that people talk about. But I also disable frilly things like the minimap, language helpers, and other things that get in the way of just typing text into a file.
I seriously looked into it as an alternative to Emacs, which I absolutely love, but I’m not sure will be as tenable to have as a main editor 10 years from now.
Unfortunately, while I could probably live without Emacs Lisp, Emacs keybindings are really not something I’m prepared to let go gratuitously. If VS Code did something that I really need, and Emacs can’t do, I would probably think about it, but right now it’s just not worth the extra effort.
The weird thing about writing this piece is that I tried to make it as objective as possible, but it’s inherently based on personal experience. I was there, I watched TextMate not be able to do auto-complete because its extension model wouldn’t support it, I watched Sublime Text gain more powerful extensions, but still struggle with making them easy to build and install, I watched the explosion of pent up energy around extensions when Atom hit the scene.
At the end of the day your point is absolute right that my subject analysis isn’t proof anything, it’s just that, my subjective analysis. Happy to hear any suggestions about a better way to capture this story.
It’s a pretty good piece, really – considers lots of angles. I don’t really believe in objectivity, especially for such an inherently subjective, uh, subject. The major thing I see missing is some examination of Microsoft’s marketing and positioning within the open source community; especially after they bought GitHub (and thus Atom). The connection between VS Code and the long-established Visual Studio IDE may also be interesting. Also the reaction against VS Code by developers who are suspicious of all the telemetry and such. Somewhat contentious stuff, which might not really fit your purpose for the article.
This other recent story might be of interest too; it’s sort of an opposite perspective on the same topic.
Yeah all of those are really interesting topics, but I don’t think they factor in to the main subject of the piece which is looking at VS Code’s popularity and unprecedented momentum. Perhaps the marketing does? But I don’t see much of an angle there, text editors have succeeded with minimal marketing (Sublime) and with a lot (Atom), do you think there’s something interesting to say about Microsoft’s role?
There’s also an interesting question there about why developers at large don’t really care about things like telemetry, or about what I call “corporate sponsored open source” (a subject I’ve also written about https://blog.robenkleene.com/2019/04/25/visual-studio-code-corporate-sponsored-open-source/ and in fact I came the opposite conclusion then from what I arrive at today).
I disagree with the conclusion of the Sublime Text piece, because I’ve lived through the stagnation of a text editor (TextMate), and it doesn’t really work. Expectations change.
Around here you’ll find plenty of committed emacs and (neo)vim devotees who I guess are behind the curve on the expectations thing. And some kakoune or vis advocates off in left field, I suppose. My own anecdotal experiences:
First laid eyes on Sublime when an old friend brought it home from Silly Valley on his first vacation from his big new job. I was like “what’s that about?” and he said, sheepishly, “about $60”. Later, it was the editor that everybody at my new job seemed to be using, so I hopped on, and grew to appreciate the feature set.
When Atom came out, it was an obvious Sublime clone, but freeeee and heavily promoted by DVCS Central or whatever that giant site was called. The writing was on the wall; it’s hard to compete at the $0 price point. I tried it for a while, found it to be too slow with big files and generally lacking polish.
Then when Microsoft got into the pop open source game, VS Code was an obvious an EEE play, and I know how good they are at that. I could tell they were spending tons of dev effort on it. Once they bought That Git Site, it was clear who was going to win. I tried for a little while it because of some extension I can’t recall, and wasted some effort trying to customize it, but it never stopped making me feel dirty, so I deleted it after a couple months. I’m sure it’s super slick by now, and the ecosystem is clearly thriving.
I guess it’s been a long time since I’ve believed that the success or failure of technologies is primarily driven by their technical merits and flaws. Sometimes a new niche opens up, and the first to market can dominate for a generation, stagnating all the while. I think marketing, historical path-dependence, and network effects can (and often do) outweigh the kinds of factors your piece is focused on.
I was nodding my head along with your comment until this part: “I think marketing, historical path-dependence, and network effects can (and often do) outweigh the kinds of factors your piece is focused on.” If you think my piece doesn’t focus on “historical path-dependence, and network effects” than I’ve failed to communicate effectively in my piece, e.g., I’m trying to capture those points here:
Aggressive development pulls platforms away from the pack because the combination of forward momentum, and third parties building on the platform, is difficult to compete with. This is the same combination that makes it so hard for new entrants to compete with popular browsers or OSes.
(You’re right that I don’t talk about marketing though, as I explained earlier.)
With “driven by their technical merits and flaws”, I think you’re talking about the section on extensions? (I’m asking because I personally wouldn’t phrase it that way, e.g., I’d phrase less as whether the technologies are good or bad, and more about where the boundaries between the platform and the extensions exist. Perhaps that’s a subtle distinction, but mainly it’s about capabilities, and less about whether the technology is “good”.)
But with that said, I do want to tackle the idea of the merits of technology head on, because I think that’s an interesting topic. I think a ton of developers take relative technology comparisons where they don’t matter, like say, React vs. Vue, or Python vs. Ruby, and then extrapolate that to situations where they do matter. Here are some examples where I’d argue technology matters:
Figma is a WebAssembly app. If technology never matters, then you’d have think an app like Figma could exist without WebAssembly?
An explosion of web apps happened in the mid-2000s, along with the birth of a new, framework-driven, approach to web development using frameworks like Django and Ruby on Rails. To believe technology merits don’t matter, you’d have to believe that these frameworks weren’t necessary for this wave of apps to emerge?
Nearly all media manipulation applications, from Blender to Photoshop to the GIMP, to more recent apps like the Affinity Suite and even Figma, are written in C and/or C++. If technology merits don’t matter, I guess there’s another explanation besides those technologies being a good fit for media manipulation applications?
The point is that sometimes the technical merits are important. My piece is making the argument that using web technologies for a text editor, and in particular expanding the capabilities of extensions, fall into the category of technology choices that matter (if you want to characterize expanding the capabilities and integration of extensions in that way, which like I said, I personally wouldn’t).
You could make a argument that they don’t matter in this case (and I’d love to hear reasoning if you believe that). But just blanket saying technology is never factor in the success or failure of a product, just isn’t backed by the evidence in my opinion.
I don’t want to be misconstrued as saying that “technical” merits (ideas, features, ergonomics, “quality”) never matter, or even that they always matter less than “non-technical” factors. I’m just saying it’s a complex stew. When there’s healthy competition, the tug-of-war can go on indefinitely, with new players coming and going over time, and ultimately everybody benefits, at least on the consumer side. Maybe that’s what’s going on here with VS Code.
But it’s pretty easy to get out of that efficient-markets sweet spot, though, especially when talking about a placid and fairly unprofitable little niche that suddenly receives a massive influx of corporate “love” from some 800 pound gorilla with fingers in all the pies steered by an extensive managerial class hierarchy all busily drafting strategy documents. And especially when you have an influx of relatively clueless new grads looking chasing good jobs and glomming on to shiny and fashionable things in the absence of any genuine received wisdom.
Ultimately I don’t really buy that editors are necessarily going to see the same lock-ins and wholesale die-offs that have occurred in the OS and web browser markets, both because of open standards like LSP (and even UTF-8 – at the end of the day we’re all just checking in text files, right?) and because the older approaches still work well for many of us; I just don’t see any conclusive evidence that editor choice is much of a determining factor in programmer effectiveness, overall. Like people who know how to use the unix command line tools, vimmers and emacsers may remain as mildly oppressed minorities, keeping their cultural traditions alive through a long era of aggressive corporate colonization. Lord knows it’s happened before.
Lots of great points in your comment, I don’t think anything is a certainty. At the end of the day I’m making a bet based on the available evidence.
Here’s how I think about the points you brought up:
Extensions aren’t a guarantee that an editor won’t get leapfrogged by others. Emacs has great support for extensions, but they’re written in (what today is) an obscure language and the technology around it (the Emacs equivalent of Electron, if you will) isn’t exactly easy to wrap your head around it in 2020.
While technically true, the reign of the web has already been longer than the reign of Lisp and isn’t showing any signs of slowing down (mobile stats not withstanding). I agree it’s possible the web will be supplanted, I just wouldn’t put my money on it happening.
in fact, past history of open source corporate projects getting abandoned mostly teaches us that it will fare worse
One observation that I left out of the piece is that corporations, first GitHub and now Microsoft, have essentially realized they can own the text editor market for what amounts to a rounding error on their balance sheet. Text editors have historically been maintained by minuscule teams and can be out resourced easily, without corporations breaking a sweat. I don’t think this realization is going to go anywhere, given the value developers building on platforms has to these corporations. This is only half a response to your point, but it’s the reason I’m bullish on Microsoft investing in VS Code longterm.
Funnily enough, I always thought that the because VS Code gained so many users, so quickly, was the reason it was destined not to last long. My understanding is that everything is supposed to work, with minimal configuration, just install this or that “plug in” and it’s ready. That means, that users don’t have an invested interest in, so it’s easier to switch away.
If anything, I think 1. VSC’s state as the reference implementation for LSP, 2. propitiatory Microsoft extentions will keep it alive. But not for decades, the technology it is based on would make that unprobable, and corporate doesn’t guarantee extended support when it’s free – just think of how many Google services were killed.
People writing plugins for it is the investment they are making. And the plugin ecosystem is huge in VS Code, so the collective investment made from users is also huge. I think that VS Code is here to stay for a while.
Probably the best thing VSCode has give all of us is LSP; this makes it a lot easier to build language-specific plugins for $any editor (and the entire model of having an external process taking care of all of that stuff is much nicer too, IMO). This alone ties people less to VSCode (or any other editor/IDE) than a few years ago, since “intelllisense”-like features will work equally well anywhere (given good support for LSP, of course).
Is this really the case? We used to have a supremely customizable browser that was leapfrogged by a way less customizable but faster browser within a few years to the point where the more customizable browser threw out its customizability and adopted the plugin model of its competitor.
You do give a good point. But at the time Firefox ditched XUL it already had problems with the extension community fizzling out. Also to note, the initial Chrome market growth was mainly people switching to it from IE. Anecdotally, Firefox users mainly stuck with what they used until the XUL removal.
That’s true. While not a plugin developer even as a user I remember the frequent issues that plugins would not work in new Firefox versions for a while until they got updated, at which point it again only worked until the next release. I can see as a plugin developer you’d do that once, twice, but if you need to keep up every 6 weeks that’s gonna take a toll.
Yet somehow I think that just throwing out extensibility out the window has made it a worse browser (“Mozilla Chromium”) and if not for my contrarian attitude there is very little to keep me in Firefox-land. Recent firings at Mozilla also have not cast a good light on the long-term viability of the browser.
It’s an investment for the plugin-creators, but not for the people using them. My understanding is that it’s just click-to-install and go. That level of investment can easily be replaced by whatever other editor, that provides the same effort.
You can invest just as much time configuring VS Code and the extensions you install as you can in vim if you really want to. That you can just click a button to install instead of manually downloading a plugin or cloning a repo to your .vim folder or adding some lines to your .vimrc or whatever the process is for installing a package on emacs is nothing but a welcome improvement.
I agree that it’s good to be wary of Microsoft, but for now this is probably the best open source editor available out there and I’m using it as long as it lasts.
Sure, it’s configurable and programmable, but is that usually done? My point was just that, for since most people just install a plug-in, and let it be, these will be the same that could easily move back and forth between other editors with similar capabilities.
The fact that there are specific plugins is important. Companies are starting to create plugins specific for their product for VS Code, e.g. Bitbucket integration or AWS Toolkit. These extensions aren’t that replaceable, so the move between editors gets more complicated. In other words, you could say that some users invest into VS Code by getting used to using specific extensions.
But these extensions will get recreated for the next editor/IDE du jour since Amazon would of course go where people are, there is no inherent connection why AWS Toolkit would require VS Code. I remember the hype of creating IDEs based on Eclipse, but most of them had their lunch eaten by Jetbrains IDEs and VS Code these days.
These big extensions only got created after VS Code got popular; it would make little sense for companies to invest into a tiny niche editor and its extensions.
Right, exactly. I think you’re missing my point - you’re saying that the big extensions will move to the next popular editor, but I’m saying that (what would be) the next popular editor might not have a chance to get popular in the first place because it was missing the big extensions people expect. It’s a chicken-and-egg problem.
So it’s not only propitiatory Microsoft extensions, that are not allowed to be ported to other editors, but also other platforms as well, but third-party service providers as well.
So in other words: Microsoft VS Code is on it’s way to become the Windows of text editors. Should anyone be surprised?
But not for decades, the technology it is based on would make that unprobable
I’d love to hear more elaboration on this. I’m assuming it means because it’s built on the web languages, but from my perspective, if any language is indicating longevity at this time it would be the web languages?
Yes, from my experience, web technologies and preferred practices change a lot, and quickly. I don’t see that as a reliable foundation. Other than that, Electron is based on Google’s Chromium, and with their increasing monopoly over the web, what they will be doing is also a great uncertainty. I’m not guaranteeing anything, just stating my guesses.
Got it, yeah saying preferred practices change a lot in the web world is an understatement. Web technologies have elements of stability (old websites from the 1990s still just work), and elements of instability (how you’re supposed to make a website changes almost everyday). Point blank my view on this is it doesn’t really matter, technology choices are really a problem that only affects resource-strapped projects. E.g., platform momentum can be leveraged to solve technology problems, but no amount of technology improvements will ever create platform momentum. In other words, if the shifting sands of web technology are ever a problem for VS Code, it will be because VS Code is already dead for some other reason.
(Which also means if you want to still be able to use VS Code, even if it’s no longer popular, then technology choice is important. Personally I think VS Code’s value is inextricable tied to its momentum, so that’s not me.)
For snippets in the shell, Fish Shell supports them out of the box with abbreviations and Zsh supports them with a plugin.
I use an ErgoDox EZ, but I’m not happy with the number of keys. I think it could be easily improved by adding one more row to each side which would get rid of all of the awkward key placements (e.g., brackets, backslash)
I use an entirely custom layout, that’s based on the Planck layout. Here’s a list of things I think most keyboard layouts for “alternative” keyboards get wrong that I’m compiling here because why not. I’ve never had serious RSI, and I’m not an expert on it, these rules come from me having minor aches and pains and looking at what was causing it and making adjustments until they went away.
I haven’t found the perfect keyboard and layout yet, so half of these I still violate myself all the time. These are aspirational goals.
These are really good points. It’s interesting that on Maltron keyboards the ‘e’ key was typed with the left thumb as it was the mosted used letter and that way one of the strongest digits was used for typing it. I think thumb clusters are really useful, but I’ve not come across a perfect number of keys for my thumbs yet :~)
Another point I would add to the list is why do only two of the keys have rasied bumps - to locate the home keys F and J? Our fingers are super sensitive - one of my design ideas is to put the braile dots on each key to represent it’s letter / symbol in braille as even if you didn’t know braille your muscle memory and touch sensitivity would allow your brain to know where your fingers are without looking - which would aid in learning touch-typing.
I find it weird of the author to pick “the most popular” as criterion for the longevity of software while at the same time showing how time and time again the popularity of once popular editors has waned. And the reasons why this will not repeat with VS Code are partly debunked by the extensibility of Emacs and partly by showing how many IDEs used to be based on Eclipse back in the day, which also has been, erm, eclipsed, since its heyday.
And at the same time, noted the existence of Emacs and Vim (both essentially originating in 1976) and dismissed their continued use as not relevant to longevity. I don’t know about VS Code, but I am pretty sure that even in 10 years people will write Emacs extensions and I am pretty sure that some form of (Neo)Vi(m) will continue to exist.
It is actually even more baffling how the author mentions
Ctrl-C/Ctrl-Vas important, while completely dismissing that just about every extensible editor (or browser) has a plugin that more or less well emulates Vi, including VS Code.If you even accept the premise.
Based on what? One SO survey?
If you’ve got more I’m all ears!
Here are a couple more:
VS Code 56.6% https://2019.stateofjs.com/other-tools/#text_editors
VS Code 76.4% https://2019.stateofcss.com/other-tools/#text-editors
Personally I think Stack Overflow is the fairest poll I’ve found, because it has the least obvious bias, but I would love to ear any and all data available on this subject.
Anecdata, but I’ve never participated in any SO poll as far as I can remember, and neither has one of my team mates (most don’t even have an account, only use it when googling for stuff).
While it ranks very highly and is frequently read, the amount of people actively participating is -imho- not representative of developers at large. Also the VS user base is still a bit skewed towards front end and web development, as far as I know - for example the non-Windows C/C++-developers I know mostly don’t.
I simply refuse any online poll to be an authoritative “that’s what developers want”, the participation is usually just too low. Not really worth fighting over though.
I don’t have a better one. But I remember that SO survey, and I can tell you for certain that the way that’s worded, if I answered today, I’d check VSCode, Emacs, IntelliJ and Notepad++.
I use VSCode for PlatformIO because that’s the least painful way I’ve found to build/load/debug code for things adjacent to Arduino, which I use for fun regularly. I use Emacs (with evil mode) for most of my regular editing for which I don’t need tight debugger integration. Todo lists, editing README files, quick and dirty C++ tools, small scripts, etc. I have a subscription to the JetBrains toolbox because I find that its refactoring tools and good build/debug integration make me more productive on things that pay my bills. And I use Notepad++ whenever I’m stuck on a windows box and need to do some nontrivial config editing.
If the question asked what was important to me for productivity, both Code and Notepad++ would fall off. IMO the wording of the question makes it likely that VS Code gets over-reported given the current environment.
Also, I don’t think the notion that backing of a large corporation prevents stagnation holds any water. This is the same large corporation that backed Internet Explorer, which stagnated for years before being replaced with Edge, which stagnated for fewer years before being replaced with a chromium wrapper. Office also had a long period of stagnation (I’d say 1997 - 2013, but others might argue that window down). As did Windows.
I think I could argue that stagnation is not fatal to some software packages, but not that corporate backing prevents stagnation.
But I also think that editing text is not a very “sticky” activity compared to editing vector graphics or spreadsheets. I can switch to any editor that can handle large files and I can come around to like any editor that provides half-assed decent vi emulation. Even emacs, as I mentioned. If MS puts VS Code into IE 6 mode, the ecosystem can move on rapidly.
I think you’re onto something here. For the vast majority of people who edit text, Notepad.exe suffices - in that they simply don’t bump up against its limitations. VS Code covers everyone else, up to the tiny minority who obsess over latency, licensing, and ligatures, and who won’t settle for anything lesser.
I agree with all of your points about corporate management, but the problem is there isn’t much point in evaluating corporate management in a vacuum. Essentially there are three models for managing a text editor:
Corporate (Atom/VS Code)
Indie/Solo Developer (Sublime Text/TextMate)
Open Source (Emacs/Vim)
I work on a Mac, so I can’t comment on other platforms, but for the Mac, the problem with #3 is that it hasn’t produced a post-1985 (when many of our current UI conventions were solidified) mainstream text editor. So #3 gets cut off for a separate reason than stagnation, it just hasn’t produce a text editor that works within modern expectations.
We’ve tried #2, and that’s resulted in stagnation (as perceived by the community), with it being a major complaint about both Sublime Text and TextMate.
So #1 is the only option left.
In other words, the question isn’t whether corporate management is reliable in a vacuum, it’s just whether it’s more reliable than #2. It the end of the day, this is all just guesswork, but given the experience myself, and many others in the developer community, have had so far with #2, I’d place my bet today on #1.
(I’ll skip the polling stuff because it essentially boils down to whether you think that polling data is useful or not. I think it’s flawed but useful, but wouldn’t fault anyone for coming to a different conclusion.)
It’s a bit weird to say TextMate originated extensions in a text that also mentions Emacs, the proto-example of a scriptable text editor where nearly everything can be overridden and changed. Of course, vim was scriptable way before TextMate as well with vimscript, albeit in a somewhat more limited way (but the text states clearly that TextMate scripting was rather limited as well)
It doesn’t quite say that TextMate “originated” extensions, but rather that it was “the first popular text editor that was primarily built around extensions”. I’m not very familiar with Emacs, but while it’s very customizable I don’t think it was “primarily built around extensions”? Vim certainly wasn’t around 2004 (although extension usage since then has increased by a lot).
Emacs is very much “built around extensions”, it just calls them modes (edit: some of them – see @zge’s comment below!), and at least one is guaranteed to be active at any time. It’s also the first thing in the “official” description: “the extensible, customizable, self-documenting editor”. In fact, if you squint a bit, even the editor itself is just a bunch of extensions on top of a text processing core.
(Edit: to elaborate a little on the squinting part. Except for a tiny (well…) core, most of Emacs’ interactive functionality is written in Emacs Lisp, which is what you use to write Emacs
modesextensions, too.When you open up a regular .txt file with Emacs, that buffer will have the plain text mode enabled by default – that’s a primary mode which is written in Emacs Lisp and is very much an “extension”, it’s just one of the (hundreds, if not thousands) that come with Emacs by default.
If you enable line numbers display on the window’s left/right side – that’s a minor mode, also written in Emacs Lisp. It’s also one of the modes that ships with the editor nowadays, but there was a time when it didn’t, so it was even more obvious that it was an “extension” :).
Most of your interaction with Emacs happens via primary and secondary modes – which is why I’m saying that, if you squint a little, the whole editor is an extension on top of a text processing core. It’s also the gist of the famous “emacs is a great operating system, it just needs a good text editor” joke – under the hood, emacs is pretty much a Lisp machine environment with a good text processing API and a GUI bolted on top :) ).
vim’s first release was in 1991! (Edit: but I think you mean it wasn’t built around extensions back in 2004, right? I wouldn’t know :D)
In 2004 you would use stock Vim with maybe a few fairly simple “scripts” which enhance it in some way. That’s not really the same as “built around extensions” where 3rd-party – both large and small – being in common use and core to the “Vim experience”.
That’s not quite right, major and minor modes aren’t really extensions, in the sense of a plug-in. For example, not all packages have to be either minor mode major modes, but they would be considered extensions. They might just provide a function, that integrates into a subsystem (think of an xref or capf backend) or create a whole new sub-application (think of Gnus).
There’s actually nothing special about major and minor modes, they are all convention – that separates them from plug-in system provided by other programmes, that have a strict specification of what can be done or not. Packages are just a collection of functions and variables, that are added to the current environment.
Ah, indeed. There are plenty of packages that don’t ship (only) as major modes – I was thinking mostly about the limited scope of editor functions. You’re right!
I think instead of framing it in terms of a plugin it makes more sense to say Emacs is a platform, and major modes are applications that run on the platform, with minor modes being smaller tools or utilities for the platform.
M-x tetris is a major mode; M-x eshell is a major mode. The various IRC clients and mail readers are as well, though sometimes they’re more than one.
Well, almost. those are all just interactive commands, the major modes are respectivly tetris-mode and eshell-mode.
This is a common source of confusion, with good reason, because perhaps it’s a smaller distinction than I make it out to be? The difference between Emacs and TextMate is that Emacs is an extensible text editor, and TextMate is an editor that can be extended through extensions. In other words, the concept that’s at the heart of TextMate is that providing things like language support and other features should be done by bundling a bunch of source code files that are imported as a package created by an extension developer, then added as a package by a user.
Emacs comes from a tradition of shared scripts, as an extension of personal scripting by users. It’s a subtle difference in theory, but in practice it’s gigantic, because personal scripting by users is (unfortunately) not very popular. My anecdotal observations puts this at about 10% of programmers, generously (I wish it were more popular, I’m a huge scripter myself https://github.com/robenkleene/dotfiles/). But using packaged extensions for language support and others features is incredibly popular, approaching 100% of programmers.
This concept, that the base unit of customization for text editor, isn’t shared scripts stemming from personal customizations, but bundled packages shared by extension developers, is what was popularized by TextMate, and that each of the major subsequent popular text editors built on.
Of course Emacs has largely gone in this direction as well, first with the
package.elscript from ~2009, which was eventually built-in to Emacs 24 in 2012, along with the rise of the ELPA package repositories.I’m not sure this point:
is such a guarantee to longevity simply by making VS Code “immune to being leapfrogged by a new text editor” :). The author does mention Emacs in their post. It’s been arguably leapfrogged by a bunch of other editors and I don’t know why they think VS Code qualifies as “the final form of progression towards maximizing the power and visibility of extensions”, when Emacs is basically a Lisp interpreter that just happens to ship with a text editor in the default image for some reason.
Extensions aren’t a guarantee that an editor won’t get leapfrogged by others. Emacs has great support for extensions, but they’re written in (what today is) an obscure language and the technology around it (the Emacs equivalent of Electron, if you will) isn’t exactly easy to wrap your head around it in 2020.
Languages and frameworks get obsolete all the time. If the hive mind moves to something else fifteen years from now, VS Code won’t fare much better than Emacs does (in fact, past history of open source corporate projects getting abandoned mostly teaches us that it will fare worse).
(This is in no way specific to VS Code, although I will admit that VS Code’s success is very baffling to me. Years of exposure to embedded programming and bastardized Eclipse IDEs have made me pretty tolerant to these things and still I have no idea how its users manage to put up with VS Code’s latency, for example – I’ve seen remote ssh sessions over very respectable distances with less lag).
(Later edit: also note that I’m saying all that stuff about Emacs with all the sympathy that I’m capable of: I’m using it today, I’ve used it for a very long time, and I’m pretty comfortable with Emacs Lisp!)
I’m using VSCode primarily due to rust development. And I don’t see how it’s slow in any way. It’s still much faster than it takes for me to recompile my stuff ^^ And it’s still faster than eclipse..
I don’t mean it’s slow in terms of “bandwidth” (e.g. how long it takes to open a settings window) – I mean it’s slow in terms of latency. Even on Windows, which I imagine is the platform where it sees the most testing and optimization, and on a pretty fast machine, there’s a very noticeable delay between the moment I press a key and the moment when the character shows up on the screen. On the one hand, I am a very fast typist (I easily get to 110-120 wpm on a good keyboard, and I do 120+ if I’m really trying). On the other hand, it’s ridiculous that I can get one character ahead of a local application! A 3 GHz machine with more VRAM than a thousand Amigas should be no match for puny human fingers!
Last time I tried it on Linux it was way worse than that, I could get ahead of the cursor without even trying, but it was one of the pretty early versions and, okay, it’s Linux, I’m sure there’s some magical Electron setting that you can poke and it works fine afterwards.
This is true of other aspects of the interface, but I guess it’s more understandable there (e.g. opening the “Settings” page results in some pretty visible effort that takes maybe half a second on a slow enough machine? Also, I have no idea how to disable that fading effect in menus and I really don’t understand why that is a thing…).
As I get mildly annoyed every time someone mentions VS Code latency without any numbers (which is every time so far), I’ve went ahead and run some light latency benchmarks:
https://gist.github.com/matklad/cf9080a2e6c600d05f12263b24e4b12e
Would it require significant effort for you to try that with mlterm or uxterm on the same system? Those are the current two champs for me both by feel and as measured using typometer some time ago.
It won’t run with VSCode or with kitty on my current laptop setup, my Emacs times are far off yours for the worse and my jetbrains times are slightly off yours for the better. VSCode feels broadly comparable to emacs on this box, and I’d be curious to see another tool or two that we have in common.
Tried mlterm, evil compsitor is disabled for the first row.
Thank you. I think that further suggests it’s weird that my emacs setup has latency similar to VSCode and I should figure out why.
I don’t have Java on this machine – I’ll try to get it later – but from what I recall, the numbers I used to get were definitely worse last time I tried it (1.5 years ago?). Typing lag was very frequently brought up in various forums when I was looking into VS Code back then. Maybe it’s been improved in the meantime.
Reading around the interwebs, it also looks like some extensions can have an impact on typing latency. The Emacs keybindings extension I used (go figure) could have made those figures even worse.
Anecdotally: I switched from plain Vim to VSCode (with the Vim plugin) a couple years ago as my main “code” editor on Linux. I’m on a pretty mediocre laptop and have never experienced any of the input lag that people talk about. But I also disable frilly things like the minimap, language helpers, and other things that get in the way of just typing text into a file.
I seriously looked into it as an alternative to Emacs, which I absolutely love, but I’m not sure will be as tenable to have as a main editor 10 years from now.
Unfortunately, while I could probably live without Emacs Lisp, Emacs keybindings are really not something I’m prepared to let go gratuitously. If VS Code did something that I really need, and Emacs can’t do, I would probably think about it, but right now it’s just not worth the extra effort.
Naked whiggery. Kind of precious, really. Definitely to be expected for such a zeal-saturated topic as editor preference.
The weird thing about writing this piece is that I tried to make it as objective as possible, but it’s inherently based on personal experience. I was there, I watched TextMate not be able to do auto-complete because its extension model wouldn’t support it, I watched Sublime Text gain more powerful extensions, but still struggle with making them easy to build and install, I watched the explosion of pent up energy around extensions when Atom hit the scene.
At the end of the day your point is absolute right that my subject analysis isn’t proof anything, it’s just that, my subjective analysis. Happy to hear any suggestions about a better way to capture this story.
Oh hi! Wow! Welcome to Lobsters.
It’s a pretty good piece, really – considers lots of angles. I don’t really believe in objectivity, especially for such an inherently subjective, uh, subject. The major thing I see missing is some examination of Microsoft’s marketing and positioning within the open source community; especially after they bought GitHub (and thus Atom). The connection between VS Code and the long-established Visual Studio IDE may also be interesting. Also the reaction against VS Code by developers who are suspicious of all the telemetry and such. Somewhat contentious stuff, which might not really fit your purpose for the article.
This other recent story might be of interest too; it’s sort of an opposite perspective on the same topic.
Yeah all of those are really interesting topics, but I don’t think they factor in to the main subject of the piece which is looking at VS Code’s popularity and unprecedented momentum. Perhaps the marketing does? But I don’t see much of an angle there, text editors have succeeded with minimal marketing (Sublime) and with a lot (Atom), do you think there’s something interesting to say about Microsoft’s role?
There’s also an interesting question there about why developers at large don’t really care about things like telemetry, or about what I call “corporate sponsored open source” (a subject I’ve also written about https://blog.robenkleene.com/2019/04/25/visual-studio-code-corporate-sponsored-open-source/ and in fact I came the opposite conclusion then from what I arrive at today).
I disagree with the conclusion of the Sublime Text piece, because I’ve lived through the stagnation of a text editor (TextMate), and it doesn’t really work. Expectations change.
Around here you’ll find plenty of committed emacs and (neo)vim devotees who I guess are behind the curve on the expectations thing. And some kakoune or vis advocates off in left field, I suppose. My own anecdotal experiences:
I guess it’s been a long time since I’ve believed that the success or failure of technologies is primarily driven by their technical merits and flaws. Sometimes a new niche opens up, and the first to market can dominate for a generation, stagnating all the while. I think marketing, historical path-dependence, and network effects can (and often do) outweigh the kinds of factors your piece is focused on.
I was nodding my head along with your comment until this part: “I think marketing, historical path-dependence, and network effects can (and often do) outweigh the kinds of factors your piece is focused on.” If you think my piece doesn’t focus on “historical path-dependence, and network effects” than I’ve failed to communicate effectively in my piece, e.g., I’m trying to capture those points here:
(You’re right that I don’t talk about marketing though, as I explained earlier.)
With “driven by their technical merits and flaws”, I think you’re talking about the section on extensions? (I’m asking because I personally wouldn’t phrase it that way, e.g., I’d phrase less as whether the technologies are good or bad, and more about where the boundaries between the platform and the extensions exist. Perhaps that’s a subtle distinction, but mainly it’s about capabilities, and less about whether the technology is “good”.)
But with that said, I do want to tackle the idea of the merits of technology head on, because I think that’s an interesting topic. I think a ton of developers take relative technology comparisons where they don’t matter, like say, React vs. Vue, or Python vs. Ruby, and then extrapolate that to situations where they do matter. Here are some examples where I’d argue technology matters:
The point is that sometimes the technical merits are important. My piece is making the argument that using web technologies for a text editor, and in particular expanding the capabilities of extensions, fall into the category of technology choices that matter (if you want to characterize expanding the capabilities and integration of extensions in that way, which like I said, I personally wouldn’t).
You could make a argument that they don’t matter in this case (and I’d love to hear reasoning if you believe that). But just blanket saying technology is never factor in the success or failure of a product, just isn’t backed by the evidence in my opinion.
I don’t want to be misconstrued as saying that “technical” merits (ideas, features, ergonomics, “quality”) never matter, or even that they always matter less than “non-technical” factors. I’m just saying it’s a complex stew. When there’s healthy competition, the tug-of-war can go on indefinitely, with new players coming and going over time, and ultimately everybody benefits, at least on the consumer side. Maybe that’s what’s going on here with VS Code.
But it’s pretty easy to get out of that efficient-markets sweet spot, though, especially when talking about a placid and fairly unprofitable little niche that suddenly receives a massive influx of corporate “love” from some 800 pound gorilla with fingers in all the pies steered by an extensive managerial class hierarchy all busily drafting strategy documents. And especially when you have an influx of relatively clueless new grads looking chasing good jobs and glomming on to shiny and fashionable things in the absence of any genuine received wisdom.
Ultimately I don’t really buy that editors are necessarily going to see the same lock-ins and wholesale die-offs that have occurred in the OS and web browser markets, both because of open standards like LSP (and even UTF-8 – at the end of the day we’re all just checking in text files, right?) and because the older approaches still work well for many of us; I just don’t see any conclusive evidence that editor choice is much of a determining factor in programmer effectiveness, overall. Like people who know how to use the unix command line tools, vimmers and emacsers may remain as mildly oppressed minorities, keeping their cultural traditions alive through a long era of aggressive corporate colonization. Lord knows it’s happened before.
This is a fair perspective. I appreciate you sharing your thoughts, cheers!
Yep. Repeat after me: there is no telos.
Lots of great points in your comment, I don’t think anything is a certainty. At the end of the day I’m making a bet based on the available evidence.
Here’s how I think about the points you brought up:
While technically true, the reign of the web has already been longer than the reign of Lisp and isn’t showing any signs of slowing down (mobile stats not withstanding). I agree it’s possible the web will be supplanted, I just wouldn’t put my money on it happening.
One observation that I left out of the piece is that corporations, first GitHub and now Microsoft, have essentially realized they can own the text editor market for what amounts to a rounding error on their balance sheet. Text editors have historically been maintained by minuscule teams and can be out resourced easily, without corporations breaking a sweat. I don’t think this realization is going to go anywhere, given the value developers building on platforms has to these corporations. This is only half a response to your point, but it’s the reason I’m bullish on Microsoft investing in VS Code longterm.
Funnily enough, I always thought that the because VS Code gained so many users, so quickly, was the reason it was destined not to last long. My understanding is that everything is supposed to work, with minimal configuration, just install this or that “plug in” and it’s ready. That means, that users don’t have an invested interest in, so it’s easier to switch away.
If anything, I think 1. VSC’s state as the reference implementation for LSP, 2. propitiatory Microsoft extentions will keep it alive. But not for decades, the technology it is based on would make that unprobable, and corporate doesn’t guarantee extended support when it’s free – just think of how many Google services were killed.
People writing plugins for it is the investment they are making. And the plugin ecosystem is huge in VS Code, so the collective investment made from users is also huge. I think that VS Code is here to stay for a while.
Probably the best thing VSCode has give all of us is LSP; this makes it a lot easier to build language-specific plugins for $any editor (and the entire model of having an external process taking care of all of that stuff is much nicer too, IMO). This alone ties people less to VSCode (or any other editor/IDE) than a few years ago, since “intelllisense”-like features will work equally well anywhere (given good support for LSP, of course).
Is this really the case? We used to have a supremely customizable browser that was leapfrogged by a way less customizable but faster browser within a few years to the point where the more customizable browser threw out its customizability and adopted the plugin model of its competitor.
You do give a good point. But at the time Firefox ditched XUL it already had problems with the extension community fizzling out. Also to note, the initial Chrome market growth was mainly people switching to it from IE. Anecdotally, Firefox users mainly stuck with what they used until the XUL removal.
That’s true. While not a plugin developer even as a user I remember the frequent issues that plugins would not work in new Firefox versions for a while until they got updated, at which point it again only worked until the next release. I can see as a plugin developer you’d do that once, twice, but if you need to keep up every 6 weeks that’s gonna take a toll.
Yet somehow I think that just throwing out extensibility out the window has made it a worse browser (“Mozilla Chromium”) and if not for my contrarian attitude there is very little to keep me in Firefox-land. Recent firings at Mozilla also have not cast a good light on the long-term viability of the browser.
It’s an investment for the plugin-creators, but not for the people using them. My understanding is that it’s just click-to-install and go. That level of investment can easily be replaced by whatever other editor, that provides the same effort.
You can invest just as much time configuring VS Code and the extensions you install as you can in vim if you really want to. That you can just click a button to install instead of manually downloading a plugin or cloning a repo to your .vim folder or adding some lines to your .vimrc or whatever the process is for installing a package on emacs is nothing but a welcome improvement.
I agree that it’s good to be wary of Microsoft, but for now this is probably the best open source editor available out there and I’m using it as long as it lasts.
Sure, it’s configurable and programmable, but is that usually done? My point was just that, for since most people just install a plug-in, and let it be, these will be the same that could easily move back and forth between other editors with similar capabilities.
The fact that there are specific plugins is important. Companies are starting to create plugins specific for their product for VS Code, e.g. Bitbucket integration or AWS Toolkit. These extensions aren’t that replaceable, so the move between editors gets more complicated. In other words, you could say that some users invest into VS Code by getting used to using specific extensions.
But these extensions will get recreated for the next editor/IDE du jour since Amazon would of course go where people are, there is no inherent connection why AWS Toolkit would require VS Code. I remember the hype of creating IDEs based on Eclipse, but most of them had their lunch eaten by Jetbrains IDEs and VS Code these days.
If those editors are able to get popular without all the big extensions that everybody relied on having been ported yet.
These big extensions only got created after VS Code got popular; it would make little sense for companies to invest into a tiny niche editor and its extensions.
Right, exactly. I think you’re missing my point - you’re saying that the big extensions will move to the next popular editor, but I’m saying that (what would be) the next popular editor might not have a chance to get popular in the first place because it was missing the big extensions people expect. It’s a chicken-and-egg problem.
So it’s not only propitiatory Microsoft extensions, that are not allowed to be ported to other editors, but also other platforms as well, but third-party service providers as well.
So in other words: Microsoft VS Code is on it’s way to become the Windows of text editors. Should anyone be surprised?
The process for installing a package in Emacs is clicking a button. In this screenshot it looks like a hyperlink that says [Install]
I’d love to hear more elaboration on this. I’m assuming it means because it’s built on the web languages, but from my perspective, if any language is indicating longevity at this time it would be the web languages?
Yes, from my experience, web technologies and preferred practices change a lot, and quickly. I don’t see that as a reliable foundation. Other than that, Electron is based on Google’s Chromium, and with their increasing monopoly over the web, what they will be doing is also a great uncertainty. I’m not guaranteeing anything, just stating my guesses.
Got it, yeah saying preferred practices change a lot in the web world is an understatement. Web technologies have elements of stability (old websites from the 1990s still just work), and elements of instability (how you’re supposed to make a website changes almost everyday). Point blank my view on this is it doesn’t really matter, technology choices are really a problem that only affects resource-strapped projects. E.g., platform momentum can be leveraged to solve technology problems, but no amount of technology improvements will ever create platform momentum. In other words, if the shifting sands of web technology are ever a problem for VS Code, it will be because VS Code is already dead for some other reason.
(Which also means if you want to still be able to use VS Code, even if it’s no longer popular, then technology choice is important. Personally I think VS Code’s value is inextricable tied to its momentum, so that’s not me.)