Hacker News Reader

Comment by numbsafari | Hacker News Reader

Using a browser based IDE is really powerful as an option, but comes with a major cost of having to co-exist with the browser in terms of keyboard macros/chords.

Personally, I've found it to be really annoying.

Using VSCode as a desktop connected to a remote code server, or using JetBrains Projector, is the true sweet spot where you combine the remote capabilities with a native app. Also fits well with vim/emacs TUI-style dev.

If I were building an IDE today, I would absolutely be building it as a client-server app from day 1.

View on HN

For PWAs, you can "install" the app to your machine / phone which gives it its own icon and launches it in its own window. This also allows it to override most default shortcuts (Cmd/Ctrl+W, Cmd/Ctrl+T etc.) I use this with https://github.com/coder/code-server on my personal server and it's a way better experience for me than mucking around with SSH / SFTP plugins.

>If I were building an IDE today, I would absolutely be building it as a client-server app from day 1.

Why ? The last thing you want as a user when pressing a key in a IDE is to then wait for a network request.

That's exactly what a lot of users that do development on a beefy remote machine from a light machine they use as a terminal want. Ssh+vim+tmux is a pretty common setup. That network request might add 20ms of lag, but means that anything that requires CPU power will be an order of magnitude faster. The unhappy path (a bad or absent connection) is bad, but the happy path is pretty damn happy.

I guess the combination is the holy grail, but the effort may not be worth it in alot of cases.

What I'm referring to would be a caching view which both hides latency, batches communication for efficiency and perhaps even does some actions on the client-side buffer if it's deemed appropriate.

code-server (vscode in gerneral with remote development extensions) does a lot of splitting of processes between the server and client. This makes normal code writing done on the client side. Intellisense still has the network delay, but is something that takes time anyway. The terminal doesnt get this benefit so they instead add local echo to make the delay a little easier to handle with [1]. I do not know if this works in code server.

[1] https://code.visualstudio.com/updates/v1_51#_local-echo

ssh+vim+tmux actually unlocked my iPad as a coding tool, which is incredible. I can go on a bike ride, stop in the park, get a bit of work done with some tea in a thermos, and then bike back home.

And bill client for the whole day ;)

Does tmux add anything in particular to SSH+Vim? I’ve never used it so I don’t know the connection, other than its obvious use as a multiview terminal with fabulous persistence?

Multiplexing in the ssh shell is way more convenient than opening a new ssh connection every time you need a new terminal. If vim is occupying your shell you definitely want a multiplexer instead of Ctrl+Z every time you need to do something in shell. I know vim 8 has an integrated terminal but I can't stand using the terminal with vim keystrokes.

tmux is also amazing for spotty ssh connections. For example, I had to run long jobs over ssh through a VPN. Tmux means you don't need to worry about the connection dropping and losing your current process

Rendering will be done locally, so keypresses will be instant, the intelligent response will have 20ms lag, but that's not exactly much addition (as a total percentage) with current IDEs.

https://www.mightyapp.com/

shrug

It’s worth noting that the setup mentioned:

> Using VSCode as a desktop connected to a remote code server, or using JetBrains Projector, is the true sweet spot

is a zero lag approach when it comes to code editing.

The only time a brief lag show up in the IDE are when you need to open a folder/workspace in an uncached directory which is easily ignored.

I’ve been banging the drum on this setup for well over 2 years. Happy to share more info if interested

More generally with web apps the extraneous browser chrome (some of which carries over into "installed" PWAs, even) is annoying. If web apps are to be treated as true peers to their native desktop counterparts, browserisms like back buttons must be left behind.

Iirc you can’t reconfigure keybindings in any major browser. To me that’s terrible UX, preventative of richer web applications, and a usability issue.

I’m not suggesting JavaScript should be able to redefine keys without permission, but I can’t even disable CTRL+w as a power user…

Given my age, for me it is back to X Windows days doing remote development, only in a more fancy protocol.

Reply on news.ycombinator.com