elm-visualization with Jakub Hampl

elm-visualization with Jakub Hampl

Jakub Hampl joins us to discuss elm-visualization and how it enables powerful flexibility through its low-level building blocks philosophy.

PublishedOctober 23, 2023

Episode#93

Transcript

Well, I think we've been plotting to have an episode on this topic for a while, but

maybe we just weren't doing a good enough job visualizing the episode happening.

But we're finally here.

We're finally here to talk about Elm visualization.

And joining us, we've got Jakob Humphel.

Welcome, Jakob.

Pleased to be here.

Yeah, pleasure to have you.

So Jakob, help us visualize this package a little bit.

What is Elm visualization in a nutshell?

What the heck is it?

So Elm visualization in a really small nutshell is a package that allows you to do data visualization,

to draw charts, graphs, whatever you want to call it.

In a slightly bigger nutshell, you can think of it as a toolbox full of different little

pieces that do each a fairly specific job.

Usually things like data transformation into different things that you can use to build

your own data visualization.

So it's not a predefined set of visualizations that you have to pick and somehow customize.

It's tools to build whatever it is you want to build.

So it's in that sense, I call it a toolbox rather than, you know, a library or something

You know, a lot of frameworks have this motto to make simple things easy and hard things

But in your docs for Elm visualization, which we'll drop a link to this Markdown document

you have a little tutorial on, you kind of say something that's almost the opposite.

You say that making a simple visualization will have a large amount of code and making

a complex or unusual visualization won't really have that much more code than the simple visualization.

So it seems like this low level building blocks philosophy is like a really unique part of

Yeah, that's right.

And that comes somewhat from experience, you know, because I've worked in a bunch of companies

where you start, you start building, you know, your MVP, and you take a charting library,

and you're going to be like, okay, we're going to do a bar chart.

And so you plot the bar chart, and then somebody comes in and like, well, we need to categorize

by this other thing.

So let's do some colors.

And you're like, okay, and the designer comes in and is like, well, I don't want those colors.

I want these gradients.

And you're like, okay, that's like, suddenly now my config is like 500 lines.

And I'm like, but I want December to be like twice as big as the other months.

And you're like, Oh, I don't think it supports that.

Okay, I just have to monkey patch this thing.

And like, suddenly, your chart is like 5000 lines of JSON.

And you know, it's still a bar chart.

It's not fundamentally more complicated than any bar chart.

But after everyone's done their little specific thing they want, you know, you've you've tweaked

literally every knob the library you were using exposed.

And this is a real story.

This totally happened to me in my first job.

So the own vision philosophy is more like, look, you're going to build a bar chart, whether

you like it or not, from from the smaller blocks.

But that means when that guy comes and says we want gradients instead of colors, well,

you're controlling the rendering.

So you've already wrote the SVG code that renders the colors, you can just as easily

switching gradients, you control the sizes.

So you can make it twice as big if you want, you can do whatever you want.

They will don't want it in a line, they want a circle, just pop in this extra helper that

transforms coordinates, and you're ready to go.

So that's kind of the that's, that's really behind this philosophy.

And it's in some ways, you could say it's not beginner friendly, it has.

And that's kind of, that's kind of the downside here, right?

Is that like, even that tutorial that you mentioned, it's fairly lengthy.

And it sort of has like, oh, by the way, before you start, you should learn these three things.

And yeah, all of those three things are kind of big things.

So you have to learn Elm and statistics and SVG, which is not a tiny thing to understand.

So like, but, you know, I think, once you've done that, you've already paid the price,

and then you get this flexibility to do basically anything, you know, suddenly the ceiling isn't

So it's, I think, for a lot of use cases, it's definitely a worthwhile price to pay,

but it's not for necessarily every use case.

But then again, we have other packages in the Elm ecosystem that maybe slot better into

some of those other use cases.

So there's, you know, a bit of a, I think, you know, you can find it, you're not like

stuck if you don't want to pay this price.

Yeah, you're never gonna go to your boss saying like, oh, that feature they requested for

this visualization, like we can't do that this library doesn't support it, we would

have to switch to another charting library that that would cost a lot of time and effort.

So we're just gonna not gonna do it or spend a few months working on it, or how long that

So yeah, that is quite nice.

Yeah, I could see myself if I was building something where like data visualization and

charts wasn't like a huge core part of the product, but it's like we need a little chart

It's not like it's just like a little dashboard with a couple of things that we want to make

a little more visual.

And maybe just throw in Elm charts, Teresa's great package for that.

It's gonna look really visually pleasing without you having to fiddle with a lot of stuff.

You don't really have to like dig into SVG and all these things, and maybe that's just

good enough, because you never really need to customize that much.

But if it's like, we're building a product where the backbone of the product is data

visualization, maybe you start immediately with Elm visualization, because you know,

you're going to need to customize every part of it.

Also, I mean, the thing is that learning is, you know, learning some of these skills is

a thing that isn't necessarily an investment that is just related to one particular project.

Like, if you learn SVG, you're going to benefit from that in this project, but also the next

project and the project after that, you know, and you're going to be even able to be hired

on a project that maybe if you hadn't learned it, you wouldn't be and so on.

So it's just there is also an element there that, you know, because we're, it's not like

these skills that are prerequisites are like, some really specific API that you'll never

use for anything else.

Again, you know, these are good things to know, if you want to have a front end career,

let's say, you know, that they'll come in handy.

Like, so I think it's, you have to consider it from that perspective as well.

Yeah, that's, that's a great way to look at it.

So I hadn't used Elm visualization before, but going through this tutorial, I think it's

really cool how it does look like SVG with a few high level helpers.

And so it makes me think of like, like people sometimes describe a framework as being don't

call us, we'll call you like you sort of pass in code for the framework to call and it wires

everything together, and then a library is the opposite.

It's like you call the function when you want to use it.

This is much more that library approach of like, you're making SVG, but then you have

a little helper that helps you draw your axes and things like that.

So you're really just making SVG and there are a few little helpers that help you do

things in a more high level way and give you some abstractions to work with that.

That's exactly right.

That that's, and I guess that's also one of the big features that I am really, I really

insist on is that it's an optional library, which I mean, if you don't like the way Elm

