@happybeing Yeah, that loop was what I was wondering about. Now, if the data being looped over is a literal (completely immutable), then I could see Svelte compile it into each permutation. It's when things inside of it can change dynamically that makes me unsure how Svelte handles that, if I'm even understanding what Svelte is doing as a compilation step to begin with
I will need to take some more time to look at it. I've been suffering from a particularly bad episode of burnout from my day job, so I haven't even had any chance to really look into the macro stuff such as
quote for reading existing ASTs, and outputting new ASTs, unfortunately.
On a more serious note, GUI development is hard and Rust was neither created by Google, Apple, Microsoft nor any other gigantic tech company. Some things simply take more time, if you cannot put near infinite resources into a project.
Mozilla's a pretty decent-sized company, and its only product is Firefox which happens to be a GUI app. It looks like Mozilla's already succeeded in porting parts of Firefox's engines over to Rust, so there might be a slight change that Mozilla will want to weight in, and eventually write a UI for Rust, so that its entire app stack is in Rust.
That said, they might find it beneficial to stick with Qt (I believe they're using Qt anyway) as their multi-platform app GUI framework of choice. Qt's notorious for its licensing, but maybe LGPL2 has made it easier on them.
@jkboyce I agree with GUI frameworks being difficult. Personally, I've always thought that text rendering is difficult. I think the text rendering might actually be the hardest part about this framework; even over efficient renders of the layout.
@s3bk I think I was looking at Pathfinder for rendering SVGs and fonts at one point if my theoretical framework ever got to that point. I'm not totally sure how it goes about rendering in OpenGL because it has a built-in state machine, and it's difficult to write your own rendering code with other libs co-existing if it acts as a black box API as your own code interacting with OpenGL can't reliably know what state the context's FSM is in without making a bunch of expensive queries.
@MartinKavik I haven't had the chance to touch Elm, although I worked at a company that used it. I've been meaning to check it out, and see how it compares to reactive component libraries such as
yew, etc. It looks like Seed is essentially the "seed" to your web app's architecture that's written in Rust, and emits JS, inspired by Elm's concepts. I would like to check Seed out more, but at this time, I've got a lot on my plate for this major deadline for our company's product launch, currently working through the biggest burnout episode I've ever survived (I'm getting old), and somehow haven't managed to write a lick of macro code in Rust thanks to work and burnout. I have read a little here and there about macros though, but I haven't lived it yet, lol.
I must say, this thread is a major success: it answers my question, and does look like there's a demand for Rust-based GUIs out there. It looks like I was wrong about the lack of GUI in the Rust space as there are quite a few exciting projects that are much more mature than I thought. In fact, my project "idea" is late to the game if anything. Sadly, the more I learn about macros, the more it looks like I'm just trying to build a statically/strongly-typed version of
LitElement which might not be the answer in Rust.