7 ms·

Fig: Visual Apps and Shortcuts for Your Terminal

102 points by DanielKehoe 6y ago

square_usual 6y ago
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.
- SllX 6y ago
  It’s a half step between getting some Terminal functionality without necessarily having to be fluent in the Terminal. I think the idea is for it to be an option expanding choice without having to necessarily seek out a GUI that will provide an interface to all of the functionality you need. If something is missing, well the Terminal is right there.
  - square_usual 6y ago
    Given that the service seems to be aimed at developers, I don't see it as being an option for people who aren't "fluent in the Terminal". I don't see any commands they support that necessarily have to be done in the terminal, either, since such things as git, ffmpeg, psql etc have great GUIs available for nearly all use cases. If you're not a developer, you're better off downloading specific apps instead of using fig, and if you're a developer, I don't see how fig helps you over binding your own aliases or writing scripts for specific tasks.
    - SllX 6y ago
      I don’t disagree, on principle I think it is better to know your tools and know them well. At the same time I too once had to learn my tools, and I can empathize with those that just want to quickly get to work and don’t want to memorize every single command-line option, whether this tool uses one dash or two dashes, or single letters, whole words, was it a capital “A” or a lower case “a” to do the thing I want. Personally I won’t be using fig, but I could see why someone might try it. If it helps new developers learn the command line, or helps them get to the meat of working with code without feeling hindered by what they perceive as this old archaic interface, but they want to learn this thing eventually, there’s probably some value in that.
    - andrewfong 6y ago
      I'm a developer and I think it'd be useful. I'm semi-fluent (conversational?) when it comes to CLIs, and this looks like a great way to recall stuff for less frequently used commands or edge cases. Two reasons why I would download this but not a full on GUIs for things: 1. There's a long tail of CLI tools I use just rarely enough that I can't justify downloading a whole application for something. I just don't need to run awk or sed that often. But if you aggregate "all terminal commands I need to Google usage for", then that adds up just enough to download a helper. 2. There are contexts in which I can't use a GUI. For example, sometimes I need to SSH into a headless server and update a Git repo or do something with sed and awk on a giant pile of logs that I don't want to transfer to my local machine.
- DanielKehoe 6y ago
  (updated the title) It's interesting to see a hybrid of a console and a GUI. For me I can see usefulness beyond a man page or Google search to see what flags are available for a command and then select flags. Plus there's benefit for users who are new to a terminal. I think we'll see more terminal/GUI hybrids like this (the Darklang "canvas" is an example).
- oezi 6y ago
  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/Skinning_the_Command_Line.pdf http://www.mi.fu-berlin.de/wiki/pub/SE/ThesisCommandLine/Ski...
  - mschrage 6y ago
    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 6y ago
      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/QuintelaGarciaL06-command-line.pdf https://www.inf.fu-berlin.de/inst/ag-se/theses/QuintelaGarci...
- scottfr 6y ago
  > 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? Having both provides a smooth skill ramp for users. They can start using the GUI and over time they learn the analogous command line interface. A GUI is also superior for discoverability compared to a command line interface even for experienced users.
