Is anyone developing a SPA package like R/Shiny or Python/Dash?

Specific Domains Web Stack
1

I’m working on a simple climate model that I would like to put online with some nice and friendly widgets. It would be a perfect fit for a Single Page Application, especially if Julia had a package that made this as simple as Shiny for R or Dash for Python. I’m a complete webapp newbie, so doing it manually like @ChrisRackauckas isn’t on the table, at least not yet.

Is anyone already working on something similar for Julia? (Shoutout to @essenciary, developer of Genie.jl: you mentioned on Gitter last month that you might have a look at Shiny. Is this still on the map? Have you considered Dash as well?)

I think a simple webapp package like this would do wonders for evangelizing Julia. Oh incidentally, Shiny is GPL-3 and Dash is MIT licensed, so there are valuables lying around there just waiting to be stolen, hint hint … :slight_smile:

5 Likes
2

There is/was Escher.jl but I’m not sure what the current status is.

3

@shashi would know more.

4

Yes, that’s definitely on the roadmap but I can’t report any significant progress yet. I know Shiny, but Dash looks great and I’ll check it out too, thanks for the tip!

My plan is to use an existing UI toolkit and after some research, I identified 3 main options:
Syncfusion Modern HTML5 and JavaScript UI Controls Library | Syncfusion
OpenUi5 http://openui5.org/
PredixUI Predix UI – Learn From Scratch

If anybody can recommend other ones, please share.

The first 2 require generating an ungodly amount of JavaScript in order to setup and configure the UI elements - and generating JS from Julia sounds like a bad idea (if you know of any good way to do it, please comment, that would open interesting possibilities).

PredixUI looks like the best choice as the UI elements can be configured with JSON alone, providing a nice way of exchanging information between the Julia and the JS layers.

But all is not well with Predix either:
a. it uses Polymer 1 which is old and has performance problems. I followed up with the developers and they do plan to migrate it to Polymer 2 but there’s no time frame.
b. in terms of JS tooling, it uses Bower to manage dependencies, which is deprecated in favor of Yarn plus Webpack. Genie already uses Yarn and Webpack so I’m very reluctant to add Bower into the mix just to support PredixUI until it gets upgraded.
c. licensing and distribution - I don’t fully understand the PredixUI license (which is a General Electric license). But I expect this can be circumvented by simply not distributing the UI library files with Genie and providing a script to automatically download it and configure it on the dev machine. But still, I need to know for sure before committing to this approach (if anybody has a US legal background, I’d appreciate help in this regard).

So, for now, I’m playing the waiting game and hoping PredixUI will get upgraded - while focusing on the Genie core (full support for Julia v0.6 and v0.7 plus proper documentation and guides). Hopefully, by the time I’m ready with the Genie parts, PredixUI will be in a better state (it is actively developed by GE and that’s a good start).

Feedback appreciated.

3 Likes
5

I’m very glad that this is on the radar for Genie!!

I know very little about web development, but since I want to dip my toes a bit I’ve been reading up lately on UI frameworks, and I haven’t seen any mention at all of any of those three toolkits you are considering. I find that slightly concerning (but again, I’m no expert). It seems that all the buzz these days is about React and its main competitors Angular, Vue.js, Riot and many others. Have you eliminated these from consideration for some reason? If so, why?

Out of these, React seems to be the heavyweight, and this is the UI framework that Dash is built on. But I would probably be tempted to use the up-and-coming Vue.js. It supposedly has an amazing API and documentation, and it requires less boilerplate and is faster than the main competitors. Also, while there’s been a brouhaha over React’s BSD+Patents license, Vue.js has the Julia-preferred MIT license.

For technical details, the Vue.js team provide a detailed comparison with other frameworks.

6

I’m very familiar with Vue, Angular, React, etc. But they’re not the same thing. The ones I mentioned are UI components libraries - they are one level of abstraction higher up the web stack (above web frameworks).

Like you say, Dash is built on React - Predix and the others are like Dash (built on top of other libraries or frameworks), and not like React (not frameworks). Predix builds on Polymer (which is Google’s) and the others use jQuery (if I remember correctly).

I considered using Vue but my research showed that there is no mature set of UI components based on Vue. There are some early attempts, but none of them have powerful or diverse enough UI elements, especially not for data vis. One option would’ve been to mash up multiple Vue components from various developers - but that would lead to different coding styles and integration strategies. So poor quality.

