[HN Gopher] WebTUI - A CSS Library That Brings the Beauty of Ter...
___________________________________________________________________
WebTUI - A CSS Library That Brings the Beauty of Terminal UIs to
the Browser
Author : IroncladDev
Score : 293 points
Date : 2025-04-12 22:02 UTC (1 days ago)
(HTM) web link (webtui.ironclad.sh)
(TXT) w3m dump (webtui.ironclad.sh)
| jasonjmcghee wrote:
| I'm not seeing any icons (on ios, tried a few browsers). Is the
| font (or svgs? Not at a computer to check how it's built) being
| served?
| mcint wrote:
| Hi again. I have the same issue in my browser, and locally in
| nvim.
|
| NerdFonts (and the right terminal emulator) were needed, and
| enough, there. Playing with AstroNvim, and blocked by use of
| yakuake.
|
| Hoping that I can hot load something from
| https://www.nerdfonts.com/font-downloads, I'm not sure what
| from https://fonts.google.com/ has the needed ligatures or
| symbols.
| kombine wrote:
| not seeing icons on Firefox (Linux) either. I do have NerdFonts
| installed, but I guess that shouldn't be needed for a website.
| djaychela wrote:
| I'm also not seeing any icons (macOS, running Firefox). Tried
| it in safari and just get blank rectangles instead of the
| rectangles with a small hexcode(?) in FF.
| nonrecursive wrote:
| This looks amazing! Good job. I don't know that I'd ever use it
| because there's never enough time for all the things, but thanks
| for the few minutes of aesthetic satisfaction that brought.
| Lord_Zero wrote:
| Icons not loading for me.
| bbor wrote:
| Execution is incredible, and the idea is far from bad, but I must
| I say that it is certainly _hilarious_. Giving serious "we've
| figured out a way to more durably connect microservices!" energy.
|
| Ngl, I see a non-zero chance of this kind of aesthetic catching
| on for nerdy blogs, which tends to proliferate to the wider web
| eventually. If nothing else, I love some support for those of us
| who spend all day reading (stylized) Markdown syntax!
| williamguerra wrote:
| I dig this stuff
|
| for more, I liked The Monospace Web:
| https://news.ycombinator.com/item?id=41370020
|
| and some other good examples in the comments
| runlaszlorun wrote:
| OMG that's awesome. I've been meaning to goof around with TUI CSS
| [1] but this looks amazing. Props to the author.
|
| Maybe it's because I cut my teeth on 80s Turbo Pascal but there's
| something about the TUI that I feel hits an optimum in the
| simplicity vs use of visual space spectrum so, so lost in a world
| of Vulkan etc.
|
| [1] https://github.com/vinibiavatti1/TuiCss
| pjmlp wrote:
| It is lost because we aren't producing executable files with
| multiple segments, jungling near and far pointers, trying to
| fit everything into 640 KB, while writing directly into the
| video memory.
|
| Turbo Vision was great and one of the frameworks I am most
| found of, back in 1990.
| waldrews wrote:
| Looks great. We should've stuck with BBS's and Gopher all along.
| Minor issue, scroll bars are showing and getting slight scrolling
| when using arrow keys.
| matt3210 wrote:
| Peak design!
| nickandbro wrote:
| This is the UI I would have used for my hobby project, vimgolf.ai
| if I knew about it sooner! Though for certain sections of the
| site, I might just be able to use it. Great work!
| godelski wrote:
| Why does this ask for a login when I click on "motions". Sorry
| but insta pass for me
| nickandbro wrote:
| Because I have to spin up a neovim instance for every user on
| the backend, I only allow authenticated users to gate the
| amount of users at this time. I am going to adjust the site
| more to reflect that as it's more of interactive experience
| rather that a vim tips site.
| meta-level wrote:
| For python there is also https://github.com/Textualize/textual-
| web, based on the rich/textual framework
| nurettin wrote:
| > This will generate another URL, which will present you with
| your terminal in your browser
|
| > Don't share this with anyone you wouldn't trust
|
| This is on another level. They built a terminal sharing
| application that connects to their servers. One must truly like
| to live on the edge to try this at home.
| kombine wrote:
| I am working on a pitch for an AI startup and need to create a
| nice looking webpage with the demo. I have very little experience
| with webdev and I wonder if it is a good idea to build a TUI-like
| interface, as I am a fan of terminal aesthetics in general. This
| would much relieve the burden of thinking about design and focus
| on the content.
| godelski wrote:
| > I am a fan of terminal aesthetics in general
|
| The superpowers from the terminal do not come from aesthetics.
| They come from the way a language was developed (see my long
| comment). It is what reduces the burden of thinking and allows
| for the elegant and seamless movement through the space. It is
| not about memorizing individual keys, it is about learning a
| language. That's the power. I want to see more of this, but
| people miss what was created.
| mcintyre1994 wrote:
| Honestly I wouldn't personally, I'd use a really good
| components library like https://mantine.dev/ (no affiliation,
| just a fan) and make your site look similar to your
| competitors. That's what people seeing your pitch will expect
| IMO. Depending who you're pitching to they might not use a
| terminal very often.
| godelski wrote:
| I'm terminally terminal, but I'll be honest, I'm a bit confused
| by this. If it is trying to be what I think it is, I * _really*_
| want this. But to be a bit blunt, it also feels a bit cargo-
| culty. To look like the thing but not be like the thing. I 'm not
| saying this to discourage you, because if you are trying to make
| a web interface that I can fully use via keybindings then please
| for the love of god keep developing, I want it more than
| anything.
|
| But the reason it feels so off, or uncanny valley, to me is it
| _looks_ like what someone thinks a vim interface is, but doesn 't
| feel that way. No buttons work for me other than "/", but that is
| a pretty common binding on websites anyways. going to the
| examples page, things feel more weird. I can do {c,d,l,n} to
| change my theme and {1..5} to access options, but other than
| that, nothing works. I see <C-i> for inbox but what does this
| mean? Control + i? (the usual meaning) That doesn't work. Is it
| command + i? That doesn't work. The annotation is reminiscent of
| vim and the landing page looks like vim, so am I in command mode?
| But then why are there no motions? Is this emacs? Oh, I do search
| and can go to the style-guides page and h,j,k,l motions work. Oh,
| l takes me to the right pane? Why is H,M,L missing?
|
| To be fair, a lot of TUIs have these same uncanny feelings, but I
| want to draw your attention to this as it appears people like me
| are your target audience and I do want this product, so I really
| do want you to understand what I need and how my space works.
| There is a lot of method to the madness with vim. A lot of people
| make the mistake of trying to memorize commands instead of
| memorizing patterns. There's too much in vim to memorize all
| individual commands, but if you approach it in the way of there
| are motion keys and action keys then honestly, you can be highly
| functional in vim in an after noon! (vimtutor does communicate
| this btw) So the things like how the theme switching and
| application switching feel very non-intuitive to me. I have to
| learn something new but it throws me off because visually it
| looks like I should be doing another set of patterns. For the
| theme switching I would expect to do something like `:colorscheme
| dark` or have some action associated with this (idk, c would be
| find since you aren't going to be cutting text?) and then an
| associated motion. The application switching I would want to move
| like I do with buffers. gt and gT to cycle through, 1gt to go to
| the email (first), 5gt to all components (5th).
|
| So I love the idea and really, I do want this thing to exist. But
| at the same time it feels like bizarro land to me. Many TUIs make
| these same mistakes and it leaves me with the same feelings. What
| I really want is for the wheel to not be reinvented. In a typical
| webpage I can surprisingly use a lot of keyboard commands and
| even use some motions. But what things like vim are very useful
| for is the movement. It is not a text writer, it is a text
| editor. So it is important that I be able to have fine control
| and be able to _move_ through a document (page) quickly. It is
| important that there is this synergy of combinations of motions
| and commands (or some other philosophy!) that I can learn the
| basic rules from and then extrapolate from there. This is the
| thing that gives me superpowers in the terminal, and this is the
| exact reason I so desperately want something like this around the
| web. But I also understand why this is difficult and often
| missed. After all, most vim users I know never learn the vim
| meta. But I really want to speak up, not to talk you down but
| because I really want to see something like this succeed and I
| want you to understand where these "super powers" come from.
| It's non-obvious unless you get deep into it, but there is a
| connecting philosophy that allows people to know how to do
| something new without having ever been told. You get to a point
| in vim where it is speaking a language and that is the end goal.
| Do not design one offs and just maps to useful motions, a good
| interface has to be a language because the goal is to communicate
| with the machine.
|
| I hope this makes sense. I really do want to see this thing
| become a reality. To bridge this gap between our worlds.
| osel wrote:
| Do you know of any good resources that discuss TUI user
| interaction/research?
|
| I'm working on a new project to build some simple workflow
| applications for business, and one of the aspects I would like
| to attempt to resolve is the speed of input. It is painful
| watching operators work with modern GUI inputs, particularly
| web based as the mouse work slows them down horrendously. And
| keyboard 'shortcuts' where they exist are often anything but,
| as the entire GUI model assumes a mouse (or on the web a
| Document) first.
|
| It is like you mention about this CSS library, it kind of
| misses the point in that the awesomeness of TUI is not in the
| appearance, but rather how workflows that the constraints of a
| keyboard-first interface enforce allow creative and highly
| efficient solutions.
|
| When all you have is a mouse everything becomes a click, and
| that is a horrible way to input data.
| godelski wrote:
| I don't, but I hope someone else does. I can speak the
| language but I doubt I could teach it.
|
| People see the aesthetics and appreciate the beauty but the
| best way I can describe the problem is it's like trying to
| write poetry in a language you do not understand. You can get
| the rhythm and tone but it has no substance. The aesthetics
| are driven from the language, the way we play, the way we
| speak. There's something natural to this but only when you're
| fluent. The art is a reflection of us. It looks like
| something you pull from outside, a craft to hone, a monument
| to build; but it will always miss because it is an
| expression, a feeling, it comes from you.
|
| I don't know how to describe it like a linguist would
| describe a poem. There's depth they see that I don't. I only
| know the feel, the way Sylvia Plath can make me feel but Su
| Shi never will. I can appreciate it from afar but it remains
| foreign. I do not know the language, the culture, the
| context, so I can only be a stranger as if looking through
| glass.
|
| But I do know this. We programmers often fail to see when
| building and designing things. The Zen of it is to use your
| things the same way you use the grass under your feet or the
| air you breathe. It feels weird to call the ground a tool but
| you use it to move. I certainly do not have the right words
| but I hope the meaning is clear. The point is to build
| something that feels as natural as the air you breathe. A
| space to live in and makes you feel free. It's okay if this
| has to be learned but there's something more I don't know how
| to describe. It's like saying it's okay to learn a new
| language but recognizing that the concept of language itself
| is natural and part of us. Even without a language we still
| speak, there is a drive to make sound, to communicate, to
| express. It makes language inevitable yet as difficult to
| describe in detail as the beating of your own heart. It's
| just you
| tgv wrote:
| But an editor is something where you navigate for a long
| time, whereas the average web page navigation is brief. In
| 99.99% of the cases, it doesn't make sense to attach a
| (complex) keyboard interface to it, and a specifically vim-
| like interface even less.
|
| > When all you have is a mouse everything becomes a click,
| and that is a horrible way to input data.
|
| Quite a few people access web pages via a table or phone.
| Touch is often easier than a mouse (not always, though), and
| can also outdo a keyboard.
|
| I think web-based TUI is a very small niche. Large-scale data
| entry might be about the only place where it could work, but
| then you'd want a highly tailored, ergonomic, user-friendly
| interface.
| terminaltrove wrote:
| This looks awesome and we're fans of the TUI aesthetic at
| terminal trove (1) (we're biased), it's also great that WebTUI
| has keyboard shortcuts to go with it.
|
| Not CSS but similarly ratzilla (2) also comes to mind, that
| allows you to build terminal-themed web applications with Rust
| and WebAssembly.
|
| Check out the examples (3) they look great!
|
| (1) https://terminaltrove.com/
|
| (2) https://github.com/orhun/ratzilla
|
| (3) https://github.com/orhun/ratzilla?tab=readme-ov-
| file#example...
| WD-42 wrote:
| This site is amazing!
| rollcat wrote:
| I don't understand the obsession with 1980s terminals. They're
| even less powerful than the contemporary 8-bit home computers.
| It's perfectly OK to be a retro enthusiast, it's another thing to
| claim that this is the peak tech to power our modern CLIs, or a
| solid foundation for portable UIs.
|
| From the docs: Stop thinking in standard CSS
| units like px, em, rem, % Start thinking in Character
| Cells for spacing, sizing, and positioning
|
| A VT102 already has a character grid, but it needs a serial
| protocol to allow applications on the mainframe to talk to it.
| You can loop around this and use the raw mode to address
| individual cells.
|
| The web browser has an insanely powerful typographic and layout
| engine. Now we're looping back into character cells. Something
| went wrong here, at least once.
|
| That said, I like the aesthetic and the default color palette.
| It's quirky, but it has its places.
| onehair wrote:
| I think they're just being funny, and if asked seriously
| they'll tell you that those words are only meant to hype up the
| project and not neat seriously (cells vs ems, %, px)
| pdntspa wrote:
| And can we stop calling every stupid little hobby project
| "beautiful" while we're at it? The word has no meaning any
| more.
| big_paps wrote:
| I find the usage of ,,i love x" for x representing something
| inanimate you surely do not love far more unsettling..
| tgv wrote:
| This is getting quite off-topic, but I do love music. At
| least, that's how I would describe it. I just heard a
| fragment of something truly beautiful, and the my emotional
| attachment to that music is quite real (in this case, the
| Largo of Bach's concerto for two violins, BWV 1043;
| although I know someone who dismissed it as long-winding).
|
| But words tend to get nerfed, and clickbait culture
| certainly doesn't help. "Slams" in a headline has been
| reduced to "made a somewhat negative remark about," and
| "genius" now means "it took more than 2 seconds of
| thinking." Let's not discuss what "beyond excited" has
| become. I too would like word meanings not to shift too
| fast, as it helps preserve culture, especially literature,
| but the forces are too strong and diffuse to oppose.
|
| So "I love this web font" now just means "Don't think, just
| click on this link."
| rollcat wrote:
| I would love to help bring elegance and beauty to the
| software we build, both on the inside and outside - and
| that's my main motivation behind criticising terminals
| and TUIs specifically.
|
| I have vague ideas for how I could build something
| ergonomic, easy, and pleasant to use, but I lack
| experience in this area, and the focus/energy to
| experiment.
|
| I'm hoping to bring this subject to the light, and have a
| constructive discussion. If not me, then perhaps someone
| else will get inspired.
| tgv wrote:
| IMO, you need to be a domain expert in order to produce
| something ergonomic, easy to use. You (or the team you're
| part of) have to understand the topic and users extremely
| well. There's no catch-all design, not even a process
| that covers more than the most mundane cases.
|
| But inspiration is a fickle thing. If you're going to
| build something, you might as well be inspired by
| terminal-style interaction, but it can't be the goal.
| nkrisc wrote:
| What's interesting is nearly all words in language are on an
| irreversible trajectory towards abstract meaninglessness.
| Take your own use of the word "project" for example. Long
| ago, it meant "to throw or thrust" an object. Of course,
| today its meaning has expanded so far beyond that original
| meaning. That is what is happening to the word "beautiful",
| but the only difference is that it's happening during your
| lifetime, instead of long before it. You probably didn't even
| think about your "misuse" of the word "project" because the
| truth is it no longer means what it used to mean.
|
| Perhaps 500 years from now "beautiful" (or whatever it has
| morphed into) will simply have a meaning similar to
| "pleasant".
| godelski wrote:
| The obsession is because it is still the best. For all its
| faults, I'm still terminally terminal. The beauty of it is in
| the utility and how it becomes so natural. It's a language you
| learn that gives you so much freedom you cannot find anywhere
| else. I've tried many IDEs but I'll always come back to vim. It
| might have taken time to learn but this is true for anything
| else. I didn't learn a tool, I learned a language. I didn't
| learn to run, I learned how to move my legs. With that I could
| teach myself, I can walk, I can run, I can jump, I can dance, I
| can be anything I want to be. In VSCode I can walk, hell I
| might even be able to run, but there is no dance, there is no
| "me".
|
| That's the beauty of the terminal. It's not a one size tool for
| all. There is no product that can be made for everyone. Instead
| it's an environment for you to craft and live in. Everyone's
| dotfiles are as unique as they themselves are. That's the
| point. Because when you can't build something for everybody you
| give them the means to craft their own worlds. The computer
| didn't become so great because the chips, it was the ability to
| write software and build the things you need. The smartphone
| didn't take off because it had a big screen, it did because the
| app. Because you could create. Because your phone is yours and
| no other phone is like it.
|
| But I haven't found a browser that lets me be me. That let's me
| dance around the web and jump and be free. And I fear we lost
| sight of this thing as it became so natural, that the phone and
| computer are turning into things that be instead of a
| reflection of me
| wiseowise wrote:
| GP talks about how you develop those TUIs, not TUIs
| themselves.
|
| Web model is objectively better than
|
| ''' Stop thinking in standard CSS units like px, em, rem, %
| Start thinking in Character Cells for spacing, sizing, and
| positioning '''
| freehorse wrote:
| It is a different design decision. You do not have to
| choose all capabilities of modern browsers when you do sth.
|
| Of course nobody would expect this to take off largely. But
| aesthetically speaking, I see nothing wrong in the design
| per se. It is clean, consistent, light and minimalist-like.
| Terminals just provide a minimalist style that is tested
| and also familiar to some. It is very easy to get around
| the website. Pages load fast.
|
| The main drawback I see is lack of multimedia support,
| obviously (even if supported they would be a bit out of
| style). But that's not a problem if you do not care about
| that. And that it is hard to place ads.
|
| Sure, "Web model is objectively better" but also depends
| what one considers as "web model" because a lot of modern
| web is just a bloated mess, which I find more annoying than
| a project like this.
| rollcat wrote:
| > Web model is objectively better than [...]
|
| Hard disagree. Modern web browsers are incredibly complex
| beasts that evolved by amalgamating decades of
| experimentation, poor non-standards, and elaborate counter-
| measures to fix that mess. I recommend reading
| <https://browser.engineering>, or even just building
| Chromium from source, to gain some appreciation. Most
| applications would benefit from something much simpler. But
| it's often practical to use as it is, pretty much exactly
| like terminal emulators.
|
| The main difference being, terminal emulators are still
| several orders of magnitude less complex than web browsers,
| but in spite of that still require a lot of complexity to
| undo the side-effects of having a serial line between the
| CPU and the character grid. If you like monospaced fonts
| and character grids, you can probably render that with
| plain SDL, bitmap fonts with indexed sprite sheets (no
| Freetype), and in return get non-broken copy & paste, or
| even a dock icon. You know, the MVP of GUI.
|
| Try <https://lite-xl.com>, it builds its GUI straight on
| top of SDL.
| troupo wrote:
| > If you like monospaced fonts and character grids, you
| can probably render that with plain SDL
|
| You don't even need SDL
| https://github.com/cmuratori/refterm
| rollcat wrote:
| Interesting project, but you still need to hook it up to
| a backend to create a window to draw pixels on. SDL is
| likely the most portable library to do that; you could
| substitute fbdev, DirectX, wgpu, glfw, win32, metal, and
| so on.
|
| The point is, once you have a window and a putpixel (or
| even better, surfaces and blitting), the rest is easy to
| handcraft. A standardised library would of course help.
| rollcat wrote:
| > I've tried many IDEs but I'll always come back to vim.
|
| Vim and Emacs both have GUIs. As an Emacs user, I
| subjectively find the GUI superior - I can e.g. rebind Cmd-S
| to "save", and that's a reason enough.
|
| > It's a language you learn [...]
|
| You mean the serial lines and ANSI escape codes and termcap?
| I would say it's more like pidgin with a dozen obscure
| dialects, and a body language on top. Try writing a portable
| TUI application from scratch, without touching curses or
| termbox. <https://viewsourcecode.org/snaptoken/kilo/>
|
| Or do you mean, how to drive a TUI application from the
| keyboard? Here's the painful truth: you can't quit a TUI
| application without learning it. In vi, it's "Esc-q!-Enter",
| in Emacs it's "C-x C-c", in screen it's "C-a C-\", in tmux
| it's "C-a C-d", and so on. Maybe pressing "q" or F10 or C-d
| will work, but good luck guessing. This is just to quit, and
| ironically - it's only the start.
|
| By contrast, on macOS it's Cmd-Q; on Windows, it's Alt-F4;
| and so on. Innovation happens on stable foundations, not by
| pulling rugs.
|
| > It's not a one size tool for all. There is no product that
| can be made for everyone. [...] Everyone's dotfiles are as
| unique as they themselves are.
|
| You know non-TUI applications are also customisable? I have
| Hammerspoon scripts, a dozen custom keybindings in macOS,
| .xsession+.Xdefaults+.Xresources, .gitconfig (I use git via
| Emacs+Magit), various .config/*'s (for e.g. sway), .emacs
| (bankrupted several times), and so on - none of these are TUI
| applications.
|
| Or do you mean the command line? I believe we can build a
| better REPL than a terminal emulator. Emacs is a decent PoC,
| you can also have a look at Swift Playgrounds. Maybe we can
| build a generic non-terminal REPL where Ctrl-C means "copy",
| and Ctrl-V means "paste", that would be a great start.
|
| Don't get me wrong, I'm happy if you're happy, I just don't
| understand the collective obsession. These tools exist, which
| is great, but we deserve better.
| dullcrisp wrote:
| Hmm I just use :w<cr> to save in my graphical editors too.
| It's easier to type.
| __float wrote:
| No, it's objectively more difficult to type [on a qwerty
| keyboard].
|
| cmd-s is a single keypress and can be done with a single
| hand.
|
| shift-; w cr is two more _and_ involves a back and forth
| over the entire keyboard.
| dullcrisp wrote:
| I use two hands to type, but if I only had use of one I'd
| probably use a different key sequence, or more likely a
| different input method.
| godelski wrote:
| To support this claim I'd like to give a common example
| in vim. Everyone hates `esc`, right? Well I use `<C-[>`
| instead. Yeah, that's control plus left bracket. 2 keys!
| But this is a hell of a lot easier that lifting my hand
| from the keyboard to reach to the top left corner. I just
| drop my left pinky slightly and move my right ring finger
| slightly. Both actions are quite normal in how I just
| type and my wrists never lift. Using two hands is what
| makes it easy. I neither type with a single finger, I use
| every one of them. :w<CR> is not hard because :w might as
| well be one key (plus I'm always hitting : so the action
| "burns in" as any constant motion does), w is just a
| normal key requiring very little movement from my rest
| state, same as pressing enter (pinky).
|
| I'll give the parent that this is _slightly_ harder than
| <C-s> but they got the right conclusion for the wrong
| reasons. But if that trivial extra effort is what's
| required for what I can do in vim, I'll gladly make that
| trade. I love my panes, buffers, windows, completion (see
| :h ins-completion), my visual mode, my search, my replace
| (way more powerful than many think), my tags that allow
| me to walk through the program, and how I can
| effortlessly move my cursor around the screen and around
| the document. It takes _far_ less effort to move my
| cursor to where I want than it is to lift my hand and
| grab the mouse. I love that I can open all files in my
| project while my computer doesn 't even blink, and I can
| do some refactors of all my code with a single line. No
| IDE has ever come close to giving me these abilities and
| I haven't even mentioned the half of it.
| wruza wrote:
| Good thing you can bind arbitrarily complex action to a
| key/combination in a programmable editor and avoid this
| semantic fuss whatsoever.
| EasyMark wrote:
| right but easy doesn't always mean fewest key strokes, it
| can simply mean "I have muscle memory for exiting this
| editor that I use 43% of my working hours with so Imma
| map it to exiting my browser and ________ app as well." .
| I personally have to move between too many systems for
| something like that to be useful to me but if you stay on
| a single machine most of your work day I can see the
| value.
| godelski wrote:
| > I can e.g. rebind Cmd-S to "save", and that's a reason
| enough.
|
| I'm no emacs user but I'm pretty confident you don't need a
| GUI for that. I can certainly do that in vim in the
| terminal. :nmap <C-s> :w<CR> >
| In vi, it's "Esc-q!-Enter"
|
| That's not accurate. In vi it is :q<cr> (: then q then
| enter). The escape (or <c-[) is only necessary if you're in
| write mode. "!" Is only necessary if you've modified the
| document and want to force quit.
|
| Do you also get pissed off when you modify a word document,
| click quit, and it asks you if you're sure and like to quit
| without saving? It's literally the same thing.
|
| Idk I just don't see the problems you are talking about.
| They aren't things I face. On my Mac I can still use native
| cmd+{c,v} and on anything else I'm not upset by adding a
| shift. Though most of the time I'm yanking and pasting
| because I can "vim" in bash, zsh, hell I can even do it in
| ipython! In tmux and screen I just type exit or <c-d> to
| kill a pane. You say it's just the beginning and I agree,
| but I think you missed that in tools like vim the language
| is the motion and actions. It's why I can discover "new
| commands" but it's like discovering you can jump over a box
| when you already know how to jump. If you're just trying to
| memorize commands and combinations you are doing it wrong.
| I'm sorry whoever taught you failed you, and I'm sorry
| there's so much noise.
|
| But if we want to be pedantic then you're going to have to
| admit that cmd+q and <c-q> don't always quit. Many times
| they just close the window. Sure, alt+F4 is different, but
| that's a force kill list like typing "pkill <program name>"
| or simply <c-c> (which came first? <c-c> or <c-q>?)
|
| It's not like I don't use a GUI at all. But yeah, it's nice
| to not lift my hand from the keyboard. Don't get me wrong,
| I'm happy if you're happy, I believe the best tool for you
| is the best tool _for you_. But if you want to understand
| why I 'm obsessed, you have to try to see what I see, from
| my eyes and not yours. It's hard over text like this,
| that's fair.
|
| And you're right! We do deserve better! If you ask me, my
| number one annoyance is when the computer won't let me do
| things. I'm very frustrated with both windows and Mac since
| they put up so many walls that make it difficult for me to
| shape my machine the way I want. Sure, this is hard in
| Linux but there's no locked doors in which I need to find a
| key (other than sudo) or a back door. I edit my dotfiles to
| make these things a part me, why would we not want to carry
| on that idea?
| sva_ wrote:
| > By contrast, on macOS it's Cmd-Q; on Windows, it's
| Alt-F4; and so on. Innovation happens on stable
| foundations, not by pulling rugs.
|
| That's the window manager of the respective systems though.
| On i3, I can also kill any window by pressing Option-
| Shift-q. But that's more like the sledgehammer approach and
| not how I'd close a text editor on any system ...
| freddie_mercury wrote:
| If it is still the best, what's the superior terminal
| equivalent for Photoshop, Premiere, Audacity, and Figma?
|
| Not everyone's work life revolves around text just because
| yours does.
| tomxor wrote:
| > Not everyone's work life revolves around GUIs just
| because yours does.
|
| FTFY
|
| They both have their place, pros and cons, that fit
| different purposes differently. The mistake is in trying to
| assign superlatives.
|
| Two things can be true at the same time, TUIs are superior
| to GUIs, and GUIs are superior to TUIs, but in different
| contexts.
| rollcat wrote:
| > Two things can be true at the same time, TUIs are
| superior to GUIs, and GUIs are superior to TUIs.
|
| TUIs _are_ GUIs - in a trench coat. A TUI program must
| still process input events, draw widgets, manage state &
| focus, etc - all the things a GUI must do. What OTOH it
| _can 't_ do, is even the most basic stuff, like system
| clipboard or displaying pictures. You have to use side
| channels to get that, and once you do, you throw away the
| TUI's one single advantage - SSH.
| bhaak wrote:
| But the original terminal was also already using a side
| channel. You used them to connect to a remote piece of
| hardware and weren't running anything locally. In that
| sense ssh itself is also a side channel.
|
| I also don't know why you consider manipulating the
| system clipboard a side channel. The terminal emulator
| provides a way of manipulating the clipboard but that is
| just convenience.
|
| Any program can access the clipboard and a TUI program
| can do this as well. I have a grepalike that inserts a
| search match into the clipboard for convience. Somewhat
| ironically most of the time that match gets pasted back
| into the terminal.
|
| I would actually like to have a network wide clipboard
| system. There are solution for that but I haven't yet
| found any that isn't too unwieldy.
| rollcat wrote:
| > But the original terminal was also already using a side
| channel.
|
| What? The serial link was the only way for the terminal
| to talk to the Big Machine. There never was a "side
| channel", in fact things like control flow are mixed in-
| band; that's why some programs get confused about C-s and
| C-q.
|
| > The terminal emulator provides a way of manipulating
| the clipboard but that is just convenience.
|
| That's different from the TUI application accessing the
| system clipboard. You need to use pbcopy or xclip, that's
| non-portable, won't work over SSH, relies on those
| external tools being installed, etc.
|
| > I would actually like to have a network wide clipboard
| system. There are solution for that but I haven't yet
| found any that isn't too unwieldy.
|
| Try any two Apple devices signed in to the same iCloud
| account. It works OOB, zero setup, 100% reliable. It's
| called Continuity: <https://support.apple.com/en-
| us/108046>
|
| Yeah, proprietary, non-portable, etc. Choose your trade-
| offs.
| godelski wrote:
| My terminal can display pictures and use the clipboard.
| Most of them can in fact. You might be limited in
| pictures on some but neither do we live in the 90's
| anymore. I routinely login to remote machines and view
| the pictures I have stored on them through my terminal
| rollcat wrote:
| > My terminal can [...] use the clipboard.
|
| Yes, but the TUI application running in it can't - unless
| using non-portable side channels such as pbcopy or xclip.
| Copying text is limited to what's visible on your screen
| (and have fun if it's drawn inside a widget). When
| pasting, you're dumping the text as if it was typed in.
| Also, have fun with Ctrl-C / Ctrl-V.
|
| > You might be limited in pictures [...]
|
| That's right, sixels are indeed 1980s technology, seems
| like VT200 can do that.
|
| But you know what I mean. It can't do audio, video, HDR
| pictures, precise mouse motion, accessibility, or even
| recognise shift+alt (ran out of bits in ASCII). It's a
| serial link, and using a side channel is just cheating.
| godelski wrote:
| I think you know your point is obtuse. Context matters in a
| conversation. You got me! Everyone is going you agree with
| you, including me. But only got me by moving the
| conversation to somewhere no one was considering and could
| be well agreed upon that it was out of scope. It's correct,
| there's no one size fits all.
|
| But I'll also say, in all these applications having good
| key bindings is still a massive help. Those really good at
| these programs aren't clicking dropdown menus constantly
| but are issuing keystrokes in combination with the need for
| their mouse. In a way, that's not too different even if in
| another way it is
| sgarland wrote:
| What a lovely sentiment. Fully agree; staying in the terminal
| for as much as possible makes for far less friction when
| context-switching.
| jampekka wrote:
| Text-based interfaces can be done with techniques other
| than simulating a very restricted device from 1978.
| godelski wrote:
| If your terminal is from the 70's you really should get
| with the times. Check out ghostty or something because
| things are very different these days
| geocar wrote:
| > Something went wrong here, at least once
|
| The higher-level view of data-over-time is inherently serial,
| and I don't think there's anything anyone can do about it:
| Serial is the correct/best abstraction.
|
| That being said, I acknowledge the problem you're referring to,
| because serial _what_ exactly? Every time we complete the
| circle, it gets a little smaller, and our collective knowledge
| of what is _actually_ going on improves.
|
| It should make a certain amount of sense if you look at it this
| way: Use a serial decoder to fill a memory bank of character
| cells or pixels or whatever, and share that memory bank with a
| video encoder, and the software guys say: well, how about I
| just fill up that memory bank directly. Then, you don't want
| character cells but triangles, and you find you're just DMA'ing
| in that shared buffer and working around the timing of another
| process reading it and your ring-based memory buffer has turned
| back into a serial protocol before you know it.
|
| I think the main problem is that programming languages are
| _terrible_ at serial, so programmers keep trying to work around
| it, and then convert to /from serial at the edges.
|
| > it's another thing to claim that this is the peak tech to
| power our modern CLIs, or a solid foundation for portable UIs.
|
| I can't explain all of it, but terminal UI _remain_ without
| match: Even today (2025) I use a terminal because there 's no
| better human-computer interface for doing intellectual work.
|
| A _picture_ of a terminal, is not a terminal, so I understand
| why stuff like this confuses.
| pjmlp wrote:
| Yes there is, it is called a REPL, Xerox PARC has plenty of
| examples across all their workstation variants, followed by
| Oberon, and some of that work even inspired Plan 9 and
| Inferno UI and related developers editor, ACME.
| geocar wrote:
| I don't understand exactly what you are trying to say.
|
| I think a REPL is the real-eval-print-loop used by lisp
| systems to talk to a terminal, or something that
| looks/works like that (but maybe doesn't use lisp). These
| days I think lots of things have REPLs. Even Python. The
| only ones to survive 40 years though, have been serial
| ones, and I don't think that's an accident.
|
| That command box/area that the user uses and re-uses in
| Oberon and Acme is something else and specifically worse
| than a REPL because you can't script it: There's no GNU
| expect for rio, and no DESQview-learn for Oberon and their
| command language just isn't good enough. This interface has
| not proven particularly efficient for users either, but
| terminals are still around.
|
| Emacs is what I'd consider "peak terminal", and it has a
| REPL and an excellent command language. You can also script
| Emacs with emacs, by literally running emacs in an emacs
| terminal.
| pjmlp wrote:
| That is a a barebones REPL from early 1960's, not the
| experience I was mentioning.
|
| Imagine Emacs mixed with Jupiter netbooks, for the whole
| OS stack.
| geocar wrote:
| > Imagine Emacs mixed with Jupiter netbooks, for the
| whole OS stack.
|
| Sounds dreadful.
|
| > That is a a barebones REPL from early 1960's, not the
| experience I was mentioning.
|
| No, that is a definite article. I was talking about three
| things, two of which are things you brought up in an
| effort to find common ground. If you don't know Oberon or
| Acme then there's no point in talking to you about them.
| I still don't know what you're trying to tell me, and I'm
| beginning to think you don't either.
| rollcat wrote:
| > Sounds dreadful.
|
| Depends. Emacs has had brilliant ideas, did brave things,
| it just remained stagnant for the past 30 years. (Unlike
| terminal emulators, which do boring things, and have been
| stagnant for 40 years.)
|
| A slightly better REPL doesn't have to be brave. It just
| needs a sensible text editing widget, that's already a
| tenfold improvement. The cognitive load between Ctrl-C
| and Ctrl-Shift-C drives me crazy.
| troupo wrote:
| The obsession is with information-dense quick-to-use low-
| latency interfaces that are nearly impossible to replicate with
| most modern tools [1]
|
| Whether libraries like this one manage to replicate the
| experience is a whole other question.
|
| [1] Just look at what modern tools FilePilot and RAD Debugger
| can do with their UIs and compare that to nearly every single
| one of modern apps.
| pjmlp wrote:
| Me neither, Turbo Vision was cool, Clipper kind of ok for data
| entry applications, and curses, well it was the way of UNIXes
| before X Windows became affordable.
|
| Apparently that is some kind of retrocomputing movement.
|
| The strange part is that most folks pushing for TUIs weren't
| even born and don't get the pain we went through.
|
| We used TUIs because that is all we could afford, not because
| we were given an option.
| hdjjhhvvhga wrote:
| It's all true but they have one advantage over everything from
| the last two decades or so: latency. Obviously it's double lost
| if you try to reconstruct just the aesthetics.
| sgt wrote:
| Occasionally when you see someone using a point of sale
| terminal that is terminal based, the operator usually flies
| through the interface like it's nothing.
|
| So there's something to be said about those types of interfaces
| - it may look simple and be text based, but it's the most user
| friendly for the qualified operator to get things done.
| pjmlp wrote:
| I see the same on any graphical one on the supermarkets and
| restaurants.
|
| Maybe it is a matter to actually design for the customers use
| case.
| __float wrote:
| Modern GUI apps tend not to design for the keyboard-
| wielding power user.
|
| TUIs can have just as many quirks and bugs, but on the
| whole they tend to be a little simpler, and the author
| usually is an end-user :-)
| pjmlp wrote:
| Someone is responsible for developing them.
| rollcat wrote:
| Exactly. POS terminals are optimised for throughput.
| Otherwise it's literally less sales, your bottom line.
|
| You can build a perfectly snappy, keyboard-driven GUI
| application; a terminal emulator is (ironically) the
| perfect example.
| graypegg wrote:
| Another example of this sort of interface is office phones.
| When someone knows their phone well, they can speed through a
| hold, page to another desk, then transer to them, without
| even looking at the keypad.
|
| I have a feeling that sort of "trainable speed" is a feature
| of interfaces that treat the thing they manage like a
| physicial "thing" you're rolling thru a process. (instead of
| a feature of textmode interfaces) Rather than having to get
| to a menu for outside lines in some abstract window, there's
| just actual physicial buttons to mash. You get this feeling
| that you're juggling a call between your fingers because
| every press you do is doing a "thing", not just opening a
| menu. There's real physicality to that process that my monkey
| brain can learn no problem.
|
| I don't have any experience operating a terminal based PoS,
| but from what I know, they tend to also have the same sort of
| "juggling" actions, like SALE, DISCOUNT, VOID etc. I have to
| imagine using them feels like juggling the current item
| you're looking at thru a few different buttons.
| rollcat wrote:
| See my sibling comment:
| https://news.ycombinator.com/item?id=43673486
| kmeisthax wrote:
| Good GUI apps have shittons of keyboard shortcuts to achieve
| the same result. The ideal is that the qualified operator
| keeps their hands on the keyboard for anything that isn't an
| actual pointing operation. For example, in a video editing
| app, you can rough-cut with a handful of keys[0] for setting
| in and out points, jogging through the source material, and
| inserting into the current active timeline. The keyboard
| isn't a mere text input device, it's a large-ish macro pad
| with a huge number of redefineable keys, and it will always
| be faster to press a button with a known location versus
| opening a menu and clicking an option by name.
|
| Related: I really liked Blender's text-searchable menus and I
| wish every GUI app had searchable menus. It's faster than
| hunting through a static hierarchy. In fact, one of the few
| criticisms I have of the 4.x era Blender UI is just that it's
| mildly harder to invoke search.
|
| [0] Which is how linear video edit consoles worked before
| modern NLEs, mind.
| geocar wrote:
| > every GUI app had searchable menus
|
| They do on mac: shift+[?]+? opens a "search menu" menu.
| sgt wrote:
| The amount of alternative navigation and accessibility in
| macOS is actually astounding.
| kmeisthax wrote:
| OH MY GOD. I never knew about that.
| no_wizard wrote:
| This doesn't always show everything. It's up to
| developers to make sure some shortcuts can show up in
| this documentation beyond system ones
|
| Luckily most do, but I've encountered situations where
| they haven't and it only shows compatible system
| shortcuts
| c-hendricks wrote:
| > I wish every GUI app had searchable menus
|
| On macOS and KDE (Wayland), they do! Agreed it's really
| handy.
| _blk wrote:
| Airlines (and our corp. interface to it) seem to still rely
| on those. Kinda weird but fun to see HR/Travel people using
| those. They definitely have their place still.
| MrJohz wrote:
| I've definitely seen this in real life, but recently I've
| started trying to actually watch when people use these
| interfaces, and they usually seem very slow - lots of
| hesitation, lots of mistakes, lots of repetition to do very
| simple actions. I watched someone use a terminal PoS recently
| and to clear a text input and insert a new value, she had to
| navigate to the start of the text box (no home key or
| anything like that), type new characters over the old ones,
| and then at the end delete any leftover characters from the
| previous input that they hadn't typed over. In a modern GUI,
| I would expect the user to have to (1) tab to the text box or
| press ctrl-A if they were in that text box, then (2) type the
| value they were interested in, possibly with typeahead
| support if it makes sense.
|
| My working theory is that these terminal-based UIs aren't
| quicker because they're terminal-based, but rather users need
| to learn the keyboard shortcuts because they're so painful to
| use any other way. A well-designed GUI equivalent could be
| significantly quicker, and much easier to learn, but nobody
| wants to pay for that.
| mrighele wrote:
| That has nothing to do with the interface being a terminal,
| but with the primary input method being a keyboard instead of
| a pointing device.
|
| You could get the same result with a graphical interface, as
| long as you provide proper keyboard based navigation. The web
| browser provide all the capabilities that you need for that.
|
| The nice part of a text based ui is that you have a simpler
| device to use for rendering, so things like layout is easier,
| as long as you remain in the domain of what the device allows
| for.
| Vegenoid wrote:
| Agreed that a GUI can be just as keyboard-friendly as a
| good TUI, but it would seem natural that restricting things
| to a grid of characters encourages keyboard interaction,
| whereas allowing arbitrary placement of elements at the
| pixel level encourages mouse interaction.
| EasyMark wrote:
| once those keys become muscle memory no mouse driven
| interface will ever repair lol. I used to work best buy and
| they had a bunch of backend inventory/database stuff and I
| could absolutely fly through those. I used be able to do the
| same with wordperfect as well. now all those skills and
| muscle memory..... gone like tears in the rain.
| suobset wrote:
| Personally I felt this as a retro hobbyist project. I don't see
| it being used for serious matters, but I'd snag something like
| this up for my personal website any day!!
| EasyMark wrote:
| It would make a lovely homepage, expecially for retro
| computing sites, archives of 60s-90s, etc. I'm not sure why
| people get angry when developers go outside the box and make
| something nifty. I have been using the star trek console
| looking theme for my pihole for years and still love the
| aesthetic.
| SkyMarshal wrote:
| There are folks from that era (the 90s and earlier) who learned
| and mastered TUIs and are very productive with them. Like a pro
| Wall St analyst operating Microsoft Excel with no mouse, you
| can fly through them if all the keyboard commands are in muscle
| memory. Mouse interfaces are more intuitive and easy, but less
| efficient.
| nsonha wrote:
| I like terminal aesthetic, and I think the modeen equivalent of
| it is high constrast UI, plus minimalistic elements. Forcing
| character cells onto the web is dumb.
| wruza wrote:
| Because it's how normal people think. This under that. This
| after that, left-aligned with that. Text modes are the most
| basic tech supporting it.
|
| Css uses boxing with no sugar (like size groups or custom
| allocation). Boxing is this in that in that in that, sometimes
| stretched. And now when you want A and B in different boxes to
| align well, you're screwed, cause it creates an invisible
| fragile tree of braces that hold everything in place.
|
| Maybe they would use a much more natural constraints-based
| language instead of text modes. Like, literally, "this under
| that, and these five left- and width-aligned". But web is
| reluctant to add it, because when not used carefully it could
| slow down first interactive renders by 0.01% out of average 10s
| (that is, assuming the same moronic site structure for some
| reason and the code that renders it).
| imiric wrote:
| Ah, wonderful. It even mimics the empty rectangles when a font
| doesn't contain a glyph...
|
| This is neat, but no, stop it. TUIs are an abomination of design
| that poorly mimic actually beautiful UIs. They look the way they
| do because of inherent constraints of the terminal, not because
| their authors particularly wanted them to look like that. So
| bringing that design language to a platform that does support
| rich UIs is artificially limiting what can be done on the web. It
| will also never truly have the same design as the terminal,
| unless you also want to avoid having any rich multimedia,
| interactivity, or use any web functionality introduced after
| 1995. At that point, your users would be better served by a text-
| only or Gemini site instead.
|
| As an aside, I think TUIs are wrong in most cases. If you're
| building something like a text editor or process manager, sure,
| they have their place. Although even then I would argue that they
| shouldn't mimic the look and feel of GUIs, but be purpose-built
| for the app in question. But most terminal programs shouldn't use
| TUIs. They should accept command-line arguments to modify their
| behavior, run and do what the user asked, and then exit. This is
| how you make programs adaptable, composable, and scriptable. They
| can still be made interactive at runtime via a different e.g.
| "client" program, but forcing the user to manually interact with
| an interface that mimics GUIs is an awful experience.
| varun_ch wrote:
| I think you're reading too much into it! This seems like a cute
| design library for eg. a personal blog or a portfolio website.
| I really doubt the author thinks this is the best design style,
| it's just got an aesthetic that it sticks with, which is fun.
| imiric wrote:
| Haha I suppose you're right. I do get a kick out of similar
| CSS frameworks that mimic the look of Windows and other OSs.
| I was just triggered by "beauty of TUIs", but beauty is in
| the eye of the beholder... :)
| rvz wrote:
| Hmm, Not really convinced. I like TUIs and also the aesthetic
| of them.
|
| Much faster to use on a keyboard than point clicking all over
| the place with a mouse on the screen or typing the long
| commands and flags and forgetting a single flag and having to
| typing it once again.
| pfg_ wrote:
| If you forget a flag, can't you move your cursor and add the
| flag? No need to type the whole command again
| wpm wrote:
| If your terminal is using readline/emacs bindings, Meta + B
| will go backward one word. Ctrl + a will move the cursor to
| the beginning of the line. There are of course equivalents
| if your terminal is configured to use the vi/vim keybinds.
|
| On macOS, you can hold Option and click to emulate the
| correct amount of left or right arrow presses to move the
| cursor.
|
| So, no, you don't need to type the whole command again. I
| would personally probably hit Ctrl + a and move my cursor
| forward a few words to where I need to add the flag.
| eMPee584 wrote:
| TUIs are memory-friendly tools for complex tasks and have a
| different UX feel (can be more comfortable, clear &
| informative, accessible) to pure CLI or native/web apps. I for
| one am extremely happy there's a thriving terminal ecosystem,
| nowadays with colors, icons (nerdfonts), emojis, mouse support,
| widget layouts.. even sixels and smooth scrolling..
| santiagobasulto wrote:
| > TUIs are an abomination of design that poorly mimic actually
| beautiful UIs
|
| My mother used to have an early "digital company" back in the
| 90s in Argentina. We are from a small town in the "Patagonia
| region"[0] and there was only 1 programmer in the whole town.
| The guy was a huge nerd that had spent some time studying in
| Buenos Aires.
|
| Long story short, my mother hired this kid to build software
| for him. This is around 1992 so it was all DOS.
|
| This guy built a full TUI software with CRUD operation,
| reporting, "cron jobs" (some stuff that I never understood but
| would run every night), printing, etc.
|
| Until this day I remember the people working at my mother's
| company how they just FLEW over the software. It was all
| keyboard and hotkeys. They'd just go back and forth, print
| stuff, enter data, connect with the Fax machine, all with their
| keyboard in this black screen full of green, white and orange
| glyphs.
|
| I NEVER found any other software that is SO powerful and
| efficient and user friendly as TUIs.
|
| [0] The "true" Patagonia region in the East of Arg.
| imiric wrote:
| That's great, but keyboard shortcuts are not exclusive to
| TUIs. GUIs can be just as powerful in that sense, and most
| advanced web apps support keyboard navigation. My objection
| is mainly to the claim that TUIs are beautiful, and to the
| effort of bringing their design to the web. But this is
| ultimately down to personal preferences, and others may
| disagree.
| santiagobasulto wrote:
| Yes, GUIs and Web interfaces can support keyboard
| navigation. But I have NEVER found one fully exploiting
| this. Linear (ticket tracking app) is maybe the only one
| that comes to mind as a good alternative, but nowhere close
| to the fluidity achieved by TUIs.
|
| I think the reason is "limitation", if you have to design
| an app that CAN NOT use a Mouse, you'll be darn sure it'll
| work well with the keyboard.
| graemep wrote:
| Its true in theory, but it does not work well in practice
| because:
|
| 1. Developers have to make an extra effort (and require
| time) to do it right 2. People are much less likely to
| learn the keyboard shortcuts
|
| If you designed a GUI to be keyboard first then it might
| work as you say, but I cannot think of any real life
| examples of that. I think people need to TUI look to push
| them to use keyboards.
| trollied wrote:
| You're correct that modern web apps support keyboard
| shortcuts just fine. Unfortunately the reality of it is
| that the modern web is bogged down by the mess that is npm
| modules, react etc, and the majority of web apps are slow.
| Oldschool terminal apps you can just type away, and you
| know your keystrokes will just happen. The modern web?
| Urgh.
|
| Don't get me wrong, you can do it right, but most don't
| bother with non- functional requirements "this should take
| 5ms" etc, so you just end up with pointless animations and
| transitions that stop useful work being done. This is often
| simple things like the tab order being wrong, or an AJAX
| request blocking the next thing you want to do.
| pjmlp wrote:
| Except my laptop isn't something bound to 1 MB RAM, with luck
| having a VGA card able to do 256 colors, running at about 20
| MHz with turbo button and a whooping 40 MB hard drive.
| jen729w wrote:
| Except it's quicker to navigate an interface using
| keystrokes than it is using a mouse regardless of how much
| RAM you've got.
|
| Compare a proficient travel agent who speaks Sabre to you
| booking a flight on Skyscanner. They'd whup your ass.
|
| https://youtube.com/watch?v=G8n0_3t-EhI&pp=ygUPc2FicmUgY2xp
| I...
| pjmlp wrote:
| GUIs have keyboard shortcuts for decades, blame the
| developer that wasn't up to their stuff, not providing
| keyboard navigation.
|
| Heck, there are even Win32 and X Windows APIs designed
| with the exact purpose for keyboard navigation and
| shortcuts.
|
| Maybe instead of doing TUIs one should better spend their
| time learning the tools of their craft.
|
| Skyscanner failure to adopt such tooling, which browser
| also have due to accessibility requirements, has nothing
| to do with technical issues, all about skill and
| willingness where to spend budget.
| maccard wrote:
| The bottleneck with Skyscanner isn't not being able to
| enter the dates without moving my hands, it's waiting
| 30-50 seconds for all the flight options to appear, and
| trying to figure out "which ones are actually flights
| with the airplane and not third party resellers".
|
| Similarly with IDEs and programming - saving 0.5-2
| seconds for 10-20 operations isn't my bottleneck once
| I've decided to do the thing; waiting for the corporate
| antivirus to scan the chrome executable that has self
| updates since it last saw it, plus the VPN timeout
| because I haven't logged into a corp site in 3 hours is.
|
| Besides, visual tools can and do have very powerful
| shortcuts. 'Make run' takes longer to type than pressing
| F5 does, in visual studio. Photoshop, Maya, Nuke,
| ProTools, Final Cut, even Unity/Unreal are all graphical
| tools that have powerful widely used keyboard shortcuts.
| graemep wrote:
| I saw similar in the 90s in a bank branch that was still on
| an old system. People who new it were very, very fast.
| ximm wrote:
| Nice use of the ch and lh units!
| n3storm wrote:
| Somebody went too far after watching The Brutalist
| lionkor wrote:
| On Firefox mobile the search field is one "cell" too large to the
| right and doesn't fit... I think I'm good. It seems petty, maybe,
| but the creator can't get their homepage right with it, I'm not
| sure I trust it.
|
| If someone built a full C compiler but it throws errors when
| compiling itself, would you use it?!
| wsintra2022 wrote:
| Second this, I opened the link and saw it was jank in my mobile
| browser. Why would someone not check that before showing the
| world? Anyway I am a fan of terminal and definitely on the
| bandwagon that a lot of the comments allude too. My reason;
| keeps fingers on the keyboard.
| catapart wrote:
| Oh, sweet! I really like the faithfulness to the original
| subject, while still being useful with a mouse.
|
| I was actually going to write a theme for a project I'm working
| on that is meant to be styled like an inventory terminal from an
| auto parts store circa 1995, which was all some kind of TUI, so
| your theme is a great inspiration!
| adhamsalama wrote:
| This will make it easy for people to write terminal emulators
| using web technologies that look a lot like actual terminal
| emulators (like Hyper). So we have gone full circle like twice?
| ahdanggit wrote:
| The _only_ thing I don't like about this is the automatic
| prefixing of '#' in header tags. Everything about this is
| freaking awesome.
| jiehong wrote:
| That's nice!
|
| ## Shameless plug
|
| I explored a bit what older tech such as IBM's TN5250 terminals
| could bring to the Web [0] 2 years ago. In particular for data
| input scenarios.
|
| It's designed for Desktops, not mobile.
|
| [0]: https://jiehong.gitlab.io/web_tn5250
| magicink81 wrote:
| I came here just to post a few words of encouragement. I think
| this is fun project. Thanks for making it!
| jadbox wrote:
| Examples don't fit on mobile screens :(
| AlienRobot wrote:
| This looks great but the scrollbars are unstyled.
___________________________________________________________________
(page generated 2025-04-13 23:01 UTC)