←back to thread

536 points helloguillecl | 2 comments | | HN request time: 0.44s | source
Show context
gschier ◴[] No.45648871[source]
This is exactly why I made Yaak [1]. It's fully offline, no telemetry, open source, and can even sync with Git.

https://yaak.app

replies(24): >>45649247 #>>45649460 #>>45649533 #>>45649785 #>>45650125 #>>45650134 #>>45650346 #>>45650414 #>>45650872 #>>45650904 #>>45651211 #>>45651696 #>>45651897 #>>45651944 #>>45651953 #>>45652091 #>>45652467 #>>45652699 #>>45652703 #>>45652804 #>>45653077 #>>45654796 #>>45657795 #>>45689069 #
dayson ◴[] No.45650134[source]
I was looking at Yaak, and wondering if you've plans to bring it inside VS Code some day?

how would someone use this in a project that operates within VS Code Remote where the source sits on a remote server and isn't physically on the file system.

replies(1): >>45650492 #
gschier ◴[] No.45650492[source]
No plans for VSCode integration, no. It's only great because it's designed for a very specific use case and environment.

I'm not quite sure why Yaak wouldn't work in this case. It it because your running server wouldn't be accessible to Yaak, running on your system?

replies(1): >>45651113 #
exasperaited ◴[] No.45651113[source]
In case you aren’t familiar (and with apologies for my verbosity if you are): VSCode Remote can be best understood as a sort of hybrid of a local text editor and a remote web-based or X11 view of an editor for a remote session.

When you use a remote, the code is on the remote and all your editing functions (search, version control, terminal, extensions) happen in the remote via a worker process.

So in a remote session, everything is “local” to the remote. You may have no file “mount” of the thing at all on your host desktop machine. If you do a git commit, it’s running inside/on the remote. If you do a file search the files are searched on the remote, rather than downloading them over some network filesystem and searching locally.

The GP’s point is, I think: if you implemented Yaak as a VSCode extension, it could be made to function either in a local session or inside a remote (on a server accessed via SSH, a docker container, on the linux side of WSL etc.) and therefore have fast rather than slow access to the code, git repo etc.

I do essentially all my dev work (apart from compiling the odd mac app) inside remotes of various kinds to create reproducible environments, avoid cluttering the host, sandbox the tools, give me freedom to work from more than one machine etc., and I run into this sort of thing quite a bit.

There are at least two clients like this for VSCode —- Thunder Client and EchoAPI, and I believe both function in a remote session.

P.S. I loved Insomnia before the bad happened; it really helped with learning APIs. Thanks.

replies(2): >>45651343 #>>45653375 #
kyawzazaw ◴[] No.45651343[source]
probably too much work for a solo dev
replies(1): >>45652334 #
1. vscode-rest ◴[] No.45652334[source]
The REST Book extension was made by a VS Code dev and does a decent enough chunk of what is needed, at least for simple use cases.

Handy Dandy Notebook as well, but that requires some reformulation to get everything in terms of standard curl/node/python/etc commands. (whether that’s better or worse than a custom http dsl is a matter of some debate)

replies(1): >>45652720 #
2. saikatsg ◴[] No.45652720[source]
Also: httpBook - Rest Client