Web-based editor
docs.github.com
docs.github.com
- 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.
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!
(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.
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].
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.
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.
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.
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 :-(
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.
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)
- Not all extensions are currently available
- The terminal doesn't work
If you have a pipeline setup you can of course run code on commit.
Hell, this turns an iPad into a limited dev station. For situations where your not at your dev system you can still get some limited work done.
We 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.
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.
docker run -p 8080:8080 -v "${PWD}:/workspace" mltooling/ml-workspace
docker run --name=cocalc -d -v ~/cocalc:/projects -p 443:443 sagemathinc/cocalcSince 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.
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.
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.
- 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.
> 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..
However, the lack of language servers hardly make it a replacement for a desktop install of VSCode.
Writing Rust code without RLS, or Zig code without ZLS is not a great experience.
Great to see other development tool picking up the same usecase.
https://news.ycombinator.com/item?id=28143722
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.
Curious to see how the developing experience will evolve in the next few years.
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
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.
Troubleshooting
If you have issues opening the web-based editor, try the following:
Make sure you are signed in to GitHub. nope
Disable any ad blockers. nope
Use a non-incognito window in your browser to open the web-based editor. nope
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.
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
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
"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...
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.