visualization does something, you're not locked into it.

You can replace like, you don't like the way our axes look out of the box.

There's some knobs you can customize, but like, there's nothing, it's just SVGs, or

you can just pop in your own implementation, and in fact, you can drop into some lower

level functionality we provide to help you build those.

And also the modules, and so to get a little bit into some internals, the modules in Elm

visualization are also only depend on each other through their public APIs.

So that means that if you don't like the way one of the modules work, you can just literally

copy paste its code, pop it into your project and mess with it.

And you don't have to copy paste the entirety of Elm visualization because there's some

like internal package dependencies, there aren't any.

So each module is kind of standalone.

If it depends on the other ones, it's just through the same API that you as the user

have access to.

So that's another axis of customization that you can do with this project, I guess.

So that's what I mean by it should be always like optional is, you know, if you if these

helpers are helpful, by all means use them.

If they're not, you can replace them.

I have to say actually, like this, this conversation for me is very helpful.

Because like in the past, I have to admit, I haven't really had a huge need for visualization

tools in the Elm work I've done in the past.

So I haven't like deeply researched visualization packages, but just when I've been browsing

through packages that pop up and I see Elm visualization, like I've seen your visualization

gallery and that I'm like, wow, this is impressive.

Like there are a lot of things you can do.

It seems very powerful.

But then when I look at the API, I just didn't quite know how to how to frame it.

So this conversation is really helpful to like, understand why these design decisions

were made this way.

Yeah, I think I think that was a bit, that was a big piece that we were missing for a

And it's, it's one of the reasons I released this tutorial recently.

Because my one of my aims is a little bit to bridge that gap between the API seems to

be these low level things.

And then you have the examples which show you often like interesting graphics.

And it's a little bit, you know, that meme with how to draw the owl where like the first

frame is like an oval and then the third frame is the length thing.

You know, the middle says just draw the, draw the, draw the owl, draw the rest.

So like, I think we were a little bit in that.

So I think the tutorial is trying to like slightly connect how to think about from,

you know, these smaller bits, how to get to something bigger.

What are the mental models you should have on connecting these things?

And what kind of things we, you know, Visual Studio expects you to do, what kind of things

it can bring to the table and how that's going to work.

So I don't know if it succeeds in that.

But that's sort of one of the my motivations for kind of writing it.

Because I also felt that there was a little bit of a that disconnect.

Yeah, that tutorial is very helpful, I think, because if you as great as as the Elm package

docs setup is, and as great as like your galleries, those are two good pieces, like, but the package

docs are reference.

And for this, I think you really need like a conceptual guide that walks you through

how to think about it and how to set up these basic charts.

So very helpful.

So maybe we can, like walk through like, what would some of those building blocks that you

would use to have these sort of higher level helpers that you use within your SVG builder

to do something very simple, like a like a bar chart, for example, like, what would be

those abstractions that Elm visualization gives you that you would use to make a simple

I think the most fundamental abstraction that is used extremely commonly, not 100% of the

time, but it's sort of the bread and butter of working with Elm visualization is, is what

we call the scale.

And you can think of the scale as a way of on the one side, you have your data, which

is you can think of it as it occupies some abstract space, you know, let's say, it's

So you know, it's this actually from like zero kilometers per hour to, you know, whatever,

500 kilometers per hour, if you have really fast cars, I don't know.

And like, on the other side, you want to show it on the screen as let's say bars, so they're

going to be a certain number of pixels long.

And so you need some relationship that can transform between these two different abstract

And that's the job of the scale.

So the scale encodes is usually most of the scales are bidirectional.

So you can go from from one, one space to the other and back.

But they also encode in them a lot of the common operation.

So like a common operation is you want to show what we call ticks.

So you can think of it on an axis.

There's those little lines at the bottom with the numbers.

That's what we would roughly call ticks.

Ticks are funny, because you want them to be roughly evenly spaced, but you also want

them to be like human readable.

So you don't really want them to have like 25 decimal places.

So you would like them to kind of land on nice even values.

So there's a fair amount of logic, you know, to do all that stuff.

And you kind of get that sort of stuff packaged in this little scale type.

And so really what you would do for something like a bar chart is you would pick a scale

for the x axis, you would pick a different scale for the y axis.

And this gives you kind of an immediate way how to kind of construct a rectangle, right?

Because you can then in SVG, you can say a rectangle should have, it has to start at

x or x position, it's so much wide, starts at a y position, so much, so much, it has

And both of those numbers you can get from the axes.

And then, you know, you just pick some colors and you're mostly, you've got the core of

the chart ready.

And then you can add extra stuff.

So the scales kind of tie on nicely to axes, which is kind of, axes are almost actually

in a typical element of visualization, because they're one of the only things that actually

gives you, doesn't give you back data, it just gives you actual SVG.

But axes are just so common in data visualization that programming them always from scratch

So then you can take your scale, plop it into the axes, and it will, you know, actually

draw the little line with the little ticks and format the little labels and stuff like

And then just to polish it off, you probably need to put it into actual SVG, add some,

maybe some transforms to get stuff aligned nicely, and you're basically done.

So that's kind of how those two primitives work to make a very simple chart.

And it basically, yeah, and it doesn't necessarily, visualization doesn't really have a strong

opinion on how your data is going to be structured.

So like, if we were doing a bar chart of Elm Radio episodes, and the popularity of an episode

and the date of an episode.

So you know, if we have a record that's like, you know, popularity, and episode title and

episode date, and that's just a record, a list of records of that type, you know, I

mean, or it could be whatever type, Elm visualization doesn't really care because we're going to

be the ones writing some code that's going to be doing a list.map and rendering some

SVG element for each of those that's going to render the bar.

So Elm visualization isn't involved yet, when we're just rendering an SVG element.

It's involved when we are rendering SVG attributes.

And now it's going to help us for the height of it.

To write, yeah, to basically calculate like the pixels, given a scale that we have.

And that's kind of one of the somewhat, I guess, unusual design philosophies of Elm

visualization is that it tries fairly hard, doesn't always succeed, but it generally tries

fairly hard to be as unopinionated about the data structure that you want to use, let you

do that, which, you know, gives you that flexibility.

It's up to you how to deal with how you want to fetch and store and deal with your data.

