Wanted to jump back in with a few comments on this thread, starting with, I’m really glad we’re having this conversation, given the diversity of perspectives on what Julia is and/or should be here. I’m especially interested in broadening the base of users (as is being discussed in the parallel thread), and the collection of compilation/deployment/GUIs recur in those kinds of discussions. I’m pursuing some nascent work in this general area, so this thread and others like it are enlightening.
These are the people I generally support, so I fully agree here. The use case, as I refer to it, is building internal scientific, engineering, and analysis (SEA) tools for end users. (Note that this is roughly equivalent to internal tools development, though those tools generally target business/database users and are web-based. My users are technical analysts doing desktop modeling and simulation, but they typically aren’t writing low-level code. I’ve seen efforts to provide solutions in Python, but the bolt-on GUIs and deployment, not to mention performance, are problematic. I can easily see an opportunity for Julia here if we can address the issues that @uwestoehr is encountering.
GUIs… the current state of this for cross-platform development isn’t great. There was yet another timely piece today speaking to the difficult landscape here. (BTW, I’m not advocating for X-Windows and Lisp…). In this thread alone, we’ve heard about GTK, IMGUI, QT, and I’ve looked at pretty much everything else on the list at one time or another. My takeaways for Julia and GUIs for SEA are:
- There are probably a limited set of higher-level “widgets” needed for this work; providing the whole, raw toolkit isn’t necessary, but of course as illustrated here, they are available if you wanted to go that route. But, I’m not sure Julia is your best language choice in that case.
- The complexity of these toolkits, as well as the corresponding complexity of the IDEs (esp. drag and drop interface builders) for working with them isn’t necessary for building UIs for internal SEA tools, and that level of developer investment on the UI isn’t consistent with the workflow and priorities of the users, in my experience. This is why we see the rise of low-code/no-code tools in the business internal tools world (e.g. ReTool, Outsystems…)
So, frameworks and tooling for developers who support this class of users is where I think there is a sweet spot that Julia can fill. The closest existing solutions are, for example, tools integrated with MATLAB for building apps, and similarly for Mathematica. We’re not far off with Makie and Genie, which would need to be part of this solution due to their broad adoption. However, we don’t want to create another 2- (or 3- or 4-) language problem by requiring UI development to involve HTML+CSS+JS. And it all needs to be integrated with tooling that supports the kind of deployment workflow the OP presents.
I’m very interested in this thread or separately in what kinds of UIs are being built for these types of tools.
Finally,
One thing I really appreciate about the Julia community is the help offered in going after these kinds of issues, and often getting workarounds and fixes out. Trust me, having come from a development community the suppresses bad news, this is really refreshing! Looking forward to working further with everyone on this challenge.