Make a webapp framework/ecosystem as awesome as R's Shiny: a challenge to Julia's community

Weā€™ll get there.

5 Likes

My understanding is that once people start re-jiggering LLVM, JVM etc to output to WebAssembly and it is universally supported in browsers, the JavaScript domination might come to an end shockingly quickly, no? (This is a question not an assertion, I have no idea what Iā€™m talking about.)

Well, I guess that was my question though, will it really take that long? I donā€™t see why it would take that long, all you need is to write the code that does LLVM IR to WebAssembly and things start changing really, really fast right? I suppose there is the barrier of all the front end developers not necessarily wanting to jump up and change to a different language, but the front-end developers I know donā€™t particularly like JavaScript.

The Birth & Death of JavaScript

2 Likes

I see. I donā€™t have a lot of experience on this, but Iā€™d love to hear specifically what are the extra steps that are required (after the application is already done with WebIO) to set it up with Mux, how the Binder approach solves them and whether there is some tradeoff or the binder approach is just fine.

1 Like

Although I personally would love to see the death of JavaScript :nerd_face:, and have Julia ā†’ WebAssembly take over as the preeminent language of the web, unfortunately, no matter what much better options are available, I donā€™t see JS going away anytime soon - just because of the shear momentum, all the resources available (books, on-line courses, tools, coding camps, money spent to make JS run fast), and all the programmers already skilled in getting JS to do what they want, no matter whether or not they are truly happy with it.

After all (as I commented on here), COBOL and FORTRAN are still around and in heavy use :scream::joy: after nearly 60 years!

I am cautiously optimistic that WA will help level the playing field, and in addition, just as LLVM has helped spark a lot of creativity in new programming languages (such as Julia itself), WA will spark just as much creativity in new languages designed for client side web programming.

1 Like

I want to report back with some great news.

Iā€™ve been eying Predix UI for quite some time, wanting to use their components on top of Genie. If youā€™re not familiar with Predix UI, itā€™s developed by GE and they have a huge amount of high-quality UI elements implemented as Polymer components. Lots of them are focused on data science and data visualization as theyā€™re used by GE to build software for monitoring their industrial equipment. They fit perfectly into Genieā€™s view architecture as they can be represented purely as a combination of HTML elements and data - so no ugly generation of JS from Julia! :nauseated_face: Ex: Predix UI ā€“ Learn From Scratch

Whatā€™s been holding me back from pursuing this was the weird GE licensing of the code. The awesome part is that a couple of weeks ago GE started to migrate the Predix UI components over to BSD-3 and Apache licenses. (Amazing luck or maybe my constant nagging on all available channels, from Quora to Github, got them to review their licensing :blush:)

Iā€™ve now begun experimenting with building Genie + Predix UI apps. There are some hurdles, mostly related to assets management: Polymer and Predix use Bower, which is deprecated, while Genie uses the modern Webpack + Yarn combo. Plus thereā€™s gonna be some work to setup reactivity. But most of it Just Works by default and if Iā€™ll have enough time I might have a demo in a couple of months. Fingers crossed!

26 Likes

Way to go @essenciary, exciting!

I think it basically boils down to:

  • do you want a notebook?
  • or do you want a website?

As a dashboard app is a single page thing, Iā€™m guessing the easiest way to do this is through a jupyter notebook.

Binder solves the threading issue this causes by using docker boxes to house your jupyter notebooks.

Once InteractNext upgrades to the new version of WebIO thatā€™s compatible with Binder, it should remove the javascript issues (for simple stuff like sliders)

// also, I think a Jupyter app looks a lot more iconic (at this point in time) than a home-rolled bootstrap app

Iā€™m picturing something very simple: a plot, a few sliders, some check boxes, some dropdown menus and I wanted to understand how much extra effort it takes from: ā€œit works locally on WebIOā€ to ā€œit is a web app everybody can use onlineā€. Your approach seems to simplify this step drastically.

What were the drawbacks of the binder approach? For example, is the slowish page loading time due to using Binder or is it inevitable with Julia based web apps?

