Web IDE Beta
docs.gitlab.com
docs.gitlab.com
If I hadn't read it, I might think Gitlab incorporating vscode was a good thing.
What's the TL;DR?
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
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.
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.
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.
You can install the Python plugin & friends -> PyCharm
You can install the Go plugin -> Goland
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’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.
The python plugin in intellij was a little inferior to Pycharm for Django (pycharm had deeper support for the django ORM) and so on.
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.
[0] https://github.com/intellij-rust/intellij-rust#compatible-id...
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.
[0] https://www.jetbrains.com/products/compare/?product=idea&pro...
[1] https://www.jetbrains.com/help/idea/jupyter-notebook-support...
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.
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)
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
Probably to sell their more expensive "all access pass" instead of just one IDE that does everything.
Android Studio's C++ support is done by Google's own licensed CLion for integrating it into a proper development experience.
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.
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.
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).
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.
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.
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?
Fleet (https://www.jetbrains.com/fleet/).
They're building a distributed IDE. A web-based UI would fit nicely into their new roadmap.
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.
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.
In addition, a lot of the good language plugins are proprietary, like PyLance and the C# plugin.
Your complaint is with the binary that Microsoft ships, not with the codebase.
A mantra that was famously internally coined at Microsoft[0], and was found during anti-monopoly proceedings.
As such they will always be looked at skeptically when adding proprietary things to open source things.
[0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
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.
Look at Android and how it is almost impossible to de-Google it for a live demonstration.
(I don't think there is a market for developer tools, though.)
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.
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.
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.
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.
This is a big one. A lot of the value of VSCode comes from its plugins, and M$ doesn't allow VSCodium to access them.
On the one hand sure I wish Microsoft open sourced more, at the same time what they already open sourced is a fantastic foundation for building upon.
Instead of having to write an open source IDE from scratch we can leverage this one and then implement a few plugins for popular languages.
Shout out to CodeLite.
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...
Definitely recommend giving it a go!
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!
I am increasingly antsy about hosting my private Gitlab instance on the web, and this does not reduce that.
About 100 users and it handles all of our CI, which runs on a separate GKE node pool.
Gitea is a good example of, do less stuff and do those well zone.
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.
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].
[0]: https://www.reddit.com/r/Python/comments/n9yse1/as_of_today_...
[1]: https://www.reddit.com/r/linux/comments/k0s8qw/vs_code_devel...
Unless these extensions were closed source Microsoft-authored?
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?
Maybe not, but it's absolutely insidious to have open source features and then replace them with proprietary ones.
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.
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.
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.
It's a different group of people steering the ship then it was 25 years ago.
I know how fun it is to presume they are being exclusively evil but who knows, things can change
tl;dr: MS is still evil.
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.
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.
> 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.
Now, what exactly are your arguments?
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.
Divjoy and others have a nice drag/drop - there are variants on this theme.
Maybe someone can bring this all together.
Kind of like "nocode-at-first-but-really-there-is-code-if-you-need-to-edit-it"
Or as you say: VB.
Or better: Access for the modern web.
Other than that it provides the best experience of being able to throw up demos and allow people to fork and modify them.
Or Microsoft's Power Apps.
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.
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?
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.
Personally, I still prefer Sublime Text to VSCode.
Now, the problem is ST is proprietary, but then VSCode is starting to be proprietary as well.
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.
>"...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.
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.
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.
Even writing a proper IDE-aware compiler is a quite a daunting task.
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".
Well yeah, there's the problem. This isn't an easy task, it has never been done before.
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.
> > 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
My apologies if I misunderstood how you intended the pronouns to be applied.
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.
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.
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.
Rather useless at the moment. I at least can't really work around in a codebase without project search.
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.
It's not inspired by VSCode, it _is_ VSCode.
Thanks for the feedback.
I created a merge request to update our documentation based on your comment and linked to the comment in the MR description: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107599
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.
New? GitLab has been corporate-y for a long time.
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.
I wonder if at some point VS Code will add some enterprise editions, these feel like the perfect place to do it.
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.
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'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)
People don't really optimize for 0.001% of use cases.
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.
> The Web Terminal and Live Preview are not available in the Web IDE Beta.
> These features may become available at a later date.
This blog post gives a little more high level overview of the current functionality and where we're headed: https://about.gitlab.com/blog/2022/12/15/get-ready-for-new-g...
For a deeper dive you can check out our Remote Development [direction page](https://about.gitlab.com/direction/create/editor/remote_deve...) and [documentation](https://docs.gitlab.com/ee/user/project/remote_development/)
Computing on a remote computer has a rich history going back to the terminals of the 60s and 70s and has never really gone out of style.
VSCode is just the latest iteration.
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.
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.
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.
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.
[0]: https://gitlab.com/gitlab-org/gitlab-web-ide/-/issues/72
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].
[0] - https://news.ycombinator.com/item?id=34080388
[1] - https://gitlab.com/groups/gitlab-org/-/epics/9466
[2] - https://docs.gitlab.com/ee/user/project/web_ide_beta/index.h...
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:
https://gitlab.com/-/ide/project/<namespace>/[<subgroup>/...]<project>/edit/<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:)
Where did all the investor money go? just to slap vscode?
I sincerely hope Sublime Text open sources its editor so the community can hack together a WASM version of ST..
Things are not looking great
Specially the people who have a short memory and forgot about the recent Python extension controversy
Screw them!
Considering we were warned already from that company, remember dotnet hotreload?
https://www.theregister.com/2021/10/22/microsoft_net_hot_rel...
When your sole choice becomes their sole product, one should have reacted in the past
Is this really something that will benefit Gitlab in the short, mid or long term?
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.
That's the last question I would ask.
There is more context in this blog post: https://about.gitlab.com/blog/2022/05/23/the-future-of-the-g...
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.