So sometimes it's a tough job for me sometimes as an API designer to actually pull that off

because we don't have a huge amount like polymorphism and stuff like that in Elm.

So sometimes you have to make a choice and you just get on with it.

But in general, the aim is to keep that as flexible as possible.

I'm guessing in most cases, you want the user to use their data and to convert them to later

lists, Elm lists, or do you take other kinds of types as well?

Ideally, we don't care.

So for things like scales, we don't really need to see your data at all.

We just need to see a datum.

I mean, what I mean by that, like if you, for instance, if you want to store your data

as a list of records, and then you want to visualize like a particular field in that

field, like a scale only cares about that number in that field.

It doesn't care if you store a list, store it in an array, if you store it in a record

of arrays, it's really up to you how you want to structure your data.

If you store it in a tree, it's not really...

Now that's not always the case.

In some cases, we do need more of that.

And in that case, we sort of force your hand into some data structure and then you potentially

need to write a conversion function or something like that.

But the aim is to not do that if possible.

Did you have any influences for this approach?

Like one thing that comes to mind for me is D3, which is I think known for like it's extremely

popular and yet it's pretty low level, which is kind of interesting, but it's like a powerful

set of low level building blocks that gives you a lot of flexibility.

And there are like massive books written on D3 and how to plot with that.

Yeah, D3 is definitely a massive influence.

I acknowledge it even if you look at the readme, it sort of mentions that at the bottom.

So yeah, D3 is definitely a big inspiration.

We, you know, D3 is a really old library.

It predates most of like modern JavaScript.

So, you know, there's a lot of like stuff in there that in Elm there's much better ways

So it's not a slavish, you know, re-implementation or something like that.

But there's definitely a lot of really good ideas that I think are totally worth stealing.

Could you give an example of something that there are better ways of doing in Elm?

Yeah, so like, for instance, D3 has this idea of what they call selections.

And so selections are, you can say like, I want to select this DOM node, and then I'll

add a handler for when it's associated data changes, I will do this sort of DOM mutation.

So it's like, it's kind of a declarative way of doing DOM mutation, but it's a completely

different declarative way than the virtual DOM declarative way of doing DOM mutation.

It's really like data focused.

And in general, I would say it makes things like performant animation quite easy, but

on, you know, which is sort of thing virtual DOM, on the other hand, tends to struggle

like animation in virtual DOM is often kind of difficult.

But it makes a lot of just building stuff the easy way kind of hard.

And it's a completely different mental model.

So it's again, like adds a lot of a lot of stuff to learn.

So for instance, that's something that it's a it's a thing that predates, you know, virtual

DOM approaches by probably, I would guess at least five years, but maybe longer, I don't

So it's so that's a thing that, you know, we could have tried to reimplement, but I

see really no point, we have a perfectly nice way of, of dealing with DOM mutation in Elm.

So for instance, but also like, a D3 has built in stuff like CSV parsing, it has stuff like

timers and dealing with, you know, recurring events, a bunch of stuff that like in Elm,

you would just solve completely differently.

And of course, it has also a lot of like, completely mutable API's and stuff like that

that just are terrible.

But you know, yeah.

So there's, there's a lot to love about D3, but it's its own world as well, for sure.

So with the didn't say that D3 had a lot of books written on on it with the book for Elm

visualization, we would it would be a lot smaller?

I'm not much one for writing books.

The tutorial I think that's, you know, like, whatever, five pages long, I spent like a

So book is not really for me.

If someone wants to write a book, I'll be happy to give them some pointers.

But you can write the preface or the recommendation.

I'll write the blob at the bottom back, which is like one paragraph.

X is a great author.

This is the best book on the subject.

And then there's then a second one comes in and like, Oh, no, I have to evaluate it.

So the second one can be the newest book on the subject.

So I feel like when I read the documentation, I feel like you put a difference between charting

and visualization.

And I don't know what the difference is.

Could you explain that to me?

The terminology is kind of isn't great.

But there's two fundamental workflows, I think, in data visualization.

And one is what we would call exploratory data visualization.

And that means you get a data set, you don't know what's in it.

Maybe you've got some description about it, but you don't really understand it.

And so you want to use some tools to be able to understand this data set.

And so you can, you know, a lot of people use Excel for this or Tableau or other tools.

But you can sometimes it's much easier to do this in code.

And you can have libraries that are really well designed for that task.

So in we have Vega, Vega light, our classic examples of this, there's very nice Elm version

So I think there's Elm, Elm Vega, Vega, don't really know how it's pronounced, V E G A.

And that's really designed for that workflow, like and it does a lot of stuff for you automatically.

You know, it can work out a bunch of stuff about your data and render really nice charts

based on that data.

And then you have the other workflow, which is you usually understand your data set pretty

well, but you want to communicate about it to someone else.

So it could either be like a journalism kind of aspect where you think you want to tell

a story about the data, or you maybe you're building a dashboard in your product, you

want to show your customers some specific stuff about data that you produce, other sort

of things like that.

And there, the it's not so much about speed of constructing the chart.

It's more about things like customization, you want to be able to point out specific

things about the data, you want to be able to, you know, really emphasize specific relationships

in your data set, for instance, you want to make the data set as easy to understand as

possible, even if that costs you as the programmer, potentially quite a bit of extra effort.

But, but, you know, you, you know, so it's, there's a really different workflow here.

And the tools that support these different workflows are, you know, are designed in different

So Elm Visualization is definitely on the second side of this divide, you know, where

we really emphasize this flexibility.

And, you know, you can tell exactly the story that you want with your data.

But yeah, you have things like Vega.

Elm Charts is a little bit in that more in that camp, maybe as well, where like, it's

really easy to get, you know, you throw in some data, you say, like, give me a bar chart,

and you have a bar chart.

And you know, you didn't have to do almost anything to make that happen.

And so you can really right away look at your data and be like, Oh, yeah, there's something

interesting going there around, you know, Thursday, 2020.

You know, January, like, oh, maybe a pandemic happened or something.

Like, you can make some sort of influence.

It's you know, from that, but but it's a different workflow.

And so you get different libraries or a different workflow.

And so that's a little bit what I'm trying to talk about there is, is, you know, if you