PredixUI is very polished and is actively developed by a billion $ company (it’s a GE product used by them for their dashboards). And it’s running on Polymer, another actively developed project backed by a billion $ company (Google). It has a huge library of elements with everything that’s needed, from buttons to powerful data visualization (check out the time series UI component for a quick example, using D3: Predix UI – Learn From Scratch).

1 Like
7

Could all the web devs that use Julia get in a room somehow and hash through this?

This seems like an extremely opinionated project that might otherwise spawn as many packages as there are javascript frameworks

I’m not saying @essenciary, @shashi, @jobjob, and @dfdx actually get a room, but maybe a google-hangout/gitter/slack would suffice?

1 Like
8

I can’t say I do (there was a small demo, in some Github issue…); I see WebAssembly generation, rather than JS or asm.js, as the future (likely possible already), for Julia code, but interacting with JS seems still needed? asm.js interacts perfectly as just a JS subset, but I believe WebAssemly ↔ is more complicated. Just look it up (and then GC missing, Julia would probably prefer that - to provide its own).

BSD works well with MIT?! “BSD+Patents license” + MIT also I believe, while yes some disagree (Apache foundation). That stance may be overblown and not affect Julia even with:

This issue was closed (and the situation unchanged; unlike for e.g. Facebook’s Zstandard that just took out the PATENTS file - they actually had no patent on the compression standard it seems):

9

I’m quite suspicious of generating front-end components at the back-end. I’ve seen several frameworks for it throughout the years, but every time it projects ended up rewriting everything into something less coupled. Also, snippets like this from Dash:

app.layout = html.Div([
    html.H1('Stock Tickers'),
    dcc.Dropdown(
        id='my-dropdown',
        options=[
            {'label': 'Coke', 'value': 'COKE'},
            {'label': 'Tesla', 'value': 'TSLA'},
            {'label': 'Apple', 'value': 'AAPL'}
        ],
        value='COKE'
    ),
    dcc.Graph(id='my-graph')
])

makes me think that I still will have to learn front-end (or at least HTML) and also learn how to generate it from back-end.

Maybe a better way would be to create a good tutorial / example of such a dashboard built on top of existing components. A little Genie server exposing data via HTTP and an example page with a few Vue.js components should be an easy to grasp even for a complete newbie in web programming, still not locking a user to a specific framework.

Could all the web devs that use Julia get in a room somehow and hash through this?

Not sure I will be very helpful, but feel free to create a Gitter/Slack channel and ping me to join.

2 Likes
10

I doubt Dash has the best solution for specifying layout, but I’m quite attracted to the idea of being able to make simple web apps directly from Julia without writing any HTML or CSS (or at least without most of the boilerplate).

I’m sure there were skeptics who said something similar when the first compilers were introduced, but it is sometimes useful to be able to abstract away the underlying technology.

2 Likes
11

Does all the code have to be in Julia?

Maybe you could have handlebars-like files that get compiled through Julia somehow, i.e.

  • *.html.jle
  • *.css.jle
  • *.js.jle

Another idea would be to use glimmer and rely on the ecosystem for the level of abstraction you want?

Then you could somehow allow people to edit components/webpages/html+js+css on either the WebApp side or the Julia side?

edit: then you could load in different component styles (bootstrap, material design, etc) like how Plots.jl loads in different plotting libraries

12

I gave this example specifically to show that you don’t really get an abstraction layer. The html.Div is translated into HTMLs <div> tag, the H1 is a <h1> tag and Dropdown most likely translates to <select>, maybe with some styles. So I simply don’t see what you get - it is still the same HTML, just with additional layer of translation and fewer capabilities.

1 Like
13

I understood that and I agree. That’s what I meant when I said Dash might not have the best layout syntax. But even if Dash is using the same HTML structure there’s still less boilerplate.

1 Like
14

Thanks @djsegal for tagging me, I wouldn’t have seen this otherwise.

Ok here’s a bit of info about the current state of web related packages in JuliaGizmos.

WebIO

Tools to allow you to build things with html/js/css, with two-way js<–>julia communication.

Currently runs in Mux, Blink, IJulia, Atom/Juno, (probably just about anywhere that displays/outputs html/js/css from julia in future), with very minimal changes for each backend (1-2 lines of boilerplate).

It includes a DSL (adapted from Hiccup.jl) to write html:

dom"div.top-level"(
    dom"span#text1"("epic text")
)

becomes

