It's the end of being able purchase any kind of perpetual license to your software. It'll all be on the web and it will be paid per month. When that meets a company with an aggressive sunset policy or if they have an outage it won't be a good time.
One could also see it as an option that makes contributing to open source so much easier for small edits. There are plenty of times when I am working that I would make a small change or refactoring to a project, but the idea of cloning, setting up an environment, figuring out how they run tests, etc. makes for too much of a barrier to entry.
With a piece of software I physically own and that has an offline activation mode (tips hat to Jetbrains), I can be reasonably certain that I can keep using it for as long as I can maintain some kind of virtual machine for the host OS. I will not be affected in my usage of the software by any decision the software maker decides to do in the future - think UI overhauls, deprecation of features -, the balance of my bank account or the software maker goes bankrupt or bought out.
If I am skilled enough, I can mod the piece of software to do whatever I want (this especially applies to games), or can swap out pieces with other pieces (e.g. replace the built-in compiler of an IDE with a different one).
A pure SaaS environment? I'm completely at the mercy of the operator now. I am locked in into whatever decision the operator makes, I depend on them keeping their service available 24/7 (because when they go down, I can't work and make money), I depend on them not getting bought out by a competitor that then decides to close up shop (either to get rid of competition, acqui-hire or the specific SaaS service is unprofitable), I'll have to pay whatever price the operator wants (which is particularly insidious given the SV model of price dumping, monopoly formation and subsequent extortion), and in most if not all cases I have no way of modification (userstyles/userscripts just don't work in compiled JS/CSS apps any more without a lot of work). And to top it off, for many SaaS solutions I have to pay money to keep using it under a contract, which is an obligation on my future budget.
I just want to add that running in the browser does not mean running in the cloud or web. I actually once worked on enterprise software that used a browser as GUI. That's not at all bad. Of course there is always room for improvement.
By a reasonable guess your app was distributed as a binary that spun up a local web server and automatically pointed the user's browser to it. That's a perfectly fine approach for some use cases, but for many others, even the server binary isn't needed.
An extremely underappreciated approach for development and distribution is targeting the browser as a sandbox for fully local applications (embodied in static files—or better: as a single file). I see lots of people making apps and throwing them up on GitHub Pages, but rarely do the developers package them up into a form that you can download from the Releases tab from the associated repo and then double click to run. At best, they'll point at the repo with instructions in the README about running npm or yarn.
(Then again, if their build processes would also target the browser's JS engine and standard browser APIs instead of NodeJS and its proprietary ones, then the entire exercise of setting up an NPM-based development environment need not exist, either. Oddly enough, people who think of themselves as JS developers and spend their days writing web apps seem to either really dislike the thought of actually using the browser, or they're so afflicted with tunnel vision that they've missed the obviousness of using the browser runtime in this way.)
Ellen Ullman quotes Whitfield Diffie in her book Life in Code and I think he’s spot on:
> We were slaves to the mainframe! he said. Dumb terminals! That's all we had. We were powerless under the big machine's unyielding central control. Then we escaped to the personal computer, autonomous, powerful. Then networks. The PC was soon rendered to be nothing but a "thin client," just a browser with very little software residing on our personal machines, the code being on network servers, which are under the control of administrators. Now to the web, nothing but a thin, thin browser for us. All the intelligence out there, on the net, our machines having become dumb terminals again.
I used to think this was pushed by some of the large tech companies that do not have a popular OS and are forced to turn the browser effectively into an OS. But both Github and VS code are owned by Microsoft now.
Users in general (with exceptions) do not care about how and where their software runs and data is stored.
For many people internet connectivity and local computation power (within the browser) is now good enough to skip installations and updates all together.
It makes perfect sense for them to do this and in the end they are not giving up control if they still own the OS.
Microsoft can always the decide that "untrusted" websites (which, for example, are not "certified" by them) get blocked from using certain features.
It smells to me like Microsoft have realised Windows is heading the way of VMS and they need an exit strategy. Its no coincidence windows 11 pro has a built in wayland compositor to go with WSL2.
If you think about it, browser is just an OS for the apps that have crappiest stack (typesetting engine from 80s and, well, javascript), weird window manager (full-window tabs), sandbox for everything (including TCP/UDP calls) and no apps distribution process whatsoever – you download app each time you want to use it.
Why people are excited about this OS, I don't know :)
IMO, This is the best thing about browser as an OS. You can run untrusted apps and know that it couldn't steal your ssh keys or other things without your consent, similar to iOS and Android.
There are more benefits with the browser sandbox than just plain old file access. Web apps can’t just read the clipboard or enter scripts/commands or take screenshots or activate webcam and microphone
For all practical purposes, file system sandbox features might actually be the first to become meaningless again when more and more data is stored in offline browser caches
And application delivery in enterprise environments is also much more lightweight compared to VDI solutions like Citrix so there’s another benefit in terms of sandbox and isolation
Some people are excited because there's no gatekeeper taking 100 USD every year for the privilege of distributing apps on it.
Also, it's quite simple to start developing for it.
For complex software (e.g. video games) on the other hand the web is a real piece of crap: performance suck, no UDP, a certain browser is purposely a ton of useful APIs (or is straight up buggy).
At Google in 2013, many developers just used Chromebook's. I am starting a new job in a few weeks and I expect quite a lot of my work will be done in AWS SageMaker.
I am fairly comfortable having my laptop being a conduit to better resources in the cloud. There are also strong security advantages of not having sensitive data on laptops.
It's surprisingly good! Same experience as using VSCode on my computer. I'll definitely start using it for quick edits, then probably end using it for normal development.
Curious to see how the developing experience will evolve in the next few years.
It looks like this is actually just the editor from Visual Studio Online unless I've missed something.
It's great, but if it were really Visual Studio Code that would be awesome and I'd be pleasantly surprised.
(The difference being that if it's just the editor it misses out on all the compiler/analysis integrations. If Github were providing Linux containers in the cloud for working on projects - essentially the SSH feature from Visual Studio Code - it would be absolutely brilliant.)
> Because there is no associated compute, you won’t be able to build and run your code or use the integrated terminal. Only a subset of extensions that can run in the web will appear in the Extensions panel and can be installed. Likewise, support for certain programming languages may be more limited in the web.
That's a shame, but at the same time a big step forward.
Azure has had this for a few years now (unless there's upgrades in the Github version I'm not aware of) and it's been really useful for quick edits - will be good to see it develop now that it's sure to pick up much more use through GH.
Hmm. $0.18 per hour for 4GB of RAM is a rather steep. A c6g.large on AWS would run you less than a half of that, for the same number of CPUs and memory. A quarter if you're happy to use spot instances. Might be neat to have an OSS tool that spins up an EC2 (or Azure or GCP) instance running Code-Server[1] (VS Code running natively on the server, but presenting the UI in the browser), with a given git repo and credentials.
docker run -p 8080:8080 -v "${PWD}:/workspace" mltooling/ml-workspace
Cocalc-docker also includes Git, Jupyter, SSH, a collaborative LaTeX editor, a time slider, but no code-server or VScode out of the box:
https://github.com/sagemathinc/cocalc-docker
docker run --name=cocalc -d -v ~/cocalc:/projects -p 443:443 sagemathinc/cocalc
vscode is open source but many of the most interesting features are proprietary, making the use of anything but the official build impossible for many use cases.
A few weeks ago I investigated using an embedded version of vscode to create containerized dev environments for an internal developer platform we're working on. The hope was to allow devs to write and debug code from inside a k8s container by using vscode inside their browser. Very similar to the newly announced codespaces feature.
Unfortunately, there were several factors that made this impractical. The extension marketplace can only be used with the official build. There are at least two alternatives but both were missing extensions that our devs used. Also, the c# debugger is proprietary and only works with official vscode build.
From that experience I believe that while the core editor features of vscode are open source, "Visual Studio Code" the tool that people actually use is defacto proprietary and entirely controlled by Microsoft.
None of which has anything to do with "embrace, extend, extinguish". That just means they are not wanting to fully commit to open sourcing their own editor.
It has everything to do with it. Their open-sourcing stuff is just the modern form of the "embrace", and that open-sourcing being only partial is the very epitome of "extend".
The "extinguish" is obviously yet to come, but turning a blind eye to it certainly won't help stave it off. And trying to fog others' vision to it is... Less than a good look.
Open source development, starting with Javascript/Typescript. Microsoft own Typescript, VSCode, Github, Azure and NPM. It's not hard to imagine in the future an online dev environment that works with all of these technologies together. But this environment won't have an open source counterpart.
Extend & extinguish: make all of them work together really well in a way that can't be reproduce by the open soure community.
I think it's a bit early to say that they are embracing and extinguishing at this point, but I wasn't here last time and may be biaised because I find these tools incredibly convenient. In a way, Microsoft is leveraging their unique advantage over other cloud vendors, which is their proximity with developers.
"Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions."
So if your text editor doesn't support integration with Github and a cloud vendor, or if your repositories don't support integration with an online text editor and a cloud vendor, or if your cloud vendor doesn't support integration with Github and an online text editor, this will affect your market share. I think the end goal is around "developer mindshare" (which, I admit, is a really vague concept), especially in web applications. By assembling all that they have, they can create an experience no one else can, all while leveraging open source tools.
You could also imagine an integration with education (Github student pack, Azure credits, etc). At this point, they could dominate the web app market because no one else can offer such a deep integration across the stack.
I think one of the differences with the "old" EEE would be that instead of intentionally crippling certain features, they are instead focusing on giving the best-in-class experience. If you consider that it's just regular competition and not EEE because of that, that's totally fair. Still, I think that we should still be wary of domination. Competition is what's pushing Microsoft to develop all those wonderful tools, and I fear that with domination they might become complacent and abuse their position.
The GitHub folks were already on a roll with this before Microsoft came along. How many people don't understand the difference between Git and GitHub, don't realize that saying "can you <interact with me somehow> on GitHub?" makes the same presumptions as "can you <interact with me somehow> on Facebook?", don't give two shits about how messy their commit messages are formatted, don't realize that Git doesn't actually have PRs, don't realize that the closest analog that it does have is intended for the convenience of a core team of frequent collaborators pulling from one another (N-to-N instead of the star topology that dominates on GitHub—and not for drive-by contributors), and wouldn't know what to do with a patch if you gave it to them, or if they do, wouldn't accept one if you tried.
That is a very good point. I had the chance to start my "Git adventure" with Mercurial on some in house software at my university. They then switched to Git with Gitlab. And now I use Git with Github. It helped me to realize which piece does what. But if you start with popular tutorials, everything is Github. Github even released a CLI wrapper around Git that integrates Github-specific concepts.
This has annoyed the crap out of me for a long while too. I never found out how to drive the difference -- "that's not git, that's GitHub!" -- home to people who'd just answer "What are you on about, it's the same thing!" before this idea struck me right now:
"No, they're different things. Just like GMail is one e-mail server (and client), but GMail isn't the same thing as e-mail."
The PC; the whole idea of a universe of independent microcomputers.
Microsoft, Amazon, Google (and Facebook?) each have their own angle on it, but seem to be moving towards the same goal: a return to the old model of centralised computing, with the Web as the substrate, your "PC" reduced to a graphical terminal, and their servers as the mainframe.
The difference in angles is partly just that they each want their servers to be the main mainframe, not those of one of the others; and partly because they're each coming at it from different directions, each trying to play off of their own strengths. But the goal and direction? All absolutely the same.
The best we can hope for (if I'm being pessimistic) is probably that none of them wins outright, but instead we get a shaky balance between as many as possible of them.
> "Embrace, extend, and extinguish" (EEE) . . . is a phrase that the U.S. Department of Justice found that was used internally by Microsoft to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.
This is a completely valid reason to be concerned with these sorts of things now that GitHub is owned and operated by Microsoft. They continue these practices today, and GitHub is no exception.
You get downvoted but I also have that little voice in my head. I keep thinking about hitting a point of no return with my dependency on Microsoft. But I'm not there yet, I could untangle fairly quickly, fairly painlessly. Moreover, many of MS' recent stuff is FOSS, they can change it, but we can fork it. And competitors like GitLab are still alive and kicking, not suffering by the looks of it.
Yeah the downvotes don't surprise me, but their strategy has existed historically - proven, as it were - and thus I have to assume they still employ these tactics. At least from the outside, it sure seems so.
Tbh I think they have bettered themselves. I'm not so afraid of it. Companies can change, Satya is an admirable man, he always comes across as wise. Well, I guess the same could be said of Ballmer, some videos being a BIG exception of course. But it doesn't hurt to keep an eye on them ;)
Looks like there are some Microsoft fan boys here...
For the others, that does not know the concept that was applied by them numerous times, it's easy:
- embrace: they buy GitHub, play nice, be part of the community, we will change nothing, commit to open source spirit
- extend [current step]: oh, we are just adding nice features, now you will use our visual studio, but don't worry, it's for free, it just improve your experience.
- extinguish [next step, my guess]:
* "sadly, VS works better in edge and does not support minor browsers like Firefox",
* there are these cool new synchronization features/real time collaboration that requires Visual Studio on your computer.
* Sorry, you need an official VS build to use the features because security/authentication/...
* Here are the corporate workspace accounts that allows to limit code edition in the cloud, for security. And so, for security also, you can only use it from edge on windows X with TPM.
Based on previous MS experiences, the possibility are endless!
I would kindly remind that the version of VisualStudioCode that almost everyone use is just a freeware but it can't be built as is from ope source code.
Also, not long so long ago they were willing to switch everyone GitHub accounts with Microsoft accounts...
Finally. I've been waiting for this since 2009 when the Bespin project emerged. But now I'm afraid they will occasionally deprecate the offline VSCode or make it a paid option.
Am I alone in not jumping on the Visual Studio [Code] bandwagon? Other online editors have had "vim modes" for ages (e.g. Overleaf) and frankly I'm unlikely to write a chonking great script or project in a browser on Github -- a minor modification is much more likely. VS Code's codebase is huge. Will Github allow people to use other $EDITORs?
(Yes, I'm aware this makes me sound like an old man!)
NetBeans is the best free and open source IDE, at least for PHP.
It lacks some nice features and improvements that PHPStorm has, but it's pretty good overall. There are a couple things that NetBeans does better than PHPStorm, though.
Gotta be web-based and only other major one I know of is Atom, which was originally started by GitHub and is also owned by Microsoft now. Don't know if people are still using it much though.
Each to their own really, and honestly not every tool is going to be a good fit for every project. I have day work on Visual Studio that I wouldn't dream of moving to VSC for a bunch of reasons.
The reasons myself and others like VSC also have a lot to do with the plug-in ecosystem. More people using it means someone has likely already encountered my use case which means it's more likely a plugin exists to do what I need.
There are places that live on JetBrains for this reason (sprawling homogenous codebases that cross domains and languages). Having support to hand not only for the code you use most, but every language/framework other folks in your organisation use, is a really useful feature for integration/debugging work.
The range of support is great. I can program and run web front end, node, plain C or C++ for desktop, same for programming various chips, and ESP (using platformio), all from one familiar editor.
I would now feel uncomfortable using anything else.
VSCode is/was a neat editor, but I fear it is slowly morphing to become an overloaded mess.
It was so sleek and lightweight at first it was really a pleasure to use. But performance and bugs seem to increase, even if you don't use many or any plugins at all.
I'm curious to know what sort of dev work you do with vscode, it still feels rather snappy to me with ~40 extensions, but perhaps using it for other languages is more of a problem?
Devs with this many extensions are an OpSec/data governance nightmare!
VSCode desperately needs some sort of access policy/permission system for their extensions, and make it more obvious when an extension phones home code or other data its user doesn't directly provide it with.
Copilot, for example, straight up sends and uses your code - not just the modifications you've made to the laundered code it provides you with, but any or all of it [1].
I am an embedded dev that mostly writes C/ASM, but also JS/HTML for visualization, where I use VSCode mostly.
It still has decent performance and I will continue using it. I think I have my linters correctly configured so there isn't any huge background scanning of files. But I have the impression the early versions were faster.
Companies want developers to buy into editors like religion. All of them (editors) do the same, but spending money on IntelliJ is the hardest flex because it says I’m an enterprise developer look at me.
Really? I swapped to PyCharm when I was a solo dev because it had superior code insight compared to the other editors. What is enterprise about it beyond it costing money?
Wait, wha? I worked for myself and it was busy time. I'd spent almost as much on other IDEs as PyCharm. Not a flex. When I flex, the Hulkamaniacs go wild and everyone takes their vitamins and says their prayers. WTF is a flex about buying software?
I've been trying to make VSCode work like PHPStorm. I've tried a huge combination of plugins and there's no way to do it.
It doesn't even come close. It's powerful but it's definitely not the same. I would go back to NetBeans before using VSCode. There's no religion behind it, it's just that there are tools that suit my needs better than others.
You can get access to all Jetbrains tools for $650/yr for the first year, with the price reducing in subsequent years.
Considering nearly every S/W dev globally can make that in a couple of days, I'm not sure how much of a flex it is considering it would be your primary work tool.
And I say this as someone whose never used a Jetbrains tool and use Vim for nearly everything (except when I'm on Windows where I use a mix of Notepad++ and VSCode).
Yea, it’s only recently I’ve been buying licences for things that make my life (as a dev) better
Sometimes you can afford it, and sometimes you can’t.
I think we forget when you could (and still can) do dev with a text editor.
I 100% get what you say, but that’s a lot of money potentially - which is where I think vscode /vim etc shine in that it’s free and can do the same kinda thing
I have never used vim in my life (20 years in dev. including on linux and used linux since the late 90s). Many people talk about vim lately, probably the most I've seen and I'm still not sure why.
That said, VSCode is very good. But I don't believe in a web-based IDE and in remote Github repos. That's a recipe for disaster and unescapable vendor lock-in, and in any case it's only an option for web dev., really.
Edit: Since some people always take things literally: I have of course tried vim, like most people who ever worked with Unix/Linux I suppose, but never got beyond that. I am surprised that it seems to have become so "fashionable" lately. There are many alternatives to vi/vim and many IDEs. My experience is that vi has always suffered from its interface and has struggled to expand beyond "bearded Unix gurus"...
If I just need to do a quick edit of a text file from the CLI I usually use nano, as well.
For dev. I use an graphical editor, usually VSCode these days. I used emacs at some point a long time ago.
The good thing with git and al is that there is no need to access a remote repo., and that's one of the points, so there is usually no need to edit source files remotely.
> Many people talk about vim lately, probably the most I've seen and I'm still not sure why.
Extrapolating from personal experience, I think this might be down to Covid WFH where more people have had to ssh into remote machines and may need to edit files so might choose to use vim as it’s easily available. And vim is something that I find is better learned progressively where you pick up 1 or 2 tricks every week or something so those people might have been able to pick it up over the last year or so and are now evangelizing it.
I have also been WFH because of Covid but haven't had to change much or anything to my way of working and I do SSH to multiple machines every day. That might vary a lot from person to person, though. I have avoided doing actual dev. on a remote machine by setting up a VM to run Linux locally as any sort of remote desktop tends to be a pain.
Also, with distributed source control (git and friends) there is usually no need to access remote source files.
Want to have your mind blown? Microsoft (yes that Microsoft) officially supports remote development on Windows Server via SSH. As in, run vscode on your Linux box, create an SSH remote on your Windows Server, develop remotely on the server via SSH. Fully supported.
Porting cross-platform projects to the operating system that looks and feels very different to pretty much everything else out there. I prefer doing that from the comfort of my primary desktop OS.
I've been using it for a couple months now as my main editor. Overall I really like it. It's just a touch laggy. So for example if you press esc then try to do a normal mode command, sometimes your key presses still go into insert mode.
> Is it fair to say, because VSCode does not have a "vim mode", it is somehow inferior as an editor?
Is VSCode an inferior editor compared to Vim/Neovim? Absolutely, it is. Is Vim/NeoVim an inferior IDE experience compared to VSCode despite the ongoing evangelism by NeoVim fundamentalists? Most likely, yes.
Here's an example before I start getting flak — NeoVim doesn't have stable indent visualization lines and stable and sensible code folding support. Try writing serious Markdown documentation or Python code in NeoVim and then in VSCode.
The NeoVim website also mentions that being like an IDE is not one of its goals.
I already know the responses I'm gonna get - it's open source, submit patches or shut up, it's personal taste, those features are irrelevant etc etc.
> I seriously don't get it. I have used VSCode almost from day one. It is a fantastic editor and quite a capable tool. I seriously love it.
You should keep using it. Don't get swayed by people proselytising Neovim.
I'm someone who also writes code for a living. Linux and MacOS are my primary OSes (in that order). I've used Windows, but only sparingly.
I've written a lot of C, a lot of scripting languages, and a bit of C++. I've used many IDEs.
For me, the "command line" workflow of Makefiles, vim & gdb are really, well, great. When I was a graduate student, I did a lot of pair-programming with a vim wizard who showed me just how insanely fast one can be with it -- it's small, but extensible. Sufficiently intelligent that you can open a 10 GB+ text file in it, jump to a certain line, make a change and exit; all before VS/VSCode would have opened. It's an add on to an IDE. Sometimes, for me, it replaces it.
I've never ever felt the need to use VS, or VSCode. I know other devs love VS for C++, but I love vim – VS feels like a big, bloated IDE where you have to memorise the location of 4e6 different GUI positions and take your hands continually off the keyboard to do anything. Intellisense (and, to a lesser extent, Windows as a whole) deeply irritates me. Vim has a weird, esoteric language with a learning cliff rather than a learning curve -- but I've used it almost from day one. It lets me feel incredibly powerful; it's light, yet has more features than I will ever need.
You and I are different. We've got different interests, different application areas in mind, and different preferences for how to write code and debug it. And that's okay! The key to being productive is accepting that people are different, work differently under different circumstances, and have different strengths, skills, and preferences. It's much better to be accommodating of them, rather than stifle them, and leave a proportion of your staff frustrated.
I'm just very slightly peeved that your preferences are being chosen by Github as a defacto default $EDITOR, but that there is no option whatsoever for mine – despite the fact that javascript vim / emacs "modes" are recognised as being almost religious, with highly developed FOSS javascript libraries nearly offering both keybindings and an implementation for either editor at a click of a button [e.g. 1] that have been around for >10 years.
On top of that, I can't help but notice that Github is usually very accommodating with individual developers' preferences -- to the extent there are often multiple ways of doing things as a result. The fact that, now, both Github and VSCode are both Microsoft products -- and that Microsoft famously likes people to use its "infrastructure", which is often orthogonal to the rest of the world -- just makes a little tiny bit of me feel like this is a change being pushed upon us, as originally explained in their "Embrace, Extend, Extinguish" strategy. I get it, it's a neat feature in beta, and it'll directly benefit some large proportion of their users. But if they're going to deploy fully equipped editors to the web, I'd like to have the ability to chose mine -- and give you the freedom to choose yours. I can't help but think that if this feature was developed prior to their acquisition by Microsoft, it wouldn't be VSCode that was deployed.
> ... VS feels like a big, bloated IDE where you have to memorise the location of 4e6 different GUI positions and take your hands continually off the keyboard to do anything.
it sounds like you are completely ignoring the command palette, which allows for a quick, keyboard-only way of interacting with VS Code. have you given it a chance?
When I tried VS Code, it wasn't even possible to hide the tabs. As a long-time user of Emacs and highly-configurable X window managers, the inability to remove useless graphical elements like tabs made VS Code unbearable.
How can you mock VS having 4e6 different GUI buttons, while Vim technically requires far, far more memorization? (Just logically - a keyboard's 30 or so keys will always be less flexible and require more memorization than a GUI, even if it is faster AFTER you've learned all the combinations).
It’s essential to know the basics of a terminal editor (vim, nano/pico, whatever), but for heavy lifting VSCode has a remote SSH plugin. It’s good enough I often use it for developing on a Linux box from my macOS machine.
There’s also a “code” command that will open a file or directory in VS Code.
Old man here - not sure what VS Code has to do with age, but I would rather use it than anything else.
Does it load fast and offer the features I want? Yes. Within reason, that's all I care about. I don't know what the perfect codebase size is for you (4mb? 16kloc?), but if that matters to you I hope you get to use that product.
> Am I alone in not jumping on the Visual Studio [Code]
These are at least 3 different questions:
1) Why should I use VS Code in general?
2) Why should I use VS Code online? (the articles topic)
3) Why should I use VS?
The answers might turn out completely different.
Personally, I have for my main languages (C++ & Python) full IDE's (VS & Wing IDE). For quick Python scripts, VSCode is considered an option that I use rather often.
In what VSCode shines is - as also other commenters mentioned - his plugin eco-sytem. This has true swiss-knife traits. So I'm using it for many secondary and ad-hoc technologies:
VS is unrelated to VS Code. VS is a full IDE for C++ and C# and the other .NET languages (and some other things like C to a lesser extent).
VS Code is a decent text editor with a good plugin ecosystem. It's faster to start (if it doesn't have too many slow plugins) than most IDEs and easier to get used to than vi-based editors or EMACS. And unlike Sublime Text it's free. Unlike Notepad++ it's cross-platform.
I personally use CLion for C (as well as Markdown, CMake, and shell scripts that are part of the same project as the C), PyCharm for Python, DataGrip for SQL, and VS Code for various text tasks like log file analysis and quick note taking.
It's a handy editor, very useful for ad-hoc work but not really advantageous compared to a full IDE for most regular day-to-day work IMO.
For me the advantage of VSCode is in its approach and how it has differed from other products:
- VSCode Remoting is really useful. It doesn’t suffer as much from latency as SSH or display forwarding, and lets you use some local configuration when remoting. Neovim will soon have a feature like this.
- Language servers for code intelligence has greatly improved editor support for languages. Up until the introduction and adoption of LSP, which was practically an invention of VSCode, language support was significantly more hit-or-miss with most editors. Basically only IntelliJ IDEA could do similar code intelligence across many languages. Because of LSP though, more editors and more languages can participate in inline documentation, go to symbol, errors as you type, debugging, etc. for example, many people now use language servers with Vim, and you can see useful integrations for languages like Terraform/Hashicorp HCL.
- The extensions ecosystem: it isn’t necessarily the greatest ever, but it is very solid.
- Compared to many IDEs, it remains lightweight and fast to boot. Though I’m not complaining, (regular) Visual Studio and IntelliJ are too useful to ignore in some cases.
- Unification: because it’s so versatile, across OSes, across runtimes, over remoting, over Code Spaces, you can buy into the ecosystem in your projects. You can tell Code Spaces what extensions to install and what commands to run, to try to build a nice environment. You can tell desktop VS Code what extensions are recommended, add workspace configuration to help improve the workflow. Users still can use other editors, and you can still include editor information for those editors too. But, for someone who just wants a good option to edit a specific project, pushing them towards VS Code is a really safe bet.
To be clear it has some issues too:
- There is no equally useable OSS version, as the Microsoft distribution has become more dependent on services and blobs.
- It’s not as quick and responsive as something like Sublime Text or vim.
… but honestly, I think it’s just great. If I was a new programmer again and I could jump right into projects and immediately begin working on them without having to figure out the rigmarole of version control, tool chains, build system and editor config, that would be amazing. For that reason I think Code Spaces and VSCode are net goods, though I think we ought not become too dependent on the specific solution. VSCode is never going to be the perfect editor for any specific use, but I believe overall it is usually a great editor.
I get worried that VS Code is too popular, and that some higher ups might be tempted to go for an EEE play.
The flipside is that MS pouring money into VS Code has tremendously benefited the entire code editor ecosystem, including (especially) FOSS editors that can reuse their language servers.
> This is why MIT isn't always the correct choice. GPL wouldn't hurt devs at all and would protect from this kind of garbage from MS.
But would it protect against Pylance existing, or would it just be more expensive to develop but still proprietary (and possibly not free-as-in-beer), or would it be Free?
There's only one of those three where devs (as opposed to Free Software ideologues) win, and one where both lose.
(And really, it would do none of those, since pyright is also owned by MS, so they could reuse it on any terms even if the owner [them] offered it to others only under GPL terms. All GPL would do is prevent someone else from competing with Pylance by taking pyright and building similar functionality on top, possibly with a still-Free license.)
I wish this point was brought up more often. Like in the TiVo case when everyone lost their minds about ideology, meanwhile millions of people got to watch what they wanted on their schedule and with no ads.
This attitude of MIT being bad because it gives people freedom to do Bad Things™ really makes me question what open source is actually about (yes I know that it's complicated and means many things, that's not what I'm talking about here). It seems to me that some proponents of it really believe in it so they can tell other people what to do.
If pyright were GPL'd then MS would own their own pieces, but the contributions would be owned by others and that would prevent the relicensing you're talking aobut.
MS could pay a dev team to write everything themselves, but it's a matter of cost. Given the choice between paying for a ground-up development for a tiny gain or using the open project, inertia would push toward the open project.
Finally, there's the question of trust.
Why does MS feel the need to lock these things down?
It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
> If pyright were GPL'd then MS would own their own pieces, but the contributions would be owned by others
So in your hypothetical, Microsoft not only uses the GPL instead of MIT outbound, but accepts contributions under the GPL instead of the CLA it uses for most MS open source project contributions, including pyright, inbound, etc.?
If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
> If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
How is that any less true when the outbound license is MIT, and, therefore, how is the fact that they get contributions with the CLA now not a firm disproof of that claim?
> It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
There's never a question of Microsoft's goal. It is always to destroy your choice to use non-Microsoft products. They pour resources into a "free" product that I will admit is good. It has to be, to kill all competing products over many years. Then when there is no reasonable competing product, they switch it to a paid product.
I can remember when Windows 3.1 was released. I did development on it at Ford, to emulate a vector graphics terminal. I remember when Office was bundled with Windows for free; now it is 1/3 of their revenue. I have seen Microsoft repeat this game over and over. History truly does repeat itself.
In this case both Pylance and Pyright are developed by Microsoft.
I suspect that open-sourcing in anything at all is essentially a long-term PR/marketing/recruiting investment, as well as as positioning Microsoft as the keepers and main developers of what has become an important standard.
That said, by "reuse" I mean that end-users are free to install the non-free binaries extracted from VS code, which interoperate with any text editor that implement a language client. They are all on NPM.
Can you point to how? Pretty much all of the functionality Microsoft has made that is proprietary they’ve packaged inside extensions. The app itself works fine without those extensions.
I read some of that issue but it seems to be about OpenVSX, and one of the solutions was to try switching to the official extension marketplace, probably against ToS. That seems to not be sabotage.
I tried VS Code for over a year and consider it severely lacking features that most IDEs had fifteen years ago. GitHub should reconsider whether they really want to be reminding everyone that MSFT owns them.
Same here. I've been told by various people how fast and efficient it is but it uses as much memory as a Windows VM and the code completion is screwed up 50% of the time for MS tech (and worse for others).
And - I find the constant change in configurations very confusing, and the plugins also have scant documentation. I can tell 'what is installed' but not exactly how they work together.
Having tied out JetBrains after years away - I'm now permanently back in the IDE camp. For whatever reason they are now 'faster' and so the extra bulk of features comes pretty much for free, and they are just well optimized for whatever you're trying to do.
Java on VSCode is frankly full of little snags. C++ same.
VSCode is a handy go-to tool for quickly looking at code from any language.
For pilfering through some open-source Java, Dart, Rust, that little C project, Python ... the VS is it.
I've been using a highly-tuned emacs configuration as my IDE for a decade now. Each time I want try to switch to VS Code I find that all my weird little shortcuts are going to take a lot of time to re-learn in VS Code.
I should really just take the time to switch to VS Code and rip off the bandaid since I think it would make life easier in the long run.
1) When you alt-tab you lose dialog tooltip, I can't handle this, it should be a number one priority to fix this
2) A lot of languages just look plain ugly in VS Code, not so in Emacs for example, Vim w/e
Yes, just clone? Most people who want other editors probably don't want browser-based ones.
I'm not sure if the VSCodeVim or VSCodeNeovim extensions work on the online version yet, but I'm sure some VSCode/GitHub engineers are on the case if not.
EDIT: VSCodeVim (the main "Vim" extension) does "work" on github.dev but the escape key doesn't, so as soon as you press "i" you're stuck in insert mode forever. https://github.com/VSCodeVim/Vim/issues/7005
I'm waiting for version 8 of xterm.js where they introduce a minimal version that uses less resources. Then we'll find out who's really behind the project...
As the maintainer of xterm.js I have no idea what you're suggesting? FWIW we just shipped xterm-headless which is literally a minimal version that uses less resources.
Nope you're not alone, the hype behind VSCode just seems wierd. It's not a bad editor by any means, but I can't figure out why its any different than the parade of TextMate, Sublime, Atom that came before.
I'm fully bought-in to VSCode, though I can still appreciate the benefits of diversity
Unfortunately I really doubt they'll ever offer alternate editors, especially given the technical challenges involved in embedding it in the browser, connecting it to whatever hosted environment it has, etc.
The best you might hope for is that they'll provide a terminal to the workspace, from which I could see text-based editors being available (in fact... I wonder if you could do that from VSCode's built-in terminal)
I’m with you. I see no real benefit to VS Code other than not understanding how your code editor works, if not a bit restrictive. SublimeText has filled the gaps above and I haven’t ever found a reason to leave it.
The web-based editor doesn't have a terminal, but the full-blown codespaces do have one, and they let you import your dotfiles (including running a bootstrapping script if necessary [1]).
From there, you can run whatever terminal-based editor you want, or so the blog post about github.com development having moved to Codespaces tells me [2].
But for the lighter-weight web-based editor, it doesn't look like it. If you're a CLI person, you could browse using the GitHub CLI and clone repos from there to start editing; not as convenient as punching a single key to get from viewing in a browser to editing, though.
I'm on RubyMine with vim navigation.
I find extremely helpful in everyday work and it's not only perceived feeling - I pair program sometimes with people that use VS Code and they tend to be much slower in finding things just because of the clunkiness of the VSC's UI.
I used to use VSCode as a quick editor for small things, but the bloat seems to be accelerating. I really like Jetbrains editors (and pay for them). My biggest complaint about both is how they're so in your face about every little feature. I see you have this thing, should I enable feature X for you? It looks like you're editing a Docker file. Should I enable Docker integration.
It seems we are moving to a world of magic, where developers will be alchemists, and only a handful of people will understand "physics" or "chemistry" and know what is actually going on in the cloud, serverless, fileless, functionless development.
Since google translate and google maps, I always ask myself, what is the real price for this very convenient and engaging product.
Does anybody really know anything which goes on under the hood, all the way down to transistors? I think it is half a century since this was even possible for a single person.
but there is a difference between knowing vaguely how internal combustion engine works versus treating your car as a magic box from the future. (which of course now most cars are, you can not even disable the tire pressure alert after you pump your tires without going to the service shop)
I fear that nobody will even teach the fetch-execute cycle to our kids.
https://nandgame.com is a great introduction to such stuff. But that is just a single layer. The problem with computing is not that the individual layers are difficult to understand, is it the sheer amount of layers.
I follow the rule of thumb that you should understand the layer you are working at, and one layer below. Understanding all they layers is great, but will take you a lifetime.
You can learn very decent overview of all the layers in a single weekend watching Youtube videos. It's only the deep expertise that takes time, as it always has.
I am pretty much sure engineers from late 70s said the same for young engineers. Same for the engineers from 80s for those in 90s. And the trend continues. I think servers becomes the new processors and the abstraction gets higher and higher.
It is the nature of evolution whether you like it or not.
but now we are at a day where "Amazon to remove more content that violates rules from cloud service" is on the front of hackernews together with "Visual Studio Code now available as Web based editor for GitHub repos"
evolution or not, i will revolt, if i think the path its taking is harmful.
(not that i can do much besides teaching my kid to know how computers work haha)
True, I agree with you and you have all the rights to revolt. But let's say you have an opinion, instead of revolting I would say you should push it on the world and let the world decision whether they agree with you or not. What Amazon and Google is doing is, they are enforcing their opinion by luring you into their eco system. That's one way to make the world compliant to your opinions.
Just revolting in your own universe doesn't get the job of changing the course of evolution.
This is the nature of tools, specialization, and how industries mature. This is the evolution of software eating the world -- now it's also eating development itself.
Just like "scientist" and "engineer" have fractured into many specialist disciplines, the same is happening (and has happened many times before; when's the last time you wrote assembly?) in the disciplines of "computer science" and "computer engineering".
There will still need to be experts to continue the building and maintenance of services; however, not everyone designing web sites or doing data analytics needs to know in intricate detail the underpinnings of their tools.
Haven’t we been in that world for a while now? Some of what used to be deep magic becomes shallow magic, accessible to far more people, while the magic that enables it becomes a deeper, darker art. I also don’t think this is particularly unique to computing, except insofar as computing is inherently more accessible than other technologies.
While I learned assembly language and machine code and a tiny bit of electrical engineering in school over 20 years ago, and I think it was helpful to have a basic understanding of how computers work at that level... I don't remember the details, and certainly haven't had to use them in my career as a programmer, and you don't really need to understand this stuff to be a solid programmer.
Computers are devices for abstracting, always have been.
If we had to understand everything down to do anything, we'd still be at the punchcard stage of computing, and not doing anything more sophisticated than was done then.
Well, nobody uses <table> to render a table because it has so much baggage that it is incredible slow (implicit calculations for width/height for every cell etc.).
These super fast super browsers we have today? You can kill all of them if you render a table with around 500.000 cells.
So yes, many people use divs and spans for the same functionality.
Yes, but with write access and commiting from the page (vs 1s' readonly approach), as well as some extensions working (or atleast, it filters better than 1s and only shows those that do work).
Github1s was one of the most polished projects I came across in HN. When I saw this announcement I first thought of Github1s and searched for any credits.
I thought it was amazing when someone showed me 4 years ago that you can access RStudio feature complete in a browser. Data and compute lives air gapped on the server and the developers device is just a thin client.
Great to see other development tool picking up the same usecase.
Opens up some very attractive features for the developer. The amount of vendor lock-in that this will create over time is spectacular. Can we glean something of how the future of software development looks like? Thinking especially of open-source projects here.
You can't build/compile/test within this, you'd have to lean on GitHub Actions open in another tab to check that, and actions seems more focused towards automating tests / releases after a feature is pushed, rather than during a coding session.
As far as making quick edits, it's very much a step up over the previous/ "raw" edit file function.
I made a patch to phpstan-src a few weeks back, I only needed to update one file, but couldn't get GitHub to load the file through the web editor (very large resource file of function declarations)
Just tested it in this, loaded as fast as vscode or sublime, no issues with scrolling on that 13k line file, Search works like a dream.
I've been using this for a while. Very, very, very handy for
- Just exploring some code.
- Quickly pull up as reference code w/ decent navigation without having to checkout locally or navigate forward/back in the source tree in GitHub.
- When reviewing PRs and wanting to check out some surrounding code that is not part of the actual PR.
- If you want to quickly commit something really small and trivial in master/a branch/a PR without having to do the whole stash/checkout/pull/change/commit/push rigmarole (like if you're in the middle of doing something else).
Things that are very annoying:
- Some of the most used VSCode hotkeys are browser hotkeys, like Ctrl+T, Ctrl+P, Ctrl+Shift+P etc. The functions aren't even rebound to anything else, they're just not available via hotkeys.
- Some extensions are not available, especially ones that (partially) may rely on some kind of local binary. I understand that, but that also sometimes rules out extensions that could partially work. Example: none of the Zig extensions work because they reference tooling binaries, so I can't even get syntax highlighting of Zig code. You could argue that's an extension packaging issue, however. That's fair.
- The PR reviewing UI needs a lot of work, because right now it's not as good as the normal GitHub UI, so currently, for larger PRs, I need to have both UIs open.
I hope in the future you can save a gist or something with custom settings/hotkeys/extensions to load. I'm sure they're working on something like that.
Update: Oh, there actually is some form of settings sync. Have to check that out.
> - Some of the most used VSCode hotkeys are browser hotkeys, like Ctrl+T, Ctrl+P, Ctrl+Shift+P etc. The functions aren't even rebound to anything else, they're just not available via hotkeys.
On chrome(os) at least if you move the editor to it's own fullscreen window all keys are passed to the editor.
There's probably a way to make this work without requiring the window to be fullscreen.
Too bad cmd+w, ctrl+tab, and ctrl+shift-tab doesn't close an editor tab / switch editor tabs… and if you hover on the close icon, it just tells you to use cmd+w instead of something else.
> Some of the most used VSCode hotkeys are browser hotkeys
This kills me with Jupyter. Open bash kernel, make typo, Ctrl+w, sigh as tab disappears. I often open and pin several empty tabs so it only kills the tab, not the whole window.
I suffered from the same until I discovered Gnome tweaks' "Emacs input" setting, which makes every text field behave like a Bash readline prompt with emacs keybindings!
Firefox has a config option to not close window with lasttab. I actually find it quite useful. If you're on Chromium based browser, pretty sure there will be something similar
> - Some of the most used VSCode hotkeys are browser hotkeys, like Ctrl+T, Ctrl+P, Ctrl+Shift+P etc. The functions aren't even rebound to anything else, they're just not available via hotkeys.
You can also use "chromium --app $url" and you'll have these key bindings available. If you want to use github isolated from your browser history, you can use it like so:
> - When reviewing PRs and wanting to check out some surrounding code that is not part of the actual PR.
It's interesting to see how suitable is the IDE for code review for different people. For me, it's usually pretty much overload, since it's focused on writing, not reading. But GitHub is really doing a great job of eliminating the necessity of cloning the branch for the review.
I'm doing a few experiments in this area on a tool called Viezly (example: https://viezly.com/change_requests/3986). Its focus is on dependency and navigation. So it's a light version of IDE-in-the-cloud for these cases of code review.
> If you want to quickly commit something really small and trivial in master/a branch/a PR without having to do the whole stash/checkout/pull/change/commit/push rigmarole (like if you're in the middle of doing something else).
Agree, except code formatting (e.g. w/ Prettier) is missing - which would make it extremely helpful to do small PRs.
I've been using it for the last couple of weeks on a development VPS and really love it. I'm considering moving my dev environment over to the server and just open a browser to do all the work.
Benefits of code-server is that it requires zero tooling on the client except a browser. I can use e.g. someone's iPad to quickly do some edits vs requiring my laptop with SSH keys. Other than that, using native vscode is a bit faster and has all keyboard shortcuts working. I use both vscode remote with SSH and "code server" behind NGINX.
“.” is a common convention meaning the current directory. I typically open projects locally with “code .” so I don’t view this as a complete ripoff; however, a section for “prior art” on Twitter and/or the changelog would have been a nice touch
Are you alleging that GitHub was aware of this and copied it?
Personally, this is the first that I've heard of 1s, but I'm conversely aware that Microsoft has been working on cloud based development with vscode for a while now.
github1s has 20k stars, so I'd imagine someone on the team saw it. Not saying they "stole it"... it's a pretty obvious idea considering MS owns GH and VS code.
I'm sure even Nat Friedman saw github1s because it was high up on HN and he frequents the site.
When I saw github1s on HN a while ago I thought Githuh should just hire whoever built that.
Difficult to argue if it was a plain rip-off or not, because the idea is somewhat obvious if you work in that space.
BUT, it's amazing to see how innovation is driven by individuals and small players faster then large companies - because it's a fact that github1s was first!
Not everyone sees everything that makes it to the front page. I've been frequenting HN for 10 years and this is the first I've heard of github1s, though it's not my job to know about it. It's cool.
Dude github1s was an outstanding idea, and I use it frequently. I'm surprised GH didn't steal it sooner. Sucks they didn't credit you or github1s in any way, but I guess at this point you've been well and truly sherlocked :-(
Brave users out there, something in the security model is preventing from loading the Service Worker. I tried to relax the permissions on the domains but it's still being blocked somehow:
I was trying to access [vscode](https://vscode.dev), but couldn't login using my `live.in` email address.
It says that "'live.com' does not exist in tenant 'Microsoft'", LOL
When are going to get JavaScript accelerators in hardware and OSes such that we can have a few tabs with full blown softwares like “VSCode IDE”, “Slack”, “Spotify”, “Outlook mail”, “Zoom for video calls”, “Photoshop for your photos in the cloud” and many others?
The only thing to install on your client computer being a crazy optimised web browser!
And then all the actual apps run somewhere else, in "the cloud"?
Congratulations on turning your fancy PC into a mere terminal, useless without your user account(s) at your new overlord's (or overlords') mainframe(s).
Too bad enthusiasts like you will help turn that dystopia into reality for the rest of us too.
I pressed "next section" thinking it would move me down to the next item in the menu, but it skipped me to another page. Then I tried to press some kind of "back" button and it ended the onboarding completely. And there doesn't seem to be a way to get it back again.
> Pressing the dot ( . ) key while browsing any repository on GitHub.
if you are using a QWERTY keyboard layout, yet again, decision made by someone self centered, probably a mac user since github's font looks so bad on linux
TL;DR this only lets you edit files, not actually run commands since there’s no underlying container (unless you pay by the minute for Github Codespaces).
This is in contrast to WebContainers which launched a few months ago (https://news.ycombinator.com/item?id=27223012) and enables VS Code to run entirely in-browser (including terminal commands) using a WebAssembly based operating system.
Source: worked on WebContainer and am CEO of StackBlitz
306 comments
[ 3.7 ms ] story [ 283 ms ] threadWe are still in the Wild West Phase of SAAS.
I do this for all sorts of applications.
Not going to happen..
If I am skilled enough, I can mod the piece of software to do whatever I want (this especially applies to games), or can swap out pieces with other pieces (e.g. replace the built-in compiler of an IDE with a different one).
A pure SaaS environment? I'm completely at the mercy of the operator now. I am locked in into whatever decision the operator makes, I depend on them keeping their service available 24/7 (because when they go down, I can't work and make money), I depend on them not getting bought out by a competitor that then decides to close up shop (either to get rid of competition, acqui-hire or the specific SaaS service is unprofitable), I'll have to pay whatever price the operator wants (which is particularly insidious given the SV model of price dumping, monopoly formation and subsequent extortion), and in most if not all cases I have no way of modification (userstyles/userscripts just don't work in compiled JS/CSS apps any more without a lot of work). And to top it off, for many SaaS solutions I have to pay money to keep using it under a contract, which is an obligation on my future budget.
An extremely underappreciated approach for development and distribution is targeting the browser as a sandbox for fully local applications (embodied in static files—or better: as a single file). I see lots of people making apps and throwing them up on GitHub Pages, but rarely do the developers package them up into a form that you can download from the Releases tab from the associated repo and then double click to run. At best, they'll point at the repo with instructions in the README about running npm or yarn.
(Then again, if their build processes would also target the browser's JS engine and standard browser APIs instead of NodeJS and its proprietary ones, then the entire exercise of setting up an NPM-based development environment need not exist, either. Oddly enough, people who think of themselves as JS developers and spend their days writing web apps seem to either really dislike the thought of actually using the browser, or they're so afflicted with tunnel vision that they've missed the obviousness of using the browser runtime in this way.)
> We were slaves to the mainframe! he said. Dumb terminals! That's all we had. We were powerless under the big machine's unyielding central control. Then we escaped to the personal computer, autonomous, powerful. Then networks. The PC was soon rendered to be nothing but a "thin client," just a browser with very little software residing on our personal machines, the code being on network servers, which are under the control of administrators. Now to the web, nothing but a thin, thin browser for us. All the intelligence out there, on the net, our machines having become dumb terminals again.
Obviously it's no Visual Studio Code (not least because of the ecosystem of plugins), so it's great to see things coming along.
For many people internet connectivity and local computation power (within the browser) is now good enough to skip installations and updates all together.
It makes perfect sense for them to do this and in the end they are not giving up control if they still own the OS.
Microsoft can always the decide that "untrusted" websites (which, for example, are not "certified" by them) get blocked from using certain features.
Why people are excited about this OS, I don't know :)
IMO, This is the best thing about browser as an OS. You can run untrusted apps and know that it couldn't steal your ssh keys or other things without your consent, similar to iOS and Android.
When all your data is on a server its like you dont need a sandbox any more. :)
For all practical purposes, file system sandbox features might actually be the first to become meaningless again when more and more data is stored in offline browser caches
And application delivery in enterprise environments is also much more lightweight compared to VDI solutions like Citrix so there’s another benefit in terms of sandbox and isolation
For complex software (e.g. video games) on the other hand the web is a real piece of crap: performance suck, no UDP, a certain browser is purposely a ton of useful APIs (or is straight up buggy).
I am fairly comfortable having my laptop being a conduit to better resources in the cloud. There are also strong security advantages of not having sensitive data on laptops.
Curious to see how the developing experience will evolve in the next few years.
It's great, but if it were really Visual Studio Code that would be awesome and I'd be pleasantly surprised.
(The difference being that if it's just the editor it misses out on all the compiler/analysis integrations. If Github were providing Linux containers in the cloud for working on projects - essentially the SSH feature from Visual Studio Code - it would be absolutely brilliant.)
Azure has had this for a few years now (unless there's upgrades in the Github version I'm not aware of) and it's been really useful for quick edits - will be good to see it develop now that it's sure to pick up much more use through GH.
Admittedly, the storage costs would be higher.
[1]: https://github.com/cdr/code-server
"embrace, extend, extinguish" ...
A few weeks ago I investigated using an embedded version of vscode to create containerized dev environments for an internal developer platform we're working on. The hope was to allow devs to write and debug code from inside a k8s container by using vscode inside their browser. Very similar to the newly announced codespaces feature.
Unfortunately, there were several factors that made this impractical. The extension marketplace can only be used with the official build. There are at least two alternatives but both were missing extensions that our devs used. Also, the c# debugger is proprietary and only works with official vscode build.
From that experience I believe that while the core editor features of vscode are open source, "Visual Studio Code" the tool that people actually use is defacto proprietary and entirely controlled by Microsoft.
The "extinguish" is obviously yet to come, but turning a blind eye to it certainly won't help stave it off. And trying to fog others' vision to it is... Less than a good look.
Embrace: Buy Github, NPM, develop VScode, Typescript, Azure.
Extend & extinguish: make all of them work together really well in a way that can't be reproduce by the open soure community.
I think it's a bit early to say that they are embracing and extinguishing at this point, but I wasn't here last time and may be biaised because I find these tools incredibly convenient. In a way, Microsoft is leveraging their unique advantage over other cloud vendors, which is their proximity with developers.
"Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions."
So if your text editor doesn't support integration with Github and a cloud vendor, or if your repositories don't support integration with an online text editor and a cloud vendor, or if your cloud vendor doesn't support integration with Github and an online text editor, this will affect your market share. I think the end goal is around "developer mindshare" (which, I admit, is a really vague concept), especially in web applications. By assembling all that they have, they can create an experience no one else can, all while leveraging open source tools.
You could also imagine an integration with education (Github student pack, Azure credits, etc). At this point, they could dominate the web app market because no one else can offer such a deep integration across the stack.
I think one of the differences with the "old" EEE would be that instead of intentionally crippling certain features, they are instead focusing on giving the best-in-class experience. If you consider that it's just regular competition and not EEE because of that, that's totally fair. Still, I think that we should still be wary of domination. Competition is what's pushing Microsoft to develop all those wonderful tools, and I fear that with domination they might become complacent and abuse their position.
"No, they're different things. Just like GMail is one e-mail server (and client), but GMail isn't the same thing as e-mail."
Gonna try that next time I get onto the subject.
Microsoft, Amazon, Google (and Facebook?) each have their own angle on it, but seem to be moving towards the same goal: a return to the old model of centralised computing, with the Web as the substrate, your "PC" reduced to a graphical terminal, and their servers as the mainframe.
The difference in angles is partly just that they each want their servers to be the main mainframe, not those of one of the others; and partly because they're each coming at it from different directions, each trying to play off of their own strengths. But the goal and direction? All absolutely the same.
The best we can hope for (if I'm being pessimistic) is probably that none of them wins outright, but instead we get a shaky balance between as many as possible of them.
> "Embrace, extend, and extinguish" (EEE) . . . is a phrase that the U.S. Department of Justice found that was used internally by Microsoft to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.
This is a completely valid reason to be concerned with these sorts of things now that GitHub is owned and operated by Microsoft. They continue these practices today, and GitHub is no exception.
But the little voice indeed remains.
Outside games, even most native mobile apps don't work without their timesharing infrastructure.
For the others, that does not know the concept that was applied by them numerous times, it's easy:
- embrace: they buy GitHub, play nice, be part of the community, we will change nothing, commit to open source spirit
- extend [current step]: oh, we are just adding nice features, now you will use our visual studio, but don't worry, it's for free, it just improve your experience.
- extinguish [next step, my guess]:
* "sadly, VS works better in edge and does not support minor browsers like Firefox",
* there are these cool new synchronization features/real time collaboration that requires Visual Studio on your computer.
* Sorry, you need an official VS build to use the features because security/authentication/...
* Here are the corporate workspace accounts that allows to limit code edition in the cloud, for security. And so, for security also, you can only use it from edge on windows X with TPM.
Based on previous MS experiences, the possibility are endless!
I would kindly remind that the version of VisualStudioCode that almost everyone use is just a freeware but it can't be built as is from ope source code.
Also, not long so long ago they were willing to switch everyone GitHub accounts with Microsoft accounts...
(Yes, I'm aware this makes me sound like an old man!)
At least this way it makes sense, as a pure Web application.
It lacks some nice features and improvements that PHPStorm has, but it's pretty good overall. There are a couple things that NetBeans does better than PHPStorm, though.
Each to their own really, and honestly not every tool is going to be a good fit for every project. I have day work on Visual Studio that I wouldn't dream of moving to VSC for a bunch of reasons.
The reasons myself and others like VSC also have a lot to do with the plug-in ecosystem. More people using it means someone has likely already encountered my use case which means it's more likely a plugin exists to do what I need.
There are places that live on JetBrains for this reason (sprawling homogenous codebases that cross domains and languages). Having support to hand not only for the code you use most, but every language/framework other folks in your organisation use, is a really useful feature for integration/debugging work.
I would now feel uncomfortable using anything else.
[0]https://github.com/glacambre/firenvim
I was thinking of something that would allow you to use any machine with a browser.
It was so sleek and lightweight at first it was really a pleasure to use. But performance and bugs seem to increase, even if you don't use many or any plugins at all.
Devs with this many extensions are an OpSec/data governance nightmare!
VSCode desperately needs some sort of access policy/permission system for their extensions, and make it more obvious when an extension phones home code or other data its user doesn't directly provide it with.
Copilot, for example, straight up sends and uses your code - not just the modifications you've made to the laundered code it provides you with, but any or all of it [1].
1 https://docs.github.com/en/github/copilot/telemetry-terms
It still has decent performance and I will continue using it. I think I have my linters correctly configured so there isn't any huge background scanning of files. But I have the impression the early versions were faster.
My main drivers are IntelliJ products (WebStorm, Rider, CLion, DataGrip...).
VSCode is just too sluggish for me.
Still have some hope that eventually it gets redone in React Native or something.
But I did go from notepad, to eclipse, to ST, to vscode to JetBrains, so … obviously I’m trying to get into emacs now
I don’t ask my work to pay, because I use it personally as well, and I look at my brother as a woodworker and he’s honed his tools to what suits him.
I do the same.
It doesn't even come close. It's powerful but it's definitely not the same. I would go back to NetBeans before using VSCode. There's no religion behind it, it's just that there are tools that suit my needs better than others.
Considering nearly every S/W dev globally can make that in a couple of days, I'm not sure how much of a flex it is considering it would be your primary work tool.
And I say this as someone whose never used a Jetbrains tool and use Vim for nearly everything (except when I'm on Windows where I use a mix of Notepad++ and VSCode).
Sometimes you can afford it, and sometimes you can’t.
I think we forget when you could (and still can) do dev with a text editor.
I 100% get what you say, but that’s a lot of money potentially - which is where I think vscode /vim etc shine in that it’s free and can do the same kinda thing
This is only possibly true if your definition of "global" is "1st world".
I have used many IDEs.
I have never ever felt the need to use vim.
Is it fair to say, because VSCode does not have a "vim mode", it is somehow inferior as an editor?
I seriously don't get it. I have used VSCode almost from day one. It is a fantastic editor and quite a capable tool. I seriously love it.
Everyone can use it as its meant to be, a great tool platform that has a great community of plugins and support.
That said, VSCode is very good. But I don't believe in a web-based IDE and in remote Github repos. That's a recipe for disaster and unescapable vendor lock-in, and in any case it's only an option for web dev., really.
Edit: Since some people always take things literally: I have of course tried vim, like most people who ever worked with Unix/Linux I suppose, but never got beyond that. I am surprised that it seems to have become so "fashionable" lately. There are many alternatives to vi/vim and many IDEs. My experience is that vi has always suffered from its interface and has struggled to expand beyond "bearded Unix gurus"...
I personally tend to install micro, or use nano if that's not possible.
For dev. I use an graphical editor, usually VSCode these days. I used emacs at some point a long time ago.
The good thing with git and al is that there is no need to access a remote repo., and that's one of the points, so there is usually no need to edit source files remotely.
Extrapolating from personal experience, I think this might be down to Covid WFH where more people have had to ssh into remote machines and may need to edit files so might choose to use vim as it’s easily available. And vim is something that I find is better learned progressively where you pick up 1 or 2 tricks every week or something so those people might have been able to pick it up over the last year or so and are now evangelizing it.
I have also been WFH because of Covid but haven't had to change much or anything to my way of working and I do SSH to multiple machines every day. That might vary a lot from person to person, though. I have avoided doing actual dev. on a remote machine by setting up a VM to run Linux locally as any sort of remote desktop tends to be a pain.
Also, with distributed source control (git and friends) there is usually no need to access remote source files.
Want to have your mind blown? Microsoft (yes that Microsoft) officially supports remote development on Windows Server via SSH. As in, run vscode on your Linux box, create an SSH remote on your Windows Server, develop remotely on the server via SSH. Fully supported.
I was excited for this as a way to avoid touching Windows altogether, but it works pretty crappily in my experience.
See this plugin here: https://github.com/VSCodeVim/Vim
It works surprisingly well.
I also enjoy the emulated plugins (vim-surround mostly).
Is VSCode an inferior editor compared to Vim/Neovim? Absolutely, it is. Is Vim/NeoVim an inferior IDE experience compared to VSCode despite the ongoing evangelism by NeoVim fundamentalists? Most likely, yes.
Here's an example before I start getting flak — NeoVim doesn't have stable indent visualization lines and stable and sensible code folding support. Try writing serious Markdown documentation or Python code in NeoVim and then in VSCode.
The NeoVim website also mentions that being like an IDE is not one of its goals.
I already know the responses I'm gonna get - it's open source, submit patches or shut up, it's personal taste, those features are irrelevant etc etc.
> I seriously don't get it. I have used VSCode almost from day one. It is a fantastic editor and quite a capable tool. I seriously love it.
You should keep using it. Don't get swayed by people proselytising Neovim.
https://github.com/lukas-reineke/indent-blankline.nvim/
I've written a lot of C, a lot of scripting languages, and a bit of C++. I've used many IDEs.
For me, the "command line" workflow of Makefiles, vim & gdb are really, well, great. When I was a graduate student, I did a lot of pair-programming with a vim wizard who showed me just how insanely fast one can be with it -- it's small, but extensible. Sufficiently intelligent that you can open a 10 GB+ text file in it, jump to a certain line, make a change and exit; all before VS/VSCode would have opened. It's an add on to an IDE. Sometimes, for me, it replaces it.
I've never ever felt the need to use VS, or VSCode. I know other devs love VS for C++, but I love vim – VS feels like a big, bloated IDE where you have to memorise the location of 4e6 different GUI positions and take your hands continually off the keyboard to do anything. Intellisense (and, to a lesser extent, Windows as a whole) deeply irritates me. Vim has a weird, esoteric language with a learning cliff rather than a learning curve -- but I've used it almost from day one. It lets me feel incredibly powerful; it's light, yet has more features than I will ever need.
You and I are different. We've got different interests, different application areas in mind, and different preferences for how to write code and debug it. And that's okay! The key to being productive is accepting that people are different, work differently under different circumstances, and have different strengths, skills, and preferences. It's much better to be accommodating of them, rather than stifle them, and leave a proportion of your staff frustrated.
I'm just very slightly peeved that your preferences are being chosen by Github as a defacto default $EDITOR, but that there is no option whatsoever for mine – despite the fact that javascript vim / emacs "modes" are recognised as being almost religious, with highly developed FOSS javascript libraries nearly offering both keybindings and an implementation for either editor at a click of a button [e.g. 1] that have been around for >10 years.
On top of that, I can't help but notice that Github is usually very accommodating with individual developers' preferences -- to the extent there are often multiple ways of doing things as a result. The fact that, now, both Github and VSCode are both Microsoft products -- and that Microsoft famously likes people to use its "infrastructure", which is often orthogonal to the rest of the world -- just makes a little tiny bit of me feel like this is a change being pushed upon us, as originally explained in their "Embrace, Extend, Extinguish" strategy. I get it, it's a neat feature in beta, and it'll directly benefit some large proportion of their users. But if they're going to deploy fully equipped editors to the web, I'd like to have the ability to chose mine -- and give you the freedom to choose yours. I can't help but think that if this feature was developed prior to their acquisition by Microsoft, it wouldn't be VSCode that was deployed.
[1] https://github.com/ajaxorg/ace
it sounds like you are completely ignoring the command palette, which allows for a quick, keyboard-only way of interacting with VS Code. have you given it a chance?
This one sentence convinces me that you have not used VSCode in any meaningful way.
I ditched GUI items for getting stuff done long time ago with VSCode. I just bring up the command palette and type away. Its insanely great.
When I tried VS Code, it wasn't even possible to hide the tabs. As a long-time user of Emacs and highly-configurable X window managers, the inability to remove useless graphical elements like tabs made VS Code unbearable.
Also, Command Palette? Heard of it?
There’s also a “code” command that will open a file or directory in VS Code.
Does it load fast and offer the features I want? Yes. Within reason, that's all I care about. I don't know what the perfect codebase size is for you (4mb? 16kloc?), but if that matters to you I hope you get to use that product.
These are at least 3 different questions:
1) Why should I use VS Code in general?
2) Why should I use VS Code online? (the articles topic)
3) Why should I use VS?
The answers might turn out completely different.
Personally, I have for my main languages (C++ & Python) full IDE's (VS & Wing IDE). For quick Python scripts, VSCode is considered an option that I use rather often.
In what VSCode shines is - as also other commenters mentioned - his plugin eco-sytem. This has true swiss-knife traits. So I'm using it for many secondary and ad-hoc technologies:
- CMake files
- Julia
- GPS files
- JS files
- LaTeX
- JSON
- XML
- CSS
- Markdown (vanilla, asciidoc, ReST)
- remote editing
VS Code is a decent text editor with a good plugin ecosystem. It's faster to start (if it doesn't have too many slow plugins) than most IDEs and easier to get used to than vi-based editors or EMACS. And unlike Sublime Text it's free. Unlike Notepad++ it's cross-platform.
I personally use CLion for C (as well as Markdown, CMake, and shell scripts that are part of the same project as the C), PyCharm for Python, DataGrip for SQL, and VS Code for various text tasks like log file analysis and quick note taking.
It's a handy editor, very useful for ad-hoc work but not really advantageous compared to a full IDE for most regular day-to-day work IMO.
- VSCode Remoting is really useful. It doesn’t suffer as much from latency as SSH or display forwarding, and lets you use some local configuration when remoting. Neovim will soon have a feature like this.
- Language servers for code intelligence has greatly improved editor support for languages. Up until the introduction and adoption of LSP, which was practically an invention of VSCode, language support was significantly more hit-or-miss with most editors. Basically only IntelliJ IDEA could do similar code intelligence across many languages. Because of LSP though, more editors and more languages can participate in inline documentation, go to symbol, errors as you type, debugging, etc. for example, many people now use language servers with Vim, and you can see useful integrations for languages like Terraform/Hashicorp HCL.
- The extensions ecosystem: it isn’t necessarily the greatest ever, but it is very solid.
- Compared to many IDEs, it remains lightweight and fast to boot. Though I’m not complaining, (regular) Visual Studio and IntelliJ are too useful to ignore in some cases.
- Unification: because it’s so versatile, across OSes, across runtimes, over remoting, over Code Spaces, you can buy into the ecosystem in your projects. You can tell Code Spaces what extensions to install and what commands to run, to try to build a nice environment. You can tell desktop VS Code what extensions are recommended, add workspace configuration to help improve the workflow. Users still can use other editors, and you can still include editor information for those editors too. But, for someone who just wants a good option to edit a specific project, pushing them towards VS Code is a really safe bet.
To be clear it has some issues too:
- There is no equally useable OSS version, as the Microsoft distribution has become more dependent on services and blobs.
- It’s not as quick and responsive as something like Sublime Text or vim.
… but honestly, I think it’s just great. If I was a new programmer again and I could jump right into projects and immediately begin working on them without having to figure out the rigmarole of version control, tool chains, build system and editor config, that would be amazing. For that reason I think Code Spaces and VSCode are net goods, though I think we ought not become too dependent on the specific solution. VSCode is never going to be the perfect editor for any specific use, but I believe overall it is usually a great editor.
The flipside is that MS pouring money into VS Code has tremendously benefited the entire code editor ecosystem, including (especially) FOSS editors that can reuse their language servers.
An example is the Python language server
https://github.com/microsoft/pylance-release
They base it 90% on the open-source pyright library. Then the lock down all their own enhancements.
https://github.com/microsoft/pyright
This is why MIT isn't always the correct choice. GPL wouldn't hurt devs at all and would protect from this kind of garbage from MS.
But would it protect against Pylance existing, or would it just be more expensive to develop but still proprietary (and possibly not free-as-in-beer), or would it be Free?
There's only one of those three where devs (as opposed to Free Software ideologues) win, and one where both lose.
(And really, it would do none of those, since pyright is also owned by MS, so they could reuse it on any terms even if the owner [them] offered it to others only under GPL terms. All GPL would do is prevent someone else from competing with Pylance by taking pyright and building similar functionality on top, possibly with a still-Free license.)
This attitude of MIT being bad because it gives people freedom to do Bad Things™ really makes me question what open source is actually about (yes I know that it's complicated and means many things, that's not what I'm talking about here). It seems to me that some proponents of it really believe in it so they can tell other people what to do.
"Some", perhaps. But this is a really disingenuous way to characterize open source.
MS could pay a dev team to write everything themselves, but it's a matter of cost. Given the choice between paying for a ground-up development for a tiny gain or using the open project, inertia would push toward the open project.
Finally, there's the question of trust.
Why does MS feel the need to lock these things down?
It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
So in your hypothetical, Microsoft not only uses the GPL instead of MIT outbound, but accepts contributions under the GPL instead of the CLA it uses for most MS open source project contributions, including pyright, inbound, etc.?
If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
How is that any less true when the outbound license is MIT, and, therefore, how is the fact that they get contributions with the CLA now not a firm disproof of that claim?
There's never a question of Microsoft's goal. It is always to destroy your choice to use non-Microsoft products. They pour resources into a "free" product that I will admit is good. It has to be, to kill all competing products over many years. Then when there is no reasonable competing product, they switch it to a paid product.
I can remember when Windows 3.1 was released. I did development on it at Ford, to emulate a vector graphics terminal. I remember when Office was bundled with Windows for free; now it is 1/3 of their revenue. I have seen Microsoft repeat this game over and over. History truly does repeat itself.
I suspect that open-sourcing in anything at all is essentially a long-term PR/marketing/recruiting investment, as well as as positioning Microsoft as the keepers and main developers of what has become an important standard.
That said, by "reuse" I mean that end-users are free to install the non-free binaries extracted from VS code, which interoperate with any text editor that implement a language client. They are all on NPM.
Check out VSCodium, similar to Chrome/Chromium, it's just VSCode minus all the related Microsoft stuff.
It is usable just not very good, yet.
And - I find the constant change in configurations very confusing, and the plugins also have scant documentation. I can tell 'what is installed' but not exactly how they work together.
Having tied out JetBrains after years away - I'm now permanently back in the IDE camp. For whatever reason they are now 'faster' and so the extra bulk of features comes pretty much for free, and they are just well optimized for whatever you're trying to do.
Java on VSCode is frankly full of little snags. C++ same.
VSCode is a handy go-to tool for quickly looking at code from any language.
For pilfering through some open-source Java, Dart, Rust, that little C project, Python ... the VS is it.
But for mainline projects, a good IDE is it.
I should really just take the time to switch to VS Code and rip off the bandaid since I think it would make life easier in the long run.
Emacs will be around forever, but vscode will dominate.
1) When you alt-tab you lose dialog tooltip, I can't handle this, it should be a number one priority to fix this 2) A lot of languages just look plain ugly in VS Code, not so in Emacs for example, Vim w/e
Yes, just clone? Most people who want other editors probably don't want browser-based ones.
I'm not sure if the VSCodeVim or VSCodeNeovim extensions work on the online version yet, but I'm sure some VSCode/GitHub engineers are on the case if not.
EDIT: VSCodeVim (the main "Vim" extension) does "work" on github.dev but the escape key doesn't, so as soon as you press "i" you're stuck in insert mode forever. https://github.com/VSCodeVim/Vim/issues/7005
xterm.js [1] is pretty good.
Something like gotty [2] and a engine for getting a container with a git checkout started should be relatively straight forward.
[1]:https://github.com/xtermjs/xterm.js/
[2]:https://github.com/yudai/gotty
xterm-min-8.js
I forgot HN is not the place for humor, and I did not intend to cast any actual aspersions toward anyone maintaining cool projects.
Unfortunately I really doubt they'll ever offer alternate editors, especially given the technical challenges involved in embedding it in the browser, connecting it to whatever hosted environment it has, etc.
The best you might hope for is that they'll provide a terminal to the workspace, from which I could see text-based editors being available (in fact... I wonder if you could do that from VSCode's built-in terminal)
From there, you can run whatever terminal-based editor you want, or so the blog post about github.com development having moved to Codespaces tells me [2].
But for the lighter-weight web-based editor, it doesn't look like it. If you're a CLI person, you could browse using the GitHub CLI and clone repos from there to start editing; not as convenient as punching a single key to get from viewing in a browser to editing, though.
[1]: https://docs.github.com/en/codespaces/customizing-your-codes...
[2]: https://github.blog/2021-08-11-githubs-engineering-team-move...
IDEA is the same way. Turns out coding isn't about text input after all.
I guess I'm a pair programmer with Clippy now :-(
- Pressing the dot ( . ) key while browsing any repository on GitHub.
- Change the URL from "github.com" to "github.dev".
rad
Is there a way to disable this option? (to avoid accidentally opening up the editor). Couldn't find info on this from the linked page.
Since google translate and google maps, I always ask myself, what is the real price for this very convenient and engaging product.
but there is a difference between knowing vaguely how internal combustion engine works versus treating your car as a magic box from the future. (which of course now most cars are, you can not even disable the tire pressure alert after you pump your tires without going to the service shop)
I fear that nobody will even teach the fetch-execute cycle to our kids.
I follow the rule of thumb that you should understand the layer you are working at, and one layer below. Understanding all they layers is great, but will take you a lifetime.
It is the nature of evolution whether you like it or not.
but now we are at a day where "Amazon to remove more content that violates rules from cloud service" is on the front of hackernews together with "Visual Studio Code now available as Web based editor for GitHub repos"
evolution or not, i will revolt, if i think the path its taking is harmful. (not that i can do much besides teaching my kid to know how computers work haha)
Just revolting in your own universe doesn't get the job of changing the course of evolution.
i meant i will take action against the evolution, and one of the things i can do is spend as much time as i can in educating my daughter.
Otherwise we'll end up recalling the retired programmers that know cobol because nobody else can fix it anymore.
Aren't we talking about "SaaS services outside of your control" here?
There will still need to be experts to continue the building and maintenance of services; however, not everyone designing web sites or doing data analytics needs to know in intricate detail the underpinnings of their tools.
Computers are devices for abstracting, always have been.
If we had to understand everything down to do anything, we'd still be at the punchcard stage of computing, and not doing anything more sophisticated than was done then.
License: MIT
It works insanely well.
These super fast super browsers we have today? You can kill all of them if you render a table with around 500.000 cells.
So yes, many people use divs and spans for the same functionality.
Problem is the bloated standard for html tables that requires many calculations. This is why any browser-excel is implemented with divs.
Great to see other development tool picking up the same usecase.
You can't build/compile/test within this, you'd have to lean on GitHub Actions open in another tab to check that, and actions seems more focused towards automating tests / releases after a feature is pushed, rather than during a coding session.
As far as making quick edits, it's very much a step up over the previous/ "raw" edit file function.
I made a patch to phpstan-src a few weeks back, I only needed to update one file, but couldn't get GitHub to load the file through the web editor (very large resource file of function declarations)
Just tested it in this, loaded as fast as vscode or sublime, no issues with scrolling on that 13k line file, Search works like a dream.
- Just exploring some code.
- Quickly pull up as reference code w/ decent navigation without having to checkout locally or navigate forward/back in the source tree in GitHub.
- When reviewing PRs and wanting to check out some surrounding code that is not part of the actual PR.
- If you want to quickly commit something really small and trivial in master/a branch/a PR without having to do the whole stash/checkout/pull/change/commit/push rigmarole (like if you're in the middle of doing something else).
Things that are very annoying:
- Some of the most used VSCode hotkeys are browser hotkeys, like Ctrl+T, Ctrl+P, Ctrl+Shift+P etc. The functions aren't even rebound to anything else, they're just not available via hotkeys.
- Some extensions are not available, especially ones that (partially) may rely on some kind of local binary. I understand that, but that also sometimes rules out extensions that could partially work. Example: none of the Zig extensions work because they reference tooling binaries, so I can't even get syntax highlighting of Zig code. You could argue that's an extension packaging issue, however. That's fair.
- The PR reviewing UI needs a lot of work, because right now it's not as good as the normal GitHub UI, so currently, for larger PRs, I need to have both UIs open.
I hope in the future you can save a gist or something with custom settings/hotkeys/extensions to load. I'm sure they're working on something like that.
Update: Oh, there actually is some form of settings sync. Have to check that out.
On chrome(os) at least if you move the editor to it's own fullscreen window all keys are passed to the editor.
There's probably a way to make this work without requiring the window to be fullscreen.
https://www.cnet.com/how-to/this-setting-makes-chrome-os-fee...
1. Go to any Github repo 2. Press . 3. Wait for the editor to load... 4. Press Ctrl/Command + P 5. It opens VSCode's "Go to File" prompt
Too bad cmd+w, ctrl+tab, and ctrl+shift-tab doesn't close an editor tab / switch editor tabs… and if you hover on the close icon, it just tells you to use cmd+w instead of something else.
Considering that there was obviously going to be a keyboard-clash, their approach seems to be very pragmatic.
Now I just have to change the other bindings (and relearn).
This kills me with Jupyter. Open bash kernel, make typo, Ctrl+w, sigh as tab disappears. I often open and pin several empty tabs so it only kills the tab, not the whole window.
You can also use "chromium --app $url" and you'll have these key bindings available. If you want to use github isolated from your browser history, you can use it like so:
[$] chromium --user-data-dir=$HOME/github_or_whatever --app="https://github.com/orga/repo" --new-window;
edit: If you use MacOS or Windows, my browser wrapper script from another project might give you some hints on how to use Safari or Edge this way [1].
[1] https://github.com/tholian-network/stealth/blob/X0/browser/b...
It's interesting to see how suitable is the IDE for code review for different people. For me, it's usually pretty much overload, since it's focused on writing, not reading. But GitHub is really doing a great job of eliminating the necessity of cloning the branch for the review.
I'm doing a few experiments in this area on a tool called Viezly (example: https://viezly.com/change_requests/3986). Its focus is on dependency and navigation. So it's a light version of IDE-in-the-cloud for these cases of code review.
Agree, except code formatting (e.g. w/ Prettier) is missing - which would make it extremely helpful to do small PRs.
All of this works for me when I am in full-screen mode.
https://github.com/cdr/code-server
I've been using it for the last couple of weeks on a development VPS and really love it. I'm considering moving my dev environment over to the server and just open a browser to do all the work.
It automatically sets up the server for me on any machine I can SSH into and I can use real VSCode instead of the browser version.
No Credits given :( => https://github.com/conwnet/github1s/issues/346
Personally, this is the first that I've heard of 1s, but I'm conversely aware that Microsoft has been working on cloud based development with vscode for a while now.
When I saw github1s on HN a while ago I thought Githuh should just hire whoever built that.
Difficult to argue if it was a plain rip-off or not, because the idea is somewhat obvious if you work in that space.
BUT, it's amazing to see how innovation is driven by individuals and small players faster then large companies - because it's a fact that github1s was first!
> Error loading webview: Error: Could not register service workers: NotSupportedError: Failed to register a ServiceWorker for scope ('https://a47e99b4-9517-4e50-87ca-95e06da14aed.vscode-webview....') with script ('https://a47e99b4-9517-4e50-87ca-95e06da14aed.vscode-webview....'): The user denied permission to use Service Worker..
When are going to get JavaScript accelerators in hardware and OSes such that we can have a few tabs with full blown softwares like “VSCode IDE”, “Slack”, “Spotify”, “Outlook mail”, “Zoom for video calls”, “Photoshop for your photos in the cloud” and many others?
The only thing to install on your client computer being a crazy optimised web browser!
May be ChromeOS was ahead of its time.
And the direction will probably be WASM instead of Javascript. It seems like JS runtimes are not easy to optimize further.
Congratulations on turning your fancy PC into a mere terminal, useless without your user account(s) at your new overlord's (or overlords') mainframe(s).
Too bad enthusiasts like you will help turn that dystopia into reality for the rest of us too.
I pressed "next section" thinking it would move me down to the next item in the menu, but it skipped me to another page. Then I tried to press some kind of "back" button and it ended the onboarding completely. And there doesn't seem to be a way to get it back again.
if you are using a QWERTY keyboard layout, yet again, decision made by someone self centered, probably a mac user since github's font looks so bad on linux
It's pretty nice to have an extra tier between "local clone/checkout" and "commit to remote repository".
I can code on my three different machines with one "remote checkout" and commit when I'm finished.
Before, I would have to pull/push every time I switched the machine.
I used Cloud9 before, but VSCode simply has the better eco-system.
The only thing that sucks is (obviously) offline work. It would be cool if I could do more locally, especially when I'm in a train.
And the project never loads.
Edit1: That said I also started development on my own web IDE: http://edit.rupy.se
Edit2: This other URL works: https://github1s.com/tinspin/rupy
This is in contrast to WebContainers which launched a few months ago (https://news.ycombinator.com/item?id=27223012) and enables VS Code to run entirely in-browser (including terminal commands) using a WebAssembly based operating system.
Source: worked on WebContainer and am CEO of StackBlitz