True, i worked in a insurance company, the main CRM was a TUI with a Mainframe in the background, fast and reliable as hell/heaven.
Then everyone (Management) wanted to go away from mainframe (because it's 60's technology and expensive), so we developed a Java application with a GUI and Oracle in the background..and i was just ashamed about the whole project when it was finished.
It was slower for the user, less reliable and counting the dev-cost would gave us 10years of "free" mainframe-time.
- user security massively increased (they need hardware tokens)
- user management is now part of a globalized management system where control access are much stricter than (let's call the dev to add somebody)
- it is muuuch easier to find new Java devs; development is now shared between the company (for business knowledge) and another company for the development, diminishing the train factor by a huge amount.
- code has been modernized and so is much more easy to audit
- SQL database can be queried by armies of cheap data analysis tools
- some of the consultants have now much less power to negotiate their salary (less than they were only 3 managing the application :-) )
That were for the positives. Negattives:
- Java UI needs much more time to get polished or much better dev's.
- Security is now much more administrative. Gone the days of the quick fix in production.
- hardware token for security is not vey well handled, incurring a heavy toll on data access (a limitation of our security token, which was unfortunately not seen during project planning)
- we had to reproduce all the TUI shortcuts for people to stay productive. Yes, you read that correctly :-)
It sounds you had a much bigger budget than we had ;)
BTW, the Mainframe had a sql-database (DB2) and was attached to Active-Directory already, the Reports/Print-jobs where send to a Linux Machine, it was actively maintained and not some old crusty 70's System.
The only sad part here is that you didn’t get your own 3278 with beam spring keyboard ;-)
People often equate a later fad with “modernisation” when a well architected app can be easy to manage even if written in COBOL and running under CICS.
If a person can learn Java, they can learn to read COBOL.
Similar experience (as a user) at a medium-sized college.
The information system (class registration, bursar, etc) could be accessed via a TUI over telnet/ssh. It was amazingly fast, and all the older professors could move around that thing fast as hell, since all the shortcuts were in muscle memory. Force-adding a student to a class could literally take <5s if they had all the numbers.
Students could use it, too. And those of us who knew about it would do so, since it was so much better.
Hehe, we also had similar system in university. It was usually accessed over telnet, but in some places at the school, you could still find the real electron tube green (or orange?) text teletype terminal, where the student could sit and access just this system.
It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time.
> It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time.
Often the way these things work, the old terminals go slow (sometimes very slow) but work, and the new way times out often making it impossible to make changes, but sometimes you still can, but won't know if they worked.
Wanted to hear this. This had been my experience too. But no one on the net seem to talk about it. It was always "we are stuck with mainframe due to politics..."
But this isn't about mainframe vs Java. I have a feeling it's about Terminal user interface vs GUI.
A modern terminal app, will be just as much fast as those old mainframe apps, is my feeling.
Mainframes do have a more sensible way to build a TUI than something like curses. A 3270 TUI is very similar to using html forms. The fields are named, have attributes, validation, and a so on. The mainframe sends the form, the user interacts with the form, and nothing is sent back to the server until either a field validation is needed or the "Enter" key is pressed.
Did you mean to link to a 380 page PDF book? Sure, it fits with the literal meaning of "more detail", but it doesn't feel helpful in a discussion context like this...
I clicked on that link hoping to see one or two pages of info that made it clear how the whole system worked with more detail than you gave, but not a whole book of minutia that I don't have enough reason to care about at this point in the discussion.
Few things would make me as happy as the Django admin module ported to a TUI. In the mainframe days, how much did application developers need to worry about the displayed field length, or was that handled by the OS?
That approach is good enough for simple forms ala HTML, but it's not effective for the sorts of full-featured TUI's with character-based graphics, drop-down menus, widgets, panes/windows etc. that are expected nowadays. Even writing a simple interactive text editor would be problematic using that model.
I don't think it is exactly TUI vs GUI, but more keyboard-first vs mouse-first, i.e. how you interact with it. Granted, Desktop GUI are usually developed mouse-first, but it doesn't have to be that way: if you take windows 98 / windows 2000, you could get everything done more efficiently with a keyboard than with a mouse.
Just think about the difference between an app developed specifically for the desktop (mouse) or for mobile (touch): same GUI but completely different programs and experience
Plus responsiveness. Terminal apps have faster response time than GUIs. And when someone is typing like 10 chars per seconds it matters.
The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.
Terminal apps are running under a GUI terminal for at least two decades now, there isn't really a reason for a GUI application to not be as responsive as a terminal application, it is just that "modern" GUI toolkits being slow.
IMO a reason is because nobody seems to bat an eye when faced with a "TUI" made out of lines, boxes and garish colors but if a GUI is made like that it is suddenly ugly so toolkit developers put a ton of effort into shiny looks.
But try a GUI made with Win32, Motif, Tk (not Ttk) or even Gtk1 and it'll be as responsive as any terminal application (of course it also depends on the application, there isn't much the GUI can do if the application abuses it or is sluggish for other reasons ).
A bit of that is also related to different UX design, with many of the venerated old TUIs actually having better UX, not due to being TUI, but because they avoided certain popular (anti-)patterns of GUI programming.
A top example, from discussing with non-techies who had the tools change from TUI to GUI, is the drop-down menu bar at the top of the window (or top of the screen, for mac). What used to be few keys at worst, turned out to multiple long trips by mouse to select an option 3+ levels of nesting deep, because the job was just that complex - but there was no contextual shortcut available.
Many old TUIs (and we're talking divergent brother of S/370 with random other stuff in the mix old) tended to have ways to reach pretty deep in the navigation structure pretty fast (sometimes even direct - for example airline reservation systems, where you often can make a CLI command go straight to a completely different context).
> The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.
Actually I think it is more nuanced than that.
Some GUI programs are well optimized for fast keyboard only usage even if you can use point and click. NetBeans, Eclipse, IntelliJ, Sublime Text and VS Code are on top of my mind but even some old web applications used to be quite usable I think.
I had a similar experience. And it would have been simple to pay attention to tab traversal, field highlighting, key bindings, etc, to have made the new application more familiar and faster. Wasn't to be though.
Yes - all of the examples in the linked repo run in the terminal and are also ported to the Web using Emscripten.
> Or is it only when you have a framebuffer available?
ImTui creates a framebuffer and renders the scene using ASCII characters into the framebuffer.
To create the scene, you can use the entire API of Dear ImGui [0] - it has various options for creating windows, buttons, sliders, tables, checkboxes, colors, etc.
You now need to display this framebuffer somehow and also provide input from the keyboard and the mouse.
ImTui provides an ncurses interface for this. It uses the ncurses API to render the characters in the terminal and also to grab input from the keyboard and the mouse.
Technically, ncurses is an overkill for this application, since ImTui only uses only a very small subset of the ncurses functions. But this was the easiest way to make it work.
ImTui can be extended with more interfaces. For example, I made a second one which I call "Emscripten" interface. It's purpose is to provide an API to easily export the framebuffer to the JS layer and to easily grab input back from the JS layer. This way, I can have a single application code that builds and runs both in the terminal and on the web.
It feels like we live in a pretty good time for writing TUIs, CLIs and also small self-contained tools (thanks to languages like Go, which have a lot of libraries, are easy to use, but also compile to statically linked executables).
It made regular shell scripts into a fully fledged CLI with nested commands thanks to just a few decorators that were sprinkled in the source files, as well as the occasional slight signature alteration.
Developing a GUI feels awfully complicated in comparison and i'm amazed that there don't seem to be all that many (if any) frameworks for creating GUIs in a similar way - by annotating method calls as actions that correspond to the actual GUI elements and letting some smart parsing logic handle the rest for you.
I feel like perhaps the world would be a slightly better place if desktop software could also be distributed as libraries of callable code, where you could automate button presses programmatically and there would be a 1:1 link between what you can do in code and manually.
It’s kind of a language thing. When Visual Basic came out, it’s UI builder was ahead of anything I’ve ever seen on a GUI and more versatile than HyperCard (and much faster).
A decent GUI builder attached to an IDE and some nice language support goes a long way.
That’s the opposite of the experience you get when using, say, Flutter or React Native. The language is better than BASIC, though.
Sadly it seems a thing of the times, perhaps due to the direction the industry has gone in.
I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects.
There is Swing for Java which had a really nice GUI builder in NetBeans, but the other IDEs are somewhat lacking in comparison and then JavaFX/OpenJFX came out, which didn't integrate quite as nicely and complicated things further.
As for .NET, it has always had lovely GUI options, especially with WinForms/WPF in Visual Studio, yet it has always lacked cross platform options for the most part.
How we got from being able to drag and drop components to create fully functional GUIs to embedding browsers and creating apps with full webdev stacks locally never ceases to surprise me in a bad way.
> I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects.
Lazarus and Free Pascal are used for new projects all the time, if anything judging from the mailing lists, they are more popular than they've ever been (hell, unlike only just 5-6 years ago, i rarely see people mention that they remember using Turbo Pascal back in their school years whenever a new release is made nowadays :-P).
Free Pascal comes with a ton of bindings out of the box, but making new ones for C should be simple with the included h2pas tool (i think there is also a frontend for Lazarus though i never used it myself). There should also be already made bindings for stuff that aren't distributed with Free Pascal. You should also be able to use Rust libraries by going via cbindgen -> h2pas, as well as any other language that can "export" C header files for FFI. Beyond that you can do it manually, which can be a pain, but that is the case with pretty much any language.
Of course using libraries from scripting languages and managed languages like Python, JavaScript, Java and C# is harder but not impossible (and not really that much harder than using them from any other native language, C included).
It wouldn't be too difficult to build on Glade or QtDesigner and better integrate it with code generation. Both Glade and QtDesigner output language-neutral UI descriptions that could be used to build any sort of app.
Lazarus already saves the forms into text-based files that you can read, however this is really missing the point and reducing an advanced RAD tool to nothing more than 80s-circa resource editor for Windows. There are tons of tools like that.
The big feature of Lazarus (and Delphi and C++ Builder, etc) is how integrated the entire thing is - not just the form designer but also the framework being itself designed around its use inside Lazarus' form designer, object inspector, etc and the language having features (e.g. published properties) explicitly for such use and the IDE knows about the framework so it can automatically plug things, generate code (not in the Glade style of unidirectional generation but in that the IDE understands the code and can modify it). Hell, even C++ Builder actually feels a bit "alien" to VCL (which was originally made for Delphi and Borland had to add several extensions to C++ for it to work, which only really worked because they had their own compiler, linker, etc to work with).
The closest you could get to that elsewhere is QtCreator but you quickly realize (assuming you were used to Lazarus-like tools, most developers actually do not realize that) you are working with something that was meant to be coded against instead of used with visual designers (which is kinda backwards IMO considering the "G" in GUIs and kinda remind me a quip about Motif back in the day about how its documentation was a bunch of volumes almost without any screenshot :-P).
But if you want to do it right, you can't really work around the need for all these to be integrated with a unifying vision. Even Lazarus and Free Pascal, which are technically different projects, largely managed it because they basically did what Delphi already had done - and most of the warts when using Lazarus come from not being a truly integrated project like Delphi was, like issues with different FPC versions or relying on GDB as a debugger (which is the #1 source of debugging issues, fortunately there is a new debugger in works which can work as part of the IDE itself and personally find it to work fine, though it isn't enabled by default).
I recently came across YAD (https://sourceforge.net/projects/yad-dialog/), which is a improved version of dialog. Allows you to create a simple GUI, where all the entries are written to STDOUT. So, you can interface with your favorite language. For examples, see this page: http://smokey01.com/yad/
I just read the following links to build up foundation of knowledge first - low-level:
http://%CA%9E.cc/irl/term.html
https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
Other libraries:
# C, C++, Python and Rust
https://github.com/dankamongmen/notcurses
# Python, more polished presentation - but I cannot judge the technical foundation
https://github.com/willmcgugan/rich