Live data from Hacker News

A year of building for the terminal

textual.textualize.io

21–30 of 95 posts

Re: A year of building for the terminal

#21
post #16

Earlier quoted context omitted.

I'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server? So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView. This would be a really interesting toolkit for building real-time UIs for remote processes.

That's pretty much on the nose!

Ah, so that also explains the significant use of asyncio for all UI operations.

Are you also considering a "WebView" front end, a little like Electron?

Re: A year of building for the terminal

#22
post #20

How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

We were funded with Venture Capital. Which means full-time developers for the foreseeable future. But its worth pointing out that both projects existed for a long time before funding.

And how do they see themselves getting money back? Is there a plan for paid subscriptions or something in the future?

Not trying to be snarky or anything -- generally curious! I love the project.

Re: A year of building for the terminal

#23

How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

I think ultimately, the idea is some sort of freemium model where the TUI is free, but usage as a web UI is will cost extra(?)

Re: A year of building for the terminal

#24
It's not quite ready yet, but I'm writing something similar for Rust [0]. It's much more similar to React (with respect to components, and hooks), and the DSL is inspired by SwiftUI.

Disclaimer: Version 0.6.x has a pretty severe flaw where the constraints around hook order are way too strict, and this also prevents conditional renders [1]. I'm working on a full rewrite which will be released as version 0.7.0, which exists on github as a branch right now [2]. Docs also exist for an alpha version of 0.7.0 [3].

[0]: https://docs.rs/intuitive/latest/intuitive/

[1]: https://github.com/enricozb/intuitive/issues/4

[2]: https://github.com/enricozb/intuitive/tree/0.7.0

[3]: https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html

Re: A year of building for the terminal

#25

The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever. It all hinges not necessarily on more fanciness in the terminal, but on the availability of data to work o…

> The terminal still has and always will have great potential as the glue that holds all computing together. Users refine their skill in a few, interoperable and flexible standard tools, and any command that turns out to be useful can immediately be part of a script that automates and simplifies this task forever.

But the topic here is exactly the sort of framework whose apps are not particularly easily scriptable and integratable in typical shell-driven workflows.

Re: A year of building for the terminal

#27
Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right?

Now I am not someone who would ask creators not to build something new because something like it already exists. By all means build new stuff and create new tools. It providers options and choice for user. So I fully support work like this.

But I also ponder about user behavior. New users who flock to the modern terminal tools need to learn new keybindings, new shortcuts, new workflows. Yet they are willing to invest that time in learning these modern terminal tools. But many of the same users are averse to investing that time in Emacs. Why is that? What explains this?

EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? My comment is an honest question. You can post comments and explain if you disagree with my premise. But downvoting isn't helping me learn anything.

Re: A year of building for the terminal

#28
post #22
post #20

Earlier quoted context omitted.

We were funded with Venture Capital. Which means full-time developers for the foreseeable future. But its worth pointing out that both projects existed for a long time before funding.

And how do they see themselves getting money back? Is there a plan for paid subscriptions or something in the future? Not trying to be snarky or anything -- generally curious! I love the project.

At some point next year, we will be working on a web service that puts Textual apps online. Completely opt-in, but it will allow you to serve Textual apps on the fly. There are various add-on services, like authentication, we can charge for. Plus a generous free tier.

Re: A year of building for the terminal

#29
post #16

Earlier quoted context omitted.

That's pretty much on the nose!

Ah, so that also explains the significant use of asyncio for all UI operations. Are you also considering a "WebView" front end, a little like Electron?

We were! I figured if we don't do it somebody else will. But there is already a project to bundle a Textual app with a working browser. So you can distribute Textual apps as a binary.

Re: A year of building for the terminal

#30
post #23

How does Textualize make money? I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components. Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.

I think ultimately, the idea is some sort of freemium model where the TUI is free, but usage as a web UI is will cost extra(?)

Kind of, yeah. But there will also be a generous free tier.
Post reply on HN