The comment marked as abuse is a single word “outrageous” after many substantial opinions have been voiced, in a heavily-followed issue. I would mark it as spam ten out of ten times in my own repos.
I wish they (and all repo caretakers) would do this more often. Each comment notifies every person who subscribes to an issue, and if that comment adds nothing other than an information-free expression of feels that no-one other than the feeler is interested in, that notification is spam. Every moronic "+1" or "any update on this issue" or "outrageous!" could spam thousands of people.
I've had to unsubscribe from many issues I'd like to follow because of spam caused by information-free comments.
the vscode team made a change to shorten private properties in the minified source code which saved ~1.8MB off of the binary size.
There are extensions that used some of these private properties to change the UI of the editor, as well as other things I'm sure, and now they won't work since the property names are mangled.
They probably didn't do this to intentionally break those extensions, but it was a side effect.
VSCode has an API for extending it, but you can dive into its Javascript guts and mess with the UI more than said API allows.
MS is pushing a change that will break any extensions that were diving into said guts (but also shrink their code a bit).
One such extension was described by its own creator as
> basically a pile of hacks that works by monkey-patching javascript in browser and main processes, which is something that regular extensions can not do, and probably for a good reason :)
-
I clicked on the link fully prepared to be outraged, but I walked away 50/50 on it: it's true that even if you don't officially support a hack, if enough people use said hack, you'll break things for real users when you change stuff that was supposed to be an implementation detail.
I'm guessing this is being done to free them of cases where that was already being worked around internally, and not outright malice judging by the language being used
From reading the actual messages, the "to prevent UI customization" in the HN headlines seems to be editorialization. They explain in the comments that it was to reduce bundle size and it produced a measurable improvement in load times.
> We are doing this to save bandwidth and startup time. Mangling allowed us reduce the size of our renderer JS bundles by ~13% (-1.5MB). This yields in ~5% faster code loading. Similar numbers apply to the main and extension host bundles.
These were private properties, not part of the exposed API. Plugins that depended on these were prone to breakage anyway, as is the case with using any private API.
No reasonable developer would expect these extensions to not eventually break, and yet, because Microsoft is being implicated, the outrage will continue.
Maybe no reasonable developer would (depending on how you define reasonable), but any software project with a non-trivial user base would have unreasonable users. That’s why xkcd 1172 is popular and Hyrum coined it as a Law.
I don't really see the problem? If your extension relies on private properties the onus is on you that it might break at any time without notice. The title is highly misleading as well, the change was made to reduce the bundle size and startup speed, a 5% change is considerable. While I understand the frustration that something that used to work no longer works, I don't really see how Microsoft is supposed to be in the wrong here.
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
My answer was why Microsoft "might" be wrong here. If you look at the history of Windows, Microsoft has compromised because people have relied on behavior like if the windows version is less than XP allow this software to run. So, they hacked some tricks that windows 7 was also able to run windows XP softwares even those software ran version checks.
The problem here is Microsoft didn't provide customization for "technical" reasons. So, a user had no choice but to rely on private fields because they were truly facing some accessibility issues. I also don't like the way VS Code wastes vertical space. Hence, they also broke my vscode ui. I will personally disable upgrade.
The big deal is that 100K+ users were relying on those properties not being mangled so that they can use an extension that allowed them to customize arbitrary pieces of the UI to make it more ergonomic for their screens (change fonts, change paddings, hide elements). Personally, the default UI wastes too much of my laptop's screen space, so when I want to edit multiple files plus having a browser on the side, it's just impossible without these tweaks, so this is a deal breaker, as I can't update VSCode anymore unless this is addressed somehow.
edit: And it's strikes me as odd that you'd want to basically screw over all the demographic of what is your "power users", meaning those that have the ability and the desire to tweak things.
The year is 2080. With a cup of joe I swivel around into my VR space zone (automatically projected into my retina). Bio-reading authenticates, dissolving and summoning my desktop background of Richard Stallman. Internal stats flicker green in the top right corner. Only one voice command remains:
In fact, there's already an actively-maintained fork of VSCode which removes the telemetry (VSCodium), they could easily remove the name mangling as well.
I gave up on contrfor VScode after I found it impossible to "contribute" to some of the features to fix some show-stopping bugs. The source is simply not available for some features (e.g. remote containers).
Ironically, these bugs only seem to occur on windows. It seems the devs (all microsoft employees) all run mac and/or linux! There was a running joke on the issue trackers suggesting we donate windows licenses to the devs.
In my opinion the underlying outrage isn't about this pull request in particular, it's about a failure to allow simple customizations like changing interface font sizes from otherwise hardcoded values. [1] It's a usability and potentially accessibility issue, not an aesthetics issue.
In no way was this pull request intentionally targetting compatibility with this extension. But adding exactly this and similar customizations has been requested since 2015 [2] and the requests are either ignored or dismissed, not out of malice. I understand the frustration of feedback being ignored and having to deal with UI or compatibility breaking changes for the sake of some improvement without clear impact. User customizable UI/UX is worth an extra few seconds loading time, in my opinion and the only option is downgrading. Some other people seem to agree and have similarly chosen to downgrade (15 thumbs up in that locked pull request thread). Title is wrongly sensationalized.
VS Code seems to have management issues because it is so much unlike the process of developing .NET runtime, another MSFT-managed project, where merging a change that breaks a substantial amount of users is unthinkable, and if a particular feature gets such a one-sided feedback it is returned back for further redesign.
Good software engineers don't defend breaking changes by hiding behind their API documentation. They know that that certain behaviors that are depended on by a large number of users are as good as public regardless of what the spec says.
33 comments
[ 3.1 ms ] story [ 83.1 ms ] threadI've had to unsubscribe from many issues I'd like to follow because of spam caused by information-free comments.
There are extensions that used some of these private properties to change the UI of the editor, as well as other things I'm sure, and now they won't work since the property names are mangled.
They probably didn't do this to intentionally break those extensions, but it was a side effect.
MS is pushing a change that will break any extensions that were diving into said guts (but also shrink their code a bit).
One such extension was described by its own creator as
> basically a pile of hacks that works by monkey-patching javascript in browser and main processes, which is something that regular extensions can not do, and probably for a good reason :)
-
I clicked on the link fully prepared to be outraged, but I walked away 50/50 on it: it's true that even if you don't officially support a hack, if enough people use said hack, you'll break things for real users when you change stuff that was supposed to be an implementation detail.
I'm guessing this is being done to free them of cases where that was already being worked around internally, and not outright malice judging by the language being used
These extensions were depending on variable names that weren't part of the API.
> We are doing this to save bandwidth and startup time. Mangling allowed us reduce the size of our renderer JS bundles by ~13% (-1.5MB). This yields in ~5% faster code loading. Similar numbers apply to the main and extension host bundles.
These were private properties, not part of the exposed API. Plugins that depended on these were prone to breakage anyway, as is the case with using any private API.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
[1] https://www.hyrumslaw.com/#
The problem here is Microsoft didn't provide customization for "technical" reasons. So, a user had no choice but to rely on private fields because they were truly facing some accessibility issues. I also don't like the way VS Code wastes vertical space. Hence, they also broke my vscode ui. I will personally disable upgrade.
edit: And it's strikes me as odd that you'd want to basically screw over all the demographic of what is your "power users", meaning those that have the ability and the desire to tweak things.
"Initiate Emacs."
The GNU splash buffer smiles lovingly at me.
In this case name mangling might be disabled by removing one line https://github.com/microsoft/vscode/pull/166126/files#diff-e.... Or if not it's still trivial to remove everything added by this commit.
In fact, there's already an actively-maintained fork of VSCode which removes the telemetry (VSCodium), they could easily remove the name mangling as well.
They already did.
Ironically, these bugs only seem to occur on windows. It seems the devs (all microsoft employees) all run mac and/or linux! There was a running joke on the issue trackers suggesting we donate windows licenses to the devs.
In no way was this pull request intentionally targetting compatibility with this extension. But adding exactly this and similar customizations has been requested since 2015 [2] and the requests are either ignored or dismissed, not out of malice. I understand the frustration of feedback being ignored and having to deal with UI or compatibility breaking changes for the sake of some improvement without clear impact. User customizable UI/UX is worth an extra few seconds loading time, in my opinion and the only option is downgrading. Some other people seem to agree and have similarly chosen to downgrade (15 thumbs up in that locked pull request thread). Title is wrongly sensationalized.
1. https://marketplace.visualstudio.com/items?itemName=iocave.c...
2. https://github.com/microsoft/vscode/issues/519
Compare to Linus's approach: https://lkml.org/lkml/2012/12/23/75