Live data from Hacker News

Visual Studio Code is designed to fracture

ghuntley.com

81–90 of 149 posts

Re: Visual Studio Code is designed to fracture

#81

I had to use VS Code it briefly for a class, and was kind of shocked by the telemetry stuff, and that it's just ignore-accepted by both the students and the instructors. But what turned me off more was this janky feeling around the whole application, something I don't remember experiencing in many other Microsoft tools, such as VB. It feels like it was designed from the code up rather than from the interface down, an…

FYI you can get around HSTS errors on Chromium-based browsers by typing thisisunsafe. Source: https://chromium.googlesource.com/chromium/src/+/d8fc089b62c...

Additionally, you can remove stored HSTS states using Chrome's chrome://net-internals configuration page.

Re: Visual Studio Code is designed to fracture

#82
The article is alarmist at best.

But it does point out one critical point: if you start using the whole ecosystem because of convenience, you may end up reliying on MS Codespace, and therefore lock yourself in.

The solution seems simple to me: don't put your entire stack in codespace. Make sure you can easily use your whole stack on your own computer, and migrate easily.

Re: Visual Studio Code is designed to fracture

#83
post #79

Earlier quoted context omitted.

But ultimately these applications are still winning based on merit. If somebody created a new editor or browser that was substantially better, nothing's really stopping everyone from moving to it. Now- we can talk about how it's a problem that nobody can afford to build something good enough to compete with what these megacorps can afford to develop and give away for free. But that's a different, older, much bigger d…

You and GP's point is that these applications win on the merits of their user experience. That's not wrong, in fact I'd say that's absolutely true. But it's important to call out that the user experience most people care about has almost nothing to do with whether or not software is open/hackable. Because of that, I would suggest it is realistic that a decade or two from now we could largely lose that feature, and fi…

Yes, we could end up in a world some day where most people are using 100% proprietary cloud-based IDEs.

But then, at worst, we're back where we started. All the open-source foundations we have now will still be there (plus any open bits from the cloud editors, like Monaco and LSP). Anyone sufficiently motivated to avoid using these cloud-based IDEs will have just as many options as they do today, and probably more. I just don't see how this is a loss.

Re: Visual Studio Code is designed to fracture

#84

Here's $0.00. Take it, and buy yourself a real editor. Anything you choose to pay above that goes to needy children in Uganda. corrected per systemvoltage : https://www.vim.org/sources.php

Can't use my mouse with it. And it doesn't look nice. And it requires a shortcut palette different than the OS conventions. I bought VS Code with $0.00 and sent the rest to needy kids in Uganda.

Re: Visual Studio Code is designed to fracture

#85

I don't really understand this post. I'm a supporter of open source and free software and I can also understand wanting to avoid vendor lock-in. However I don't understand how this is Microsoft's fault for building closed source tooling. I'm upset with Microsoft's hypocritical stance on .NET and C# being open source without all tooling being open source as well but when it comes to useful tooling like Codespaces, Pyl…

It is an App Store monopoly problem. Take Google Android as a counterpart.

