3 ms·

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

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!
wayneftw 6y ago
Nice work! Can you operate the GUI entirely with the keyboard? If not, I think it would be great if you could do things like: - Use Ctrl+Tab to switch tabs. - Use Tab to cycle focus over inputs. - Use Keyboard Mnemonics (underlined letters) to focus on specific inputs. If Fig can already do these things, I would update your demo video to show that because switching between CLI and GUI is very easy when you don't have to constantly pick up the mouse. (Oh, didn't notice this was Mac only. Ewww. (Sorry.) I hate macOS precisely because operating it's GUI with a keyboard is the most painful experience of any OS.)
- mschrage 6y ago
  This is a great question. We spent a lot of time making sure the Fig can be driven from the keyboard. You can launch apps, search your shortcuts and toggle focus between the terminal and Fig all without touching the mouse. Our global hot key is CMD+I. Each Fig app also has its own shortcuts. A few of the conventions we are trying to enforce across all of them are J and K for moving between inputs (tab also works) and the keyboard mnemonics you mentioned.
  - masukomi 6y ago
    I think i would make this way more obvious on the front page. I use the terminal in no small part so that i _don't_ have to reach for the mouse. What I saw in the animation made me think "OMG YOU'RE MISSING THE WHOLE POINT!!!" BUT if these visual additions didn't require me to reach for the mouse, _and_ were design with keyboard interaction as a primary input not an "well yeah you can also...." then yeah, count me as intrigued. Would love to play with it. related note: the signup form doesn't work when you hit enter (single input forms usually do) and when you tab to highlight the submit button the halo is almost imperceptibly small.

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!

wayneftw 6y ago

Nice work! Can you operate the GUI entirely with the keyboard? If not, I think it would be great if you could do things like: - Use Ctrl+Tab to switch tabs. - Use Tab to cycle focus over inputs. - Use Keyboard Mnemonics (underlined letters) to focus on specific inputs. If Fig can already do these things, I would update your demo video to show that because switching between CLI and GUI is very easy when you don't have to constantly pick up the mouse. (Oh, didn't notice this was Mac only. Ewww. (Sorry.) I hate macOS precisely because operating it's GUI with a keyboard is the most painful experience of any OS.)

mschrage 6y ago
This is a great question. We spent a lot of time making sure the Fig can be driven from the keyboard. You can launch apps, search your shortcuts and toggle focus between the terminal and Fig all without touching the mouse. Our global hot key is CMD+I. Each Fig app also has its own shortcuts. A few of the conventions we are trying to enforce across all of them are J and K for moving between inputs (tab also works) and the keyboard mnemonics you mentioned.
- masukomi 6y ago
  I think i would make this way more obvious on the front page. I use the terminal in no small part so that i _don't_ have to reach for the mouse. What I saw in the animation made me think "OMG YOU'RE MISSING THE WHOLE POINT!!!" BUT if these visual additions didn't require me to reach for the mouse, _and_ were design with keyboard interaction as a primary input not an "well yeah you can also...." then yeah, count me as intrigued. Would love to play with it. related note: the signup form doesn't work when you hit enter (single input forms usually do) and when you tab to highlight the submit button the halo is almost imperceptibly small.