The idea is pretty cool, but I'm unsure of the mix of TUI and animation. Once you start going down the path of animations, layout, fonts, etc, you start just reinventing the web - but with extra steps.
Personally I would cut complex animations (i.e. sub-character) and only have a single size monospace font. I would rip out CSS and go for maximum compatibility. (If something exists like that, please let me know!)
Another feature that could be cool is to have this served (optionally) via telnet. I would also make it be able to produce static content (with a subset of features).
Tbh this can all be covered by ANSI escape codes. They aren't very expressive or compasable, in comparison to CSS but adequate for most TUI programms. And even the DX around them is okay-ish in textual and other TUI frameworks.
I like the telnet idea. I haven't used that in like 20 years. Do people still use that?
I guess it's kinda like running over ssh? Or do you mean you hit an open unprotected port (telnet) and then the app takes care of setting up the SSL connection so you don't have to worry about SSH details?
I prefer TUIs over GUIs primarily because TUIs are often tailored for advanced users — essentially, for professionals. In contrast, the majority of GUIs prioritize user-friendly experiences for the general consumer.
When a 'TUI' begins to incorporate features like mouse-clickable buttons, drop-down menus, scrollbars, windowed interfaces (as opposed to panes & separate screens), it gradually shifts away from its core identity. Eventually, it becomes a GUI operating within the limitations of a terminal.
Imagine something like lazygit with text-drawn buttons, drop downs and other TUI anti-patterns. Or even more extreme, without its keybindings and modality. It would miss the point entirely.
I don't think the two use cases are mutually exclusive. You can have that keyboard driven muscle-memory workflow, while keeping things discoverable for users who haven't committed everything to memory.
I've found Fusion 360 to be highly mouse-driven with frustratingly few keyboard shortcuts available. It feels borderline unusable without having one hand on the mouse at all times to select various operations, and the faux-pie menus are too contextual to be a great replacement.
Tools like Plasticity CAD¹ or Blender feel way more keyboard-friendly in this space.
the TUI library for tcell has mouse support, though you see it more in tview (or one of the dozens of maintained forks)
I've already experimented with dropdown menus and minimizing sections. While I too love the TUI and keyboard driven experience, many want something they can click on, less overhead from every application having their own hotkeys. For me, it's about reaching more people, and the hope that I can bring more of them into the mouseless development experience
Right now on my desktop I see 4 TUI windows, and 11 GUI windows.
A full-featured web browser or a video chat client can't be realistically made TUI. I could have run Emacs in TUI mode, but I appreciate variable font support in non-code texts I write.
For the videochat client it could be one video window with several panes (PIP, main+side small, ...) with a textual interface for controls, chatting etc.
yeah, I've consigned myself to needing a GUI, but for the time being, iteration with a TUI is much faster. Our focus is also CUE, where working from the Go API unlocks way more possibilities. We get to keep the extra complexity of representing CUE constructs as JSON for sending on the wire. Though that GUI might be native and avoid all the web stuff anyway.
tmux. I know the keyboard shortcuts (that I customised) to create new windows and panes, and the shortcut to resize them all equally. I've not bothered to learn / remember the keyboard shortcuts to swap pane focus or resize individual panes because I've enabled mouse support and simply click where I want to focus and drag to resize.
In theory GUI is a superset of TUI, there's nothing inherently bad or unproductive about GUI. You can argue in practice there exist a lot of unproductive GUI that's worse than a TUI client, but I think it's the problem of the designer, not the tool.
Also there are some areas that's universally acknowledged to be better suited for GUI, anything that requires visualization like video editing, image editing, 3d modeling, etc. Maybe someone can go full ffmpeg to edit a feature length film, but that'll take some effort.
Only if the TUI is non-scriptable. That's the big bait-and-switch possible here: Is it a TUI in that the menu system is made out of text, or is it a TUI in that it's a command line with a scripting language and the ability to create new commands out of composable pieces? Just saying "Textual User Interface" doesn't disambiguate the two.
How com GUI isn't scriptable? Most GUI is made from scripts. Or do you mean the ability for end user to extend the software with a software-provided scripting system. In that case that's not related to GUI and TUI, all application no matter GUI or TUI can be extended by scripts if the software author wants to support that.
I wish I could accurately share my experiences watching travel agents working on mainframe terminals finding me a good deal on flights in my travel windows.
it was amazing watching them work, and there was no mouse involved. there wasn't even a mouse connected to the terminal. F-keys and hotkeys galore, and the applications were extremely responsive, none of this 400ms response from a webserver then another 1200ms waiting for the JS to render the page.
I am in favor of TUIs if they can bring this kind of accommodation for power-users. I agree with you that there is a strong danger of UX people getting involved and making things perfect for new people at the expense of anyone advanced.
Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you.
Also lazygit and neovim (since you mentioned modals) are GUIs in the terminal. The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.
> Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you.
I am not sure why you think my comment is in disagreement of that.
> The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.
From reading both of your comments it looks like you are saying that people who use [Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming] fall into the category "general consumer" but people who use vim fall into the category "professional". That's not how I would distinguish professionals from general consumers.
Ah, I see, that's not what I meant (hence the 'TUIs are often tailored for advanced users' and 'the majority of GUIs prioritize user-friendly experiences for the general consumer' phrasing).
I agree there are also many GUIs tailored for professionals. Not sure if there are TUIs tailored for general consumers though.
GUIs have a rich history of power and complexity, which has been watered down over generations of business fucks insisting that everything be 'easy to use' so they can get those grandma dollars
I"m a professional software developer and I like user-friendly experiences. I didn't know drop down menus and clickable buttons (thought that was the point of a button) are somehow anathema to advanced users
Neat. I’d like more alternatives to the current paradigm of design. For example I’m currently building a UI with gradio and I’m enjoying it vs html/JS. The level of complexity to build a usable app is about as low as I can imagine until we get to a wisywig.
As a user I don’t like what the web has become. People build UIs as if the medium is the message, but I can assure you the content is more important to me than the form. Plain text sports is popular for a reason!
TUI is just a thinly disguised GUI. I mean it's pretty cool what they've done, but if it's effectively just an alternative graphical frontend (that happens to run in a terminal emulator), well I guess someone out there has a use case where they need to run this over an SSH session?
Personally I find CLI (not TUI) and/or client libraries a much more attractive proposition; otherwise a native application, that uses proper system widgets and integrates with the rest of your desktop environment (an icon in the dock, system notifications, matching light/dark theme, etc), seems superior to a TUI in all aspects? (Except for "I need to run this over SSH / serial console"...)
I wrote a TUI before for work, entirely of my own volition and for my own near-exclusive consumption (it was theoretically for anyone, but I'm the only person who would've had a reason to look at it - we were a fairly silo'd dev shop).
This is what made me pick TUI over a web UI:
* no web stack, period. no client/server. no js or html. this simplified the problem dramatically. also, no additional services to babysit.
* no browser - no certificates, security, auth, etc. It's just unix permissions and ssh.
* there's something comforting about the constraints of just ASCII/ANSI and curses. No bikeshedding over border widths or radii when it's just you picking among a few characters for the shape. just having less decisions to make speeds things up and helps you focus on what you actually want the UI to be able to do.
Obviously if your app is just calling APIs anyway, that might be negate some of these bullets about no additional services to babysit etc. In this case, it was running an internal infra app that directly connected to a pg db.
And what made me pick it over just having a CLI:
* discoverability - it was a complicated app and while it was all technically exposed via cli flags, having a GUI made it a lot easier to figure out what the right incantation is.
* richer communication medium that's back-and-forth instead of unidirectional. The TUI is able to fetch a list of e.g. valid IDs and let you pick them with a check-list, instead of you having to go query the db yourself and type them in.
I consider it one of my greatest victories that my boss was able to use the TUI to recover from an incident without needing to page me while I was on holiday, and he said he barely had to read the docs and felt confident he was getting it right the first time. "I did it while sipping my coffee."
I used https://github.com/mabe02/lanterna - would recommend. They even have a Swing-based emulation mode for easy development iteration running it from intelliJ.
> there's something comforting about the constraints of just ASCII/ANSI and curses.
If you are using raw Ncurses from C or C++ you know where the name came from.
My favourite feature are the macros ncurses.h defines, like `OK` and `timeout`
100% one of the best things about building a TUI is not having the pain of modern web development. I do think there is a way to have a CLI & TUI come from the same code, so you can get the best of both, or pick the best for the task at hand.
TUIs being constrained to just text means that they are most likely 100% usable with a keyboard.
Text editors are a great example: I tried using VSCode with the vim extension, but every once in a (short) while some GUI panel "steals" the focus and I had to click somewhere to get back to where I was.
Apart from vim, I also use some chat TUI, and tig for browsing git, for the same reason.
It's like back in the days, common users of software could get really good and fly through with keyboard shortcuts. Nowadays I'm saddened when I have to watch a cashier CLICK through some shitty GUI at snail's speed.
> TUIs being constrained to just text means that they are most likely 100% usable with a keyboard.
Anecdata: a long time ago, I worked for people trying to sell a (physical) ad-system to Titan and they made a whizzy web UI for booking adverts on their system. Problem was that Titan already had a TTY booking system and their ad bookers could whip through multiple bookings on that using the keyboard in less time than the whizzy web UI took to even load the first page...
One thing that most TUIs have but most GUIs (web or native app) don't is fast keyboard navigation. There are obviously exceptions to both cases, but as a general rule this seems to hold true.
Watching people who are very familiar with the TUI that they're using do complex business transactions is a sight to behold. In particular, a seasoned user will likely type a series of commands that will get buffered until the TUI catches up with them - I've never seen a GUI that could do this.
Type-ahead works fine with single-threaded GUIs. It was rock solid in Windows 3.1. It worked in nearly all win32 apps because hardly anyone used threads other than for background tasks. But it's broken in most modern UI toolkits and on the web.
I'm probably a bit more positive to TUI type applications than you (and don't care about theme matching, docks, or notifications), given e.g. my editor runs purely in a terminal (and I'm writing a new terminal...) but I think we sort-of agree when you say it's just a thinly disguised GUI.
While I think it's impressive how good they've made it look, for me the point of a TUI is for it to be simple and pared down. It's nice if it looks good, but I want something keyboard driven and command focused rather than UI element focused. I'm not sure who the target group is here. Are there enough people who love to work in a terminal but still want their apps to look like GUI apps?
EDIT: From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point. I'm ambivalent of the chances for that to succeed, but who knows.
I think you are spot on classifying the project as “for people who want to write GUI”, based on the GitHub read me (which has screenshots) it does not appear to be a tui on the web at all
https://github.com/Textualize/textual-web
It looks like on the web it is rendering widgets that the library can also render via tui on the terminal. So it seems the title is quite misleading. The web based ones are not using font glyphs to build up a ui.
ack, I was fooled by the screenshots. That is even less advisable than I had feared. the widgets would likely have very poor accessibility if they are implemented as text on canvas.
> I want something keyboard driven and command focused rather than UI element focused.
I think we are in more agreement than you might suspect. Command-driven operation is how I tell a good UI from a poor UI. Good interfaces are intuitive for beginners and provide a smooth learning curve to mastery. Good way to get there is for the interface to remain simple and consistent on the surface, but unravel more specialized power as you dig in, and ultimately allow full customization.
It's all the things that make macOS UI so good IMHO: apps look and work similarly at the surface, have consistent keyboard shortcuts, you get excellent feature discoverability through the top bar menu + search box, and you can even rebind any menu item to a custom shortcut (both per-app and system-wide) through the stock Settings app. Pitch that against your typical selection of TUI apps: vi, less, top, screen, tmux, irssi, mutt, etc all do things differently, the *only* thing they have in common is a grid of character cells.
Terminal emulators themselves unfortunately seem to be the anti-thesis of good UI. The ecosystem is highly fragmented. Writing a TUI app from scratch (yes I wrote my own TUI text editor) is hell, if you want to aim at more than the lowest common denominator, while ensuring portability (I'm talking just Linux+BSD+Mac; I wouldn't even know where to start with Windows). Even if you chose not to waste your life and started with Termbox or heck even ncurses, you'll still be fighting a dragon at the end of every dungeon level: keybindings (why can't I do ctrl+shift+a!?), colors (crap it ended up being black on black!), etc.
> From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point.
I haven't looked at the framework yet (TL;DR...), but that seems like a goal that I could get behind. Writing a good GUI app nowadays means you have to learn and use platform-specific APIs, and cross-compiling is a massive pain.
Beeware (https://beeware.org/) is working on something pretty good in that direction. I encourage everyone to have a good look at it.
Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus. The first time I got a Mac, I thought this was insane. When I sold my MacBook years later, I still thought it was insane, because it is.
In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option, with subsequent letter keypresses opening other menus further still or selecting menu items. Windows still supports this and both Gnome and KDE(?) apps that still use traditional menu bars do, too. (Gtk used to even let you assign which letters opened which menus/items directly from the main application UI—no opening up any control panel—but they got rid of it around Gnome 3, as I understand it.)
> Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus.
Try Cmd+Shift+/ (aka Cmd+?) and typing a few letters of the command you want to invoke. It's pretty much the same mechanism that Emacs uses (C-x followed by the command name).
I'll admit it's not very discoverable.
> In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option
First, Macs don't have an "Alt" key ;) But more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions, their OS is arguably the most consistent one on the market thanks to that. Some people (hi) greatly value that consistency.
I think it could be argued either way about which convention is better, I'd say it boils down to preference.
O[1] RLY?[2][3] (Whether they have one or not is beside the point.)
> more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions
Irrelevant. The Mac OS isn't the same as the one that shipped in 1984. It certainly didn't have Spotlight then, for example. Supporting CUA-style menu access keys would be an additive change—the same way that importing the benefits of the UNIX userspace by way of NeXTStep was additive (but far less invasive than that one); no one said to stop supporting other menu access methods.
> Supporting CUA-style menu access keys would be an additive change [...].
As I said, Macs don't have an Alt key; there's an Opt key, which (depending on context) can work like AltGr or Alt (the latter usually when combined with Cmd). You can't draw a 1:1 comparison with a PC keyboard, because they're just different things.
Overloading Opt to access menus is not an additive change. Opt-e in my keyboard layout produces "ę"; Opt-x produces "ź". You'd take away my ability to type in my native language.
Introducing new modifier keys (say OptGr+e would produce "ę" but Opt-e would access the menu) would be a drastic and unwelcome change. I would equate it with changing the meaning of "Shift" when pressing number keys. It's something you just don't do to your users, no matter how much more sensible it appears to you.
Again, it's all platform conventions. When you travel to Italy, you don't bitch that nobody speaks German - even if German is standardized, and officially spoken in three different countries.
> an icon in the dock, system notifications, matching light/dark theme, etc
Textual apps will eventually support this and other OS integrations exposed by the browser. It's never going to look native, given the terminal origins. But it will be possible for them to play better with the OS. And when we add PWA support, they will have a more desktop look and feel.
SSH is an advantage when running in the terminal. In the browser the advantage is that you can deploy them where you couldn't run a web server. Think IOT, routers, lab equipment. Or just cloud servers, where you want a backend to work with the local file system.
Another advantage is development speed. Textual has a learning curve which is far less steep that a regular web stack. It allows non-web developers to build bespoke apps.
I also think that TUIs can be more attractive than GUIs in some scenarios. Not because they look better, but you can build UIs that are snappy and keyboard driven. TUIs are a more natural fit for that kind of interface.
> [...] you can build UIs that are snappy and keyboard driven.
That's not an advantage that is exclusive to TUIs; after all, you're running your TUI inside a graphical application that emulates a terminal. (Unless you're rocking an actual VT102, in which case I bow down to you.)
In fact there's an entire class of applications that are extremely snappy and keyboard driven, by their very nature: games.
Load time tolerance is proportional to session length and focus required. People put up with GTA V Online taking tens of minutes to load the "micro"transaction store contents [1] because when they sit down to play online they are going to spend a couple hours in near 100% focus.
Compare with a mobile game, even a 3D one, where sessions are usually in the tens of minutes themselves, a lot more effort is spent optimising load times and it can be a competitive advantage.
Lagrange cold-starts in roughly a second on my M1 Mac. That's roughly the same as Terminal.app on the same hardware.
Games tend to take a lot of time to start up because they need to preload heavyweight data, such as textures, models, maps, sounds, video. You don't need any of that in a desktop application.
TUIs are a really great way to mix GUIs into CLI "suites." For example, one may usually use homebrew through a CLI, but one can imagine that certain workflows with homebrew might be better served through a TUI than a CLI. Perhaps browsing and filtering the list of packages -- though the specific workflow isn't important for this example. In that case, homebrew can ship a CLI that handes most or all workflows, plus one or more TUI workflows to enhance some subset of those workflows. Because you're already interacting with it in a terminal, it's a pretty smooth transition to give you the rich TUI experience when appropriate. The same could not be said of a native application.
The only thing I think you're missing is that a browser is kind of a clunky dependency. It really wants you to use it for a certain kind of thing and although they can be tricked into doing other things, you and your users are always going to feel a bit of pressure to conform to the norms of the modern web.
So if you're trying to avoid the mess that is the web these days, a TUI is really your whole "everything else" for things that don't CLI well. So it's nice to be able to put it in a browser later on without having had to build it there in the first place.
There is an easy way to write GUI apps that both look good and do not boil down to the lowest common denominator of 80s state-of-the-art: use something like SDL/GLFW, with an immediate mode UI toolkit on top.
Lagrange (https://gmi.skyjake.fi/lagrange/) is a beautiful app that (despite my ideological purism in favoring more "native" solutions) I find perfectly usable and pleasant to use.
That’s why I developed a CLI brower ( https://sr.ht/~lioploum/offpunk/ ). When reading the title, I clicked hoping to see some alternatives or innovative solution to browse the web from a terminal.
Turns out it’s the opposite : putting a terminal in a web browser.
The point of textual is, from what I can tell, making simple and fast UIs very easy to develop. Running in a terminal also makes keyboard input easy, so why reinvent that wheel?
Being able to turn that into a website with little extra work is nice and I think the web absolutely needs a bit more simplicity.
> I guess someone out there has a use case where they need to run this over an SSH session?
Raises hand.
I write a lot of internal tools for musicians (primarily film composers), many of which are primarily local but will be web-based once I put together the rest of the pieces of the pipeline. Being able to run the same interface as a local desktop app, or as a web app, or over an SSH connection, is a huge selling point to me.
Plus, I just honestly love the look. It's clean and simple with high information density. Totally my cup of tea.
IMO Textual/Rich is one of the coolest projects to come out in recent years.
IMO, you're not missing much if anything. It's definitely a cool project and I've spent some time tinkering with it, but feels a lot more like an art project trying to evoke a certain aesthetic rather than something that actually makes writing terminal-based programs easier.
>rather than something that actually makes writing terminal-based programs easier
Are there alternate options you'd recommend? I've used Textual to create a few interactive apps and found it a pleasing experience. In my case, I didn't need it to be a TUI, but it was much easier to reason about compared to tkinter.
I think the best "TUI" I used was the Bloomberg Terminal.
The command box, and being able to reach any function with 4 chars, was the best part imho. I grant it's not a true TUI, as they do pixel level rendering, but the keyboard driven experience and aesthetic certainly makes it a contender
I'm happy to see this stage come to fruition!
What I really can't wait for is to be able to build static websites with this, but to me, that's a really good first step towards that.
I am looking forward to this. I have a TUI game in development called coolmaths to practice maths problems. The limitation of TUI is that I can run it on my local machine or ship a software. With GUI, I am assuming that I can host it somewhere and point the URL to the players. It will becomes extremely convenient to share our apps with others.
I've been developing a websocket server that lets multiple users connect to the same command-line app.
I wrote a short example [1] that exposes a TUI game on the web. In theory, hot-seat terminal games should be playable over the web with this.
My current challenge has been around refreshing the screen for late joiners. I need to save some of the ANSI escape history and replay it to clients, or ask the application to redraw itself. If anyone has ideas on how to approach this i'm all ears.
How long would it take me to learn and get proficient with something like this? I would use it for email, JIRA tickets, reading github code, using the github/gitlab UI (as a TUI).
Maybe even some google sheets.
As I type this I now realize most of this is probably not possible :(
I've been using it to build a dashboard for a web scraper with postgresql backend. Thing's it's helped with that could help you
1. Formatting tables of json from API specs
2. Keep track of growing database tables
3. Have buttons to start tasks queues
Things I've noticed are the debugging and logging experience are pretty good. You could have multiple processes dumping to different log files and grepping those.
There's a lot of formatting you can do with Python and the sister library Rich.
Have spent about 12 hours on it and it's much easier to get a UI running than say learning a flavor of the month JavaScript framework.
I suspect it has the same problem as ncurses: Not easy to learn, get proficient with, or rapidly produce something decent with.
I've been working on a project for a while that allows running any console program within it, and use text, keyboard, or mouse triggers to add a VT100 TUI, but it's uncomfortable to learn, very hard to get proficient with, and while it's possible to rapidly produce something decent, you're going to hit a hard wall producing something excellent.
The tui only really makes sense in the context of the tty terminal. I like the tui for one reason, it makes running the interface remotely via ssh effortless. Other than that they sort of suck.
Now command line interfaces... Those are pretty kick ass. I would love to see more command line interfaces on the web.
It appears that, by default, the textual-web command makes a WebSocket connection to textualize-dev.io and hosts through that. WebSocket is a session-based network protocol that allows for long connections with bidirectional traffic.
In this case, the computer running textual-web initiates the connection, so there’s no need to listen for new incoming connections. But in all other respects, it’s acting like a server. The code is still running on your machine with all the permissions it had when you started it, so... be careful.
Well... In the early days if modern IT (Xerox Alto and so on) the UIs where textual-centered GUIs, actually connected as needed. It's curious that they are still more advanced than 2023 tech...
Too young to remember MS-DOS TUI masterpieces like Norton Commander or Borland Turbo Pascal? For a large segment of serious software that didn't need fancy graphics there was no justification for the reduced performance, dubious hardware compatibility and more complex programming of a proper GUI.
I so want to use this to emulate a Turbo Pascal-like UI for my SaaS. But I think it will confuse my users and also the OpenAI staff probably wouldn't even approve my plugin if it looked like that.
A similar thing is in use for mainframe applications to this very day to try to "modernize" them.
Basically fancy screen-scrapers that turn everything into forms and menus and fields, they do have their use. (In the industrial case, it's for things like text entry and mainframe applications to be made more "touchscreen friendly" for modern industrial devices and modernize them to the modern metal you have to use.)
I'm not sure how they're rendering in the browser. But if the TUI is rendered to DOM elements and not canvas/webgl, perhaps it could be useful to use a browser automation tool like Playwright to run test suites against the TUI. If your project involves CLIs and web apps interacting with one another, you could exercise them and assert their behavior within the same test framework.
lol, I've been working on a TUI of late around CUE and feel myself slipping towards IDE territory. Not helping is that the underlying tcell library has functions specifically for supporting vim & emacs modes
.jpg){kind=link}
Personally I would cut complex animations (i.e. sub-character) and only have a single size monospace font. I would rip out CSS and go for maximum compatibility. (If something exists like that, please let me know!)
Another feature that could be cool is to have this served (optionally) via telnet. I would also make it be able to produce static content (with a subset of features).