2 Likes

Slow page loading isnā€™t a julia thing in general. Iā€™ve written a recommendation system on top of HttpServer.jl and a small embedded webdemo application to explore the results in a web gui (the recommendation itself is meant to be used via a simple REST interface) and itā€™s lightning fast. But I just used HttpServer to process get requests and all the webpages are handwritten html (and a little javascript) directly on top of that.
Also I did load testing on the rest interface (again directly on top of HttpServer.jl) and I was pleasantly surprised how well it scaled on a simple PC with 4 cores it could easily handle hundreds of requests per second.

2 Likes

In 2019, Julia 1.x world, I found the combination of Intract+Mux relatively simply for deploying an interacting model to the web Ć -la Shiny, although the documentation of the two cited packages could still be improvedā€¦

using Interact,Plots,Mux

function myModel(p1,p2)
    xrange = collect(-50:+50)
    model = p1.*xrange .+ p2.* (xrange) .^2
    return model
end

function createLayout()
  p1s = slider(-50:50, label = "Par#1 (linear term):", value = 1)
  p2s = slider(-5:0.1:5, label = "Par#2 (quad term):", value = 1)

  mOutput = Interact.@map myModel(&p1s,&p2s)
  plt = Interact.@map plot(collect(-50:50),&mOutput, label="Model output")
  wdg = Widget(["p1" => p1s, "p2" => p2s], output = mOutput)
  @layout! wdg hbox(plt, vbox(:p1, :p2))
end

function serveLayout(port)
    try
      WebIO.webio_serve(page("/", req -> createLayout()), port)
    catch e
      if isa(e, IOError)
        # sleep and then try again
        sleep(0.1)
        serveLayout(port)
      else
        throw(e)
      end
    end
end

serveLayout(8001)

Resulting in:

Disclaimer: the code in this example is from an upcoming Apress book on Julia I am finalisingā€¦ I am a bit confusing on copyrights, but I think I can still post itā€¦

20 Likes

This is really lovely! We can definitely make something here!

Sorry for reviving this old thread, but Iā€™ve been asking that very same question on the Julia Slack, and this has led me to this thread. And the example by @sylvaticus looks tantalisingly close to the start of a good Julia equivalent to R Shiny and Dash Plotly. It looks like it mostly needs some wrapping to hide some of the technical details a data scientist does not need to know about. Is there no one interested in pursuing this further?

2 Likes

In case someone is looking at https://genieframework.github.io/Genie.jl/

1 Like

Genie is pretty heavy.

1 Like

I havenā€™t tried it yet, but this looked promising:
https://github.com/waralex/Dashboards.jl

Genie looks interesting, but it looks more like an alternative to Ruby on Rails, Flask or Django then what weā€™re looking for in this thread. In other words, itā€™s far too low-level to be usable by a data scientist like myself.

Iā€™m fully convinced that it could be used as the basis for a Julia equivalent to Shiny, but itā€™ll need a much thicker layer of abstraction than whatā€™s present at the moment. If I could, I would love to work on this, but Iā€™m a data scientist, not a developer, and Iā€™m quite new to Julia. I simply do not have the required skills.

That said, I cannot emphasise enough how much a killer app an equivalent of Shiny/Dash would be for Julia, at least in the world of data science. We thrive on the ability to quickly show the results of our analyses to our clients/businesses. Being able to build quick-and-dirty webapps even when your web development skills are limited to some generic knowledge of HTML is vital in such a world. I guarantee the existence of a Shiny/Dash like framework for Julia would accelerate adoption of Julia within data science a lot. Much more than Flux.

4 Likes

That actually looks interesting. Thanks for the link!

Seriously Interact.jl and Mux.jl is the way this will happen. We make a bunch of interfaces for models and simulations with it, and its really lightweight and flexible.

But most of the time itā€™s enough for our needs and there are other things that need a lot more work! SO I donā€™t chip in to improve it as much as I would like to.

So when you say:

Is there no one interested in pursuing this further?

That probably means itā€™s time to clone InteractBase.jl and write some code.

3 Likes