I'm not really making a point. Making comparisons like this or the OPs flagrant political comparison is silly at best and completely dishonest at worst.
> Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.
Sure, and Emacs has this with MELPA (And Atom with... whatever they have). It's great paradigm and all editors should have it.
But I'm not talking about thousands of lines of copied elisp. I'm thinking about molding your editor to fit your needs. Here's an example:
We use hosted Gitlab at work. I like to highlight a line in my editor, call a command in the editor and get a URL for that line in that file in that branch on our internally hosted Gitlab server (with a custom path segment prefix). This is literally maybe ~40 lines lines of very compact elisp in a global configuration file. It would probably be less in JS because I'm better at JS than elisp. It's very specific to my circumstances and doesn't really need to be generalized to anyone else.
There are ~5 different plugins in the marketplace that purport to do this, but none of them fit my use case. Which is fine, I can do this myself...
However to do this vscode I have to create an extension, edit the package.json to register the command and few other things (this is tedious, believe me), re-read/remember the plugin API, re-read/remember how to build vsix files for production, install that plugin with the command line tools, reload vscode.
If I need to make a change, do it all again. But there is no reason that the Emacs behavior couldn't be included in vscode. And maybe some day it will. But the idea that not having it and claiming that is a _feature_ or (as others have done) claim that emacs is losing to vscode in configurability misses the multitude of use cases that emacs users have benefited from for decades.
As far as testing and code quality goes, I can't really argue with that but neither can vscode users? Do you know what all your plugins are doing in the background? All of these centralized plugin repositories are significant attack vectors. Which language do you think the first big own will be written in?
Have you looked at the VS Code marketplace? It is not great. The LSP modes are great and then here and there you get interesting extensions, but a bunch of it I would not call higher quality by any means.
(I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)
vscode can only be customized by an extension. There's a bunch of one off plugins you have to install to get little bits of functionality that you can get by pasting 15 lines of elisp from the emacs wiki. If no one has built that extension yet, you have to learn to build one yourself. You could always create private "personal" extension and keep it local, but that workflow is tedious.
I'm not saying vscode is less extensible or customizable though, I'm saying there's a barrier to ad-hoc personalization that's will keep it from ever being more easily customized (unless you and I have different definitions of what is "easily customized").
Script Commands[1] is an interesting plugin that attempts to address this shortcoming, but I'd like to see something official at some point.
Folks can data dredge and present their results as significant. Lay people trust the conclusions. They had the data, but they didn't understand that the data presents a narrow view. They trust it blindly.
Worse are the people that treat conclusions drawn from polling and surveys as scientifically rigorous.
Happens all the time with Vox, NYT, Quartz, you-name-it articles. Policy is enacted from information like this.
> There's nothing more annoying than a web designer saying "I know better than you" and re-implementing features. Because they're usually wrong.
It's not just that they are saying "I know better than you", they are saying they know better than HCI teams that have spent years tuning interfaces in response to actual research and testing. Most of the web and app designers I've worked with have never watched a person use their designs, much less considered their work in the context of the entire OS experience.
This does more than proxy, the genius proxy alters not just the underlying code that makes the content, it alters the way the content is intended to be consumed.
