It makes far more sense in the context of effectively a remote session or dumb terminal serial connection. Your "terminal" application is only emulating a text mode environment inside a gui, typically... you can ctrl+alt+F2 - F5 in a lot of Liknux's to switch to a terminal session if you want, but that's not what people tend to actually use.
Beyond this, without remote X properly configured, again, most don't and probably shouldn't.. you aren't running remote gui applications over an SSH session. Richer TUIs were pretty common in ye old days of DOS and other OSes before rich GUIs become the norm. DOSShell, Edit.com, etc. The IDEs of days past and Word Perfect even. These all interacted with Mice and were considered the norm. The features that allow this over a remote terminal today are pretty great IMO, the harder part is properly handling window sizes/resizes, etc.
With graphical extensions, there are even nice app explorers with image previews via TUI. It pushes the boundaries. For that matter, I often wonder what could have come with RIPscrip/RIPTerm if the leap to web didn't happen the way it did...
I think the single hardest part of TUI is dealing with wide characters and secondary fonts for color emojii that don't quite render in 2 spaces completely in a lot of termianls... it makes the line drawing harder too.
These sarcastic reddit style comments grate me. And it's also inaccurate, you're not runnning remote graphical applications from a remote headless webserver. You're rendering it locally.
He's functionally right though, a remotely served interface can be implemented as a TUI behind ssh, or it could be implemented as a website. Which is the better option depends on the context, but they're both serving the same function, and the terminal emulator you're using to view the TUI is most certainly rendering it on your computer.
This is true only up to "you can send and receive data".
A terminal is an OS construct mostly. It will, with permissions, allow you to do anything the OS can do, including shutdown, or serve more data. It's the default mode of operating the system.
The opposite is not true. The default mode of operating a web browser will not let you create a terminal access or do anything new with the machine.
Insofar as the previous is false - because it website has flaws that allow code execution, shell escapes, or remote package installations, it's worth pointing out that these are usually possible because your web server is running as a user on a system, effectively with system access via similar interfaces as the shell.
This is like saying you can operate a car from the truck - yeah maybe through some weird gymnastics, but the trunk is for transfer, and the drivers seat is for operating.
You can easily reboot a machine from a web interface, if rebooting the machine is intended to be part of that interface. I do it all the time with my shitty wifi router (which incidentally, also has a TUI interface.)
You're off base with your talk of terminals being "OS constructs" or whatever, I think it's because you're not being precise with what exactly you're talking about. "The terminal" is a combination of a terminal emulator, which is a userspace program which interprets control sequences that tell it which characters to render where. The terminal emulator is connected to a psuedoterminal, which is a pair of files for IPC with some special semantics, notably canonical mode. Importantly, in none of this is anything for controlling the system.
For controlling the system, you need some other program besides a terminal. A shell. A shell isn't part of the terminal, nor part of the operating system except in a broader sense of the term. And it doesn't have special abilities to control the system, anything the shell can do, a TUI or web interface, or any other kind of interface can be made to do.
Anyway, you ssh into a computer and start a TUI. The TUI doesn't render anything, it just sends you text and escape codes. The terminal emulator on your computer interprets this stream of escape codes and text, as a web browser interprets html, and renders it locally.
Yeah I got off the main point. A shell is something else.
Text interfaces and text based sessions have a definition, as do graphical interfaces, as does web interfaces. They're separate and well defined even if there's some minor blurring at the edges or you can emulate one inside another.
An X server also normally renders things locally, as does a VT-compatible terminal. If you want no local rendering at all, there's VNC.
With a web app, you can slice and dice processing between local and remote by running JS locally. Most processing usually happens remotely though, and only the display and command logic is run in the browser.
I've built my career in web based apps... Depending on what you're doing, your exponentially increasing you bug surface in a web based app vs a TUI over a remote shell/ssh.
It's not a matter of if you can do much as if it's practical, reasonable or worth the effort. I say this while writing an application that is effectively a remote web GUI over what can be done in their terminal sessions, because I want a nice UX.
I'm hoping to sell it commercially even. That doesn't mean TUI can't be a better option.
Where did I say you couldn't create it use a web application? That said, it's not a their GUI, it's a local UI as part of a thick client.
You can definitely connect aWeb.UI to a remote system and over web sockets be really close to immediate. Though you're still interactive with disconnected state.
It's not usually an issue. That said, there is a lot more complexity and room for bugs for some use cases over a terminal session and plain text or TUI applications.
I've built a career on handling the complexities of web based applications over the past 3 decades. It's far from a panacea.
Beyond this, without remote X properly configured, again, most don't and probably shouldn't.. you aren't running remote gui applications over an SSH session. Richer TUIs were pretty common in ye old days of DOS and other OSes before rich GUIs become the norm. DOSShell, Edit.com, etc. The IDEs of days past and Word Perfect even. These all interacted with Mice and were considered the norm. The features that allow this over a remote terminal today are pretty great IMO, the harder part is properly handling window sizes/resizes, etc.
With graphical extensions, there are even nice app explorers with image previews via TUI. It pushes the boundaries. For that matter, I often wonder what could have come with RIPscrip/RIPTerm if the leap to web didn't happen the way it did...
I think the single hardest part of TUI is dealing with wide characters and secondary fonts for color emojii that don't quite render in 2 spaces completely in a lot of termianls... it makes the line drawing harder too.