oDot

This post is about a TypeScript repo, which is what I commented on. It may as well be a necessity since Pi is using a JS runtime as well. It has nothing to do with JetBrains and everything to do with the codebase in the link.

It also has nothing to do with TUI vs. GUI, since my comment addressed both (anecdotally).

If anything, your mentioning of their performance work is exactly my point.

I do code -- the app logic. I also am well aware of what the infrastructure code does, I just don't type any of it myself.

Even if I wanted not to code it I couldn't. LLMs are still incapable of creating code up to any decent standard.

Also, while I do the get the joy of programming, we sometimes forget to focus on the user. You being happy to have typed the whole thing once, and have it run everywhere via the magic of browsers may not be the best strategy if this means your user's lap will be overheating.

In the end as much as I like coding I would prefer my users' experience to be the best it can be. LLM assisted code delivers this better and faster than hand-typing it all (which in turn is better than completely vibecoding it)

I do not get the appeal of web-based GUIs now that we have LLMs.

Migrating my screenwriting software[0] from OpenTUI to Roc thought me what were once rough edges that take a lot of time are now just a prompt away from a solution.

It now uses 10x less RAM, bundle is half the size, and my initial implementation is 700-800 fps for scrolling and 200 fps for writing.

Granted, a TUI is less complex than a full-blown GUI, but I built a Roc Iced platform just as easily that abstracted Iced flux away

[0]: https://blisswriter.app/

Thank you for Squirrel as well!

The Gleam community is generally very very nice. I maintain about 200k lines of Gleam[0][1], and they have generally accommodated even my stupidest posts on Discord.

The language itself is as welcoming. Even LLMs are less cranky and output nicer code, not having to deal with React.

[0]: https://blisswriter.app/

[1]: https://nestful.app/

I appreciate the aside. Interesting observation

Does anyone know if the original promise of their simple layout model proved itself?

IIRC, the Flutter team mentioned how using just width/height constraints is enough to represent all relevant layouts. This sounds very nice, being so much simpler than Flexbox and miles ahead of CSS Grid ergonomics.

Did it live up to the promise or did they expand the model with Flex/Grid/etc?

Do expand

What's the state of FOSS licensing compliance? Have they repented?

Do these providers have 80+% gross margins or is something eating into them? Maybe utilization?

This is a bit of an "XY Problem" question.

I have migrated all my code to Gleam, FE and BE, Bun, browser, and BEAM.

Claude knows much less about Gleam than it does about Javascript or React. However the constraints of Gleam and its Elm inspired framework Lustre are so strong, Claude gives me much better results.

The only difference is I need to adjust my initial guidance.

Yep, that's about it. I am making a TUI for non-techies, packing it with Ghostty, and sending it to non-techies to use:

https://github.com/weedonandscott/trolley

They should just use Trolley[0] which will ship their TUI inside Ghostty.

[0]: https://github.com/weedonandscott/trolley

TUIs are so nice.

Please consider using Trolley to package this for non-technical users:

https://github.com/weedonandscott/trolley

You should try Gleam. I'm using it in production to great delight:

https://blisswriter.app/

https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and

Computed is only a concept because you need a band-aid for that lack of separation. You can read more about my efforts ditching Vue here:

https://blog.nestful.app/s/the-tech-behind-nestful

Yes. In the Elm architecture it is possible (and ergonomic) to model your state separately from the view

The problems OP tries to address are unfortunately a deep design flaw in mainstream frameworks like React and Vue. This is due to 2 properties they have:

1. They marry view hierarchy to state hierarchy

2. They make it very ergonomic to put state in components

I've been through this endless times. There are significant ways to reduce this friction, but in the end there's a tight ceiling.

This is why this kind of work feels like chasing a moving target. You always end up ruining something inherent to the framework in a pursuit to avoid the tons of footguns it's susceptible to.

It's also why I moved to Gleam and Lustre (elm architecture) and bid those PITAs farewell

Thanks. Will be a while before I could give this a shot...

Very nice

Could I use OpenTUI Core with this?

I'd like to replace the hero at https://blisswriter.app with the actual app

Thanks.

This was written for my own screenwriting software, which is now in private alpha. It works quite nicely for an alpha

https://blisswriter.app

I use libghostty for Trolley[0], which packages TUIs as desktop apps, like Electron does for web apps.

It really is quite an amazing piece of software. I just wrapped it in a useful GUI and a bundle/package CLI and it just works. Even on Windows. Kudos to the Ghostty developers.

[0] https://github.com/weedonandscott/trolley

I used to run a site that compares prices[0]. Not only is the ecosystem pull to the cloud strong, but many developers today look at bare metal as downright daunting.

Not sure where that fear comes from. Cloud challenges can be as or more complex than bare metal ones.

[0]: https://baremetalsavings.com/

It launches whatever TUI you give it with just window decorations. Here's the Linux one with one the debugging examples I use

https://imgur.com/St8O8Gm

Shameless related plug for my recent project Trolley, which lets you package a TUI as a desktop app, for your non-technical users or otherwise:

https://github.com/weedonandscott/trolley

I think it may actually work. It's just that I only have a VM to test it on, and it does not support OpenGL. I got it to compile and run, but it crashed on that VM limitation.

Feel free to open issues in the repo, I'll find a way to get a Windows machine if there's interest.

You can also email me at `trolley [at] wands [dot] is`

Yes, that's it. It came about after writing a small TUI for a friend to back up their Vimeo library. They liked the simplicity and speed but not having to use the shell. Didn't want to install Ghostty either.

So here we are

I find the decay of human connections an interesting problem to solve. I used to have an app that encouraged meeting in person by utilizing friends inviting other friends[0]. This solved many app-problems like correct matching and safety.

Didn't catch on, though. Setting up events turned out to be too prohibitive. If this interests anyone feel free to contact me at contact [at] eventful [dot] is

[0] https://blog.eventful.is/p/the-perfect-dating-app

I'm the author of Trolley[0] (Electron for TUIs).

It was so easy to get the terminal functionality going with `libghostty`. Most time was spent building the functionality around it.

Thanks for making it.

[0]: https://github.com/weedonandscott/trolley

I read somewhere, but can't remember where, that a major reason those APUs aren't as efficient as the Apple ones is a conscious decision to share the architecture with Epyc and therefore accept worse efficiency at lower wattage as a tradeoff.

Can someone confirm/refute that?