The initial release is scheduled for JuliaCon, the latest, when there will also be a Stipple presentation.
9 Likes
FYI: GitHub - plotly/Dash.jl: Dash for Julia - A Julia interface to the Dash ecosystem for creating analytic web applications in Julia. No JavaScript required. is the future (and Dashboard.jl from the same guy has stopped development), and it’s “a work-in-progress”. It’s good to know the older “exposes” all components, I would want to know is all functionality is supported in Dash.jl.
It might be interesting, or give confidence, to know it has company backing (Julia one of the three languages):
Most people are surprised to learn that of Plotly’s 50 engineers, the vast majority are React developers. This is because Dash is primarily a frontend library — there are far more lines of JavaScript (Typescript) than Python, R, or Julia code. Plotly only has 3 full-time Python developers, 2 full-time R developers, and 0 full-time Julia developers. This is because the heavy lifting for a library like Dash is in JavaScript. […]
Julia Computing and Plotly have quietly taken first steps to support Julia as a first-class Dash backend
Since old code at work uses Dash from Python, and they want it ported to Julia, it seems like Dash.jl would be the obvious choice. I’ve also made some code from scratch with Plots.jl (and showing with Blink.jl), that should be easy change to PlotsJS.jl and then Dash.jl.
I’m just curious what other alternatives for web (or non-web) there are for a) the Julia code; and the b) old Python code. It’s not obvious you should port from Dash; or Python, given Dash is a framework, should pyjulia rather be used rather than PyCall.jl, in case we do not port?
4 Likes
I can’t go into technical details re Dash, but I can say that conceptually, in many ways, Stipple is the opposite of Dash/Dash.jl. As I understand Dash, compared to the approach Stipple takes, the libraries are better fit for distinct use cases.
1 - Stipple is a pure Julia solution. The goal/ambition is to provide a library which takes advantage of all the Julia features we value and love and be: performant, productive, composable, readable, and a joy to use 
2 - the development is from inside out: from Julia to JS. This ensures extreme detail to the Julia API, with a lot of time being put in coming up with good defaults, to provide maximum of effect/UI with minimum of Julia code (and absolutely no HTML/JS code unless the developer wants to go into deep customizing).
3 - Dash is striving to provide a cross-language solution - Stipple is striving to provide the best Julia solution. Period. Thus, Dash should be more suitable for porting a code base or potentially repurposing an in-house Dash team. Stipple should be better suited for building a pure Julia solution from scratch.
4 - Stipple is primarily a Julia library, not a frontend library (like Dash says they are). Like I said, development is inside out (Julia to JS), so Stipple is effectively written in Julia. The frontends are abstracted away and pretty much any Vue library can be adapted (or indeed swapped out or complemented by other JS libraries). The goal is to provide Julia API stability (starting with v1.0) and continuously update the JS frontends to latest and greatest without impacting the existing code base.
5 - Dash: almost 50 React developers and 0 Julia developers in their team. For me, this was a bit of a shock and I take it as a proof of React’s complexity. How many developers Stipple has? Just me - and a friend/partner will join me soon on the frontend (he’s currently busy working on design and website). Of course, we’re building on a huge Open Source foundation (Julia, Genie and Vue) leveraging the work of thousands of developers over many years.
This will probably result in Dash being a better match for corporate projects, while Stipple’s focus, at least until v2, will be solo developers and small teams (startups) which build/learn from scratch and want to embrace pure Julia solutions.
44 Likes
I had never heard of Apexcharts (based on Vue?). At work we use Dash and Plotly (from Python, currently), for time-series mostly. Can I assume these alternatives (and your) should be just as good? We don’t have a lot of Dash code to port I think, and I’m not sure we’re wedded to that, that choice was maybe done by default because of Plotly.
The hard requirement was to use a ready made plotting library for Vue. As such, I did quite some research on the available Vue plotting libraries and Apex Charts seemed the best. Unfortunately, for Plotly there is no well supported Vue integration (or at least I couldn’t find it). So going with Apex Charts just made more sense.
Apex:
- has quite a list of available plots: JavaScript Chart Examples & Samples Demo – ApexCharts.js
- and it even goes beyond these basic types as it allows variations, mixing, etc (ie, these are all line charts):
- it’s actively developed, has a strong community, it’s used in thousands of packages, so we can be sure that it will be maintained for at least a few years on
- MIT license
Plotly:
Plotly is great, but unfortunately when it comes to Vue integration, the best I could find was this: GitHub - David-Desmaisons/vue-plotly: 📈 vue wrapper for plotly.js
However, the key part is that the Apex integration is just a package (called StippleApexCharts) which extends the base Stipple library and its API. There is absolutely no problem in also having a StipplePlotly package and the users could employ each, and even both, in the same app.
Apex is a good starting point which follows to the 80-20 rule: it will cover 80% of the use cases for 20% of resources (dev time).
7 Likes
I’m watching with excitement, but just out of curisoity…
Any chance that Stipple can be abstracted so we can use React instead of Vue or will it be forever tied to Vue? There are also nice component libraries available for React that can do similar things AND work with Plotly.js for which there is already quite a lot of Julia integrations.
2 Likes
If you want to leverage the React ecosystem it would probably make more sense to create a Stipple for React (Ripple? Sounds like a great name 
), from scratch. If we just want to use Plotly, I’d say that going with a Stipple Vue wrapper for Plotly will be the most efficient way (ie GitHub - David-Desmaisons/vue-plotly: 📈 vue wrapper for plotly.js). I’m happy to give it a try at some point, soon, if nobody else will attempt it.
5 Likes
Maybe Vega/Vegalite could be another option, given that it is already integrated with Julia pretty well through VegaLite? There also seem to have been some efforts integrating Vega with vue which could serve as a base to build on.
2 Likes
And let’s not forget the new kid on the block Svelte. It differs from other reactive javascript frameworks by its clean syntax, focus on compilation over runtimes, and that it doesn’t shoehorn your code into an object-oriented structure. You might even say it relates to Vue and React as Julia relates to Python and R. I hope its fantastic step-by-step tutorial might one day serve as a template for a similar Julia tutorial (once Julia runs reliably on the web).
5 Likes
I have a similar problem to solve - there are just too much UI frameworks, and I don’t even know, on what parameters should I compare them with each other. Can you please provide some details about how did you compare them? What parameters did you use for comparison?
1 Like
Mostly licensing, number and quality of UI elements that will be effectively used by Stipple, documentation, and project stability (size of contributing team, frequency of updates, etc).
3 Likes
For a quick intro to Stipple, join me for the JuliaCon presentation!
15 Likes
Thank you so much for this! Between Genie.jl and Stipple.jl, your contributions to the Julia community can’t be overstated. I’ll definitely be tuning in.
8 Likes
I just wanted to echo this sentiment. This is freakin’ awesome - I’m really excited to see your Stipple.jl talk, wishing you the best for it!
Have you stress-tested Stipple.jl to see how large of a dataset it can handle? Usually the two places I see data visualization on a web frontend dashboard fall over and die is JSON data transfer and when rendering large numbers of DOM objects.
Also, speaking of plotting frontends - I’ve had a lot of success with the Apache incubator project echarts that has Vue components. Might be worth taking a look there.
2 Likes
Pretty safe to say many of us data geeks are googling everywhere trying to find the repo to use this. Any idea when it will be released? I have hundreds of use cases, some professional some for funsies…
1 Like
@dustyirwin Thank you!
@versipellis Not yet, the project is still in its early phases. However, I think this is still the best possible architecture:
1 - sending JSON is efficient and it can be improved further - the payload can be compressed (with gzip) or potentially upgraded to BSON
2 - with further optimisations the data can be streamed (row by row, point by point) and the UI elements updated as the data comes in.
3 - a major benefit of sending pure data is that if all the data can be sent to the client and no server updates are needed, it can be decoupled from the server (so the app can run 100% on the client). This is a huge benefit in terms of scaling. Combine this with server-side rendering and we can build fully interactive client side dashboards.
4 - my understanding is that rendering large numbers of data points is not much of an issue with today’s browsers/computers/devices, ie 50 million points with D3 https://int21.io/post/50-million-points/index.html
I’ve also checked echarts and I love it. Another benefit of the architecture is that it’s modular, so any Vue compatible library can be turned into a Stipple package by overloading the API. The objective at this point is to go by the 80/20 rule and provide a software which solves 80% of the needs with 20% of effort. Plotly might be next in line as traditionally there is considerable adoption for it in the Julia community - although the problem is, Plotly lacks good Vue integrations.
@anon92994695 It’s coming these few days, before the presentation, guaranteed. Working to get a decent README written
11 Likes
All I can say is thank you @essenciary. Your contributions to the Julia Ecosystem have and will have some of the biggest impact on the language. We’re all here to root you on. This Stipple thing fills a HUGE void in the ecosystem and stays true to Julia.
5 Likes
Here is the link to the presentation:
Stipple is available here, with links to the demo apps and the additional libraries:
Enjoy!
28 Likes
Thank you
1 Like
Due to technical issues the Stipple presentation has been rescheduled from now in 1h. I’ll be on Discord if you want to catch up
5 Likes