Live data from Hacker News

Web-based editor

docs.github.com

51–60 of 307 posts

Re: Web-based editor

#51
post #27
post #2

Its scary we're heading towards a situation where everything is done in a browser. Maybe Chromeos really is the future.

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 :)

Start disecting how the brain works and its very similar one stack of garbage hacks on top of another constantly accumulating over time.

Re: Web-based editor

#52
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.

Re: Web-based editor

#53
post #33

Is this similar to what github1s.com offered?

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).

Re: Web-based editor

#54
post #3
post #2

Its scary we're heading towards a situation where everything is done in a browser. Maybe Chromeos really is the future.

Why is it scary?

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.

Re: Web-based editor

#55
post #31

Earlier quoted context omitted.

I see this happening a lot with the young engineers. Very few of them really know what's happening under the hoods.

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.

that is of course true

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)

Re: Web-based editor

#56
post #41

Earlier quoted context omitted.

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.

haha maybe Christopher Domas knows :D https://www.youtube.com/watch?v=jmTwlEh8L7g [x86 god mode] 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 teac…

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.

Re: Web-based editor

#57
post #50

You can open any GitHub repository in the web-based editor in the following ways: - Pressing the dot ( . ) key while browsing any repository on GitHub. - Change the URL from "github.com" to "github.dev". rad

> Pressing the dot ( . ) key while browsing any repository on GitHub 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.

Doesn't look like there is, or for any other keyboard shortcut on GitHub...

Re: Web-based editor

#58

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!)

Yes, you're alone you luddite (kidding!). 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…

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.

Re: Web-based editor

#59

Remember the typical Microsoft: "embrace, extend, extinguish" ...

What exactly is it you are saying they are embracing, extending or extinguishing here?

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.

Re: Web-based editor

#60
post #39

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.

I'm not sure what attractive features you mean?

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.

Post reply on HN