Personal observations while learning to work with ply

[FireUnderTheMountain]

I know it can be hard to figure out how people connect with a project where you aren't gathering telemetry, so I thought I'd drop by with my primary notes from the last two weeks of building with ply. They're mildly refined to explain myself better at some points, so if the read choppily, that's why.

--

Design:

Offering setup instructions only using plyx and not manual setup makes the project seem shady, in light of all the recent supply chain attacks.

Paradigm for usage in a larger app not clear from examples. Examples on site just don't really go in depth on ins-and-outs of their features or how I might use them in complicated or spectacular ways.

In a more well-known framework I wouldn't expect examples to be in-depth because you have hundreds of AI generated sites talking about how EXCITING everything is and look at this cool thing you can do AND our fifty popup ads!!!!!

I guess that's just extra legwork you have to do when you're trying to grow from nothing; be your own marketer, marketing to devs.

Many frameworks are opinionated enough that just by looking at them you can tell how they're "supposed" to be used. Others relay their design goals in what they make easy. I haven't been able to discern anything from what ply gives me.

Except... I have discerned ply isn't meant to be the final UI solution - There's no default theme or even any theme system to establish consistent defaults; no buildable components to make reuse easy. I am GUESSING that's what the CustomElementData on ply is for, but there's not really a hint of that via design or in the getting-started docs on the main site.

This contradicts the site's advertising: "Beautiful apps in Rust. Cross-platform. Dead simple." - But the beauty would 100% come from me and not ply, and it's certainly not dead simple to use.

Ultimately, I just don't feel like I'm growing more comfortable with ply even as I use it more. I don't feel like I'm sliding into a mindset where I'll just "get it" like I have in the past with other UI frameworks.

Ply reveals all macroquad features, but it's unclear when I should be using them vs expecting a ply wrapper.

--

Documentation:

I'm not sure what to do with CustomElementData. Am I supposed to put my global UiState object into it? What's the benefit over a global store struct passed around?

Inline documentation for padding doesn't divulge order of directions for number-only provisions. ie (/* top?? */ 0, /* right?? */ 1, 2, 3)

macros (grow, fit...) should have better inline documentation to explain what they accomplish, since the docs examples encourage using them all the time

--

Misc:

How do I get app window size??

screen flashing when window resize

The hover example at https://plyx.iz.rs/docs/interactivity/ suggests you have to use an extra child, otherwise irrelevant, just to check if the element is hovered. When coding that myself, it feels jank, like there really should be a better way.

Nested on-hover effects feel strange to try to implement. How do I know what the "top layer" hovered element is? Parent doesn't have a hovered_and_no_child_hovered() to indicate its the top-level element hovered.

So I have to grab the pointer_over_ids() vec and manually parse all ids against a LUT for "reacts to hover" + "stop propogation", and then preserve that information on my own to feedback it into the render loop? I thought the point of ply over macroquad was to make me not have to implement all the gears that turn the proverbial wheel.

It also doesn't work to bake into the render loop if checked during render, given the parent -> child order of rendering.

No control of siblings in singular way - IE set all heights to uniform based on height of biggest. Set all children same color. Only can iterate, but then have to go back and re-iterate if future child is biggest. So how do you do such a thing besides processing a second render tree that you parse entirely before the real render routine, Shadow DOM style?

[TheRedDeveloper]

@FireUnderTheMountain

setup instructions

plyx is recommended. It's needed anyway, if you want to build for non-desktop platforms. The setup is quite obvious and shown on getting-started all that is not shown is that obviously there's ply-engine in the dependencies. It's all quite self explanatory.

Examples on site just don't really go in depth

That's why they are examples. If you need anything specific you can ask me. For example in #58 I show how you can make a dropdown. You can decide how you want to make your app. The paradigm is upto you: object oriented, functional, procedural, reactive or everything in between, it's the freedom of Rust. I'm not sure if I want to publish the source of my game. I obviously would like to make money with it. I have some other things and apps I made with ply-engine, I might post somewhere, but they are not good examples, except the breakout one. I have one where I asked Opus to make a nice application to show off Ply's features, it made a app called Focus Forge, that's quite nice and has markdown with image fetching. I tried getting it to port the entire Claude Code to Ply with many many parallel subagents, but I cancelled that after 2 days, because Anthropic's codebase was just too big. I have a lot of vibe coded projects like that, I don't really want to publish. I'll add the breakout example to the website when 1.2 rolls around (hopefully start of May).

