Microsoft mangles VS Code protected properties to prevent UI customization

From reading the actual messages, the &quot;to prevent UI customization&quot; 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.<p>&gt; 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.<p>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.

In my opinion the underlying outrage isn&#x27;t about this pull request in particular, it&#x27;s about a failure to allow simple customizations like changing interface font sizes from otherwise hardcoded values. [1] It&#x27;s a usability and potentially accessibility issue, not an aesthetics issue.<p>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&#x2F;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.<p>1. <a href="https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=iocave.customize-ui" rel="nofollow">https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=iocave.c...</a><p>2. <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;519">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;519</a>

I don&#x27;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&#x27;t really see how Microsoft is supposed to be in the wrong here.

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:<p>&quot;Initiate Emacs.&quot;<p>The GNU splash buffer smiles lovingly at me.

I gave up on contrfor VScode after I found it impossible to &quot;contribute&quot; to some of the features to fix some show-stopping bugs. The source is simply not available for some features (e.g. remote containers).<p>Ironically, these bugs only seem to occur on windows. It seems the devs (all microsoft employees) all run mac and&#x2F;or linux! There was a running joke on the issue trackers suggesting we donate windows licenses to the devs.

One of the nice things about open-source is that if you don&#x27;t agree with a change you can revert it.<p>In this case name mangling might be disabled by removing one line <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;pull&#x2F;166126&#x2F;files#diff-e05f6f1e81b687da98f621f2abc1a5303ce8da9b9d07d697ab2d24aa4b7443b2R143">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;pull&#x2F;166126&#x2F;files#diff-e...</a>. Or if not it&#x27;s still trivial to remove everything added by this commit.<p>In fact, there&#x27;s already an actively-maintained fork of VSCode which removes the telemetry (VSCodium), they could easily remove the name mangling as well.

What? It seems like they literally just renamed some private properties. How is it a big deal? Am I missing something?

When people said this change was outrageous, Microsoft censored their comments, calling them &quot;abuse&quot;.

Good software engineers don&#x27;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.<p>Compare to Linus&#x27;s approach: <a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2012&#x2F;12&#x2F;23&#x2F;75" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2012&#x2F;12&#x2F;23&#x2F;75</a>

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.

Can someone summarize this in a couple sentences someone who merely uses VS Code as an IDE would understand?

that reason for mangling was so casually said it’s ridiculous. wtf?

Outrage mongering at its finest.

LOL, ok. We have many reasons to hate on MS (their approach to privacy mainly) but this is not one of them.

This title is sensational. The stated reason was to reduce bundle the size which saves both bandwidth and decreases the start up time of VS code.<p>These extensions were depending on variable names that weren&#x27;t part of the API.