Termimad author here: I’m always a bit afraid, when I see the popularity of this crate, that it might be undue and that people may lose time trying to use it when it’s probably not the tool they need.
Termimad isn’t a full-fledged TUI framework. It can be used to build TUIs (I made broot, bacon, safecloset, etc. with it), but if you want to quickly build a TUI and compose UI components and widgets, you’ll probably find it much easier to choose a real TUI framework (e.g. ratatui).
Termimad isn’t a generic Markdown viewer either. Markdown is mainly used as a language for the developer to describe parts of the interface—especially rich text—inside a TUI. People interested in rendering arbitrary Markdown files will find that it lacks features such as image rendering.
We don't know exactly why nature can't do otherwise, but any complex brain has to sleep.
Some animals, mainly sharks which can't stop or they would be asphyxied, deal with that by having kind of 2 brains which are never both sleeping at the same time.
Imagine you have a big enum in Rust, for example an Error, with a dozen or more variants.
When maintaining related code, for example a Display implementation, or routing to some behaviors, it's sometimes much easier when it's alpha sorted: you immediately see what's implemented or not.
That's when you can hit the codesort shortcut to have this specific list (enum variants, match arms, etc.) sorted.
Imagine you need to attach to some records a bag of data which you always fully need or not. This bag may have a tree structure, which is expensive to deal with in a relational model. An example would be the JSON configuration of a component/client/whatever. In such a case, trying to fit this bag of data in a relational model would be inefficient.
Those bags of data are usually called "documents". And a lot of systems need a way to store them along relational data.
If you're just storing and retrieving those documents, without any query, you don't need JSONB, a simple blob is enough.
If you sometimes need to do some queries, especially free queries (you want all component whose configuration has some property), then JSONB is suitable as it lets you do the filtering in the database.
> If you sometimes need to do some queries, especially free queries (you want all component whose configuration has some property), then JSONB is suitable as it lets you do the filtering in the database.
This feels like a slippery slope into a denormalised mess though. Before you know it your whole client record is a document and you’re using Postgres as a NoSQL database
Such use cases may not be quite as optimized as relational usecases, but they should be possible. If you are doing that then perhaps a different database would be nicer or faster for that scenario, but again not PostgreSQL's concern.
If the PostgreSQL devs were relational purists they would never have added special support for querying JSON.
An application may be better served with a properly normalized schema, or it might not. That is a choice for the application developers to make.
In practice competent developers should quickly realize if they went too nosql when a relational approach would provide benefits (Like if multiple "documents" need to reference consistent shared
data, or if json query performance is not good enough) and normalize as needed to get those advantages.
So long as the application does not contain random sql queries scattered everywhere (and doesnt treat its database as a sort of API for external access) then database refactoring is not impossible. Indeed the difficulty is often overestimated. It is seldom fun work, and tends to be a bit of a slog, and require more extensive testing before pushing to prod, but that happens.
reply