“shiny” for building GUI interfaces to packages is huge in the R world.
10 Likes
Exactly. I was going to say the same. What we need is the equivalent of Shiny for quickly building simple web GUIs/web apps around data visualization, querying the data/results or as a simple interactive report (knitr plays an important role there too and it’s integration with Shiny).
2 Likes
I’ve been asking for an “easy mode” to Genie that would be Shiny like. That would be the silver bullet in my view if paired with PackageCompiler.jl
2 Likes
Yeah, I’m really hoping to see Julia replaces unrealscript in the future. Currently, I’m just toying around with idea of using Julia as game data handler, but hopefully, convince developers to implement Julia as a scripting language for game designers. And if that happens…(probably takes years) I will make sure to post my experiences with using Julia in a game development in discourse.
(I think my comment is irrelevant to the subject of this thread. Hope this won’t clog valuable debate too much, Any curiosity regarding game development is welcome via private message. I will try my best to answer with the limited knowledge I have. 
)
if someone is deep into this – I did some idea-work a while ago
Just food for thought:
-
Python ships with Tcl/Tk and tkinter included.
-
There are other minimal GUI libraries which could be considered for Julia, e.g. Nuklear.
-
Starting from a minimal GUI library such as Nuklear, maybe it would be possible one day to rewrite all the C code in Julia through GLVisualize.jl.
For a (long) while I have put my hopes in libui and even started a wrapper of it but despite what is said in Libui’s page the last commit was not months ago but rather > 1.5 years, so I don’t trust it much either.
1 Like
Nuklear looks good. is there a Julia wrapper for it?
Not that I know of, there’s a list of bindings here.
From nuklear readme:
- Small codebase (~18kLOC)
- MIT License
If we speak about two language problem maybe rewrite it in Julia could be doable too.
And it could be nice test of general usability and maintenance superiority of Julia. 
Nuklear does look nice. Writing the whole thing as a single header file is a bit… weird. I’ve never felt that C shared libraries are so difficult that this would be be necessary or desirable.
First step with Nuklear could be binding, second step (if needed or wanted) rewriting.
That library does look quite good. Note that there is more recent work done on branches!
1 Like
Yes, but hardly convincing when one looks at the “Contribution activity” at andlabs (Pietro Gagliardi) · GitHub
I actually do not think we want to solve the n-language problem for GUI programming.
When someone wants to improve GUI programming, in mainstream/application programming languages they tend to Introduce an additional language/DSL.
Like XAML for C#/.Net, or as the JS/HTML/CSS split (Ok, I think that was more up to chance, than design).
I will also say that the only GUI worth worrying about is basically based on HTML.
Either is is a website, or it is something running in Electron etc.
Web is the future of GUI, whether we like it or not.
Thus even for local stuff one might as well run a website on localhost.
(e.g. as in jupyter)
What we really need is minimum effort to go from julia code running as a server,
to something the looks half-decent on in the browser,
and that someone with actual design skill can customise easily
I suspect this involves Page.jl/Mux.jl/HTTP.jl being using to expose a function bunch of restful end-points,
and then something on the browser that runs the javascript to do AJAX style stuff,
to talk to those end-points.
Possibly this front end can be automatically generated to some extent.
Which basically gets you something a like R’s Shiny.
(Like Shiny is basically exactly what is useful)
6 Likes
Taking HTML as inevitable for GUIs ignores mobiles (which are dominated by native apps) and also forgoes high performance.
I find GLVisualize.jl an attractive approach to GUIs, based on OpenGL, that is compatible with Julia’s high performance emphasis. This is in contrast with the “everything is web” model.
8 Likes
Taking HTML as inevitable for GUIs ignores mobiles (which are dominated by native apps) and also forgoes high performance.
My experience of mobile dev, which was admittedly very limited,
was that people were just writing webapps and either making them mobile compatible,
or using a tool that converts them to web-app (React/React-Native I think was the big one in that space).
This does indeed forgo high performance, I feel like it catches most of the low hanging fruit.
And to me that is people who are using Mathlab/Mathematica/Shiny:
“A few buttons/sliders and a plot”
Though you are right, high performance Vis is a thing, plotting thousands of points via SVG sucks.
Displaying ultra-HD medical scans, also sucks.
to me that is almost a separate thing from GUI. (almost)
1 Like
Let’s start with a sustainable Shiny-like in Julia first. I thought Escher.jl would be it but it’s kinda not up to date now. There is also Electron.jl now.
1 Like
Maybe not for immediately but next to a html/JS framework that would be wrapped in julia I think that for the nearby future a julia webframework that compiles to webassembly would be great. People think that webassembly is only good for low level static languages like C/C++, not garbage collected languages (because webassembly itself currently doesn’t provide a GC although that’s planned) but Microsoft just proved that wrong by implementing the clr in webassembly which has the added benefit that it can run directly .NET IL without compiling all the application code to webassembly (something e.g. TeaVM or Kotlin/native do in the JVM world). See A new experiment: Browser-based web apps with .NET and Blazor - .NET Blog.
See Blazor: a technical introduction for a nice technical overview.
The demo video looks really cool and impressive with good download & runtime performance. I really think this is the future of webprogramming.
1 Like
That’s very interesting! I also believe that webassembly (or another implementation of the same idea) will be the future of web programming.
Thanks for the heads-up about the M$ project!