The 2023 JUCE User Survey is available here:
This is your opportunity, even if you are not currently a JUCE user, to influence the direction of JUCE development.
The survey will remain open until the 15th July 2023. When we have finished collecting the responses we will publish a summary on the JUCE forum, alongside some details of our roadmap.
Please let us know what you think of JUCE. We look forward to hearing from you.
Best wishes,
The JUCE Team
Hello everyone.
Here are the results from the survey.
The data from this question shows a very broad spread of survey respondents across the world, and it’s difficult to present it in ways that are more useful than a simple summary. The top countries are:
US: 23%
UK: 13%
Germany: 11%
France: 8%
Canada: 5%
We had to do a bit of data processing for this. Despite the question description stating that not ranking a topic at all would count as a zero, almost everyone ranked everything with a minimum score of one. Next time we won’t rely upon the question description and we’ll have the scale go from 0 → 5 rather than 1 → 5. All 1 → 5 responses were shifted to being 0 → 4, and the scores from the few people who only ranked only the topics they thought were important (0 → 5) had their scores multiplied by 0.8.
Even with everyone’s responses being adjusted to start from zero, we can see that there are significant numbers of people voting for all of the proposed topics. Whilst there is a single clear winner for the Indie and Pro segments, everything else is less distinct.
There are a few general themes from this question.
The most mentioned topics are WebAssembly support and JUCE GUIs in embedded browsers. For the people who mentioned this we have some good news - a substantial piece of JUCE 8 will be the ability to interact with the javascript and DOM of JUCE’s web views, giving JUCE users the ability to do all of their GUI work in HTML, CSS, and JS. Once we have this in place we will look at WebAssembly support too.
There were also several requests for a system that would provide a declarative JUCE UI. This would be a massive chunk of work with a near constant ongoing maintenance burden, which we have already experimented with in previous versions of the Projucer. Once we have JUCE GUIs in embedded browsers released we will have taken a big step towards the declarative benefits of modern web GUI frameworks.
All other topics were spread pretty thinly, though we can address a few of them quickly here. We are improving font handling in JUCE 8, including better unicode support and fallback fonts. Sample accurate automation improvements will be bundled into our ongoing MIDI 2.0 support work. A useful CMake exporter from the Projucer is probably much more work than you expect and the team’s time is almost certainly better spent elsewhere.
Finally, lots of people requested that we get rid of most private sections of the classes in the API, and avoid using things like the pimpl idiom. Though I can understand the motivation for suggesting this, it would bring JUCE development itself to a standstill. We absolutely rely upon the ability to change the implementation details of JUCE’s functionality to fix bugs and keep on top of changes in the underlying operating systems. This is a fundamental principle of sustainable API development. This isn’t to say that we can never open up some of our classes a little more, but we have to think long and hard before making anything public. Once something is public, it, and any other indirect behaviours it invokes, cannot be changed without us having to intoduce a breaking change (see Hyrum’s Law). If there’s a part of JUCE that you think needs to be public please give us very specific feedback about what functionality you need.
MinGW on Windows has always been awkward for us to support, and even before this survey we had decided to remove the Code::Blocks exporter from the Projucer. Very occasionally people new to JUCE would attempt to use Code::Blocks with its bundled MinGW on Windows and end up frustrated. The bundled version of MinGW is now also old enough to cause compatibility problems with the rest of JUCE, and using MinGW directly with CMake on Linux is overall an easier build system to navigate. At the moment the Code::Blocks exporter is deprecated, and it will be removed in JUCE 8.
* Xcode 14.1 is currently the minimum required to submit to the iOS app store
* iOS 11 is currently the oldest deployment target possible on the App Store
Why do people need the latest version of JUCE to be compaible with iOS versions older than iOS 11? If you are using the latest version of JUCE then you must be creating new versions of iOS software. If these new versions cannot be distributed on the App Store it’s not obvious how they are being used. Internal development on old hardware? Please let us know!
* Google Play will require existing apps to target API level 31 from August 31, 2023, to remain discoverable
** Google Play will require new apps to target API level 33 from August 31, 2023
We’re very pleased with these results, particularly since the majority of the non-positive responses were qualified by people describing problems with C++ or other tooling rather than JUCE itself. We tried to avoid some of this by specifying “C++ framework” in the question, but it wasn’t very effective. JUCE is, fundamentally, a C++ framework, and if you don’t yet have a reasonable grasp of C++ then using JUCE will be a challenge.
This is another very satisfying result. The JUCE team really cares about both the framework and the people using it, and getting feedback like this is delightful.
As with the “JUCE is an easy C++ framework to use” responses a lot of the negative scores here are from people frustrated that they can’t make a plug-in without also having a working knowledge of C++. Given that JUCE is a C++ framework some knowledge of C++ feels like a reasonable starting requirement. Removing those scores makes the results look even better, but we’ve kept them in. Other than a couple of people asking us to switch to Rust there were no other responses suggesting an alternate programming language.
We’re already working on some JUCE 8 features that were highlighted in the survey.
The most prominent of these is a new way of creating GUIs based on the built-in webviews provided by each platform we support. The intention here is that by providing infrastructure around the creation of the webview and bindings to the javascript running inside it, the development of UI elements can take place entirely within the webview. Not only does this enable interoperability with industry-standard design tools, it also removes the requirement for GUIs to be written in C++.
We’re also working on adding much broader text rendering and shaping support. This would be text that runs in different directions, the ability to handle all different character sets, better fallback font support, emojis and more. It’s a huge bit of work, but one that makes JUCE much more flexible.
Support for MIDI 2.0 is another thing currently underway. We’re aiming to add the ability to communicate with MIDI 2.0 devices and parse capability inquiry messages to JUCE “soon” as part of JUCE 7, but the schedule depends on our progress.
There are also some upcoming bits of work, the most exciting of which is a thorough evaluation of the work @matt has been doing on a new Direct2D-based Windows renderer. You can see more detail here:
We will also be investigating sample-accurate plug-in parameter automation as part of the work of adding new MIDI 2.0 compatibility with plug-in APIs.
In addition to having webviews-within-JUCE we will also look at JUCE-within-webviews. A large part of the framework is already compatible with WebAssembly and we will work to make web browsers an officially supported deployment target.
Congratulations! This is in deed a very satisfying survey result. You deserve it!
Those struggling to wrap their head around C++ should consider JUCE a perfect opportunity to get started.
I have been working with dozens of languages in my long career, including very obscure and exotic ones, but never really got around to using C++ for large scale projects. It was JUCE that finally taught me to embrace C++ and appreciate its strengths and powers (and tolerate its syntactic ugliness).
If JUCE isn’t a door opener to C++, what is?
Great to hear. What about replacing OpenGL with Metal/Vulkan? Are there any ideas about this?
A very insightful survey. Thanks for the hard work, as always, JUCE team!
I imagine with the new web-frontend infrastructure the recomendation would be to use something like WebGPU.
Could you comment on how you see the future of the existing GUI capabilities developing alongside the improved support for web front-ends? Especially in relation to the GUI Widgets requested features - do you see the web front-end as an oppotunity to address all of those in one go?
Congrats! It shows you guys are doing a great job.
As @ans wrote, JUCE is good for beginners to C++ so I would support improving the docs & online tutorials to help those who find it harder to grasp the usage by reading the code of an example.
I am also happy to hear about the improved text support, so JUCE can be more accessible to those with non-latin-based languages.
Keep up the good work!
Thanks for sharing the survey results, and the roadmap. Looking forward to the text rendering improvements, MIDI 2, and web targets. I really appreciate the continuous improvements from the JUCE team. Thanks so much!
Gonna make me blush. : )
Metal/Vulkan is not a viable cross-platform replacement for OpenGL.
At the moment it is possible to have some custom OpenGL in JUCE software that will render identically on all major platforms that JUCE supports, and this fits well with with write-once-run-everywhere behaviour of the rest of the JUCE framework. Unfortunately the deprecation of native OpenGL on Apple platforms means that this will not continue to be the case forever.
If you are currently using custom OpenGL with JUCE then moving to WebGL within a webview is likely to be the least friction path to maintaining cross-platform support. WebGPU is the next generation web standard for interacting with GPU and this will probably be a better target in the future when support becomes more widespread, with source transformation tools to convert your WebGL code to WebGPU.
There will be people who cannot use an embedded browser, but the native options to continue using a single shader language are pretty restrictive.
There’s Google’s Dawn, that provides a native C++ interface to WebGPU, but this is both a very heavy dependency and is changing fairly frequently.
There’s Google’s ANGLE, that provides a translation later from OpenGL ES to the native backends on each platform, but again it’s a whopper of a dependency.
For both Dawn and ANGLE we would need to increase our minimum supported deployment targets significantly. If I don’t sound convincing about the complexity of having these projects as dependencies please attempt to build them yourselves and think about what a workable integration with JUCE would look like. We’re currently watching both projects and evaluating them again every few months.
Another option is using Vulkan with MoltenVK for Apple platforms. Whilst it’s possible to get this working, it certainly isn’t straightforward. The real blocker here may not even be the complexities of MoltenVK - Vulkan driver stability on older Windows machines is very unpredictable, to the point where Vulkan loses much of its promise as a viable write-once-run-everywhere target.
What we should be able to offer, however, is the ability to continue using a mixture of OpenGL/Metal to render JUCE components. Our OpenGL rendering pipeline is not complex, and we could implement the Metal equivalent at short notice. So if you are using JUCE’s existing OpenGL renderer to accelerate the drawing of JUCE components only (no explicit OpenGL code within you project) then this could continue to happen using Metal when Apple eventually removes OpenGL from its platforms.
Yes. Although we will continue to develop our non-webview GUI functionality as we don’t want to force a major rewrite upon everyone, I think that webview-based GUIs are ultimately the future. Moving away from C++ for GUI work will make the need for JUCE-provided widgets much less pressing, but we will see how things evolve. Initially we will provide something along the lines of plug-in parameter attachments, where there is an easy way to link a C++ plug-in parameter with a value in JavaScript, but styling sliders and buttons will be left to the user.
I get the impression from Apple that they think Metal performance is better than OpenGL performance, and we know deprecation usually comes before removal without any additional notice, so since you say you could implement ways to render Juce components using metal at short notice would that be something to prioritise? Moving our UIs to web-based tech is cool and likely the future, but this is not a simple job for years of in-service releases. If Apple does drop OpenGL, this will probably be coming with the lag of a WWDC-macOS release, which isn’t actually much time for a lot of developers many of whom won’t want to rush out fixes when Juce’s dev tip has made its way to a fully tested release. Having that available sooner rather than as a response to whenever it gets dropped would probably be quite attractive, leaning on known deprecated technologies is not ideal in Apple land. Thanks for your consideration.
@t0m Thanks for your extensive answer. I am mainly concerned about the Apple move to deprecate OpenGL. I am writing my GUI in juce using my own shaders and so forth. So when the time comes and on Mac there will be no more OpenGL it would be great if i can transfer my OpenGL implementation to Metal as i am not using juce Gui widgets for painting.
Initially we will provide something along the lines of plug-in parameter attachments, where there is an easy way to link a C++ plug-in parameter with a value in JavaScript
This really sounds great! Could you estimate a time-frame when this feature will be available?
It will be part of JUCE 8, but we’re not yet in a position where we could announce even an approximate release date.
I’d like to pick up on the responses to the value question. It appears very few of us think Juce is poor value, so perhaps there is scope for a price rise. Not just for the sake of it because that sucks, but because it could mean more people being employed so that more work can be done. I’m not complaining about the quality, but obviously more and better work can be done with more resources, and I actually think the price is quite low compared to many other business expenses that contribute far less to my output.
I want to object the view that more resources always mean more output.
IMHO the juce team is at a sweet spot in size, the recent additions seem from my outside perspective to be a great one, we can see very thorrough work being done.
I think the current price point is just right to allow developers making their first plugin with juce as well as being useful for established companies.
