What are the biggest differences between Makie.jl and Plots.jl?

I’m considering using one of those visualization packages, but I don’t know which one is better, using it for everything from particle simulations, object simulations, and mathematical graphs - also interactive if possible, but not needed. Are there some better packages for this?
Thank you for your advice.

1 Like

Plots.jl tries to give you access to a broad set of plotting backends with a unified syntax, where different backends are better at different things. This sounds good but has been unreliable in practice. For instance, neither the savefig function nor the legend keyword argument work on the Plotly backend right now. Switching backends is easy, but makes the new plot style inconsistent with previous ones I’ve generated. I also have two other GitHub bug reports open with Plots.jl that haven’t been touched in years.

I am switching to Makie which has a more streamlined focus and faster development. Not much experience with it yet, but others seem to like it.


I started with Plots but have been migrating to Makie of late.

  • Plots has been mature a lot longer and is more widely known. For example, DifferentialEquations interfaces with it. I’ve not used that package with Makie.
  • Plots is an easy way to use Matplotlib, so you have that as a fallback. (Probably not important any more.)
  • Makie can be given vectors of x, y, and z values, or a vector of points, while Plots only accepts the former.
  • Makie offers interactivity in a fairly straightforward way.
  • I find Plots’ implementation of animations easier to use than Makie’s, but not decisively so.
  • I still have trouble using Makie fully in IJulia and Pluto, so check that first if you like to work in one of those.

Thanks, @Nathan_Boyer, @tobydriscoll. Can I use Makie for making simulations of particles for example? How would you go about learning it?

Can I use Makie for making simulations of particles for example?

Yes, that was one of the main use cases I had in mind for Makie initially.
Also, it’s one of the reasons why it’s working efficient with Vector{Point}.

The docs are pretty exhaustive at this point:

1 Like

Reporting back after some brief experience with Makie and a few other plotting packages:

Currently, it seems like Makie has some rough edges and suffers from some of the same multi-backend issues as Plots. For example, the Cairo backend is the only one which can output vector graphics, but it won’t open a display from the terminal and doesn’t have any interactivity. The GL backend won’t open inside the VSCode plot pane. The WGL backend needs extra setup for multiple figures. I do think Makie is the most powerful and has some of the best documentation, but it is still a little fiddly for my taste. If you are going to stick to one environment and focus on animations, then I think it will work well for you.

For my goals of simple, composable, and reliable, I am probably going to stick with Gadfly until the Makie experience is more streamlined. Gadfly will open a nice plot that can pan/zoom anywhere I run the code. It can output to multiple file formats, and there isn’t too much to configure. The documentation and GitHub Issues backlog could use some help, but it seems to do all the basics extraordinarily well.

Some people also recommend VegaLite, but using a macro to convert Julia to JSON doesn’t meet my idea of simple.

See some more comparisons here:


Thank you, I’ll go on with Makie, as it seems to work for me, it’s also frequently updated, so I hope they will fix the problems mentioned, now I mainly need GraphMakie.

Just to give a bit more context here:

For example, the Cairo backend is the only one which can output vector graphics, but it won’t open a display from the terminal and doesn’t have any interactivity

Vector graphics cannot do 3D, so even though we try to offer all functionality from all backends, it’s basically impossible, and the backends wouldn’t exist if there weren’t different needs and applications. That’s different from Plots’s backends, which are competing full plotting libraries that aren’t as clearly split by functional scope as Makie’s backends.

While you can in principle build interactivity with Cairo, the primitives of Makie are more geared towards the OpenGL based way of doing this. These design patterns reach very deep into the library, so I think it would be difficult to offer a GLMakie like experience in CairoMakie. Given limited resources, we just say, ok CairoMakie is only static then, but delivers higher quality through vector graphics (approximating 3D plots as well as possible).

WGLMakie is similar to GLMakie (open GL shaders in the background) but hasn’t yet matured enough to offer similar interactivity, when it does however it will nicely integrate into web-based environments like VSCode, Pluto, etc. However, its speed vs GLMakie is inherently more limited by the communication with JavaScript.

What Gadfly and Plotly can offer, however, is interactivity in standalone plots, because they use JavaScript to do so. As JavaScript is the only language that can run in web-contexts, that is not a feature we can easily copy. We’d have to translate a lot of Makie’s backend logic from Julia to JavaScript to do so, maybe that can be a project for the future, but it is quite limited in scope today what a standalone WGLMakie exported figure can do. So that is the main weakness of Makie right now (in terms of pure functionality), that it doesn’t offer interactive standalone web plots without some sort of Julia process in the background. All the other bits and pieces that one might miss (ternary plots, polar plots…) are just not implemented yet but could be relatively easily. The interactive standalone web thing, not so much currently (at least that’s my opinion, @sdanisch might have a different one on that topic).


Some people in other languages are experimenting with WebAssembly.


1 Like