Android Open Source Project = VS Code (MIT codebase(

Android at Samsung and dozens other = VS Code with Microsoft EULA

Enforced Play Store in vendor phones = VS Code Extension Market Place (not accessible to any other competition)

Google offering dominant services = Microsoft Language Packages (both proprietary => user lock in)

Google abusing it (eg by marketing, subscriptions, ...) = Microsoft abusing it

So what is explained in that article is how you run a monopoly on an open source project. Julia and the DevDiv is doing that. That is understandable (she has to make money to get her bonus) but not good for the rest of us.

Disclaimer: .NET fanboy

Re: Visual Studio Code is designed to fracture

#86

Earlier quoted context omitted.

> The situation with bad application behaviors being "baked into the code" and propagating to all the "free" distributions is very sad, similar to what's happening with both Chrome and Firefox. > For example, HSTS is now baked into the all the standard distributions and there's absolutely no way (that I've found) to turn it off. I understand the "security" reasons behind it for regular users, but as someone mindful a…

They aren't the only one; many people have similar opinions (including myself), that it should do what the end user specifies instead of what the server specifies. Better web browsers will need to be written, and it isn't so simple to do. (I have some ideas about it, though.) (You are right that HSTS is a response header, but I think that it is a bad idea. Even though I have a old version of Firefox, I had to edit on…

> Even though I have a old version of Firefox, I had to edit one of the files to make it unable to recognize that response header, and change many other things.

You can edit newer versions too. It’s fully open source, the world is your insecure oyster!

> You are right that HSTS is a response header, but I think that it is a bad idea.

Fortunately for both of us, I can enjoy the good idea and you can enjoy exposing yourself to potentially compromised websites! Hopefully no one is harmed.

Re: Visual Studio Code is designed to fracture

#87

Here's $0.00. Take it, and buy yourself a real editor. Anything you choose to pay above that goes to needy children in Uganda. corrected per systemvoltage : https://www.vim.org/sources.php

Can't use my mouse with it. And it doesn't look nice. And it requires a shortcut palette different than the OS conventions. I bought VS Code with $0.00 and sent the rest to needy kids in Uganda.

Vim has had mouse support for a long time.

Re: Visual Studio Code is designed to fracture

#88

Even developers are taken for a ride. Just like WhatsApp and Chrome, it all comes down to ripple effects of "If others didn't use it, I can't". I have given a number of examples of this stubborn sticky monopoly below. Every newbie while learning to code: scared of reviews on internet like "I couldn't get help with this editor online or with colleagues and I can't risk being stuck on this project so I switched to VS C…

That is not EEE. But monopolistic behavior.

Re: Visual Studio Code is designed to fracture

#89
post #48

Earlier quoted context omitted.

The consequences for the majority are such that, over time, leading language ecosystems become tied to Microsoft services. One example in the article is the availability of alternative editors and IDEs decreasing over time in favor of extensions to VSCode. Essentially, we are driving towards a monoculture - either you are using VSCode and adjacent services, or you choose an alternative, pay the price of compatibility…

On the other hand, we now have LSP.

Their strategy is a mixed bag. They want to maintain that in an open source way but they work very hard that their experience is the best so they can capitalize on that. Not a new playbook.

Re: Visual Studio Code is designed to fracture

#90

This is a good summary of the playing field, but I think they're way overblowing the panic In summary Microsoft has: - Made an incredibly good web-based code editor which is 100% OSS, no strings attached - Made an extensions repository and a bunch of really high quality first-party extensions that have restricted licenses Sure, in a perfect world the whole thing would be fully OSS. But in the worst-case, where people…

I'm not quite as sure. To me, its kind of like saying "well, we don't have to worry about global warming, oil is awesome and if it gets too bad we always have Mars". Which, I can explain a little bit because that analogy maybe only make sense in my head.

I can't think of very many, if any, examples in computing history where a project, open source or not, followed the path of "dominating a domain" -> "sponsor does something crappy" -> "the community rallies around a fork" -> "the fork becomes a dominating force in its domain". I'm really sitting here trying to think of examples to help disprove this thesis, and would love to hear them. LibreOffice may be a good example. I can also see an argument for Oracle/proprietary SQL vs MySQL/Postgres. The NodeJS/iojs situation from years ago is, I think, a hallmark case-study in open source that more-so skips the "rally around the fork" step, but is nonetheless worth mentioning. There's probably dozens of examples in the "random esoteric npm library" domain, but those aren't hitting a thousandth the scale that the gigaprojects like VSCode do.

There's a far more common path for projects, however. I'll pick on MongoDB as an example; they did something kind of crappy, with their GPL-wearing-a-trenchcoat-proprietary license which, in my experience, all but killed the database for some companies I've contracted with. These companies (users) took that opportunity to move to a truly open source solution, like MySQL. The move, in all cases, was long; arduous; cost a lot of development time; and they were happy in the end.

Circling back to the metaphor; there's a hypothetical migration path for anything. Its near-laughably trivial to even list that as a triaging factor for "well, they could be evil, they could turn evil, burning oil could destroy our planet, but at least we have Mars." Computers are turing machines, anything can be rebuilt. That's not the point. If we opt in to an environment which is only deemed acceptable because of a Plan B, it behooves anyone with investment in that environment to think critically about the probability of being forced to implement Plan B, and the cost of that implementation.

Circling back to the examples: one is behooved to analyze this through the lens that Plan B may not be the Plan B one thinks it is. If VSCode jumps the shark; will vscodium take its place? MongoDB jumped the shark, and no one was there to catch it; those people who were left wading in the water had to invest significant engineering time transitioning to something entirely different. VSCode is more than just Code; its the users, its the marketing, its the trademark, its the extension standards, its the governing body, maturity, maybe even patents, its all these things which vscodium does not have.

Post reply on HN