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.
> - 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.
> 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
> 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.
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.
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 :-(
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.
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.
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.
“.” 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
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!)
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.
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"...
> 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.
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 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.
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.
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.
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.
> ... 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?
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).
> 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.
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.
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.)
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.
> 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.
> 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?
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.
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.
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.
> 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.
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?
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'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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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 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.
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.
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).
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.
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
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.
The Gitlab editor has been very useful but it would be nice if it also started using VSCode. It would offload the editor development and offer more consistency and features from a well-tested product.
That's a silly reason to justify a worse product. And I've yet to see what company has switched away from Github purely because of Microsoft's acquisition.
I recently discovered this feature and started using it to explore repositories and it's saved me a lot of time. My use-case is pretty simple but you can definitely do a lot more with this. For those that prefer a visual example you can watch my 2 minute YouTube video[0].
Pros:
- No need to clone code base to just explore it (cmd + p to search files)
- A lot of VS code extensions are available to use out of the box: Vim, themes, syntax highlighters
- You can import your VS code's custom settings.json + keybindings.json
Cons:
- Not all keybindings work since they conflict with the browser (cmd + shift + f to search all files sometimes bugs out and makes browser full screen)
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).
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.
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.
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.
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 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.
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 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.)
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.)
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
> 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.
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.
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.
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.
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.
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.
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.
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.
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:
This seems like something they could roll out over time, especially given how hard they've been championing LSP elsewhere. I see a convergence over time between this, VSCode remote mode, Codespaces, etc.
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.
GitHub sure is focused on getting people to edit projects from the web, but they continue to let the actual code review part languish. It’s barely usable for any kind of serious review, and it barely even loads for large PRs.
I wonder if this results in some amount of lower quality pull requests since the "barrier to entry" is now pretty low. On the other hand, it might open up more people that can help with documentation bugs and similar.
I think the net effect will be positive. Especially on documentation where adding some detail or gotcha is low risk but could possibly save someone else hours.
If folks are curious about the kind of use cases this enables, I wrote a quick article last week that highlights some of the things that are currently possible (e.g. codebase walkthroughs, web playgrounds, knowledge-base management): http://aka.ms/githubdev-fun
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.
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
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.
I have been using my own ver. Of online vscode for about a year now, had it set up on a micro server on GCP, it has its benefits while on the run and needing a quick go-to solution , very nice of GitHub implementing this solution , handy
So cool! How did I miss this?! I’ve been looking for something like this for a while now. Github has been coming out some really great features but sometimes you have no idea they are even available.
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.
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.
This is more than a little ironic, because if I remember correctly, Github created the open source Atom editor, which was gaining popularity until VS Code came into the picture and absolutely destroyed it.
Not without reason, it was all part of M$ofts plans…why people don’t see the red flags of GitHub becoming a monopoly over the code ecosystem is beyond me…..
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.
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).
gave up on vscode two years ago and bought jetbrains when I need a GUI debugger, but I use vim for daily coding.
just hit . and installed vim plugin and it worked well for basic needs, not sure how to get my snippets and some key binding there yet, but this does look nice.
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
> 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
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...
> "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 ;)
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.
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.
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."
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.
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.
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.
- 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.