<div class="top-level">
    <span id="text1">epic text</span>
</div>

and one for javascript (which originated in @mikeinnes’ Blink.jl). It enables this:

words1 = "I did it"
@js function doit(taskname)
    @var result = Math.random() > 0.5 ? "ok" : "bad"
    console.log($words1+": "+taskname+", which was "+result)
end

becomes

function doit(taskname){
    var result=(Math.random()>0.5) ? "ok" : "bad";
    return console.log(("I did it"+": "+taskname+", which was "+result))
}

Julia and JS syntax are not that dissimilar, and because the transpilation is built on Mike’s amazing MacroTools.jl, it’s fairly easy to add more features.

WebIO supports two-way communication between julia and js using Observables.jl. See the WebIO README for more details.

It’s not yet registered, though it probably will be within the next month, Shashi and I are just a little busy atm. Also, and requires nodejs to be installed to get started until then. Nonetheless it should be working pretty well.

Built on top of WebIO is…

Vue.jl

Basically allows you to do stuff with Vue.js - simple and cool.

Built on top of Vue.jl is the super new…

InteractNext

Which cobbles together some Vue component libraries, and gives you high-level widgets like sliders, toggle buttons, and dropdowns.

using InteractNext, Mux

power_slider = slider(0:1:9001; label="power level")

julia_updater = on(obs(power_slider)) do power
    pwrstr = power > 9000 ? "it's over 9000!!!!" : "power level is $power"
    println(pwrstr)
end

webio_serve(page("/", req -> power_slider))

That will spin up a webserver, show the slider (if you’re patient) and print stuff in the julia REPL.

If you check out the examples in the README, you can see plots (using PlotlyJS) and svgs, using the @manipulate shorthand. Some also use CSSUtil - which exports the vbox and hbox functions which allow you to tile WebIO html nodes vertically and horizontally, for simple layouts.

Everything @essenciary says here is essentially right:

there is no mature set of UI components based on Vue. There are some early attempts, but none of them have powerful or diverse enough UI elements, especially not for data vis. One option would’ve been to mash up multiple Vue components from various developers - but that would lead to different coding styles and integration strategies.

It’s not perfect but it’s a start towards enabling you to use high-level code to make web UIs in Julia.

Dash like polish/features is definitely a goal. I’m very interested in chatting to people.

Also, the package is very new, but I believe it works in at least the examples in the README and many more so please try it out and file issues furiously!

And naturally, contributions of docs and automated tests would be so very welcome! They are sorely lacking atm (though some of the Interact.jl docs are relevant), which is sad :cry: and I’m sorry.

Other thoughts

I think that a lot of what Escher enabled is now available with a combination of WebIO, Vue.jl, InteractNext and CSSUtil. @shashi has said [citation needed] that this is now the direction of focus, since Escher can only be run standalone (not in IJulia, Atom), is tied to Polymer, and is a bit large, which translates to unreliable and hard to maintain. Hopefully the combination of smaller packages should be better.

I’ve only just briefly looked at it, but Genie looks pretty sweet! @essenciary do you have thoughts about whether/where the WebIO/Vue/InteractNext stuff could fit in there?

Finally, has anyone tried out Puppeteer? I would really love to have some tests for WebIO, Vue, and InteractNext using it, or some alternative. Help! : )

6 Likes
15

All that sounds and looks absolutely amazing! I’m learning the basics as fast as I can, so I hope I can start making small contributions soon.

I don’t want to derail the nice discussion you devs are having here, but I have a quick question to @jobjob. The last example of the InteractNext.jl README says this:

I tried it and it was indeed broken. But there was a slightly simpler example of a sine curve updating based on the value of a slider on that page yesterday that seemed to work perfectly fine (I tried that one too). Why does one work and not the other?

1 Like
16

I’ve been thinking about building something like shinydashboard, as I’ve needed some basically functionality and ECharts.jl and Vega.jl are already JS/HTML rendering only. I’ve just been using Flask instead while I figure out how much time to invest in a Julia prototype.

17

Thanks for the feedback and the great ideas!

1/ I agree with what was said about writing pseudo HTML in Julia - I strongly dislike it (re @dfdx). It’s a nightmare in terms of editor support and it forces expensive back-end developers to write trivial view code that should be the job of junior web devs. It’s also not nice when what should be HTML and generate at most a warning in the browser, can generate fatal Julia errors crashing the whole app.

