Microsoft is forking VSCode open source community by split licensing for source code and and official build of VSCode. If you build by yourself you can’t connect to VSCode is marketplace.
This allows them to fully control VSCode telemetry and reporting along with use on platforms such as Gitpod. It’s similar to how Apple controls apps on iPhone and in turn control how much you need to pay them if you earn money on it.
In long run everything going on cloud and SaaS/ PaaS platform holding the keys to developer tooling gate such as VSCode, Microsoft has unfair advantage over other competitors and still keep benefits of OSS
Some of us were suspicious of the “new Microsoft”, mostly because with the exception of a few projects (VSCode among them, and not anymore), nothing really changed. Turns out, we weren’t wrong.
This looks really great, and nice to see both Github and Gitlab moving in this direction - ability to have IDE in the browser is great for many use-cases.
However, I am a bit worried that it looks like most of these companies and up using VSCode. It really needs to have a good competitor in this space, and I hope JetBrains can match that eventually with partnerships of their own.
The way that VS Code is spreading, and the stranglehold Microsoft has on development and direction of the product, give me very strong IE4/5/6 vibes. I really hope some of the open source alternatives that aren't corporation-controlled gain traction over the next year.
I moved from vim to VS code as I found the vim IDE experience slightly lacking. Recently I've found myself getting more and more fed up with how sluggish VS code feels.
With the push from a friend, I tried neovim with the requisite LS plugins and I'm never going back. It's lightning fast and has feature parity (at least the ones I use) with VS Code.
Its a bit of a bitch to setup, but there are preconfigured solutions out there (NVChad, LunarVim, AstroVim) if you want to skip all that bullshit and just get coding...
Seconded. Neovim with their built-in LSP is so good! Was a happy VSCode user for years but not very comfortable with how they’re starting to push more and more proprietary pieces, so started looking for alternatives. Neovim fits the bill perfectly.
Helix is another one to watch. Not quite at Neovim’s level and may need some reprogramming of the vim muscle memory but definitely promising!
NvChad is excellent. I recently finished converting my older .vimrc-based configuration to an entirely lua-based one on top of the base NvChad setup and it‘s just perfect.
Unlike IE, VS Code is open source though. If Microsoft does some terrible thing with VS Code, the community can just switch to VSCodium: https://vscodium.com/
It's not. VSC is a packaged version of the open-source code with proprietary bits added. Integration with the plugin marketplace, telemetry, etc. VSCodium does not have that.
In addition, a lot of the good language plugins are proprietary, like PyLance and the C# plugin.
This doesn't really match since the "Embrace" part is different.
The classic formula was "embracing" an established standard, making proprietary extensions to that standard, then using the adoption of those proprietary extensions to extinguish the original standard's market share.
In this case, Microsoft didn't embrace an existing code base or standard, they made one and open sourced it. What would the analagous "extinction" bere here? That they eventually stop releasing updates to VSCode as open source?
While I agree that there is good reason to doubt Microsoft's intention to be a good steward of an open source project, this seems less like another iteration of that playbook and more like what a lot of "open source" for-profit companies do where they have an open core but keep many features proprietary so they can't be easily forked.
It is quite easy to see that the "embrace" is to release a core into the open source world. They embraced the idea of open source and released something, they extended the user base into the world of the non-free option. The thinking is if they can get a critical mass of folks onto the option that is non-free, they will extinguish the free option by no longer supporting it.
And this is not much different from the things they did this with back in the day. Used to, you wouldn't target open source, as much as you would student audience. The battle used to be more over what corporate workforces would want and use. The open source development scene changed that a bit. Though, it is kind of... interesting to consider how many tools and ideas have been lost in that process.
> The thinking is if they can get a critical mass of folks onto the option that is non-free, they will extinguish the free option by no longer supporting it.
I assume you mean "non-free" as in speech, not beer, since VSCode is free. Hasn't that "critical mass" been the case since day one? I can't imagine that VSCodium built binaries have ever had more than a tiny fraction of the user-base of VSCode? Thus I don't see how "Extinquish" plays a role here.
I still think it makes more sense to think of the strategy as more akin to the FOSS-washing / freemium models used by many companies.
Yes, non-free as in speech. Though, if they were to flip it from the "beer" sense of the term, I'm not entirely clear that would make much difference. As long as they have tripped the critical mass of the userbase.
And it is very similar to the freemium models used by many companies. Apologies if I made that sound like a disagreement. I think the point was more that Microsoft doing it is part of their old game plan. Random companies acting in other means is a bit of a non-sequitur. That said, I think it is common idea that many other companies have tried to extinguish competition in their "free" market? That is, many companies do what they can to make it easy for hobbyists and such to use things for free, but as soon as you are in a company, they try to milk the company for fees.
There are several android distros that provide support for a de-googled installation. Calling it "impossible" seems like a bit of a stretch, though there are definitely limitations, even with microg installed.
I do think that the VSCode model is much more similar to the Android model (though Android is a more extreme version of the model) than either is to the "Embrace, Extend, Extinguish" model.
There is a difference, and that is that you can use something like Jetbrains and your coworker can use VSCode with issues, but if 99% of people use a browser that renders HTML/CSS differently (and I will argue better than the competition at the time) then you are forced to acquiesce to it.
What’s happening is teams will prioritize and prefer only VSCode. So while technically you can, may be, get Jetbrains to work, it’ll be subpar. After a while you just give up and switch to what everyone in the team uses. It’s already happening to me - my team uses VSCode and it comes with a nice devcontainer that’s fully configured. With Jetbrains I’m doing it all myself.
I randomly typed in the word "lines" into a pacman search and discovered the existence of the lines IDE [0]. Never heard it mentioned anywhere before. I know nothing about it, I was just experimenting with pacman search out of boredom.
Interestingly, Netbeans (though strongly Java focussed at the time) once had a fantastic collaborative coding plugin at one time, based on XMPP. It got killed because Sun wanted to foist their own "via Sun servers" thing on everybody. Needless to say, both solutions died on the vine. How sad.
Browser-based BS... I'm never going to buy it. Personal prediction (contact me if you're willing to put Swiss money on it; I am!) - in 5 to 8 years' time the pendulum will be swinging back to device-/locally-hosted apps because of $unforeseen-issues. And fashion.
JetBrains seems to be forging ahead with their own Space project and not trying to partner too closely with any existing forge. They seem to understand "IDE-in-browser" undermines their fundamental market position; they need to make people not need the browser in the first place, to retain it.
JetBrains' fundamental market position is that companies pay per seat for an it-just-works IDE. So if anything, IDE-in-browser, where code is executing on a hosted backend, is even more aligned with this.
The real question is whether they can execute on this. Will they be able to replicate years of VS Code's work on providing UI extensibility without sacrificing performance, with a team that historically had been JVM rather than JS/TS experts? Will they be able to build the right abstractions to allow for temporary network outages and all the distributed-systems challenges that come with that? It's quite a moonshot to get to the level that people expect of VS Code, especially as Microsoft has access to relatively-limitless capital in ways that JetBrains, which has not taken outside investment, does not.
I’m confused by this comment. Why do they need to move to browser-based JS/TS?
Their existing toolchain is all about doing everything in the IDE. (Remote dev envs, code review, all of it).
Am I missing something? I haven’t seen anything which suggests they are going down the path you refer to here. A local client they own is their differentiator over the browser, why would they abandon that?
I dunno, most of the stuff in Fleet looks to me like it benefits from being a native thin-client rather than a browser-based app (e.g. SSH to your remotes, run the language server locally, etc).
I can see that a web-UI option could be built atop the "Space-hosted everything" architecture they are putting together, but I don't see any evidence that's actually what their core strategy is, as GP suggested. They spend a bunch of time discussing running things on "Your machine" too, which doesn't sound like a browser-first strategy.
As I see it, their secret sauce is building client-side applications that are faster than other companies can build. I just don't see them giving up that performance edge to make a browser-based client their primary strategy.
> They seem to understand "IDE-in-browser" undermines their fundamental market position
How so?
They've recently rolled out the "gateway" product, which is basically a remote IDE. Sure, you still connect to that with a local one, but the local one doesn't do that much. Why not move it to a browser? The remote one does all the things people love about their IDEs. And if people don't care, they're probably not using their products anyway.
The only issue I'd have with a browser, is that I usually use Vim keybindings, which I've never seen well implemented. My favorite being the window intercepting ^W.
Gateway is a remote IDE in the browser, it's a rewrite of their front-end (Spring I think?) to marshal the UI over HTTP.
Remote is similar to VSCode. The IDE is split into a front-end and a backend: the UI stuff happens locally, and does RPC to the backend for file access, terminal, language server, what-not.
JetBrains gives products in very niche areas. WebStorm for JS, PHPStorm for PHP, RubyMine for Ruby, and GoLand for GoLang.
Visual Studio Code is used by people who like to many languages, but more specifically for someone who's job is to work with JavaScript then WebStorm is much better. JetBrains could very well combine all these IDEs into one, but then again think about the amount of space and data of this new IDE.
I've seen Fleet in my JB Toolbox, but haven't touched it yet.
But it is the obvious move. All the current JB IDEs are built upon the same basic IntelliJ platform, anyway.
It's "only" a matter of restructuring all that to have only one IDE where you can opt-in to support specific languages and now you have something like VSCode.
I'm not sure why, but nobody I know uses this setup – everybody has 2–3 separate IDEs (one for backend, one for frontend etc).
The initial reason behind having separate IDEs for every language, or so I was told, was using different keybindings. This way, XCode users could easily switch to AppCode, Visual Studio users – to Rider etc. – without the need to re-learn anything. (This is the reason I still have Atom keybindings in my Codium setup.)
But why would anyone want to use different IDEs with different keybindings is a complete mystery to me.
I may be mistaken but AFAIK plugins are not always at feature parity with the full jetbrains IDEs. For example the rust plugin in intellij did not support debugging but the one in CLion did (I think this is fixed now).
The python plugin in intellij was a little inferior to Pycharm for Django (pycharm had deeper support for the django ORM) and so on.
I think the reason for the difference between clion and idea for the rust plugin is that clion seems somehow different "on a lower level". It still has support for profiling and valgrind, which Idea lacks [0].
Regarding Django, do you have some examples? I'm admittedly not a hardcore Django user, but I haven't seen any difference between the two.
CLion isn't the best comparison here, as there are some architectural differences between CLion and the other IDES (IntelliJ, PyCharm, WebStorm, etc), which is the reason there isn't a C/C++ plugin for IntelliJ.
That’s absurd! I’ve used the same IDEA Ultimate instance for all languages I touch. Often 3 in the same project. Haven’t seen the point of having separate IDEA/Webstorm/Pycharm instances when one delivers all the functionality of the others.
I’m looking forward to Fleet, watching it closely. But it still has some kinks preventing me from adopting it. Once they polish up the elixir-ls integration I’ll give it a serious shot.
Like my sibling described there are weird quirks. The bigger problem is that this isn't a well documented and supported path. And if you wanted to spend time fiddling with my IDE you wouldn't be using Jetbrains.
What do you mean by "scientific modes"? Jupyter notebooks?
I've never used that, so I don't know what it is exactly nor how to compare. But, although the product comparison page [0] says idea lacks it, there's a doc page that says it has it [1]. It also shows up in the settings window of my IdeaU with Python plugin.
According to this other comparison page [2], it would actually seem that the Idea plugin does more than Pycharm.
Aside from the newly introduced Fleet the other commenter pointed out, Jetbrains' IDEA Ultimate can include all the functionality of all the individual niche products (via plugins), so you could just use a single Jetbrains IDE for most any language/flow you choose. I personally kind of like to keep them separate so I can keep different envs configured the way I most often use them, but you could just use the single IDE for all.
I thought it was weird when Jetbrains started to split up their product into language-specific products, but given how many people say they use WebStorm or an other niche product, and who say they use multiple, I can't blame Jetbrains - I think that in hindsight it was a great business move. An expensive "I can do everything" product has a higher barrier to entry than a specialized product.
Personally I've been using Ultimate on and off over the years, since I've never really stuck to any one language; at my previous job it was a mix of PHP / JS (Dojo), Go, Typescript, and sometimes (reading) C code which didn't quite work right in Ultimate.
VS Code can do all that too, but only intellij was able to actually help me with stuff - things like set the version of PHP to 5.2 so it warns me if I tried to use the PHP 5.3 array shorthand. (I did not choose PHP by the way and the project was to replace it)
> I thought it was weird when Jetbrains started to split up their product into language-specific products
They're for different audiences; the hurdle of trying to explain to a JS dev "yeah, I know when it starts up it asks for a Maven/Gradle/JVM, but just ignore that and open a directory after you install the following 8 plugins" is bad DX. As others have said, the standalone products are not feature parity with the IJ plugins. I have no idea why that is, or what incentives are driving that, but for the time being it is what it is
Can confirm... IDEA Ultimate (and Community to a lesser extent) lets me write code in Java, Groovy, Kotlin (and with slightly fewer features, but still really good support), Go, Rust, JavaScript, TypeScript, and of course, HTML/CSS... probably more but those are what I normally use.
VS Code is getting support for all the newer languages though... similar to how it used to be before with Eclipse (for those who remember the multitude of Eclipse-based IDEs for niche uses in the 2000's) and emacs (which still gets support for most esoteric langs, even if half baked, pretty quickly)... for example, I can use Zig in both emacs and VS Code, but not IntelliJ (I think they are writing one , but it was really unusable when I last checked it out). And stuff like Julia, Common Lisp.... I tend to go to emacs for those... but apparently supporting VS Code is high priority for even these languages nowadays.
I don't use them all at the same time :D sometimes I might go for months without touching some of them but I always find an excuse to go back so I don't lose the knowledge. No particular reason to try to keep up with many languages, I just enjoy it.
C/C++ is only 'one language' (I know, but for sake of this discussion, may as well be), and even then, Intellij does just fine for me, even if it's not on par with Clion. To say it doesn't support mixed language development is silly. In one sizeable project I have python, js, TS, kotlin, Java, bash, groovy, even a little C. All of it works in Intellij ultimate with code completion, refactoring, goto definition, find usages, etc. And it does it does better and faster than the same project when attempting to use VSCode. VSCode starts getting real slow trying to find references and whatnot on significant size projects, and the refactoring is night and day better in Intellij.
> Visual Studio Code is used by people who like to many languages
I don't like these language. I'm forced to write them. I didn't ask for terraform, typescript, CSS, HTML, yaml, xml, JSON, and everything else.
> for someone who's job is to work with JavaScript then WebStorm is much better
It's never been my experience that a full IDE is better for dynamic interpreted languages. Maybe if you're used to that from writing C# or Java it's nice, but I'll sooner take vi.
But like you said, thanks to lots of people that came before me, I'm not just writing one language, I'm writing many. Right now, I have tabs open with eight different languages. I need something that's suitable at everything, not just one language.
> It's never been my experience that a full IDE is better for dynamic interpreted languages.
IntelliJ IDEs are very good at figuring out dynamic languages, but on top of that they also know a lot of tooling and frameworks. So even if you have dynamic Python, but use it in Django, IDEA/PyCharm will be able to give you completions, code navigation, and refactoring just by the virtue of knowing what goes where in Django.
I get that from vscode and pylance/mypy already. I get the same thing with vscode and sorbet for Ruby. Why would I go through all the trouble of using IntelliJ for that?
Some of it made its way into VS Code, but many things definitely didn't (because they require more than just LSP and reuire someone to write a bunch of analysis tools for the python integration).
Try pycharm. It does fantastic error checking that you'd normally need to test the code for. For example, it will infer types for variables and then highlight lines that will cause problems at runtime. It's saved me days of testing the first week I used it.
I use it when it makes sense. My point is that on the spectrum of IDE <--> text editor, I'd much rather take the text editor than the IDE. The performance and ease of use of a simple text editor vastly dominates whatever convenience(s) the IDE claims to provide. Vscode is my usually my daily driver, as it's fast, has effective built-in refactoring tools, and has a decent plugin ecosystem.
No, it's python-specific. I was responding to parent's remark on dynamic languages. C++ is reasonably well served by CLion. I don't know what works for VHDL.
I wish Gitlab would just fix up their existing product instead of increasing the surface area. Every month they put out a security release that often contains a couple of "high severity" bugs and every couple of months there's a "critical" one. And they're not rocket science either, simple auth check bypasses and so on. Clearly something's not going right in the culture if you have multiple critical security bugs every year.
I am increasingly antsy about hosting my private Gitlab instance on the web, and this does not reduce that.
It does feel like GitLab is at do everything and do it at 70% efficiency of dedicated tools, zone and with the trend of being slow and constant bugs, the internal must be too complicated for developers to grasp and that kind of project can never get out of that trend unless rewritten efficiently.
Gitea is a good example of, do less stuff and do those well zone.
I got burned so many times by GitLab I can't in good conscience use them anymore. I always try to use an OSS product when I can, but I literally lost a client a few years back because we couldn't do a deploy because GL was down. For now I use GH for critical projects and a self hosted Gitea instance when it's not super critical.
On the flip side, we switched to our own hosted-on-k8s GitLab summer 2019 and it's been rock solid since. I patch it monthly (via Helm) and it's painless.
About 100 users and it handles all of our CI, which runs on a separate GKE node pool.
I don't understand that girls is letting that going when they pretend to care for OSS. Microsoft is in the embrace phase, there is not a major forge that will remain that will not force to use their things.
Then they will be able to start with messing things, like requiring proprietary extensions to lock down the thing. I guess a lot of people here don't remember the good old time of Visual Studio on Windows.
> like requiring proprietary extensions to lock down the thing.
Which they are already doing in a lot of places. For instance, the VSCode Python extension replaced the open source language server with a proprietary rewrite (PyLance)[0]. They also have quite a few extensions that are proprietary, like LiveView.
And it's worth noting that those extensions explicitly forbid running in anything other than the official VSCode from Microsoft. Forks cannot legally run those extensions, and some of the extensions will have DRM to prevent it from happening[1].
It means that there is a truly OSS core VS Code (presumably what Gitlab and Code Sandbox uses), and proprietary extensions on top that Microsoft ship in their default (proprietary) distribution
I gave this an earnest try over the course of a few months. There were notable bugs in nearly all of the extensions I needed to use for work. It's known that Microsoft ships custom builds of the open source portion of VS Code, and there's certainly something missing from the open source core. I ended up going back to hobbled Atom while I wait for projects like Zed to mature.
> That doesn't make sense to me as there are next to no changes between VSCodium and VS Code.
Honest question: How would we know that? Is it possible to somehow diff vscode's code with the open source repo? Is there an analysis available somewhere of the differences?
But given that the architecture is open source, there's nothing stopping the people behind e.g. Python from embracing the language server protocol and providing better tooling. Besides time / money, but that ties in to the known problem that open source is very difficult to monetize.
VScode’s killer feature is its remote development capability.
Its prevalence could had been averted if Linux folks were not that stuck in command prompt editors for ssh work, and lecturing beginners about their incompetence to learn the keyboard commands of vi.
At some point there was some work in forwarding UI via X11, but it was very clunky and slow. The Remote Desktop capabilities of Linux are also atrocious for rendering text.
So here we are, Microsoft covered the gaps that the community underplayed for decades, and now is dominating.
And VSCode's remote plugin is proprietary, and FOSS is explicitly forbidden from using it. So we're back at "they pretend to care for OSS" and "Microsoft is in the embrace phase".
Totally agree with this sentiment. Everything else about the VSCode experience more or less exists elsewhere. The turn key (and improving) remote experience is incredible. That the infrastructure also works with the development containers concept is brilliant.
> It's a different group of people steering the ship then it was 25 years ago.
Is it a different group of people than were steering when they decided to patent troll Android OEMs less than a decade ago?
Is it a different group of people than were steering when they started abusing their desktop market share to strong arm their way into the browser market last year? (https://news.ycombinator.com/item?id=29415031)
Microsoft didn't change, they're just being more careful now that their position is weaker.
open source as a for-profit business is hard. Most for-profits in the space have a closed source commercial product somewhere in the mix. They've got quite a bit open source right now. It's not bad. Compare with Adobe, Oracle, Intuit, Apple, ... not the worst.
They had been doing mobile ever since the mostly fiction pen windows (which became windows CE a few years later) in 1992 but lost that battle so hard with things like Kin and Lumia they dropped out. And let's forget about Zune.
At one point they has 95% of the browser market but lost that so much that they completely abandoned their browser engine.
Despite all the money they've thrown at projects like Surface and Bing, they have failed to come anywhere near a dominant position. Even in gaming consoles, which has been fairly successful, they're still in 3rd place behind Sony and Nintendo after over 20 years.
Their cloud azure is nowhere near AWS ... being a barbarian emperor hasn't been working for them for a long time and demanding the 1970s IBM style vertically integrated infrastructure is not a luxury they have.
Tangent: Why is autocomplete getting worse on phones? iOS is notably much worse, often replacing completely correct words with other unrelated words. Frustratingly even doing it _again_ when you fix the word.
My girlfriend is the only person I know with an IPhone, and her spelling got much worse over the last year when she had to get a new phone. Every time I tease her she blames the phone, some of the corrections aren't even words. It's just silly at this point. She also has to watch ads on websites because there is no firefox/ublock origin, I don't know how she tolerates it.
Ad blockers on iOS are called “Content Blockers” and can be found in the App Store. I use one called Purify.
Notably the Content Blocker implementation is in typical Apple form. The interface with Safari is such that Safari itself is applying a ruleset to the page, and the CB only provides the rules. That means the CB never sees the pages you’re actually browsing.
Feels like a combination of wanting to roll out new 'better' stuff which isn't tested enough, or just not good enough, plus essentially people not really caring and/or thinking that new tech must by definition be better.
It's like with orientation detection. You'd think that after a decade this would have been a done thing. On the contrary: it amazes me to no end how many times a day people want to show me something on their phone and then go like 'oh wait..shake phone..nope..shake again..finally got it'. When I ask them why they don't just turn it off or replace it with a hardware or software button they say something about it sometimes working and/or not wanting to lookup where to change the setting. Same with voice control in the past years. This is getting better it seems, slowly, but I can't keep track of the number of times people were getting angry because their words wouldn't come through and the navigation wasn't driving them where they want or their text message were full of bs. Still they persist, seemingly because 'I paid for this new thing so I better try'. Which is utterly nonsensical for an engineering mind.
It's a difficult balance to strike. The older systems didn't take frequency into account so they'd suggest really obscure words and the newer systems weigh it too heavily so it overrides your intentions. Problems are harder than they appear
Thank you! My subconcious has been telling me to do that for ages. I finally just did it and am typing this reply without the hand holding. Feels a bit like taking the training wheels off a bike, but good in the same way too.
I read somewhere that Apple replaced their own language model for autocomplete with a crowdsourced one (that is, taken from usage from many phones), and the quality immediately went downhill.
> Then they will be able to start with messing things, like requiring proprietary extensions to lock down the thing
Some extensions are already closed source: Remote Development, Python, and probably tons of other which I didn't even notice. So what? What does it change in practice? What's stopping anyone from creating their open source alternative if it bothers them?
Now let's say they "extinguish" their extension ecosystem. Then they die and everyone switches to VSCodium and open-vsx for extensions. Again, what's the problem?
I honestly think they're in a position where not only the EEE is not their strategy anymore, but also it's not even doable with the state of VSCode.
I bet this eventually evolves into something like "VB for the modern web" where you go to the website, just start coding, and all the heavy-lifting of app hosting is taken care of for you. Next up, a visual point-and-draw editor.
Glitch is awesome, however it seems somewhat neglected. I know it's geared towards Node development, but last I looked earlier this year it was still on Python 3.6.
Other than that it provides the best experience of being able to throw up demos and allow people to fork and modify them.
That sort of already exists in AWS, where Lambda allows you to just write business logic inside the browser without having to worry anything about hosting, and Step Functions allows you to do drag-and-drop various other AWS services into a state machine. Granted, I'm not sure how much utility you can derive from Step Functions if you also don't write Lambda functions.
But the interface is very cumbersome. Not very productive. To be productive as a developer, you need a lot of other things that VS code provides, but not the Lambda editor.
Anyone think there'll be another editor that'll surpass VSCode, similar to how VSCode surpassed Atom (and others)? I used to think that there would be one, but now I'm not so sure.
No, I think they’ve won this cycle in the same way that Windows and Google did theirs. The only issue for them is that it’s still text editing under the hood, which is a fundamental enough of a tool that there’ll always be alternatives scratching away at their supremacy (unlike an operating system for instance). So copilot and good LSP servers are probably big factors in their dominance.
Still seems like a market shift would be required to take them down, like an AI revolution, but then MS seem to be on top of that so far. Perhaps if CI/CD is reinvented in a wonderful way with mass adoption, integrated code editing and manipulation could reshape the text editor.
lsp actually came out of the .net opensource community. omnisharp to be exact. It's funny how much is actually attributed to MS in this case, when most of VSCode did not originate there.
There's no reason at all why VSCode has "won" the same way Windows and Google did. VSCode fixed two main issues of Atom. If anything it was a natural evolution. The name was just a smart marketing play. There are some things that are exclusive VSCode but most of the important pieces are not.
I think the main reason there is no direct VSCode competitor is because there is currently no need to. People that use their own respective flavours of editors have almost the same features in their own respective features, so what's the point in mirroring it?
Fair. Like I said, it’s a text editor and only does things so much “better” than their competitors who are likely to retain their user bases to some extent. We seem to generally agree on this.
But the ecosystem effects of GitHub integration and getting into the browser as is the case with the top parent post and being the home for LSP servers seem to me like enough of an “embrace” to secure a “win” however lesser it is than Google’s. I’m not a user though, just my view from the outside.
> Anyone think there'll be another editor that'll surpass VSCode
Worthy mention- Zed is the spiritual successful of Atom that is being rewritten in Rust. Text editors gain and lose popularity often, so the potential is definitely there.
This is definitely the one I'm looking at closest. There's also Lapce https://github.com/lapce/lapce which has great velocity and looks to be a pretty welcoming project.
VS Code has become the IE of old imo and it'll take an industry shift to kick it, just like IE. Microsoft is not being a good steward of open source for the project, and over time that will wear on people. Hopefully that'll irritate the right people with the right amount of money to do something about it.
Rust - I would not give rat's ass about what language was used to write an IDE as long as it performs adequately. VS Code definitely does it. I for example can comfortable edit, compile and debug my code written in C++ and other languages locally and on remote servers with fast turnaround. VS code is the closest thing ever to come to a full blown modern IDE. Replicating this complete functionality and plugin ecosystem will not be easy. I would not even bother looking at things like Zed unless it can do the same things.
Rust is pretty much the most important programming language in the world right now. Using it to eliminate entire classes of bugs is a huge win for developers everywhere.
It was rather my impression that the classes of bugs that rust fixes are entirely in memory management, which is to say that they never existed in managed languages in the first place. That makes it a big step forward for bare metal and performance critical code, but kind of unimportant anywhere where ex. Java, Python, or JavaScript are used.
The fact that Rust lets you use managed programming patterns completely safely, with zero runtime overhead compared to C or C++, makes managed languages less compelling.
This is a pretty enormous statement. Programming languages are tools and not every tool suits every job. Rust is certainly a "good" language but it will not change the world. In 10 years perhaps we can resume this conversation with some actual substance.
Go changed the world in that it made the rapid development of things like Docker, Kubernetes, possible, along a multitude of other "cloud first" services. This in turn made possible things that were much harder to do before. A single trivial example being the massive NN training pipelines by self-driving companies.
All this could have been done another way, using another language, but not at the same speed as what was enabled by the ergonomy of Go, and not with the same enthusiasm. Arguably, the boiling mix phenomenon made a multitude of things happen and possible, by making them easier to do, thus crossing a required minimum threshold where enough people have the time, desire and ability to achieve something.
Rust will do the same.
It's like catalysts in chemistry. They are not the reagents, but they often make the reaction statistically possible in the first place.
As already said I do not care. I would not trade shitty app written in "proper" language over one that is not but does the actual useful work for me.
>"...eliminate entire classes of bugs..."
With modern C++, static analyzers and address sanitizers this aspect of Rust does not matter that much for me personally. As a language Rust looks way more restricted to me than a modern C++ and dancing around borrow checker is far from fun. Unless explicitly required by contract I do not see it as a business case with positive ROI for me. I run my own company and I actually pay for development.
I see your profile says you’re in your early 20s, so I kind of understand the question but also I’ll be blunt: yes, there will be another text editor. 90% of the tools you use today will be gone by the end of your career.
I forgot the name of the principal, but there's a rule of thumb that a thing's future life expectancy is related to how long they've already been around. So in general if some new text editor emerges, I give it a reasonable chance of being dead in 6 months. VSC is old enough to probably be around for a while now. And I fully expect emacs and vi/m to outlive me:)
Exactly what I thought reading that comment... but there will still be some older people sticking to it for perhaps a decade or two... just like we have people today still using emacs (guilty) and Vim. Not sure if VS Code will last nearly as long as those, it's really hard to stay around for 40+ years (anyone here using ed, Eclipse, Sublime, Netbeans??? I am sure there are a few, but the number is dropping fast).
Sublime Text is still considerable faster than VSCode, and also has LSP via plugins, but its development again has grinded to a halt, which seems to be something that happens periodically when the team decides to focus on other products.
What will get bigger than VSCode is the wrong question to ask. Eventually it'll be unmaintained and people will have moved onto something else. The only constants in the editor mindshare circus are Emacs and vim, and even those will fade away, one day, much later than VSCode.
There's many editors in this space that are trying to do similar things but built in Rust, Go and such. They're all nascent projects and all extremely immature to the point that I installed them all and immediately removed them but they show promise. There's Lapce, Zed, Fleet and Nova which are all native apps without Electron but having tried them all out, they're lacking in one way or another
Seeing recently Onivim 2 die and Brackets too (I don’t know much about that project, but it was Adobe backed FWIW) reminds me that these things can come and go. Getting people to become users and getting plug-in authors to invest their time seems like a nightmare. It’s surely no coincidence that VS Code was backed by a mega corp.
JetBrain's Fleet looks very promising. Does many things better out of the box than VSCode with gazillion of extensions. Too bad that popular keybindings are not supported properly yet.
As of writing this comment, Fleet doesn't even have an option to render leading whitespace characters. Fleet does almost nothing better out of the box right now. It's incredibly slow to load projects, slower than VSCode to start (tested on an M1 mac), has a fraction of a fraction of the settings and features and no extension support. There's a LONG way to go
I think it makes to count any editor with an LSP client as an “IDE” and call a day rather than engage in endless, meaningless debates on subjective terminology
With language servers, I think the big IDEs will be less relevant. It'll be easier for anyone to write a text editor with language server integration and make it with just the way they like.
You're forgetting the actual heavy lifting that proper IDEs do, and that VS Code leaves to language implementors. Unless you know how to do proper code analysis, you won't be able to make it "just the way you like".
Even writing a proper IDE-aware compiler is a quite a daunting task.
At the end of the day, VS Code is a shitty Electron app. It's one of the most highly optimized and performant Electron apps ever created... but it's still a shitty Electron app. Startup time on my machine is only a hair faster than Jetbrains IDE's launching a JVM, it's ridiculous.
VS Code has the market share that it has because:
1. They encouraged a huge plugin ecosystem.
2. They made it cross-platform and gave it away for free, while Sublime costs money.
3. Most importantly of all (in my cynical opinion), they went "dark mode" by default at just the right time when this was becoming a trendy new feature among devs.
There are plenty of text editors that are far better than VS Code, but they either cost money or are for a single platform only. If someone came out with a free, cross-platform, attractive text editor that was a native executable and got critical mass going with a plugin ecosystem, then VS Code would fall out of fashion within a year. There's no genuine groundswell of support for Microsoft as a trendy entity with brand loyalty among young devs.
The recent boomer adage "No one wants to work anymore" simply has its sad technical analogue, "No one wants to create desktop apps anymore".
> If someone came out with a free, cross-platform, attractive text editor that was a native executable and got critical mass going with a plugin ecosystem, then VS Code would fall out of fashion within a year.
Well yeah, there's the problem. This isn't an easy task, it has never been done before.
It's been done with Vim and Emacs, among others. Full desktop GUI versions, in addition to the original terminal-based form.
It just hasn't been done RECENTLY... with an editor that is visually attractive, and uses modern keyboard conventions rather than arcane keystroke DSL's that are inaccessible for the masses. But that's just a matter of project philosophy, not technical limitations with what's doable.
>"At the end of the day, VS Code is a shitty Electron app. "
It provides huge practical value to me as a developer. I am not fond of JavaScript being used as front end but as long as it performs decent job for particular use case I do not care. I use development tools to develop products and make money. I do not fight holy tech wars.
>"Startup time on my machine is only a hair faster than Jetbrains IDE's launching a JVM, it's ridiculous."
I value my development time and my development computers are very decent (desktop for example is 16 core AMD with 128GB RAM). Launching VS code on my machines is nearly instant. CLion from JetBrains is much slower (10 sec from cold start to opening my C++ project in a usable state for example) but still very acceptable. I do not restart it every minute. More like once in few days when using it.
>"VS Code has the market share that it has because:"
I do not care why. I am a consumer here. It is for a people who want to beat VS Code to figure out why and do better than MS. Me - I have my own problems to worry about and I just use tools that work for me.
>"Most importantly of all (in my cynical opinion), they went "dark mode" by default at just the right time when this was becoming a trendy new feature among devs."
I do not give a flying fuck about what is trendy for a generic developer. What is important for me in VS code along with plugin ecosystem let's me develop, lint, debug my code locally and on remote servers. As long as proper ergonomics / usability guidelines are followed I do not really care whether the mode is dark or light.
>"If someone came out with a free, cross-platform, attractive text editor that was a native executable and got critical mass going with a plugin ecosystem, then VS Code would fall out of fashion within a year."
And if I had a million dollars I'd be rich. Coulda, shoulda, woulda. And VS code is way more than an editor.
>"No one wants to create desktop apps anymore".
I actually have native desktop product and it keeps bringing me some dosh for what is a very little maintenance.
For someone who starts by saying they don't fight tech holy wars, this sure does read like a tech holy war.
I am not insulting your personal identity by disparaging your choice in text editor. I am responding to a question of what could cause a future competitor to take the top spot away from VS Code.
My answer is that VS Code has inherent challenges from being built atop an embedded web browser, and that a similar implementation based on direct native executables may be the path through which it's successor will emerge. Carry on.
>"For someone who opens by saying that they don't fight tech holy wars, this sure does read like a tech holy war.
No. I need to take my eyes from work every once in a while and HN to me is one of the ways to do it. I just explained my opinion about a subject. If you believe that I really care about actually convincing anyone be my guest.
Github had the same limitation initially but they have fixed it lately. It downloads an index in the browser and uses it for search. I guess Gitlab can do the same, they just didn't get around to implementing it in the first version.
> with an implementation inspired by Visual Studio Code.
Is this an indication of Gitlabs new "corporate" culture? The website already seems less "OSS" than it did, but to say "inspired by" is a hairline away from bullshit.
That's great to hear. Thanks for the quick turn around.
I appreciate that it's a single word change, less than a whole word even; given the PR/MR but it's important, in my opinion (as a Gitlab fan) to not appear to be trying to hide the foundation this updated feature is (now) built on.
A lot of people seem to be misunderstanding this as Gitlab introducing a Web IDE. They're actually just swapping out the implementation in their existing Web IDE (which existed long before Github's)
Everyone hating on vscode because it's maintained by Microsoft... Vscode is an amazing IDE with amazing extensions, and the core part of it is FOSS. I use vscodium and connect to the real marketplace, guess what, it works. Does it break some license, sure, but it works.
I'll wait for Microsoft to send me court order, until then, I'll happily use copilot and a bunch of other extensions with vscodium.
Worried about extensions calling home with telemetry?
Block those calls on your dns.
Worried about some extensions that only work in vscode?
Wait for someone to reverse engineer them and pirate them, or wait until someone does a FOSS version of them, or do it yourself. Those last two point is how open source works.
So I think people just found another thing to complain about without any serious arguments. Vscodium is FOSS, telemetry stripped out with alternative FOSS extensions and a possibility to fallback to non open source extensions. It's great because it works and does not completely lock you out.
Sure you have to break Microsoft licenses when you try to install one of their closed source extensions, but as I said above. I'll be patiently waiting for Microsoft to put me in court.
If this is their plan for the extinguish phase, my god does Microsoft have a thing or two coming their way. They made it way too easy for the average dev to just do what they want this time.
They have one, it's called GitHub Codespaces. (Remember, nobody wants to sell software any more, only services).
Microsoft's strategy is to build a moat around VS Code/GitHub. Compared to GitLab, they have:
* Brand recognition of VS Code
* VS Code extension gallery that only VS Code can connect to
* Buttons in the Desktop version of VS Code to connect to GitHub Codespaces, Azure etc
* MS-written closed source extensions- Pylance, parts of OmniSharp, Remote SSH, Remote Containers, Remote WSL, Live Share, GitHub Copilot, IntelliCode, Python WASM In the Browser, GitHub Codespaces integration.
* Control over the VS Code API. They can add just the functionality their extensions need and nothing more.
* They own the LSP specs. They can add just the functionality that VS Code implements and nothing more.
* Control over the VS Code "proposed" API. If you want to use these APIs in your extension, you have to be whitelisted by Microsoft (or ask users to install a non-VS Code version of VS Code). Gitlab can offer a Web IDE, they can't offer integration with desktop VS Code to provide those nice features like desktop-level keyboard shortcuts, Git Clone, compare with working tree, etc as that would use the "proposed" APIs.
Right, I just realised the GitLab Web IDE is running fully in the browser, so there is no Terminal. Maybe they are considering a later version which is more like Codespaces, letting you develop and run your code, keeping the browser as the user interface.
Hi, GitLab PM for the Web IDE and Remote Development here! You're right, the Web IDE itself is running fully in the browser, but if you try to open a new Terminal panel you'll see that it can be configured to connect to a remote host. The setup (for now) requires a bit of manual config on your end but we're working on making that easier in the future!
I think the biggest risk for those companies (see GitPod who had multiple blog posts about it) is that the good parts of VSC really are closed source or not MIT-licensed so you can't use things like share or extensions and many others.
I think cloud vendors like gitlab and others should actually work on rewriting or maintaining a different fork or write an entirely different web editor altogether.
VSC is not a piece of competitor-friendly software and most importantly it does not support mobile browsers so imho all these companies are locking themselves in the past as the need for mobile and tablet editing (even if limited) is going to keep rising and they are not offering it.
VSCodium, aka VSCode without the Microsoft proprietary bits, uses https://open-vsx.org/ as the extension registry. The hard problem is convincing devs to cross-publish
I have published some extensions with about 300k users in total. So far, I've only had two people ask me to publish on open-vsx. I did make one attempt, but something broke in the signup procedure, and it took 3 weeks for someone from support to come back to me with a fix, so I had moved on.
If more people were asking for it, I would try again, but the time spent per user to set up a pipeline for each extension just doesn't make sense at the moment. I'd rather spend those nights adding features for the existing mainline users. Cynical perhaps, but there's no reward for making extensions, so there's a limited amount of time I can spend on it.
I have a few extensions, notably an update to subtle-brackets, which I cross-published. It's relatively painless - Eclipse running Open VSX is clunky, but no more clunky and UX-weird than the marketplace (which holy shit, talk about terrible UX). The issue is that VSCodium has holes, and not all extensions will run correctly.
I'd like to see a hard fork for VSCodium, where the community could make UX/DX upgrades that VSCode's Microsoft-employed gatekeepers have summarily shut down time and time again (see: issues on the find/replace dialogs)
VSC does have reasonable support for tablet editing, there was a big push to make it fully compatible with Safari on the iPad when Codespaces was first in beta. You’re right about mobile though, it’s a nightmare.
I tried the JetBrains remote IDE, it was awful. Sad since I'm sure it was amazingly hard to get to that point and they poured a lot into it. There's just so many resources and so much process tied to the local environment outside the IDE, this was light years away from making sense. I'm keeping an open mind, though, maybe some day.
This is one area I'll never jump ship. I like developing the code I write on a local machine. If some day in the distant future we are required to use cloud servers to develop, I'm out. Done. Adios.
Why is your position so absolute? There are trade-offs and as engineers we typically would balance those — for example, local development avoids putting the network in the critical path while remote development allows perfect fidelity with your deployment environment, can be an important security win[1], and could make it easier to access resources which you don't have enough space or want to store locally.
Neither of those is right or wrong globally: your particular situation will determine how much you weight each of them.
1. e.g. if you install the wrong Node module, it can still wreak havoc on your remote environment but it can't steal your local credentials, trojan your workstation, or attack your other projects — and by splitting your credentials from the remote environment's you can usually run with a far more restricted set of permissions.
I prefer the remote setup because my dev machines are nearly identical to the production machines in every aspect. I can have a fresh new machine online in minutes, so can the rest of my team, or a new hire. All our code runs close to the data. My dev instance is significantly more powerful than my laptop. I switch between a desktop and laptop across a given day but my dev box doesn’t change.
I’m not sold on the “in a browser” setup that this post is selling, I still run VSCode natively and also use it for my terminal shell.
Curious if anyone has gotten a remote extension (MS or otherwise) working on vscodium. I tried but could never get it working so I reluctantly switched to vscode proper.
We released a beta version of our new Web IDE which is built using VS Code. The new Web IDE will provide users access to more features, improved performance, and the ability to securely connect to a remote development environment directly from the Web IDE.
With all due respect (big GitLab fan here) there are at least two features that are missing that for me makes this product unusable:
1. Inability to switch branches in the editor [0]
2. Full project search "to be enabled at a later date"
So I can't switch branches off of the default branch and I can't search the entire project. To me, this undermines your claim that the new web IDE "will provide users access to more features" and in fact I don't find it useful for hardly anything in its current state.
I get that it's a beta, but it seems a very incomplete one, at best.
A link to the Epic for full project search[0] was shared in an earlier comment[1] by Eric, the Product Manager who is leading this effort. You can follow along there to track our progress.
In the meantime, you can disable the beta and continue to use the old Web IDE until all of the features you require are available[2].
As a work-around, if you know the name of the existing branch you want to switch to, you can change the URL in your browser's location bar for the IDE. Here's the URL format:
This will re-load the IDE on the different branch.
You can also switch branches in the GitLab UI's Files view, before launching the Web IDE with the "Web IDE" button (or the `.` shortcut).
Also pressing "Web IDE" from an MR in GitLab will open that MR's branch in the Web IDE.
So it depends upon your workflow currently, but I agree it will be nice to be able to swap within the IDE itself later (also when the GitLab Flow extension is added).
The built-in git support in Code is already an improvement over the old Web IDE's Stage/Commit workflow, IMHO, and after the first load, the new Web IDE also loads faster than the old one, for me at least.
Huh, that's surprising but probably good. My initial reaction on reading that you were replacing your own thing with VSC was something like "aw, now it'll be too slow to use". Hope you're right:)
GitLab team member & PM for the Web IDE here! In our measurements the memory footprint was between 50-80% lower than the previous Web IDE. I'm not sure how it compares to other web-based instances of VS Code.
The TLDR is that the Web IDE is a widely used feature (tens of millions of commits have been made using it) and building our new Web IDE with VS Code will allow us to invest in extending the experience to be more tightly integrated with GitLab and the DevOps workflow rather than re-creating VS Code features in our Web IDE.
Some companies are already moving to remote IDE models for a variety of reasons, I would prefer using this Gitlab IDE over a VPS hosted in the company cloud for sure.
If I hadn't read it, I might think Gitlab incorporating vscode was a good thing.