This also exists outside of pluto, and is not too difficult in either GLMakie.jl or Interact.jl
For those times when one needs just a quick couple of sliders and buttons, one old-fashioned possibility is GtkServer.jl.
Jumping back on this argument and the interaction with GUIs, when I first heard of julia, Iāve partially been convinced by its compatibility advertisement : knowing that julia comes late in the game with respect to python or other languages, it was made to be composed with other languages.
However, except for the example linked in my previous post, there does not seem to be much work on an interface with .NET.
For me itās really a pity. .NET has a lot of cool features for GUIs, which julia lacks almost completely, and on the other hand, .NET lacks the scientific side of julia (though being a general-purpose language).
2 Likes
Just a note, when you change something in Pluto, it only updates things that are dependent on the thing you changed.
Kind of harping on the web interface idea, I think that if Julia is going to be taken as a serious general programming language instead of a niche language, there needs to be the ability to create stand alone apps. This means that if developers are forced into using a web interface for a UI we will be limiting the development of stand alone apps.
Being an Evolutionary Biologist, I can see the need to create a non-web based UI. Most scientists working in this realm donāt want to deal with command line. Anyone doing modeling in this realm wants to see what happens with the model under changing conditions, which is the fundamental basis of Ecology/Evolution research. If this can be done in an interactive UI that is fantastic, and to tie it to a internet connection adds a level of complexity to field research, you may not be in an area that has service or the possibility to connect without a several hours of travel. Can it be used locally? Sure but what kind of configurations would you have to make to the browser? What needs to be done when service is available, what other unforseen circumstances can occur, etc. Remember you may be hours from civilization. To just include a UI with the app it is ready to go out of the box is really the way to go for this field in my opinion.
2 Likes
Internet browsers can run without an active internet connection.
Sure but what kind of configurations would you have to make to the browser?
None.
What needs to be done when service is available, what other unforseen circumstances can occur, ā¦
Well, the same applies to any desktop UI.
2 Likes
Iāve been experimenting with building Blazor apps using C# for the UI and standing up a rest api in Julia using Oxygen.jl. I have very little c# or UI knowledge and itās been working well so far.
3 Likes
While I understand what it is that you are saying, and while I largely agree, I can see circumstances and have experienced circumstances where there have been incompatabilities or issues that a non developer couldnāt solve or wonāt solve in the field. I guess what I am saying is that the more self-contained and robust something is in the field the less one has to worry about. A web browser is simply not the answer to every situation.
As I mentioned earlier, but perhaps not explicitly enough, essentially anything that is meant to work in a browser can work inside a QT GUI with one simple widget (browser) stretched across the entire window. Making it indistinguishable from a local app. With added bonus of multi os compatibility and more importantly, having all the ui side pretty much for āfreeā
Iām not advocating for web based, just saying it is a viable option.
Having said all that, as a scientist I often really donāt care about the beautifulness of the UI, I just need buttons, axes, input fields, etc. So web graphics is a huge overkill for strictly scientific work, especially if it adds development time which is counterproductive to fast interactive modeling.
3 Likes
Well, what Iām doing so far is to use some custom JSON RPC between julia and .NET but Iām facing the problem of portability of the code all the time.
Iām using the StructTypes package to help with the marshaling.
Well i do not want to diverge too far from the original theme of this threade, but my most recent attempt to improve my approach is to use JSONRPC.jl . Since itās the base of the VSCode extension and should be able to handle anything thrown at it, I guess it should work for my use casesā¦
My two cents, as someone who isnāt currently developing UIs but has been an eager observer for a whileā¦
The trajectory of both mobile and desktop apps is toward browser-like WebViews anyway (e.g. modern desktop apps like VSCode, Discord, Signal, and Microsoft Teams are developed using Electronjs). This allows you to do your frontend/UI development only once in easy languages like HTML/CSS/JavaScript, and have it run on many, many platforms (anything that can run a browser) with little fuss.
The current Julia wrapper is Electron.jl.
Edit: Apparently Blink.jl is the Julia wrapper.
After Google poured so many billions into making JavaScript run fast with their V8 engine, and with HTML5+CSS3 and modern hardware, there isnāt much reason to avoid HTML/CSS/JS for desktop app development. If youāve ever run the ādesktop appā version of TradingView, which is really just a wrapper for their browser app which hides the browser interface, youāll see that JavaScript can be surprisingly performant. Not as performant as Julia of course, but plenty for UIs.
I know itās programmer heresy, as these werenāt even considered āreal languagesā twenty years ago, and knowing them didnāt make you a āreal programmer.ā But here we are. The modern way to do ārealā full desktop app development, without having to worry about hardware and OS compatibility, is to do it in HTML; to do otherwise is a waste of time.
And if you donāt want to touch those languages because you just want a simple interface for scientific experiments or something, then Interact, GLMakie, Pluto, and even IJulia are amazing.
11 Likes
Isnāt this the probable future of most GUIs?
2 Likes
AIso my two cents, I do not think people working on .NET apps would agree with you on the āanywayā. It surely is a way to handle think kind of development, but requiring electron as a dependency for basic apps is kind of problematic. When you compile apps developed in .NET you can be efficient and quite lightweight in comparison. The same goes for the web browser, though a lot of machines may have them, not all of them do (Iām going a bit far there, but itās still an additional soft w.r.t the app)
2 Likes
To @uniment Iād say that you are optimising the gui performance and portability - two things that are greatly deprioritized in scientific guis. There are different use cases for gui. The very fact that you menion āmake the gui once andā¦ā means you are looking at a completely different use case. What Iām describing cannot be achieved by javascript, so in that sense, scientific guis are not a āsimpleā version of a ārealā gui. They are actually a lot more powerful in some ways.
I would LOVE to see .net visual studio with a Julia backend. It would be magic.
2 Likes
This is certainly true, but if thereās any constant in the history of personal computers (and technology in general) for the past four decades, itās been that bloat is solved with better hardware and the march of āprogressā continues (over the protests of the technical experts who detest how inelegant and messy it has all become).
Plenty of apps that run on our phones work through WebViews, but we donāt complain over how resource-intensive Twitter is. Heck, we can now buy computers the size of postage stamps that run Linux and Python and cost less than some meals. While this trend might slow as we reach the physical limits of silicon, I donāt see much reason for it to stop (unless certain geopolitical hazards regarding islands with semi fabs play out, but then weād have bigger problems).
Itās funny and strange that Iām making this argument in a thread for a language which specifically prioritizes performance and allows us to inspect the native assembly 
but my attitude on this is specific to user interfaces, where the cost of development/engineering is usually greater than the cost of suboptimal runtime performance.
Iām curious what UI things youāre finding JavaScript unable to do.
The web-based GUI model has been dominant for a number of years and there is now a new movement, especially in the Rust community, to replace it with more efficient models.
However, developing a modern GUI system is extremely complex, and I donāt see this area as very strong for Julia in terms of community expertise or language design. Binding to one of the newer GUI toolkits seems like a better option to me rather than trying to build a native Julia one.
4 Likes
Indeed, developing full-fledged GUI systems is a lot (a lot lot) of gruntwork which is uninteresting to much of the crowd Julia has attracted. The integral under the effortĆtime curve is very large, and itās thankless work. And to top it off, a lot of it is fashion so itās a moving target.
I think web-based desktop GUIs are here to stay, despite their inefficiencies, because a) in most cases theyāre good enough, b) the need to operate consistently across platforms forced convergent evolution, so thereās relative stability in the object model and lots of support, and c) theyāre simple enough to throw a thousand script kiddies at a problem and come out with Shakespeare, so thereās a strong business interest in keeping the model alive. Or alternatively, c) theyāre simple enough for a scientist to build a half-decent UI in their spare time.
JavaScript is a horrible language, but it survives in spite of itself because itās simple and web browsers have made it a de-facto standard (a lingua franca of the internetālike how English is a lingua franca despite being a horrible language too). Itās hard to compete against things that should die but just wonāt; how do you kill a zombie? (A more important question: How can we wean the U.S. off of U.S. Customary Units and onto SI units? Iām tired of measuring mass in slugs and distances in furlongs, and the degree to which the degrees I measure disagree with other peopleās degrees is disagreeable.)
I think for a true-native Julia GUI to be well-supported, it must be tailored to meet some persistent need of scientists. Scientists all seem to all need plotting packages, so if I were to bet on what would serve as our go-to Julia GUI platform, I would bet on an interactive plotting package: GLMakie.
2 Likes
One example for the gruntwork, it was already quite a bit of work to get Makieās Textbox to work even though itās very limited in functionality. You can input some short strings or numbers, which is nice for scientific GUIs. But people are used to such a wide range of behaviors from text fields, Iāll take volunteers to implement these 
- selecting text, marking selected text with boxes
- allowing multiline text
- allowing special character input via OS widgets
- bidirectional text
- etcā¦
The selection thing would probably be the most impactful for common usage scenarios.
7 Likes