- mschrage 6y ago
  The value for me has been the ability to easily bounce back and forth between levels of abstraction. Sometimes you need the granularity the shell provides, but other times it's nice to lean back on a more opinionated workflow. Sort of like the difference between deploying with Heroku versus managing everything with Kubernetes. Also, Fig is entirely extensible/customizable. This is probably the part I'm most excited about: anyone can build their own apps. All of the example apps on our site are written with the same API that is exposed to developers. (https://withfig.com/docs https://withfig.com/docs)
mahaganapati 6y ago
To me the logo looks like a pear instead of a fig
- leetrout 6y ago
  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
trevyn 6y ago
Unfortunately, it's gotten to the point where adding anything proprietary to the workflow is a liability.
29athrowaway 6y ago
Just a reminder that Dialog/Zenity/KDialog can be used to create "friendly" user interfaces to scripts.
deleted 6y ago
[deleted]
edfletcher_t137 6y ago
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 6y ago
  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 6y ago
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.
- kitotik 6y ago
  Plan9 is the future past.
- totetsu 6y ago
  I think we are going to go the way of Semantic ML https://stadia.dev/blog/creating-game-ai-using-mostly-english/ https://stadia.dev/blog/creating-game-ai-using-mostly-englis... Being able to use natural language to send commands.
- bitwize 6y ago
  Holy crap, Emacs really is from the future: https://news.ycombinator.com/item?id=23112030 https://news.ycombinator.com/item?id=23112030
laumars 6y ago
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
- ashkante 6y ago
  Not to mention, it being Electron could[1] mean a memory hog. Granted, not all Electron apps are, but after seeing a GUI git client which ate up 800MiB+, I'm very skeptical about this technology. I don't want a shell, a chat client, a git client and an editor to take up 3-4GiB of my RAM... [1] I can't claim that without testing, but it's a good possibility when it comes to Electron.
- rvz 6y ago
  "Electron" and I stopped reading and closed the Fig website. Aside from using it to over-engineer this non issue of terminals (Already solved via GUI) it has been superseded by aliases, autocomplete and automation. No point using a double negative product. > the landing page is so hyperbolic Well its from the typical startup launch playbook: Humaans + Flat UI + Emojis + "FAAMNG company testimonials" + "Contact Us/Sales" = 75% VC backed bullshit.
  - mthoms 6y ago
    There's no Electron involved. I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.
- mschrage 6y ago
  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.
  - 6y ago
foreigner 6y ago
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.
totetsu 6y ago
Should call it Fig leaf, because you're hiding the best bits.
deleted 6y ago
[deleted]
self_awareness 6y ago
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 6y ago
  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 6y ago
    Uh, you're right. I had to click an empty portion of the screen and click 'Play', then the video showed up. Thanks.
  - mschrage 6y ago
    Thanks for posting this. I've been meaning to compress the mp4, but hadn't gotten around to it just yet.
nobody9999 6y ago
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_Tool https://en.wikipedia.org/wiki/System_Management_Interface_To...) is the way to go.
GeneralMaximus 6y ago
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.
pcr910303 6y ago
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 6y ago
  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 6y ago
    > 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.
fmajid 6y ago
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.
pixxel 6y ago
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.
beshrkayali 6y ago
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.
ipsum2 6y ago
"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 6y ago
  You're totally right. We're deleting it from our site now. Change should be pushed in a few minutes.
  - fragmede 6y ago
    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.)
mschrage 6y ago
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 6y ago
  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 6y ago
    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!
filmgirlcw 6y ago
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!

102 points by DanielKehoe 6y ago

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.

SllX 6y ago
It’s a half step between getting some Terminal functionality without necessarily having to be fluent in the Terminal. I think the idea is for it to be an option expanding choice without having to necessarily seek out a GUI that will provide an interface to all of the functionality you need. If something is missing, well the Terminal is right there.
- square_usual 6y ago
  Given that the service seems to be aimed at developers, I don't see it as being an option for people who aren't "fluent in the Terminal". I don't see any commands they support that necessarily have to be done in the terminal, either, since such things as git, ffmpeg, psql etc have great GUIs available for nearly all use cases. If you're not a developer, you're better off downloading specific apps instead of using fig, and if you're a developer, I don't see how fig helps you over binding your own aliases or writing scripts for specific tasks.
  - SllX 6y ago
    I don’t disagree, on principle I think it is better to know your tools and know them well. At the same time I too once had to learn my tools, and I can empathize with those that just want to quickly get to work and don’t want to memorize every single command-line option, whether this tool uses one dash or two dashes, or single letters, whole words, was it a capital “A” or a lower case “a” to do the thing I want. Personally I won’t be using fig, but I could see why someone might try it. If it helps new developers learn the command line, or helps them get to the meat of working with code without feeling hindered by what they perceive as this old archaic interface, but they want to learn this thing eventually, there’s probably some value in that.
  - andrewfong 6y ago
    I'm a developer and I think it'd be useful. I'm semi-fluent (conversational?) when it comes to CLIs, and this looks like a great way to recall stuff for less frequently used commands or edge cases. Two reasons why I would download this but not a full on GUIs for things: 1. There's a long tail of CLI tools I use just rarely enough that I can't justify downloading a whole application for something. I just don't need to run awk or sed that often. But if you aggregate "all terminal commands I need to Google usage for", then that adds up just enough to download a helper. 2. There are contexts in which I can't use a GUI. For example, sometimes I need to SSH into a headless server and update a Git repo or do something with sed and awk on a giant pile of logs that I don't want to transfer to my local machine.
