
Fig: Visual Apps and Shortcuts for Your Terminal - DanielKehoe
https://withfig.com/
======
mschrage
Hey HN! I'm Matt Schrage, one of the cofounders of Fig.

We were planning on launching on HN later on, so this caught us a bit off
guard. (As someone noted, our 'Fig' icon is, in fact, an emoji pear). Still
we're super excited to share what we've been working on.

Fig lets you connect web apps directly to your terminal. You can use Fig like
a browser to get quick access to sites like Github, Stack Overflow, or Notion.
You can also run apps built on the Fig.js runtime that integrate directly with
your terminal. We want to be a low-cost abstraction. Use a Fig app when it's
useful, drop back down to the shell when it's not.

I just wanted to respond to a couple of points.

The app is actually written in Swift: we're using a WKWebView under the hood
but the majority of the codebase is native. Also because we aren't built on
Electron, we don't need to bundle v8 and node along with the app, so the
binary is pretty small (12mb).

Fig is extensible. The apps shown on the website (git, curl, and finder) are
just a few examples of what is possible. You can check out the documentation
at [https://withfig.com/docs](https://withfig.com/docs) and build your own.

Fig works with the tools you already use - we integrate with any terminal
emulator (iTerm, Terminal.app, Hyper, Alactritty, etc.). Previous attempts at
building GUI terminals have required throwing away 50 years worth of tooling
and transitioning to a new application entirely. Fig is built around the
premise that in order to upgrade the terminal, _changes must be backwards
compatible_.

Happy to answer any more questions and really appreciate the feedback we've
gotten so far.

~~~
pcr910303
I'm very happy to see it's a Swift/native app! One request, I would love to
see an API (JS or a native bundle or anything) so that I can write native UIs,
not just ones in WKWebViews as I personally think having native UIs are
important.

Also, (I've already written this on the TypeForm, but) I would like if Fig
spits out information that can be useful to stdout/stderr. For example, user
interaction can go to stderr and the result (I guess user commands?) can go to
stdout. I understand this might be a bit hard as I guess Fig is working
asynchronously - but maybe changing so that people can build on Fig with shell
scripts might be better.

Thanks!

~~~
mschrage
Yeah, these are both great ideas.

I was inspired to use web technologies for building the UI by this discussion
([https://lobste.rs/s/vrb7qh/web_as_gui_toolkit](https://lobste.rs/s/vrb7qh/web_as_gui_toolkit)).
Ultimately, I want to port Fig to Linux and Windows, so having a UI layer that
works cross platform is useful. But it would be very cool to enable access to
native UI directly. (I'd love to chat with you about how this could work.)

Outputing to stdout and stderr doesn't happen right now, but is on the very
near term roadmap. The ultimate goal is for web apps to slot in seamlessly to
shell workflows, so getting this right is really important.

Thanks for your comments!

------
pcr910303
Wow, HN is really harsh on the idea of merging CLIs and GUIs...

I think that merging CLIs and GUIs have a great potential.

GUIs are superior than CLIs on interaction because it gives context of the
current state and visual cues. (And no, TUIs aren't CLIs nor are they better
than GUIs.) However users still use CLIs - the biggest advantage that CLIs
have is that it allows various programs interact with each other, e.g. via
piping. That's why we have CLI programs that's sole purposes that are
communicating with GUI programs, for example almost every programmer's text
editor ships with a binary that can i.e. reading from stdin, opening an
temporary file, and spitting out to stdin (or at least gives the capability of
doing that) so that we can use it in e.g. moreutils vipe.

It seems Fig is an product that allows the reverse, e.g. tying GUIs to CLIs so
that people can use git, curl or other CLI programs in a more interaction-
friendly way. I think this is has a great potential, if it's rightly executed
(i.e. hopefully doesn't use Electron...?)

PS: The argument that 'every programmer knows how to use CLI, so this isn't
needed' is just proving the point - programmers deserve better than an plain-
text 1970-era interaction, yet we have to use the Terminal daily to accomplish
something.

~~~
egwor
I think the problem is that historically when people have done this they've
made a total mess of it, and inevitably it doesn't support all options so the
GUI always plays catch up (and no one is interested in keeping the GUI up to
date).

I think the example for this was the wget gui.

My take on this is that for beginners this is really useful. It can also help
show you new options that you might not have been aware of. (Have you read the
full man page?)

~~~
pcr910303
> I think the problem is that historically when people have done this they've
> made a total mess of it, and inevitably it doesn't support all options so
> the GUI always plays catch up (and no one is interested in keeping the GUI
> up to date).

> I think the example for this was the wget gui.

Yeah, that's true, but I think it'll be easier than binding GUI to the CLI.

The reason CLIs could get this usefulness was because it mixes up user
interaction with it's programming interface (which is ironically what people
most hate). If you want to make a CLI program, you almost need to spit out
useful information to stdout, which means I can extract info from sed. GUIs
are much harsher to extracting information and there are some solutions like
AppleScript, but it doesn't fly.

Which means, exposing the CLI's capabilities to GUIs are much easier than
exposing the GUI's capabilities to CLIs. While Fig isn't taking this route,
one could write an man-page parser (like how fish does for it's completion)
and expose CLI functionality automatically and increase it's usefulness with
human annotations.

> My take on this is that for beginners this is really useful. It can also
> help show you new options that you might not have been aware of. (Have you
> read the full man page?)

Yeah, agreed.

------
foreigner
The initial example with curl looks very compelling. I like that it's not a
replacement for the CLI, just a graphical way to build the CLI commands. Seems
like a much better way of learning arcane command line arguments than the
searching through man pages that I do now.

Some of the other examples like changing directories and the git client are
less interesting for me - if I wanted to actually replace the CLI with a GUI
there are better options.

I signed up for early access.

------
self_awareness
I have no idea what it is. The main page is really terrible in telling me how
it even looks like, I don't even know why I would want this.

Is it a small web browser embedded into the terminal window? Or it's a
different thing? No idea.

GUI wrappers for common tools? How do you create a GUI wrapper for 'bg'? With
a form and 1 button named "Run"?

~~~
danellis
Try reloading the page. There's a (pointlessly animated) video right on the
front page that shows exactly what it does.

Direct link:
[https://withfig.com/video/final.mp4](https://withfig.com/video/final.mp4)

~~~
self_awareness
Uh, you're right. I had to click an empty portion of the screen and click
'Play', then the video showed up. Thanks.

------
ipsum2
"TRUSTED BY ENGINEERS AT WORLD CLASS COMPANIES". This is embarrassing. Please
stop doing this - just because a friend from a FAANG company installed your
app, doesn't mean its trusted by any company, or that anyone would use it on
their internal codebase.

~~~
mschrage
You're totally right. We're deleting it from our site now. Change should be
pushed in a few minutes.

~~~
fragmede
Developers are allergic to feeling like they're being marketed to, as GP
comment proves. That doesn't mean it's a bad marketing direction, just that
more specificity is needed.

If it really is just "my bff from high school that works at a FANG installed
my software on their own personal time on their on personal laptop", then
yeah, get rid of it.

But somewhere between one person at a FANG using the software professionally,
and _everyone_ at said FANG using the software (eg an HR ERP system like
Workday), is an individual's personal threshold for what "used by a FANG"
means to them. As long as it's reworded to be represented honestly then I'd
keep it. FANGs are the gold standard for a reason, and the social proof gained
by having your software used there _is_ valuable to the segment of the
population that gives it value. (The intersection of "the segment of the
population that gives it value" and your target market, may (or may not) be an
empty set, however.)

------
pixxel
I should have closed the tab when I saw the boast of Facebook/Google/Microsoft
logos and the words "trusted by". But I thought I'd join the waiting list to
see the product in action. So I give my email, I'm then whisked away to
TypeForm's website and I have to fill out a fucking form which starts by
demanding my full name. I'm not giving an "online survey service" any of my
details just to join a waiting list.

------
edfletcher_t137
I use a terminal because it is NOT a GUI, significantly improving productivity
once learned. I cannot grok this, it feels like a step in precisely the other
direction.

~~~
mschrage
When you know the commands by memory, the terminal is hands-down the fastest
way of interfacing with a computer. The trouble is when you're using a new
command or toolchain and don't know the commands by heart.

For instance, code signing and notarizing a Mac app is a huge pain. It's not
the kind of thing I do all the time, but it took quite a while to figure it
out. I spent a few hours piecing together StackOverflow answers, assorted blog
posts, and the threads on Apple's Developer Forum before I got it to work. It
would be great if this workflow could be encapsulated an app.

------
rbosinger
I can see the power in a future OS interface that really combined the terminal
and GUI in a powerful way. Maybe this is a good start to thinking about that.

~~~
totetsu
I think we are going to go the way of Semantic ML
[https://stadia.dev/blog/creating-game-ai-using-mostly-
englis...](https://stadia.dev/blog/creating-game-ai-using-mostly-english/)
Being able to use natural language to send commands.

------
mahaganapati
To me the logo looks like a pear instead of a fig

~~~
leetrout
I think it’s the pear emoji [https://www.iemoji.com/view/emoji/602/food-
drink/pear](https://www.iemoji.com/view/emoji/602/food-drink/pear)

------
29athrowaway
Just a reminder that Dialog/Zenity/KDialog can be used to create "friendly"
user interfaces to scripts.

------
fmajid
MPW (Macintosh Programmer’s Workshop) had a feature like that, called
commandos IIRC, over 30 years ago. It did not set the world afire.

Furthermore, a closed-source solution is a non-starter.

The fish shell has an interesting feature where it parses man pages to
autocomplete commands.

------
square_usual
I personally don't see the point. If you want a GUI for some commands, why not
just get GUI apps which do those things? Why try to bolt a GUI onto a CLI,
especially one that works by pasting commands back into a CLI? You're relying
on fig to develop UIs for all of your frequently used commands, and if you
don't like fig's UIs for certain commands, you're SOL until they let you make
your own UIs, and at that point it's basically an OS with an App Store. If you
want a productivity boost from eliminating repeated commands, you're better
off writing aliases or bash scripts for your personal use, in my opinion.

Side note: I think the title should reflect the name of the service, Fig.

~~~
oezi
I worked on this idea in 2003 [1] and we envisioned it to help a lot with
discoverability and consequently learning curve. Our idea was more interactive
in that editing in the UI would immediately be reflected in the terminal and
vice versa. A power user would just type the whole command from memory but
still have the ability to click a checkbox to add that rare/elusive switch.
Beginners could do everything in the UI but quickly learn from seeing the
command line string being built.

We worked towards automatically generate the UI from man pages (prioritized
from examples found online) rather than manually developing each tool. As a
student project we did not get very far.

[1] [http://www.mi.fu-
berlin.de/wiki/pub/SE/ThesisCommandLine/Ski...](http://www.mi.fu-
berlin.de/wiki/pub/SE/ThesisCommandLine/Skinning_the_Command_Line.pdf)

~~~
mschrage
This is really interesting! I think that the scalable approach like you
proposed in your thesis makes a lot of sense, but comes at some cost to the
user experience.

Rather than being 'smart' and automating everything, we want to make
developing apps really easy and familiar.

I'm curious what the biggest challenges were for you with the project? Maybe
we could build on your research.

~~~
oezi
It has been a long time, but I think we struggled most with:

\- What is the best architecture to enable this? I think we struggled a lot
with wanting to hook on the shell level where the commands are managed, the UI
client where the user interface would have to be shown and terminal emulation
where it is all key strokes and cursors.

Today I believe that this would really need something like the Language Server
Protocol being implemented in bash itself. Today we have bash completion
scripts, but still not something as comprehensive as needed.

\- How to separate everything into reusable blocks? For instance extracting
parameters from man pages, storing as generic config files, whether to offer a
DSL for designing the UIs, etc. We did not want to be stuck with one
particular terminal, such as KDE's Konsole (for which a student did another
prototype [1] in German).

[1] [https://www.inf.fu-berlin.de/inst/ag-
se/theses/QuintelaGarci...](https://www.inf.fu-berlin.de/inst/ag-
se/theses/QuintelaGarciaL06-command-line.pdf)

------
GeneralMaximus
I really like this idea!

There are tons of CLI tools for which I've burned pretty much every flag that
I'll ever need into my muscle memory. But there are far more tools that I use
only ocassionally -- like mysqldump -- where I have to dig through a manpage
or tutorial just to get basic tasks done.

Something like this built into my terminal would make my life so much easier.
It's almost like a quick reference card or cheatsheet, except it's totally
interactive.

------
laumars
So this is basically just an Electron terminal emulator with some shortcuts
included? You can already do all this in a fair few existing terminal
emulators, not to mention shell aliases et al. I mean I get the problem space
they’re trying to solve but the landing page is so hyperbolic I’m put off
investing any time to see if this actually has usability gains over what the
team already do use

~~~
mschrage
Completely agree about Electron - it's really heavy. That's why we built Fig
as a Swift app.

Also, just to clarify, Fig isn't a terminal emulator itself. It attaches to
whichever one you currently use.

~~~
laumars
Your landing page does an absolutely terrible job explaining anything about
your product though. I assume this is aimed at engineers and technical
managers rather than non-technical folk (because why would a non-technical
manager be using the terminal)? The fact I had to scroll 5 pages (on iOS
Safari), past multiple elevator pitches, FAANG “testimonials” (who cares if a
couple of engineers in Google liked your Github repo?) and sign up pages just
to see a single screenshot, and not even one that does a good job at
demonstrating your product, shows just how out of whack the landing page is
with your target audience.

As it is, I am a manager myself and looking at standardising some of our
toolchain ahead of onboarding around 8 new engineers in September (4 of who
will be graduates so might benefit from tools like this) and I gave up with
the idea of this when I couldn’t extrapolate how we would use and integrate it
into our existing workflows.

Frankly, it was frustrating to find something that went from “ohh this might
be useful” to “I’ve read their content and I still have no idea how this thing
works”.

~~~
mschrage
Honestly this is really useful feedback. I think the page might be broken on
mobile. There should be a large video demonstrating the product at the
top.([https://withfig.com/video/final.mp4](https://withfig.com/video/final.mp4))

You're exactly the type of person we're trying to help, so we clearly need to
communicate our value prop better!

If you have some time to chat, I'd love to talk. My email is matt [at]
withfig.com

~~~
mthoms
FYI, the animations didn't work for me in MacOS Safari (with AdGuard
extension, though I'm not sure thats the reason)

------
beshrkayali
It might not be directly related to this, but I think it's way better for
learners to actually read the docs/manpage and then try to craft the command
themselves (getting it wrong a couple of times as well). This is kind of like
copy/pasting the answer, which solves the immediate problem but is terrible
for learning what's going on or how it works.

------
filmgirlcw
For whatever hate this is getting, I like the idea a lot and signed-up and
hope to be able to play with this. I can already think of a ton of apps I
would build/use with something like this -- not just for me, but for
demos/tutorials/documentation I make for other users.

Keep doing your thing! It's a good idea!

------
trevyn
Unfortunately, it's gotten to the point where adding anything proprietary to
the workflow is a liability.

------
totetsu
Should call it Fig leaf, because you're hiding the best bits.

------
nobody9999
Firstly, the webpage _bluescreened_ my Windows 7 box in Firefox ESR _twice_
with Javascript disabled.

Secondly, this is a stupid idea. If you want to do something like this to help
folks learn the CLI, a tool like SMIT/smitty
([https://en.wikipedia.org/wiki/System_Management_Interface_To...](https://en.wikipedia.org/wiki/System_Management_Interface_Tool))
is the way to go.

