I’m working on a project where I need to create a standalone application that will allow users to download, install, (activate if possible), update, and remove various plugins from a company.
I’m aiming for something similar to Native Instruments’ Native Access.
I was considering building this as an Electron project, but I’d like some insights into this type of development.
Would Electron, as a cross-platform framework, be sufficient for this?
What pitfalls should I watch out for?
I don’t believe JUCE is designed for this purpose, but are there parts of JUCE that could assist with such functionality that I may have overlooked?
I’ve been in the same position and decided to just use JUCE, as it really does have all the tools that are needed, they just have to be applied with the system-specific knowledge, i.e. where do plugins go, how to handle failed downloads, how to manage local resources and determine update semantics, and so on. The advantage to building a plugins-manager/installer in JUCE is, of course, a reduction in cyclomatic complexity …
Thanks for the insight, @ibisum
Just curious, was the UI part challenging?
I’m used to working with UI in languages/frameworks designed for it (like Swift, Kotlin, or React), so I was wondering if building an application in C++ slowed down development.
Also, have you tested the new WebView UI features in JUCE?
Using it would still get the benefices of JUCE api but will provide a more UI friendly development tool.
I also worked on two plugin installers, both were JUCE. I have lot of of juce experience, so even if another framework is faster to develop, it’s probably not faster for me. And I can reuse code between my plugin and installer app. The binaries are also pretty small once compiled, other frameworks I tried have a lot bigger footprint.
Interesting, @RolandMR! Could you share more about the types of code you reused in this project?
Aside from specific location and local resource management (anything related to file management), as mentioned by @ibisum, I don’t see much else that could be reused.
As far as using JUCE to build a normal UI application, I find it pleasant and comfortable to be honest.
The valueTreeState mechanism, broadcasting changes across variant modules is a lot more fun to deal with than MVC, and most of the UI elements that you could need are all available (see for example DemoRunner, in case you haven’t…)
Plus, having a single codebase which targets all the platforms is a dream. A lot more fun to wrangle than Qt, and a lot less borked-finger-burning than HTML/CSS, which I just utterly despise for personal reasons anyway …
As above JUCE should have everything you need, although I think this is one area where a WebView might be a sensible choice for the UI (or at least part of it) if it’s already something you’re familiar with.
One word of caution though I would personally still have the actual products wrapped in OS specific installers i.e. pkg/dmg/inno setup/etc. the reason being that
From an accessibility stand point they are far more familiar when dealing with the actual installation process
Larger facilities such as a university can benefit from these installers when trying to deploy a product to multiple devices
What’s your experience with using a webview?
Did you run into any issues?
Would you do the same today ?
Also, I’m sorry to be unaware but what’s the benefit of using Choc ? (I’ve never use it).
@ibisum I totally get your point.
My main concern is the complexity of using C++ for UI development.
I share your reservations about Qt. For me, using Qt would mean getting the worst of both worlds not benefiting from JUCE’s features and still being stuck with C++ for the UI.
I completely agree with you on the frustration with HTML/CSS. Honestly, I feel the same way, but I’ve found that using React for UI has been faster and easier than doing it in C++.
Thanks for the insights!
Since you’re familiar with it, are there any issues I should know about before starting a GUI app with JUCE Webview?
For example, are there any OS-specific bugs or potential difficulties?
At this stage, I’m considering using JUCE Webview with React (is that possible?), aiming to keep the GUI development process smooth.
Also, I completely agree with your points about installation options.
I’ll still maintain OS-specific installers because the project requires them, but I also plan to include an installer app, giving clients the flexibility to choose what suits them best
It just worked perfectly for my use case.
I connect in C++ couple of JS callback to know which installer should I download and install on the system, verify disk space, handle DL temp dir. The web dev can just do his stuff to manage which product are own by which user.
Choc was just a way to get those JS callback handling in Juce 7. Not required anymore as Juce 8 supports it natively.
Our custom LookAndFeel classes. Our network communication code, so the installer can register licensees before the plugin is run. Our custom dialog box class. Our grid view class. etc.
Thanks, @otristan. I see!
It’s really interesting, as using a JS codebase would allow my client to choose between a JS or JUCE developer in the future, depending on their budget.
@RolandMR, what you created with JUCE is truly impressive!
I understand now why it was the right choice, given that you already had those classes set up. For me, however, I’d need to build everything from scratch for a single project.
Yes, its a joke, I know there are plenty of great reasons to build JS apps, and have had many wonderful billable hours debugging JS dependencies…
The point is though, that while JUCE might have sharper edges, it has a lot greater power and potential for a better user experience.
However, do not discount the fact that - at least for MacOS - no matter whether you write your brand installer front-end tool in JS or JUCE, you still need to provide end-users with the ability to install your plugins from a .pkg (MacOS package file) - making this available alongside whatever else you do, installer-wise, means that you keep institutional users of your plugins happy, also.
With .pkg files, as mentioned above, administrators of large fleets of audio workstations can easily automate the setup and install of your plugin - this is vital for schools, where they often blow away the entire installation on their systems at the end of each semester, in order to practice sane software hygiene … and then of course need to automate the installation of plugins, and hopefully yours as well are in that set.
I completely agree with you about the .pkg file it’s already set up and working smoothly.
My client, however, wants an additional installer app, so I’m exploring all the possible options.
After reading all the fantastic responses here, it seems there’s no definitive approach for building a GUI frontend app right now.
Both JS and JUCE have their pros and cons, with no hard limitations on either side.
It seems the choice really comes down to using “whichever one you’re most comfortable with”
Yes, that’s exactly what I had in mind for an installer app, one that downloads plugins and places them in the correct location.
Since I’m not aware of an app like this, is there another mechanism for this kind of app?
Sorry if I misunderstood your last message. When you said, ‘so this is not black or white,’ I thought you were suggesting there might be another way to install the plugin with an Installer app besides just downloading the .dmg and installing it.
I won’t jump on it 
Yes, its a joke, I know there are plenty of great reasons to build JS apps, and have had many wonderful billable hours debugging JS dependencies…