Front ends for Julia codebases?

The relationship to lisp is actually one reason I like Julia. I’ve always wanted to use a lisp, but my scientific work has always been Python or R. But Julia has real potential if I can ever manage to convince myself to use it for a work project.

Though I have to admit I sometimes wish I could use S-expressions. I kinda picture Julia as lisp with arrays instead of lists.

Back on the topic of GUIs I feel like there’s a real gap in simple GUI tools for scientists. Sometimes I want to share a tool with a non-programmer for whom Jupyter is too much but for which Excel is not enough. (Or perhaps I just want to avoid writing VBA :slight_smile:)

I guess the best analogy is I’d like to see something like the Python argparse library for GUIs. You specify the parameters and their types and you get. A minimal GUI for entering those. If I get the time, I’ll look at Blink or GTK and see if I could write up something. If I do I’ll post a separate thread since I suspect there’s interest in this forum.

3 Likes

R can be lisp-y

1 Like

I forgot about that. I remember finding it interesting that many R classes are just lists underneath. Although I haven’t used R in a while, I remember finding it limiting for general purpose programming in ways that I feel Python and Julia don’t have. Though that may just be that I learned Python second so I had a better foundation.

I do miss the ESS emacs package. It made for an elegant interactive environment. Although Juno recovers a lot of that for me with its good REPL integration. Once I figure out how to do debugging in Juno I feel it will be super productive.

1 Like
using Debugger

@enter fn()
2 Likes

if you like to use the GUI, you’d only need Juno.@enter.

4 Likes

So I made some more progress on the Java front end. But am quickly realizing… Writing an interface between Java and Julia is going to be pretty painful.