just want to quickly look at some data, this is your turn, kind of taking a, you're killing

a mosquito with a bazooka a little bit.

So yeah, so you said that with Vega or with Elm charts, you can get to a solution much

faster with the downside that you can't customize it as, as much as you possibly may need to

Well, so I should probably mention as well, sorry to interrupt you.

It's not just the customization, but it's also the fact that usually these kinds of

libraries are built a certain number of predefined chart types, right?

So they can, you know, somebody coded in, like, this is a bar chart, this is a column

chart, this is a line chart is area chart, you know, and they probably have 20 or 30

or 50 variations.

And that's kind of it.

And if you want to do something that's outside of that, that you're usually kind of out of

So that's, that's the sort of other limitation on that side of things.

Sorry, go on, please.

No, no worries.

So if you were to choose Elm visualization, and you did want a bar chart, but you don't

know how it will evolve in the future.

So you go with Elm visualization.

How would you, how would one go about it?

Because there's no built in bar charts module in the library.

So that's one of the reasons we have this examples gallery that we mentioned earlier.

So kind of my recommendation is go there that you know, I've made it, I've spent some effort

making it so that like, even on the home screen, you can see everything visually in pictures.

So you don't have to, you know, it's not just a directory of GitHub, there's you can look

visually and be like, Oh, that kind of looks like the thing I'm trying to do.

And they look awesome, by the way.

And you can copy paste the code, throw it in your project, and then start fiddling from

So you kind of have a starter where you know, it sets up all the all the boilerplate essentially,

and then you can adapt it to your own data set, you know, and start start fiddling with

stuff to get it to where you actually want it to go.

So it helps to understand what I'm doing a little bit before you do that.

So read the tutorial maybe.

But once once you got a little bit of understanding, you should be able to copy paste these examples

and code there.

In fact, the examples gallery also has has a little little link there called edit in

So you can also click that and that will open an editor right away where you can start messing

So yeah, that can be a pretty good way how to get started on these sort of things.

What is the tool that it uses again, by the way, there's a there's a special like Elm

examples tool for compiling these examples, right?

Yeah, so it's called Elm examples publisher, which is a horribly hacky piece of JavaScript

that you know, does compiles all of these things and take screenshots of them and then

mix the website.

So yeah, that's that's if you want to do if you're also building on something visual,

then you want to publish a website with lots of little pictures of stuff, then I've probably

done most of the hard work there for you.

That's also you can find that just on GitHub on under my awesome.

Yeah, it's almost confusing because it has the same look and feel as the Elm package

websites and I'm always confused like, which website I'm on?

I may on the examples.

Oh, no, I'm on the docs.

Oh, no, I want the other one.

Yeah, it's Yeah, maybe that was a mistake.

Originally, it looked slightly different.

And then I was like, it's kind of jarring going between the two.

Made it look more similar.

But no, it's great.

And the edit in Ellie is is huge.

That's, that's a great feature.

So what what motivated you to build this package in the first place?

So yeah, it's been going on for a while.

So back, I think this was in the Elm 17 days on point 17.

So that's 2016.

I was trying to build my first thing at work, actually, we're using Elm.

And this was supposed to be, we had an API that collected pricing information from all

the different cloud instances, from all the different cloud vendors.

And so we would scrape all the prices of AWS, all the prices from Google Cloud, or from

Azure and so on.

And there is a lot of prices.

I think AWS has about 10,000 different prices for just instances.

So it's actually, it was quite a fun problem to work on.

But also that these prices constantly change as well.

So we were so what I was doing was just building a little website that you could go into any

cut, you could put in a Kenny kind of like instance, and we would show you what it costs.

But we will also show you what it costs historically.

And I wanted to make that historical price chart.

Well the chart.

And back then there wasn't any data visualization charts in Elm.

There was like a really outdated wrapper around D3, but that didn't work in the current version

And that was it.

So I was like, well, how hard can it be?

Seven years later.

Something like that.

So yeah, then I built something to scratch my own itch at that point.

And then I was like, well, we might as well, you know, make this open source.

And so I started really getting into it.

And then at some point later, I published the first version that didn't do a whole lot,

but it's been, we've been trying to steadily add features and features over time.

So now it's actually fairly feature rich, I would say.

Now I'm curious, like, what do you feel is missing from it?

Because a lot of things,

I look at the examples, I'm like, these examples are so wildly different.

I don't know what it can and when, especially what it cannot do.

Yeah, so it's not so much about can't do, you know, because you can just program stuff

yourself, but there's, are abstractions missing?

I mean, the big topic that we don't cover at all is like geospatial stuff, maps and

so on, which is a huge, huge world.

And it's very complicated.

I made some attempts in that direction.

But I think I ran into the limitations of what can be done on a sort of open source

So I think, at least for now, I'm not really intending to go there unless something miraculous

I can already just imagine having to draw a map of the world with all the borders.

And every time they change, you have to release a new version.

And just that would be a pain already in itself.

And like, I mean, I've worked in, you know, mapping and so on.

For some period of time, I was maintaining this other library called Elm Mapbox to do

kind of like zoomable maps and so on.

And so I've got some insight into the complexity there.

And it's just like agreeing on how to represent two numbers, i.e. a point on the earth.

There's like a very large number of ways people have decided to solve that problem.

So like just that, it's a really complicated problem.

And then it gets worse from there.

So can you explain that one?

So what you probably are mostly familiar with sort of people specifying points on the earth

as longitude or latitude pairs, right?

Have you heard those terms?

So that's what we call like, people call it the GPS coordinates or properly it's called

WSG 84 is the specification for that.

And essentially the idea is their angle.

So you can think of it as one circle is kind of goes through the poles of the earth and

the other one, other circle goes around the equator and you can kind of, you know, combining

the two angles on those circles, you can kind of come up with a coordinate system that more

or less specifies places on the earth.

So that's sort of one way you can do it.

But even there, you come into trouble because some people like to specify things as latitude

then longitude.

Other people like to first do longitude then longitude.

So like, even though you're not totally out of the weeds, but then there's like lots of

other ways you can specify.

If you can't agree just on that, then like there are 13 standards on just the ordering.

Well, there's only two ways you can do it.

But you know, it's, yeah.