2/ Exactly, the code does not have to be all in Julia. On the contrary, talking about Genie at least, it is a MVC framework and I’d like the view code to stay in the view (@djsegal)

3/ Despite all the hype surrounding WebAssembly, my research made me believe it’s not ready for general production use yet. Every few months I check developments and there was not a single professional/expensive/high profile product built with it yet. (@Palli)

These reasons and a few more make me believe Predix is the best choice so far (at least as a UI toolkit for Genie). Take for example the code for rendering a Data Table component with Predix.

<px-data-table
table-data='[{"first":"Valentine","last":"Meyer","email":"valentinemeyer@scentric.com"},{"first":"Silva","last":"Alexander","email":"silvaalexander@gmail.com"},{"first":"Hopkins","last":"Wong","email":"hopkinswong@hotmail.com"},{"first":"Joe","last":"Sherman","email":"joejoe@yahoo.com"},{"first":"Jane","last":"Bartlett","email":"jane@scentric.com"}]'
language="en">
<px-data-table-column
name='first'>
</px-data-table-column>
</px-data-table>

You can check it here, it’s pretty: Predix UI – Learn From Scratch

It is “plain” HTML. Which means it fits nicely in the view layer. This in turn means proper editing tools (for HTML plus Polymer), separation of concerns, an efficient workflow for larger teams (designers edit the views, developers the models and the controllers). And it also means no parsing and evaling Julia, instead being able to use Genie’s compiled views or just pure HTML. (Of course, there is the issue of client side rendering with Polymer, but no JS framework is above client side rendering).

Equally important, the only dynamic part would have to be the JSON data within table-data so on the Julia side of things all we’d have to do is setup the corresponding Dict() and have the framework take care of sending it down the pipe.

My vision is also that at some point we’ll also have a visual builder so that writing Dicts and view files by hand won’t be necessary for simple apps. Just drag-drop the component, use a UI to configure it, bind it to a data source and it’s done! Think Microsoft’s Visual Studio.

This architecture is probably not the right fit for all the stacks that were mentioned in this thread, but it does fit beautifully in the Genie narrative.

2 Likes
18

Why does one work and not the other?

One’s using PlotlyJS and the other one is just creating svg elements directly. Feel free to find me on the Julia slack if you want to discuss this further.

Edits (sorry was rushing):

All that sounds and looks absolutely amazing! I’m learning the basics as fast as I can, so I hope I can start making small contributions soon.

Great! Really glad you managed to get the examples working. Please do get in touch if there are problems.

19

Quickly:

I guess there’s a continuum between a quick UI to explore a concept or some data and a full featured web app like Facebook. InteractNext in say IJulia, Atom, or Blink, targets the former - particularly for those with limited web knowledge - it’s quick to get a something working and see some results. For a full featured web app, you probably need more.

Having said that, obviously it would be great to have something quick to prototype but can be scaled up, and it seems like Dash, for instance, is a decent effort in this direction - though I must admit I haven’t actually used it. It’s also been in development for over 2 years.

Re Predix table-data There’s probably a way to do the data transfer julia<–>js relatively easily with WebIO/Observables/JSON.jl

Also note in WebIO, you can use html strings as templates like so:

using WebIO
htmlstr = """<button id="btn1">clickarama</button>""" # or load from file
dom"div"(setInnerHtml=htmlstr)

maybe the syntax could be improved, and we could avoid the need for the wrapping div.

Also I wonder if
a) we can just couple to the js side of Dash
b) it might be worth seeing how easy it is to interface with Dash using PyCall.jl. Of course a pure Julia/Js solution would be nicer, but you might be able to get a bit of mileage out of that.

Anyway, lots of stuff to think about.

20

I think that a lot of what Escher enabled is now available with a combination of WebIO, Vue.jl, InteractNext and CSSUtil. @shashi has said [citation needed] that this is now the direction of focus, since Escher can only be run standalone (not in IJulia, Atom), is tied to Polymer, and is a bit large, which translates to unreliable and hard to maintain. Hopefully the combination of smaller packages should be better.

Interact.jl is actually very useful for quick data exploration but I always found that it was annoying not to be able to give basic layout instructions (for example, arrange checkboxes in a rectangle rather than one on top of the other, really basic things). At some point Escher.jl was a very good solution to get some layout in combination with Interact widgets. If it is again possible to do that (also supporting plots in PlotlyJS) it’s really good news (congrats on your work!) and I think it deserves a good tutorial.