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?

It's much easier to fix flutter layout issues than CSS on web in my experience.

The web almost got constraint based layout. Well maybe almost is too strong, but it was a candidate. CCSS.

We got tables and floats instead.

The premise is a bit off. Flutter was never just width/height: the model is min/max box constraints. The core rule is: constraints go down, sizes come up, parent sets position.

Row and Column are just layout algorithms built on that same model, not separate engines added later. GridView uses the sliver system internally, but still doesn't require anything like CSS Grid's general layout model. The render API is open enough for custom layouts too, so packages like https://pub.dev/packages/boxy build directly on it

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

Mikrotik's FOSS story is as bad.

Do expand

They don't release / host source code unless formally asked

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

hi i work at wafer. no the margins are lower averaging at about ~40%. utilization is one of the highest order bits in determining margins here, yes.

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.

Any favorite gleam projects to learn from?

I've always admired the direction gleam was heading in, and the community is awesome. But with gradual typing now in elixir, I'm weighing whether or not gleam offers anything special enough to get me spending time there instead of just using elixir.

I wrote a book about setting up a small gleam project, covers organization of the project in general. A draft is live at https://escherize.com/gleam-katas

Beautiful. Will definitely work through this.

I am currently working through https://lukwol.github.io/gleam-guide/ and it's fun so far as a ReasonML/Elm/elixir enjoyer

Looks sweet. Where did you even find that?

Gleam, lustre, and tauri? Amazing

Lustre is great

How are you liking Gleam and Lustre? What went particularly well or badly?

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

Soooo... lib ghostty supports the kitty (but not sixel) terminal image format.

Cool idea!

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

I agree! I have kept an eye on Elm for many years, I think the simplicity and architecture is great, but the language itself never clicked for me.

Then I was made aware of Lustre[1], an Elm inspired web framework in Gleam. I have done two small projects in it now and I really enjoy working with both Lustre and Gleam.

[1] https://github.com/lustre-labs/lustre

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

Is this because Elm forces you to separate the model computations from the view computations, which then lets you compose the model shape in one place and the view shape in the other, or some other property of the framework that I'm not aware of?

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

Vue provides a computed feature that acts as a buffer layer between the view and the state, so the view and the state are not necessarily strictly bound

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

Very nice

Could I use OpenTUI Core with this?

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

You should be able to. We forked OpenTUI in order to avoid having to shim a bunch of native stuff. I'd like to make it compatible - email me at hi@cjroth.com if you find a way or want any help making it work

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