But like, then you can, you know, part of the problem with that system is that the earth

isn't a perfect sphere.

So you get some inaccuracy in that system.

So there's other systems that try to fix that.

Then there's a lot of ways, well, you know, that doesn't allow you to draw a map per se

because, you know, that's a sphere, but a map is a rectangle.

So then if you try to unwrap a sphere into rectangle, you're always introducing distortion

and then you have different systems that can deal with that distortion in different ways.

And I could talk about this literally for like days.

But yeah, it just goes into, there's a lot of pain in the GIS world.

So solving a lot of that in a nice way is tough.

Did you also happen to try and solve time zones at the same time?

I'm not that suicidal.

Which one do you think is more complicated?

The maps one or the time zones?

Time zones are also just horrible.

I mean, I think I don't, yeah, I know enough about time zones not to want to know anymore.

No, no, but yeah, I mean, then you have a bunch of other things that are complex layout

One thing I'd like to do some point in the near future is what are called Sankey diagrams,

which kind of visualize flows between different things.

So you could say like, you could think of saying like, if you want to do a chart between

countries and some import and other export different commodities between them, you can

visualize this in this chart, kind that shows you the quantities of stuff flowing between

these different things.

It's a really nice, nice way of visualizing stuff.

And it's sort of non trivial to compute that layout.

So I'd like to do that one.

Is it non trivial because every flow impacts how the other flows will show or the order

of those things?

Yeah, I think that's generally the problem you get with most like complex layout algorithms

is that it's just everything affects everything and you have only so much space to put it

And so you end up having to shuffle everything around a lot.

Actually, you know, so one of the things we had a pretty major release recently, which

added this new module that deals with we call it hierarchy, but essentially, you can think

of it as dealing mostly with things you could represent in a tree, tree like data structure.

And that's all just layout, we don't really do any, as usual, we don't only do any drawing,

we just compute where in where would you put stuff if you wanted to do some kind of layout.

And so that's been a bunch of layout algorithms I've been working on.

So they're, yeah, they're just tend to be pretty complex.

Yeah, it's kind of a funny one, because Elm visualization is structured internally by,

you know, you often see as the on the API surface, it's like a single function.

And usually, that module is just documentation and, and the function, like I almost use like

a C like header pattern, where you have like a header file, which has the function signatures

and the documentation, and each function is implemented in its own entire module, because

that function implementation is probably like 3000 lines.

So it's also a little bit atypical, I think, in that regard, is that some of these things

are just inherently pretty complicated.

So this package only gives small helpers, but each one of those helpers is very complex

to compute and takes a lot of most of that some of them are pretty simple, but most of

So could you walk us through some of these sort of ecosystem of supporting packages that

you mentioned in the readme there in the getting started, so there are a few things that come

up while using this package.

Elm color is a pretty straightforward one.

It's just a kind of community standard package for describing a color.

But so like typed SVG, I actually wasn't familiar with typed SVG.

What is that package for?

Yeah, so most people probably are familiar with Elm slash SVG, the sort of, I guess,

standard library.

But it's, at least in my opinion, not a great package.

It has it basically copies is designed from Elm HTML in the sense that every element takes

two lists, and every attribute basically takes a string as its one input.

And that works pretty okay for HTML.

And it's kind of beginner friendly in the sense that, you know, if you know how to type

HTML, you probably know how to type Elm HTML, it's, you know, very consistent, which is

But it's not a great package if you want to actually dynamically compute most of the attributes,

because most of the attributes in SVG are just not strings at all.

They're either they're usually floating point numbers, typically, or they're just complex

structures like things like paths are, it's a fairly complex data structure that ends

up being stringified into a string.

But if you want to actually compute it, you don't, you know, stringifying it isn't isn't

really a core concern, you know, and then you have a bunch of things that are basically

So you can say like, I want, you know, if I make a if I bend a line, like imagine 90

degrees, you can draw the corner there in like three different ways, you can get it

kind of like to overshoot, you can kind of rounded a bit or you can kind of do like a

45 degree bend at the edge, right.

And so those are like your three options.

And, you know, you can specify an attribute that's going to be one of those three.

So like, taking an arbitrary string is just a way to shoot yourself in the foot.

Because you probably don't remember how to spell I don't know what it's called.

Well, and yeah, you don't remember what it's called.

So good luck with autocomplete with a string.

doubts and then hope for the editor.

Because it's a string, you're not going to get any help from your ID.

So you're gonna have to go and Google it.

And you know, it's annoying.

So type SVG is an attempt to solve some of these problems.

I personally am not super happy with that library either.

I think it's a move in a better direction, but I still think that like, as the ultimate

Elm SVG rendering packages is still waiting to happen.

Well, you have a choice between writing a new book and making that the library.

So yeah, I started on it once.

And then I sort of quickly just looked at the size of the SVG spec.

And I was like, yeah, no.

Okay, let me let me find a way to generate this from the spec.

Yeah, but there's, you could try that.

But then then you're not going to end up with a, you know, I think that's a little bit like

where type SVG also like falls is that, you know, some of the ergonomics end up not being

all that ergonomical, because, like, to give you an example, right, there's certain attributes

that like 95% of the time you use them, you use them with, like a number, let's say as

But they can also technically take like a straight other value, like something like

none, or, you know, something like that, or, you know, so if you just model it as like,

oh, well, then we have to wrap the number in, like one tag, so that we can have the

other tag, you end up with this spare tag, like literally, or called all over the place,

you know, so like, a better API design would be just to make this attribute just take the

number and then maybe add an extra attribute that you're going to use in that one situation

you needed that has some more awkward name.

But you know, it makes the 95% case way nicer.

You know, and it's the sort of thing which needs some experience and quite a bit of thought

to to really get the sort of developer experience to that level.

That's quite a lot of work.

Yeah, so it sounds like Elm SVG is similar to Elm HTML, where typed SVG is similar to

But you want Elm UI for SVG?

Something, something, something like that.

I think as a metaphor, I think that works.

I think also, because like, Elm CSS has the same some of the same issues you mentioned,

like, oh, none can be specified as an attribute to anything, almost.

And it also had like, needed to go through some type trickery to make it work.

Okay, so one true path, that one, I had also not heard about.

