[heather45879]

Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations?

If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about.

That being said, it’s very stable and performs well—I will give the devs a massive kudos for that. Also if I did a lot of NodeJS dev work it would probably classify as a proper IDE for that.

But all-in-all I would prefer something purpose-built with minimal configuration out the gate for development workloads (C/C++, Java, C#) and a more minimal editor (nano, vim, eMacs, notepad++, geany, etc) for editing configs.

[pizza234]

These seems impression by somebody who's not a VSC user at all. Specifically:

> it’s 2022, why not favor GUI configurations?

VSC provides, at all the (four) levels, both GUI and text-based configuration editing.

> JSON is ugly

You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).

> too powerful to edit simple configs

Editors are complex by nature; other editors are not different.

It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.

> it auto-updates every time I start it

VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.

Plugins do auto update, but one can disable this, if they want.

> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about

There is no default configuration that satisfies all the users; this is not specific to VSC.

Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.

[drschwabe]

> You can't get any simpler than JSON.

Actually a plain text file containing a JavaScript object is simpler and prettier than JSON.

Not universal across languages though I suppose.

[pizza234]

JSON, as used in VSC, can be defined as "plain text file containing an object", as configuration files have a hash map as root-level object.

AFAIK the difference between JSON (as used in VSC) and a Javascript object are minimal (no quoting for keys, possibly minor other differences) and using a JS object should have significant advantages in order to replace a de-facto standard.

[drschwabe]

`Template literals ie- multiline strings without needing escape or newline characters is a signficant advantage of JS object over JSON`

some will argue that scripting would thus be possible if the config was simply JS but that is a rabbit hole both on the debate itself and then the potential compexlity of config; there are trade-offs for/against but not a settled matter IMO as there are major projects like neovim that support full fledged config scripting (in the case of neovim they allow use of Lua)

[Conscat]

If you like JSON that much, obviously you haven't yet seen https://github.com/Enhex/Deco

[pizza234]

I've never wrote that I "like JSON that much".

What I "like that much" is the pragmatism (which, again, I didn't write) of the choice to break the JSON standard and introduce features that are significant for configuration files (comments, essentially, and to a very minor extend, trailing newlines in arrays).

I've never seen Deco, but it's not an established standard. Based on the repository, it has no grammar and it even leaves details to the implementations (e.g. multi-line strings). The simplicity comes at a cost, for example, to represent leading whitespaces.

If one asks 10 developers which format they'd use, they'd choose 10 different ones, therefore a certain level of standardization is required.

[internetter]

It's like yaml and json had a baby.... And it scares me

[charrondev]

As far as I know most configuration can be done through GUI. You have both JSON and GUI views of the preferences. It seems the GUI is automatically generated from the JSON-schema that validates and gives autocomplete to the JSON editor.

[heather45879]

VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.

[lamarcke]

It's sad that you were downvoted for this because you are not wrong at all. VS Code GUI config is a mess, and a lot of the settings are not available there. I just got used to messing with the JSON autocomplete.

[kevinmchugh]

> it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations?

GUIs can change layout and users have to spend time learning where things are. Someone who is using a text editor is probably comfortable editing text.

[heather45879]

Well unfortunately that’s a typical assumption developers make. “It’s an editor, Bob! The users ought to know how to read JSON!” Well thought-out UIs actually help the user find things and they don’t need to change all the time.

Unfortunately, even though we engineer with code, reading long streams of text is actually a terrible user experience by itself.

Good user experience should hold the user’s hand through the process so they don’t need to sift through a haystack of configurations.

VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.