DanielKehoe 6y ago
(updated the title) It's interesting to see a hybrid of a console and a GUI. For me I can see usefulness beyond a man page or Google search to see what flags are available for a command and then select flags. Plus there's benefit for users who are new to a terminal. I think we'll see more terminal/GUI hybrids like this (the Darklang "canvas" is an example).
oezi 6y ago
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/Skinning_the_Command_Line.pdf http://www.mi.fu-berlin.de/wiki/pub/SE/ThesisCommandLine/Ski...
- mschrage 6y ago
  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 6y ago
    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/QuintelaGarciaL06-command-line.pdf https://www.inf.fu-berlin.de/inst/ag-se/theses/QuintelaGarci...
scottfr 6y ago
> 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? Having both provides a smooth skill ramp for users. They can start using the GUI and over time they learn the analogous command line interface. A GUI is also superior for discoverability compared to a command line interface even for experienced users.
mschrage 6y ago
The value for me has been the ability to easily bounce back and forth between levels of abstraction. Sometimes you need the granularity the shell provides, but other times it's nice to lean back on a more opinionated workflow. Sort of like the difference between deploying with Heroku versus managing everything with Kubernetes. Also, Fig is entirely extensible/customizable. This is probably the part I'm most excited about: anyone can build their own apps. All of the example apps on our site are written with the same API that is exposed to developers. (https://withfig.com/docs https://withfig.com/docs)

mahaganapati 6y ago

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

leetrout 6y ago
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

trevyn 6y ago

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

29athrowaway 6y ago

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

deleted 6y ago

[deleted]

edfletcher_t137 6y ago

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 6y ago
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 6y ago

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.

kitotik 6y ago
Plan9 is the future past.
totetsu 6y ago
I think we are going to go the way of Semantic ML https://stadia.dev/blog/creating-game-ai-using-mostly-english/ https://stadia.dev/blog/creating-game-ai-using-mostly-englis... Being able to use natural language to send commands.
bitwize 6y ago
Holy crap, Emacs really is from the future: https://news.ycombinator.com/item?id=23112030 https://news.ycombinator.com/item?id=23112030

laumars 6y ago

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

ashkante 6y ago
Not to mention, it being Electron could[1] mean a memory hog. Granted, not all Electron apps are, but after seeing a GUI git client which ate up 800MiB+, I'm very skeptical about this technology. I don't want a shell, a chat client, a git client and an editor to take up 3-4GiB of my RAM... [1] I can't claim that without testing, but it's a good possibility when it comes to Electron.
rvz 6y ago
"Electron" and I stopped reading and closed the Fig website. Aside from using it to over-engineer this non issue of terminals (Already solved via GUI) it has been superseded by aliases, autocomplete and automation. No point using a double negative product. > the landing page is so hyperbolic Well its from the typical startup launch playbook: Humaans + Flat UI + Emojis + "FAAMNG company testimonials" + "Contact Us/Sales" = 75% VC backed bullshit.
- mthoms 6y ago
  There's no Electron involved. I'm aghast at the level of toxicity and quick-judgment in the hacker community. It's really disappointing.
mschrage 6y ago
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.
- 6y ago

foreigner 6y ago

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.

totetsu 6y ago

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

deleted 6y ago

[deleted]

self_awareness 6y ago

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 6y ago
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 6y ago
  Uh, you're right. I had to click an empty portion of the screen and click 'Play', then the video showed up. Thanks.
- mschrage 6y ago
  Thanks for posting this. I've been meaning to compress the mp4, but hadn't gotten around to it just yet.

nobody9999 6y ago

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_Tool https://en.wikipedia.org/wiki/System_Management_Interface_To...) is the way to go.

GeneralMaximus 6y ago

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.

pcr910303 6y ago

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 6y ago
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 6y ago
  > 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.

fmajid 6y ago

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.

pixxel 6y ago

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.

beshrkayali 6y ago

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.

ipsum2 6y ago

"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 6y ago
You're totally right. We're deleting it from our site now. Change should be pushed in a few minutes.
- fragmede 6y ago
  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.)

mschrage 6y ago

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 6y ago
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 6y ago
  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!

filmgirlcw 6y ago

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!