And I'm very curious, like, what is the one true path package solving?

The one true path, actually, it's funny, because that actually happened at that first Elm Europe

conference, where I think we might have met there, I don't know.

And I think a bunch of people like myself, Matt Griffith, I think was there, I don't

know, Fulgert, who ended up writing this, maybe one or two other people.

And we were all like saying, like, well, we all want to do stuff with SVG paths.

Like I wanted to generate them from various helpers.

And Matt was interested in using them for animation, because he wanted to do animation,

you know, on a path.

And I'm not sure what Fulgert was trying to do at that time.

And so we were like, well, you know, one of the I guess one of the so this goes back to

Elm's design, right?

And Elm, it's strictly typed with nominal types, which means if I produce a type that's,

you know, called something, say, the path, and you want to consume that type path, you

have to take me on as a dependency, you know, but you might have nothing at all to do with

Like, if you want to do animation, you probably don't need to, you know, depend on a data

visualization package, like it doesn't make much sense.

And so it's kind of beneficial if the community can organize around, around some of these

core types that it would be beneficial to share between a bunch of packages and produce

a single package.

And so that's how ElmColor was born, for instance, and one true path was supposed to be that

for path information.

Now I don't think in that case, that totally materialized.

I don't think there's other packages that really use it.

But that was the idea.

There was a way it's called one true path, because it was meant to be the one path package

that was going to unite them all.

And so that was the intention there to make the ability to take path data from one package

to another and, and, and share them.

And path data as opposed to like the D element in SVG, which is like, doesn't describe the

data, it describes the element directly.

So in SVG, you have what's called a path element that takes has an attribute called D, which

is super intuitive, which is this, you know, if you look at it, it just looks like a long

string of mumbo jumbo.

But it's that string is essentially a list, you can think about it as a list of commands.

And each command is like, move over to those coordinates, and then move to those other

coordinates, but as you move, draw a line, like you can think about it as almost like

a logo drawing program, you know, then go in a circular fashion to this other point,

and then like, maybe just complete the shape.

And so you get these these commands.

And so they describe what we call a path.

But essentially, it's sort of a generalized geometry.

And you can use that for drawing stuff, for instance, but you can also use it as just

a path that someone could take, for instance, in an animation.

So there's different ways you can interpret it.

But conceptually, or mathematical calculation or something.

Yeah, you know, and so that's, that's what we call path data.

And so Elm visualization has a bunch of different helpers that produce these sort of paths based

on, let's say, you have some abstract data, again, when you can use some scales, and you

can turn it into path data.

And then you can either just render it, but you can also potentially animate up, you know,

create something based on that data path.

So you know, it's one of the things you, there's a lot of data visualization libraries that

have like animation, but it's really like what I would call spurious animation, right?

It's like, you open the page and the bars in the bar chart is like, zoom in.

And it's like, Oh, like, okay, it's, I guess, cool.

But I've seen animations before, like, it doesn't, but it's, it doesn't tell you anything

about the data, you didn't wouldn't know if the animation wasn't there.

But I think there's a lot of opportunities animation in a way that's much more explanatory

and tells you stuff about the data.

So I think we have a really cool example about that.

If you look at the bar chart race example on visualization, you know, that's an example

where it's a bar chart, but it's, it's, it grows as time progresses, and then it reorders

And then kind of the motion tells you how the situation changed over time, you know,

and so it's the animation and the motion is actually telling you things that you couldn't

understand if it was just a picture.

And so I think there's a lot of like opportunity to use these sort of techniques to come up

with really intuitive ways to explain data that wouldn't be, you know, wouldn't be possible

if you just didn't have those animation permitted.

So that's my hope with that.

It didn't, it didn't totally pan out in the sense that I don't think other packages totally

But, but, hey, it's still there.

So yeah, no, that's, that's great.

That's great context.

I think, for me, at least it helps.

It helps me when I understand like the motivation for why a package came into existence.

It helps me when I'm trying to use it to understand that context.

So other philosophy we have in on visualization is that, well, you might have noticed it's

still on version 2.4 and the major version is only two.

And the only reason we made the second major version was that Elm 0.19 came out and broke

pretty much everything.

And so we had really no choice but to just, you know, redesign a bunch of stuff.

Like for instance, you might not remember this, but color used to be in Elm core, you

And then time worked completely differently.

So Elm visualization, those are pretty important types for us.

We do a lot with times and colors.

So that was, yeah, that was, so that was, and while we're going to do a big breaking

change, I fixed a bunch of like design flaws and so on.

But you know, the, the main aim here is to keep it as backward compatible as we can.

So some of these things, like, I think if I was designing it today, maybe I would have

come up with a slightly, maybe it would have made a different package for path or something

But, but it's, it works well and it's, it doesn't, I don't feel like we need to break.

It's not bad in a way that we should break anyone's code for it.

Like it works really well, actually.

And, and you recently released a new version.

What are, what are the highlights from the new version?

So the main highlight, as I mentioned, is the ability to do these kinds of tree visualizations.

So you can really, there's three ways you can lay out trees that we support now.

So one is allows you to do kind of what we call sometimes node link diagrams, but you

can think of it as somebody told you, like, can you draw me a tree on a, on a whiteboard?

That's what you would probably produce.

Like you would draw boxes and you would draw lines between them.

And that would be how you would visualize the tree.

Now to do that, to look nice is actually tricky and there are some aesthetic rules that you

can apply to make things, you know, look nice.

Like the tree shouldn't be, should be kind of look kind of balanced.

Like ideally the root of the tree should sort of be in the middle-ish and so on.

And things should be kind of neatly done.

One of the cool things we support is there's distinction between layered and non-layered

So what that means is if you have the nodes in the trees, I can have different sizes.

And so if, if you have, if you have that property, then you have to make a decision.

Are you going to make the tree such that every layer of the tree by layer, I mean here, like

think of like a rank in an army, right?

Like if you have units, then like all the generals, you would want to line them up and

all the lieutenants you want to line them up and colonels.

And I don't know, I have no actually idea how ranks work.

You would want to draw it in that sort of way where they all like end up being, you

know, at the same level to show that they're the same rank.

But like if you, so then you would say like, I want to draw it layered and that's going