be your own marketer

Marketing is hard.

many frameworks are opinionated enough

Ply is an open book. It's HTML, not bootstrap. You can put your own opinions onto it. Only fundamental best practices apply.

final UI solution

There is no such thing as final.

I am GUESSING that's what the CustomElementData on ply is for

It's just a little thing that outputs a render command with the data on the element and you can handle that render command, you can basically tag whatever you want on there. There's that one person from #1, that wants to have a browser in their UI engine (for some reason). They could make it so that the CustomElementData is a URL. Then they'll get a call with wherever that custom data is and they can make JavaScript put an iframe or something. Now that I'm saying this, I think this might be a really niche usecase and maybe I should remove it, because it's just so confusing.

it's certainly not dead simple to use

I disagree. Compared to other UI frameworks, and the sheer complexity of customizing pre-built components differently and not being able to customize them to your liking. You end up between either making them yourself or getting into a total mess. Over time we'll probably have built some respectable amount of components you can actually customize to your liking without ending up in a mess. This gives ultimate reusablility. CSS/JavaScript/HTML for example has 3 languages with thousands of keywords, attributes, operations, functions, etc and people put things like tailwind on top of that so they have even more things to memorize, and they decide that the language they've all decided to use is actually not good enough so they put TypeScript on top of that, and then they'll use some sort of framework like React, where now they are mixing two of the languages together and getting completely new horrible concepts like useEffect, then they decide that that wasn't enough and they mix it with native code (React Native), now let me remind you that you are using 6 languages (CSS, JavaScript, HTML, Tailwind, TypeScript, JSX/TSX, C++), and apparently this is how we make apps now and why it takes 10s after pressing Win to open the windows start menu. Yes this is not how all apps must be, Warp open sourced on Tuesday, revealing they wrote their own UI engine, which I found really amusing.

I don't feel like I'm sliding into a mindset where I'll just "get it"

I'm sorry to hear that. Ply is quite different, maybe that's the reason.

it's unclear when I should be using [macroquad]

I don't use macroquad anywhere besides audio actually and that's in the docs. If something is not in the docs, I probably don't use it. I'm not here to parent you tho.

I'm not sure what to do with CustomElementData

Explained earlier. What you'll likely do with CustomElementData is: Nothing. You don't need to pass anything into it. There is no benefit except when you want something really niche and custom.

Inline documentation for padding doesn't divulge order of directions for number-only provisions

That's too many weird words. I have no idea what you're talking about. If you want the order for padding it's (top, right, bottom, left) which is CSS order.

macros (grow, fit...) should have better inline documentation to explain what they accomplish, since the docs examples encourage using them all the time

I don't think you can go without them. They are needed because they are variadic (varying number of parameters) and let you name parameters, this lets you leave out details. I think they are documented well enough.

How do I get app window size??

screen_width() and screen_height().

screen flashing when window resize

Miniquad's fault.

it feels jank

#67 fixes this. Coming in 1.2.

How do I know what the "top layer" hovered element is?

It's the last element in pointer_over_ids() I think. I had a long issue on this #55. You can make the child element floating to capture the pointer in the child, so it won't propagate to the parent. The new .capture() #61, will let you just capture the pointer without making the child float.

manually parse all ids against a LUT for "reacts to hover"

I'm not even sure what you're talking about here but you definitely won't have to do that.

no control of siblings

Put a variable on all siblings, use a loop or reuse a styling function.

Only can iterate, but then have to go back and re-iterate if future child is biggest

I have no idea what you're talking about. I think you want to make a scroll container the size of the biggest child or something like that. I think you'll have to precompute the size there. I have no idea what the use case for this would be. I'm just very confused here. If you're looking for growing children you can use grow!(), if you're looking to fit around children you can use fit!().

So how do you do such a thing besides processing a second render tree that you parse entirely before the real render routine, Shadow DOM style?

I have completely lost you now. What are we doing?