I am wondering if someone is embedding a browser in their plugins and apps?
Does someone use Chromium Embedded Framework or something similar for their UI?
How bad is plugin editor creation time?
What do you do on mobile (iOS specifically, where you’re not allowed to embed an external browser inside your app)? Any showstopper issues with the stock browser views?
Do users mind the extra memory and extra CPU load? (I highly doubt that anyone is really noticing this, but I want to know what your actual experience is if possible)
What other issues do you hit with this approach.
Any help is much appreciated. Thanks.
@adamski I have a vague recollection of reading a post from you about web UI, but I can’t really find it in the forum… any chance you build your UI in web?
It looks like it could be possible on mac but last time I checked the windows embedded web view was pretty useless, using an ancient internet explorer. Things might be different with edge on windows 10. Personally I would not like to bloat my plug-ins with CEF, which is such a large project it’s a nightmare to compile. It might be possible to use libchromiumcontent builds from the electron project, but it still a big dependency with a whole host of potential issues, that would probably make me lose the will to live.
For an app it’s different, and there are a lot of nice things based on electron these days and lots of potential for quickly hacking things together using web frameworks (although I think I’m gonna have to buy a new computer because they’re so heavy)
I think for desktop it’s not a terrible option as long as you keep the number of browser instances down. The Chromium architecture means a new process per browser tab (roughly, it’s a bit more complicated). This means you can have 2-4 processes for just a simple enough app. So that’s a hundred or so megs RAM gone before you even consider your app itself. Then you have all the inter-process communication that goes with that. It’s also quite painful to debug.
I think it’s an over engineered solution in general and there are a good few articles on electron and how hungry it is. Also questions about Atom’s performance etc. It is much quicker to write a UI with web technologies though. That might be worth the cost.
Agree with @olilarkin here. I spent years as a web dev and don’t know why anyone would choose to build a desktop UI with web tools (although I know the tools have got a lot better in recent years). I can see why Electron seems attractive, but from my knowledge is also a total resource hog.
I’ve done quite a bit using React Native, which is totally different - its a javascript framework for interacting with native mobile API’s.
Web UI is a lot easier to build. That’s my reason to look into this.
While I enjoy having control, I definitely do not enjoy having to worry about the low-level rendering of my fonts. Yesterday I read a pretty extensive topic here on the forum why can’t a bouncing ball be animated with JUCE. And there are many more (and bigger) reasons - styling (although it has it’s caveats), CSS is so much more flexible and easier than the LookAndFeel approach; connecting models and views is a lot more advanced in most web UI frameworks than what we have in JUCE (MVC and MVVM are ubiquitous within the web UI → in JUCE some controls have attachments…) etc. etc.
Don’t get me wrong, I love JUCE - it solves a huge amount of problems for me and it’s well written and supported. But at the same time I can’t really say UI is its strong suit. Simply put, I feel like I am spending way too much time building my UI, than I should.
Correct me if I’m wrong, but the way I see it is - web UI can look just as good, can be just as performant animation/transition-wise (you can use Canvas or WebGL or even SVG, which is fully supported in the browser) and development time is cut by a significant amount.
So “why not” explore that option? That’s what I am trying to determine in this thread. So far, I see mobile as being the real PITA of this approach. 100MB of extra RAM on the desktop… that doesn’t really seem like a huge issue IMHO.
Late response. I do agree, using LnF methods to set component styles can be abrasive, e.g. just setting a larger font size for a TextButton requires subclassing a LookAndFeel class and finding the correct method to override.
Compared to declarative methods, such as HTML/CSS or React’s JSX and StyleSheet objects, where you would simply set the styles to override for each element. Personally I think an optimum solution may lie in having an XML based layout system within JUCE, I know @jules has mentioned his interest in this in the past.
As others have mentioned, the extra memory/performance cost may well outweigh development time using Web UI, so in that case, why not!
If mobile is an issue for you, React Native might be the answer. I have been working with React Native and JUCE for a while now, and although it adds some complication to the project, it does allow fully native apps along with Juce components.
A couple of additional benefits worth mentioning are portability of UI code to cloud projects and the ability to use artists-turned-web-stylists to work on the UI when you need to expand your team. I work on both apps and web pages with content that appears on both so it eliminates a duplication of effort for me. CEF or Edge support would help a lot as Explorer does not support JavaScript “classes” (you have to use the manual syntax).
There is an implementation on top of DPF here . Linux version includes two web view flavors, WebKitGTK and CEF. Yes, the latter is massive and adds >1Gb to the plugin size.
Example real plugin here . Web is overkill for tiny UIs like this reverb example but comes with its own set of advantages.
Web UIs are the way to go IMO, for the flexibility and power they offer, if you plan on building a complex plugin. Output Arcade is a great example of this.
