As a counterpoint, being primarily a web developer (although I did Windows desktop apps with Delphi in the 90s) I hard time doing UI with JUCE.
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.
JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework.
Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital.
These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with great results.
Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!").
My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.
But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.