oDot

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?

Indeed! Please check out this project I made to basically make the server an extension of the front end by having it reply to client side ui messages:

https://github.com/weedonandscott/omnimessage

I work in Gleam on my software and it's a treat. I use the FFI for JS libraries all the time.

Yes.

https://nestful.app used to be TS + Vue but it's almost entirely Gleam now, with Lustre used for state management and only the views being Vue templates. Those will also be migrated away for a fully Lustre solution.

Blog posts:

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

I moved to Gleam with all of my projects and am not going back. The language is fantastic but really the most impactful are the coding paradigms that it enables, especially the actor model and especially on the front end (The Elm Architecture)

I was talking just about the look of it, and not the interactivity. UX's familiarity bar is much higher than than the UI one.

Edit: And even for UX -- I am confident in saying we did not reach max usability yet. Some people (me included) are willing to take the risk of (some) unfamiliarity for potential innovation

Interestingly, I am looking for the exact opposite -- I don't want my products looking anything like other websites.

The democratization of skill-learning is splendid, but boy is it hard to find a non cookie-cutter designer these days.

If you know anyone ..

Ofek (at) nestful dot app

Thanks for the heads up about paperlater!

AI is indeed a crucial part in solving the two most difficult challenges -- typesetting and curation, although we'll probably do things that don't scale for a little while before fully automating.