to take you more space because you actually have to, you can't squeeze stuff into the

gaps otherwise.

But if you don't care about this property, then we support the non-layered, which is

much more computationally tricky to do, but it allows you to, to, to kind of take, you

know, if you have a really tall element, we can squeeze a whole sub tree in the space

that it leaves.

So you end up with these really compact, but quite nice looking layouts.

So that was a lot of fun to build.

Then tree maps, tree maps.

If you're not familiar with that is basically you take some sort of space, like a rectangle

and you start dividing it based on the structure of the tree and some quantitative variables.

So like that's great way how to use that is there's tools and there's tools out there

If you are running out of space on your computer, you can use a tool that will produce a tree

map of your hard drive.

And then you can see which directory is which size.

And you immediately see, Oh, there's that weird directory in my downloads file that

has like 10, 10 gig films in it that I'm never going to watch.

You can immediately see this is, I'm going to like save space.

Whereas if you were just looking through some other way of showing your file system, you

would never find that.

Or JavaScript bundle sizes as well.

Yes, that's a perfect, perfect example as well.

And then the last one is kind of what we call a partition layout, which is kind of like

a one dimensional version of the tree map.

So it just divides each layer successively into smaller pieces in kind of like a rectangular

And you can like one of the really attractive things you can do with that is what's called

a sunburst visualization.

So you do that, but you arrange them in a circular fashion.

And so the circle is kind of split up and you kind of go into the little branches of

the tree going from the center outwards.

And so that's quite an attractive layout, I think personally.

So you can do stuff like that.

And by the way, we'll link to the release notes, which have really good visuals of all

Yeah, I mean, the other big thing is, is the tutorial that we mentioned that for me, at

least personally was the hardest game about this release.

And then, yeah, then there's actually some really nice, just new examples.

So I always try to release a couple more examples to do some stuff.

I really recommend people looking at the weather radio one, which shows you the weather pattern

for a whole year in a particular location.

And the really fun bit is you can change the location.

And so I think when I showed it to my wife, we spent like two hours just looking at different

I mean, like, oh, what does it look like in Iceland?

Oh, what does it look in that desert?

Oh, what does it look like in, you know, Siberia?

And so it's a really fun example to play with.

So if you want to waste some time, I'd recommend that.

Yeah, that one looks amazing.

So it's actually based on a really famous, really famous poster.

And I love that poster so much, but it just has, it's a poster you buy.

And so they only pick 30 places.

And if you have no relation to those places, it's not that meaningful of a poster.

So I always wanted to make this tool to be able to make that poster.

But in the places I've like lived to or been, lived in or been to, or, you know, that sort

of thing where you have some personal relationship to it.

So you can kind of relate to those places specifically.

So I'm curious, like, how do you even approach building these visualizations?

Like I want to take the example of the weather radial, but I don't know if that one is too

complex to ask you, like, how do you go about approaching it?

Yeah, so usually you start with some sort of idea, you want to build something.

For a lot of these examples, a lot of these are like famous stuff that, you know, people

have built or, or like are in newspapers or stuff like that.

I'm thinking mostly in terms of implementation rather than designing the visualization.

Yeah, so you always start with, you know, on one side, you have your data.

And on one hand is what the pixels you want to look like, right.

And so fundamentally, you're going to end up with some form of transformation between

You know, like we talked earlier with the scales, that's the simplest case.

But you know, it usually gets a bit more involved than that.

But, but fundamentally, the workflow is pretty similar.

Like you come up with, you know, ways to, to do that.

And then you, you know, and it's, it's fun, because it's visual programming, right?

You're constantly getting visual feedback, like you put something and it just all looks

completely horrible.

And then you change the parameter, and it rotates the right way around.

And you're like, Oh, yeah, that's great.

You know, and, and so it's, I find it really like rewarding in that way that front end

engineering can be rewarding, where like, you're constantly getting this really nice

visual feedback.

So it's, it's definitely fun.

Sometimes it can be tricky when you don't know how to proceed.

But yeah, I would say like, when you have this kind of visual feedback, it's really

easy to, to iterate.

But when it's visual, then it's really hard to write tests for.

And that's, that's going into another tangent that I'm sure that Dillon has a lot of thoughts

The less visual something is, the easier to test it is.

Yeah, well, that's, yeah.

Like, so for instance, what I was really pleased about with the, with the tree work in the

latest release was that the actual papers that describe the layouts, the sort of aesthetically

pleasing layouts that trees should have, they codify them as seven rules.

And you hear like, oh, rules, fuss tests, and then something clicks in your head and

you're like, oh, I can write fuss tests.

So I think I have fuss tests for four of these rules, which were kind of sufficient enough

to really like shake up all the bugs I could, I could find.

So yeah, it's actually very nice when you end up with this situation where you get this

really powerful way to do, you know, something quite abstract.

So sometimes, sometimes it isn't like that.

Sometimes you end up with a situation where actually you get really nice properties.

And it might be hard to test the visualization itself, but the, the data transformations

that are, you know, show showing up as the final result of the visualization are easier

So that's when the unit tests come in and.

It's also like an implementation detail, but yeah, like if that's the closest you get to

be able to test something and sure.

Which is why it's harder.

It's harder to test the final full thing.

It's, but it might be pretty easy to just test some of the number crunching along the

Do you have like, when you make a visualization, do you have tests for it and not for the underlying

I mean, really for like, Oh, I have a weather radio.

I have some tests for them for that.

At work sometimes for it, for the example galleries, there's no, no tests.

I it's, they're supposed to be kind of like very self-contained examples.

So I, you know, it's slightly different emphasis, but at work we've done some, some, but yeah,

as you say, it's sometimes it's pretty challenging and just doesn't feel worth it.

You get, you know, you can test it a lot, just manually you get, because it's visual,

you can kind of, your eye can notice the defects super fast in a way that I've done.

I've done a lot of tests during development when I was doing like data visualization with

some map stuff and WebGL just because the development workflow is just really awful.

Like the WebGL tooling, at least back then was, was not great.

And so I built a bunch of like test stuff and I did a lot of, you know, you can do image

comparisons or I would, you know, render to a buffer and then do like an image diff against

the reference image and so on, which was quite nice, but it was a lot of work to get that

