DASH (Debian Alchemist SHell). I believe it's the default shell for Debian and Ubuntu (I'm a Fedora/CentOS user myself). I remember hitting some edge cases where some bespoke shell scripts don't work correctly on Ubuntu because DASH is a "slim" Bash alternative, so it doesn't have all the "bashisms".
> I remember hitting some edge cases where some bespoke shell scripts don't work correctly on Ubuntu because DASH is a "slim" Bash alternative, so it doesn't have all the "bashisms".
People say that, but usually the reason their scripts are not working is that they are using bashisms while retaining
#!/usr/bin/env sh
or
#!/bin/sh
rather than doing as they should when writing shell scripts that are using bash features;
#!/usr/bin/env bash
I think it boils down to a lot of people being unaware of the difference between what is POSIX compliant and what is not, or even that there is such a distinction to be made.
I write most of my shell scripts targeting bash, but I always use the hashbang that invokes to bash, and I also name my scripts like somescript.bash when it's a bash script and somescript.sh when it's POSIX shell.
Well, I seem to recall (but can't find) Dash, the programming language, and then there was Dash, the programming language from Google, which got renamed “Dart” because of the conflict, and there's now a newer Dash programming language [0].
The performance of the app will largely depend on the analytic code that you are running inside the Dash callback functions. A few things to note:
- The dash docs (https://plot.ly/dash) are itself a Dash app. They're getting a lot of traffic today with the launch and they're holding up OK to hundreds of active users.
- The state of Dash apps is entirely in the front-end (in JS in the web browser). The Dash app backend (the python part) is really lightweight - it's a flask server (that you run with an application server like gunicorn) that dispatches to the functions that you decorate. If your functions are really resource-intensive (in memory or if they block for a long period of time), then the app's performance will suffer as part of that. However, since this analytic code is scoped inside a function, the memory will free up after the request is done.
- Since Dash's callbacks are functional, you can pretty easily add caching. Caching will store the previously computed values and serve them if the input arguments are the same. There is some more info in the "performance" section of the docs: https://plot.ly/dash/performance
The state of Dash apps is entirely in the front-end
Cool! I develop APIs using Flask so that's good news for me. I want to keep the API as lean as possible. I also try to cache everything I can or simply render stuff into static data if possible. I.e., some data are updated on a regular basis but do not change so rapidly and thus I can just use a Jinja2 template with some {% raw %} blocks to render my jinja2 templates with much less stuff to do, or even static html when I can.
The deployment / scalability story is the biggest weakness of Shiny (in part due to vagaries of R in production settings). RStudio has done some amazing stuff to make shinyapps.io work reasonably well, but I do feel like there are still some inherent weaknesses to the deployment process.
And for the record, I'm not knocking RStudio / Shiny here—the tooling and end-user experience is really excellent. I do worry about the ability to create "enterprise scale" apps though. Fortunately, there are a lot of times when a Shiny app is plenty.
I'll be very curious to see how Dash compares in this regard.
I have to agree with you. We needed JS developers to present our UI to be more reactive/realtime. I am trying this out to see whether we can use Dash 100% without any Angular 2/React code.
Let me know how it goes! One of the cool things about Dash is that if you need to fallback on React code for building components, you can. Here are the docs on building your own components: https://plot.ly/dash/plugins. I imagine that some large teams may have 1 or 2 JS developers that build reusable components that the rest of the 100 analytical python components could use for their day-to-day app development / exploratory data analysis.
This is really similar to the Shiny framework (http://shiny.rstudio.com/) for R that is dead simple for creating quick and easy data interactives.
Plotly is also an amazing plotting library. If you're using Shiny, you can can create plots in ggplot2, and effortlessly change over to semi-interactive javascript versions with mouseovers and whatnot simply by changing the render type and render output to shiny. No change to your ggplot invocations in most cases.
Where Plotly falls down in my opinion, is in how they communicate pricing. I dig through their website and see that many things are open source, but then I see pricing information that makes me wonder whether I should be using Plotly for fear of getting locked into something that has licensing fees.
IMHO, this is something that RStudio got right. They have a clear model and communication around what is in their community editions vs. what is in their paid professional versions vs. what you are paying for with their Shiny hosting services.
I think shinny is awesome, but for online dashboards for my company, Dash seems awesome for one reason: no R. :D
Don't get me wrong, I use R almost everyday in my analysis, but setting up a dashboard that connects to a remote data source is a bit of a hassle and quite tiresome to set an entire R environment.
Ill play around with it, but working with virtualenv + requests + pandas + dash will make it easy to easily prototype some dashboards...
> In other words, is this for quick one-off visualizations, or can you see someone wanting to use it to build a fully-functional web application?
I don't think that Dash will replace standard CRUD style websites. It's more for the visualization and data-science space.
The main limitation with Dash is that every interaction has to be through components with pre-named IDs. That means that Dash doesn't support apps that need to bind interactivity or updates on an arbitrary number of items (for example, a TODO app with `N` number of items where each item can be modified). In traditional websites, this is handled through URL patterns, query strings, or client-side through JavaScript. Eventually, Dash might have the abstraction of "ID groups" or "ID patterns", but it doesn't have that quite yet. This type of application is common in standard CRUD websites, less common in data-viz applications or dashboards.
In the visualization space, Dash is for both the one-off visualizations (e.g. add a dropdown to a graph) as well as more complex applications that have drill down and search that you might commonly see in something like Tableau.
Reminds me of the clever Python integration in Bokeh.
I've been toying with the idea of a front-end framework in Python. I know enough Javascript to be dangerous and React isn't entirely abhorrent to me but using Python just makes me happy in a way that writing Javascript doesn't.
The idea of an abstraction layer where I could write my front-end code on the backend appeals greatly. Like all abstraction layers it would create it's own problems but most of the functionality I want in an SPA is fairly routine and it could all end up nice and sane.
Something based on intercooler.js - of which I have great admiration - might be enough for the tasks I'm thinking of.
I'm super excited for this! Good dashboarding for python has been a huge gap in the ecosystem, and none of the existing options (bowtie/pyxley/spyre) really came close to the functionality of shiny.
The closest IME has been ipywidgets+jupyter and the jupyter dashboards server. Jupyter is really nice for developing, but deploying is another question. The dashboards server works but development on it has been stalled, and deploying it is a pain. Also, if dash can leverage the react ecosystem, that could make it pretty compelling compared to ipywidgets.
I would agree that pyxley never came close to the functionality of Shiny, but my goal was a little different. My goal was to make a set of reusable components that were also really flexible. I wanted to be able to mix custom things with generic things without too much trouble. I think in trying to be flexible, I introduced too much complexity. Also, I never really got around to making a decent set of widgets and so it's definitely lacking in features.
I wrote a wrapper for the Plotly javascript library and I use Plotly charts in some of my apps. If I ever had some time, I could probably make a pretty decent clone. One interesting difference is how they are turning the python into javascript. I gave up on that and just ship a pre-built javascript bundle that receives props from the flask app.
I suppose each framework has their own shortcomings compared to Shiny. I wonder what key features are missing from those frameworks that would make it a viable option for you?
I wish I could answer this myself but I am somewhat ashamed that I never used Shiny due to R.
This looks so very useful. Also, good timing since we're just about to make a new visualization which could be used for more things in future. I dabbled with Plotly when it was announced, but had trouble with connecting our data sources and ran out of time.
I see the OP is here answering questions. Have you thought about Gapminder like animations?
I'd like to show our statistics with map data from our GIS systems. In the announcement the Walmart demo shows map from Mapbox so there's support for their service. Could you elaborate on what options there is for visualizing geographic information?
There was so much in the announcement from Jupyter to Excel like reactive components. It resembles Mike Bostock's D3.express in this regard [1]. I can't wait to start playing with this!
> Have you thought about Gapminder like animations?
Definitely. The user guide actually walks you through creating an app with world indicator data. Check out the last example here: https://plot.ly/dash/getting-started-part-2. As you hover over points in the scatter plot, the time series updates with data corresponding to that point. A slider below the chart filters the scatter plot by year.
We recently added animations to plotly.js (the graphing library that's used by Dash) so that points can transition smoothly between states. That's accessible in dash by setting `animate=True` in the `dash_core_components.Graph` component.
One of the neat things about Dash is that you have full control over the visuals and the analytics. So you could easily update this example to display the "trails" behind the scatter plots as they are animating or programatically filter or aggregate the data before plotting it.
> Could you elaborate on what options there is for visualizing geographic information?
Plotly.js uses MapboxGL under the hood for satellite scatter and line plots. We also have lower-resolution SVG-based world and USA maps for choropleths, line, and scatter plots. You can see some examples of community generated maps in the feed: https://plot.ly/feed/?q=plottype:scattermapbox or just play around in the chart editor (https://plot.ly/create) to get a sense of what's available.
Through the `scattermapbox` chart type you can plot custom shapefiles but we can't yet color those shapefiles through a data array. We're looking for a company to help sponsor improvements like these.
Thank you for your answers and thanks so much for open sourcing Dash!
I'll be definitely testing these examples with our data. Plotly seems to have grown leaps and bounds from when I last tried it year or so ago.
I believe we could integrate our data browser's React components into or alongside with Dash. This way data could flow directly from our APIs.
We have our geographic shapes in Geoserver, so GeoJSON would be the easiest way to get them into browser or Python for Dash. I have to see what how this could be adapted. If this were Django based I'd be using GeoDjango, but Postgis should be accessible from Flask as well.
Writing thin clients that serve data to browsers for charting/tabling purposes is one of my favourite pastimes. So I'm thrilled there's another tool for this job, especially one that abstracts many of the boring aspects of the job. Well done, I look forward to playing with it.
This is pretty much what I was looking for 5 months ago. I use R Shiny extensively to prototype, it's a great tool for building quick dashboards and visualisations, but when you want to go further, that's where Shiny starts to get difficult. I ended up building a basic Flask + d3 app to serve production visualisations.
I use Plotly quite a bit right now, almost to the point where whenever I ggplot anything I just turn it into a plotly plot. I love the work that Plotly has been doing, going to play around with Dash on the weekend. Keep up the great work!
Totally awesome. My first thought as I started reading was how I'd integrate this with Flask, and then I got to that section of the post - it's built on Flask - and we're all set.
Naming aside, this will finally get me into web programming and React.js as I can do this with my first love (Python) and the HTML/JS is abstracted away for me.
I hope so to! We learned a lot since the prototype and, more importantly, secured some corporate sponsors to help fund the work and ensure its long term success.
If you can wrap up your D3.js visualization in a React component with a declarative API, then you can turn it into a Dash component. Here's the tutorial on creating custom Dash components: https://plot.ly/dash/plugins and as a reference example, here's how we're wrapping up the plotly.js library as a Dash component: https://github.com/plotly/dash-core-components/blob/master/s...
This is probably the 5th or 6th "Dash" named product I've seen in the last 2 years.
There's:
Dash, the amazon order button
Dash, the offline API docs
Dash, the prepaid debit card
Dash, the restaurant payment service (acquired)
Dash, the OP's link
and probably a few more I'm forgetting.