So like any other insane person I decided to see what the julia ecosystem had, literally if I could click on drawn shapes in a plot/canvas/whatever I’d be able to make everything in pure Julia. Even if it was clunky. It just doesn’t exist, but there are open issues, one made by me, (https://github.com/JuliaGizmos/GtkReactive.jl/issues/58, https://github.com/JuliaGizmos/Interact.jl/issues/345) to maybe try to get the ball rolling.

In the mean time, because I know 0 JS, I am going to go back to Java land and try to write the least painful, most generic interface I can to Julia… My journey for doing that will be documented here: Running Julia from JAVA? What is crazier? (just incase someone is following along in the future and desperate to see what people have done).

1 Like

How is it done… Do you write a GUI that controls Julia code, or the opposite, you write Julia code that controls a GUI?

1 Like

How is it done… Do you write a GUI that controls Julia code, or the opposite, you write Julia code that controls a GUI?

Under the architecture/framework I’m describing, I wouldn’t say that one controls the other. You have a Julia module that contains some code that you want to make available via a GUI so you write an API with Genie to expose your functions via an HTTP request. Your front end GUI simply makes calls to this API, gets a response back, and then does what it wants with it.

I’ll try to put together a simple example in the next couple of days and I’ll post a link here.

2 Likes

I put together a trivial example and deployed it to Heroku. The link is here:

https://julia-api-client.herokuapp.com

Heroku’s free dynos go into sleep mode when not being used so it will take long to load and because the API is running on a separate dyno, the first time you try to compute an answer it will take long. Subsequent computations should be fast. It’s obviously not very attractive but I may make it a little nicer in the future if folks are interested in seeing this kind of thing.

The front end is a simple Vue.js web app that calls the API, which is written in Julia with Genie.jl. The API sets up a single route /addxy that calls a function addxy and returns the response to the client as a json object.

I’ll post the code to GitHub and add more detailed explanation when I get back home. I’ll update this response with links to the API repo and the client repo as well.

4 Likes

Once we get good binary compilation support then it will be better

1 Like

CImgui is pretty nice. A interesting approach might be to give Dart/Flutter a go. They recently added support for wrapping C native code, but the native app build process is still maturing (unless you’re on a mac). They already have GLFW integrated, multiple backend support, a nice drawing library via Skia, and I believe they’re roadmapping to get GTK support as well. Maybe not an immediate solution, but something to watch since they’re developing rapidly.

My arm chair prediction is that we may see a substantial shift from traditional GUI libraries to the cross-platform kits like ReasonML/Revery and Dart/Flutter in the next year or two…

2 Likes

Alright, the links to the API and Client are here:

The link to the app is here (the client and API are running on free dynos which go to sleep when not in use so it will take a while to load the client and then when you try to compute an answer it will call the API, which will have to wake up. It all works, just be patient and try it a couple of times :wink:)

https://julia-api-client.herokuapp.com/

Keep in mind that most of these files are generated automatically (it looks like an overwhelming amount of code but this is like an hour’s worth of work). In the case of the client, the Vue CLI does the vast majority of the heavy lifting and for the Julia API, I used PkgTemplates.jl and also copied the procfile and example from this repo:

The basic flow is this:

For the API, there is a file called Sum.jl which contains a single function addxy(x::Int64,y::Int64). There is a second file called ApiExample.jl which includes Sum.jl so that it has access to the addxy function. I then set up a route /addxy which is available to the world at https://julia-api-example.herokuapp.com/addxy. You can test this yourself by including query string parameters in the url like this:

https://julia-api-example.herokuapp.com/addxy?x=4&y=6

Go ahead and click on that and modify the x and y values and you’ll see the actual JSON object returned by the server.

The front end, which can be written with whatever you want, was written with Vue.js. It simply has two inputs that are used to construct the above URL (it just swaps out the x and y values with whatever you put into the inputs). It then makes the call to the URL and waits for a response from the server and displays the value on the web page.

Easy, right? :wink:

7 Likes

Thanks so much for doing this! Really clean example - the JS is still beyond me though.

Couple questions…

Is there any noticeble problem with passing large hunks of data around in this way? Say someone has a plot with many lines on it, and I don’t know, 5,000 points per line? Can this type of interface accommodate that? Or is it better to save it to disk/DB pass the reference and have JS load it?

@wsphillips I looked into Dart/Flutter on your suggestion. It seems pretty convenient! At least some of the JS things I don’t know are handled - the barrier to entry seems less high for a novice/solo dev. Still seems pretty high though.

I guess I am surprised that the UI/UX JS scene hasn’t found a way to make these things more convenient. I’m finding writing in Java to be painless right now. Sure I am comfortable in Java, but the workflow is much more concrete. Going from something like a simple input form to an interactive widget with visual components seems exponential in complexity for JS, while in Java it’s really not. Something I can do solo in Java in 2-3 days I feel might take a month with multiple developers if done in JS. Granted they’d do the job right, and I’m hacking away! I could be reading the wrong tutorials, being ignorant, or many other things. I remember when Flash ruled the internet - although those were dark times - it was trivial to stand up something a little fancy. Now JS is king, and I can’t seem to find my way over the bump.

The react paradigm for Julia UI’s is so easy and intuitive, GTK in python is cake, java event listeners are easy peasy. The abstraction involved in JS, workflow across languages, interfaces, etc is not a landscape I know. Nor do I see clear explanations of how people operate in this world.

Sorry if this is long winded I’m just trying to explain where I am at with this.

There is a heavy reliance on JS at the moment, but Dart and ReasonML are both trying to be a universal UX language for web, mobile, native etc. that isn’t necessarily a costume for JS. I don’t know how well it will spill over outside of the regular “app” world of mobile and web, but I think it could be a less painful alternative to what’s out there today. For instance, the guys working on https://github.com/revery-ui/revery are betting pretty hard it will be great for native UI design.

In the end, I guess it depends on how you plan to run your code and what level of integration you need between the GUI and the Julia bits doing the work. REST API > gRPC/custom socket API > local/in process API in terms of ease of implementation. For what its worth, I was able to get Interact and Blink running in a few minutes to do some hardware control and had zero issues with lag, although anytime you load Electron stuff it takes its time on initial launch. YMMV.

1 Like

I had a horrible time with blink(I think it was blink) via port forwarding the UI from a remote server. I spent two weeks writing a multiwindow app it worked beautifully and all the data ops were scaling fine. I deployed it to a remote system(which was somewhat locked down) and it was unusable :(. In that case I don’t think blink was the issue, any other solution would have done the same but bad memories.

The real issue is, interactivity with custom widgets isn’t a reality right now. At least I haven’t seen it done and don’t know how to do it. Click and drag is essential to me. Deployment in pure Julia is the most ideal situation, it just can’t suit my needs so I’m balancing the two language problem and trying to keep it from being a 4-5 language problem. I’m a hobbyist working a day job, so I can’t possibly keep up with 2-3 bleeding edge tools undergoing frequent changes while trying to learn toooo many new things (even though I desperately wish I could).

Great suggestions and down to earth experiences. We could probably all benefit from some examples if you have time to make/share some :). It’s threads like these that save peoples brains when they are at their wits end trying to make something work out.

Probably wouldn’t want to transmit GBs of data as JSON over HTTP but I suppose there are no hard and fast rules around that. As far as plotting lots of data points in JS, as long as you use canvas instead of SVG, you should be fine.

2 Likes

So my explorations lead me to Java where I had a lot of success but it’s just too much work right now. I realized, real fast, that all of my efforts were in wrapping code, and that really staying in Julia is the best way forward. Unfortunately, the only way to do that is via CimGui, which I’m struggling to get running and so are other’s.

So I may look into cross compatible C/C++ libraries that I can write quick hooks for to see how painful it all is. My guess is, extraordinairily painful, but you never know…

I have stupid question… Is the whole reason JS is used for front end because web browsers tend to be standardized, and the only open path for progress was either the JVM or JS? I learned about ELM which is actually really freaking cool and easy! But I don’t know if I could put it into Julia, or if that’s even possible. It seems like it could be a decent fit, but shit I don’t know anymore.

Vue.js seems great, but it seems to crazy to me to write code, that hooks into something that writes code that hooks into something that writes code that hooks into something in a web browser. There’s no way thats gonna be performant or stable, ever. Nor will it be easy to make custom widgets… So I’m spinning my gears again

I think most people like the big 3 - Angular, React, or Vue. I stumbled upon Svelte recently and it looks really interesting:

It’s quite easy to expose Julia backend as a REST service. I have tried HTTP.jl before and it works reasonably well.

2 Likes

We need a Julia based front end

4 Likes