So it depends on whether you feel like that's worth it or not.

So in your guide, you, you mentioned like some of the important skills being, you know,

understanding statistics and, you know, sort of data modeling and like cleaning your data.

Can you talk a little bit about, you know, for somebody maybe who is not super experienced

with some of these statistical techniques, like what are the important things to look

into and like where might somebody learn more about that?

Yeah, it's kind of a good question.

I don't think it's like necessary to get like a university degree in statistics or something

But like it's, and where exactly to learn everything, I don't really know.

Part of what I just mean by that is that like fundamentally, a lot of times your work is

going to be understanding things like sometimes a terminology, honestly.

So things like what's a dependent and independent variable, you'll hear that a lot.

If you don't know what that means, it's not the same thing as in programming, you know,

and, you know, or you're going to get things like a quantitative dimension versus, you

know, ordinal dimension, for instance.

And you know, these things just mean a quantity dimension is like a number and ordinal dimension

is something that you can, has a defined order, but doesn't have like a value, let's say.

So like, you know, like for instance, if you're doing a count of each, how many times a letter

appears in a piece of text, you want to visualize like a histogram of letter frequencies, like

letters would be an ordinal thing because they have an order.

Like it doesn't make sense to visualize them as like D, Z, X, and V. Like you're going

to visualize them A, B, C, D, E, F, G, right.

They don't have like, A is not any bigger than C in that sense.

So that's what like, you know, quantitative ordinal.

And then you have nominal is the like third category, which are just things that are distinct

from each other, but don't have any intrinsic order.

So that would be like your typical categories, blue and red and green, something like that.

So you have a lot of this jargon that it's helpful to understand, and kind of not just

the jargon, but some of the concepts, you know, like you, if you understand that, like,

look, this is a nominal variable, then you're going to think of like, okay, I'm going to

visualize it maybe with this kind of scale rather than some other kind of scale.

So it just helps you click these things.

You know, there's no point trying to do it in a quantitative way.

Data cleaning is just, that's like almost every place I've worked in has had, you know,

you get data to visualize and the data is just rubbish one way or the other.

You know, like there's just, I don't know, there's duplicates, there's the data isn't

adequately sorted, stuff like that.

So you're always going to need to do some data transformation work.

In Elm particularly, like you want to end up with nice types, it's going to make everything

else work better for you, right?

So there's always going to be work taking these data sets and making sure that they

end up neatly typed.

And maybe that's not, you know, it's not necessarily the case for everyone.

Like a lot of, if you work at a good software company and you're just trying to write a

visualization for what some nice backend API gives you, you might not need to do much of

If you're working in a lot of other kinds of companies and somebody drops a CSV file

on you, you're going to need to do a lot of that.

So it depends on your use case.

Yeah, I could imagine like the way that you structure your data being important for both

being able to visualize something the way you want to and for performance reasons too.

Like sometimes the way you order things one way or the other can completely change that.

And you talk about the Rose Tree data structure in the new release, which I have to admit,

it sounds really cool, but I don't know what that data structure is.

Could you give us an intro to that?

It sounds pretty at least.

Yeah, I should have.

Yeah, it's again, I mean, jargon is just, it's a trap that's hard to escape, isn't it?

But a Rose Tree is nothing very fancy.

It's just a tree that each node can have any number of children.

So like a binary tree is just a tree where each node has exactly two children or it's

a leaf, so two or zero, but like in a Rose Tree, you can have any number.

And it has a zipper so you can traverse it.

So in some sense, it's just kind of the, I guess the most general kind of tree that gives

you the least kind of guarantees in terms of like things like performance of searches

or stuff like that.

Like it doesn't give you computational benefits, but it can represent sort of any kind of tree

you want, as long as you would call it a tree.

Yeah, it makes sense.

I mean, in Elm, we often, I feel like try to use really high level intuitive terms for

But then at the same time, when you get into like mathematical things and statistical things

and data structures, you sort of, there are certain properties that you convey a lot of

information with when you use a particular term, when you use the jargon.

So you kind of have to use the jargon in some of these things.

But it's good to know.

It's just like, it's a good tree.

It's a good tree data structure.

I don't think I mentioned in the release, but in the docs, I do actually provide the

type alias precisely to just show that like, look, this is, it's a pretty mundane data

Like there's, you know, it's, but yeah, I guess the main idea of it is like, if you

have any other kind of tree, you should be able to fairly trivially transform it into

a Roast tree and then be able to visualize it, you know.

So, so yeah, that was, that was also one of the recent things we released is a library

to deal with those.

So that's been, there's been a lot of open source activity lately on that front.

Well, that's great information.

And so Jakob, if people want to learn more, what are some good resources?

We mentioned the tutorial, which I would highly recommend.

Are there any other good resources for people to dive in to Elm visualization?

I think basically it's, there's a, the tutorial example gallery, which we mentioned the documentation

is also fairly extensive.

And then finally there's a Slack channel on the Elm Slack called hashtag visualization,

which is one of the perks of being old because back then you could still get channels for

So yeah, so you can ask questions there and I tend to respond reasonably promptly.

So that's, that's basically it so far.

If somebody wants to write a book, as I said, please, please, you're very welcome to.

Is there anything that you would like to see Elm visualization be used for that would get

you excited or you just, that would be nice to have somewhere out there?

I think one of the things that somebody actually started on, and I think it's fairly productive

is you can use Elm visualization as a library to build the other kind of visualization library,

You can build an explanatory data visualization library, which under the hood is powered by

Elm visualization primitives.

And so I think that already exists, but what would be really cool, I think in my mind is

if you could couple that with some code gen and you would have like, you could have like

an eject button where like, you could start with that high level one and then you'd be

like, you know what, I just want to go hardcore.

You would hit that eject button and it would transform that into like Elm visualization

code and then you could, you know, fiddle with it.

That would be really cool.

Elm visualization land or something like that.

Something like that.

So that would be pretty fun.

Maybe the ejection could be an Elm review rule that automatically scoops out the code.

Well, Jakob, it was a pleasure having you on.

Thanks so much for coming on.

Yeah, thank you.

Thanks for having me.

It was really nice.

And Jeroen, until next time.

Until next time.