FAQ

Why the name?

Salami is a dog. I wanted something whimsical, but also something that riffed on the name "SVG". I also wanted to make it sufficiently uncommon (unlike "cool-svg" or something) because I'll probably give up on this project at some point in the future and I didn't want to name squat on something that was desirable to someone else. I chose to go with a scoped package in case there were parts of this lib I wanted to split out into other packages in the future.

Why not p5.js?

For the vast majority of users, p5.js will be a much better option for generative art and creative coding. p5 is a substantially more mature package with a robust community and great tooling. For example, p5 offers:

1. An online editor to explore ideas, and share sketches easily online.
2. Thorough and thoughtful documentation
3. A rich core library with support for 3D, Events, DOM, Sound, WebGL, and more
4. A massive collection of examples to learn from
5. A vibrant community

SalamiVG has basically none of these. However, SalamiVG takes a different approach which might suit some users better:

1. Local-first philosophy. You could theoretically use SalamiVG in the browser (the core library should be compatible with any JS engine that can run ES6 syntax), but it's primary design is intended for local development.
2. Complete TypeScript type declaration files shipped with the library. SalamiVG believes that type hints provide a substantially better developer experience by providing hints to the developer in their editor, rather than having to bounce between their editor and external documentation. Of course there are community-supported types for p5, but that's yet another lib you have to install with no strict guarantee that the types actually align with the functions.
3. An extremely narrow focus on writing SVG files to disk. If you need to do 3D work, interact with multimedia like sound or video, or you want to write shaders for WebGL, then p5 is unequivocally your better option. However, if you just want to write simple SVGs on your machine, then SalamiVG is a much simpler option with a significantly reduced footprint. Less features = faster to deeply understand the library.

Why not svg.js or Raphaël?

Most importantly, these libraries have a different focus from SalamiVG: while svg.js and Raphaël are both general-purpose SVG creation/manipulation/animation libraries with a focus on usage within an HTML document, SalamiVG is focused on creative coding and art. That means it ships with things like a 2D noise function, a seed-able pseudo-random number generator, linear interpolation, mixable colors, and classes that focus on spatial relationships rather than user-oriented features like animations. SalamiVG also ships with some useful wrappers to make it easy to quickly iterate on a sketch, which is the most satisfying part of creative coding.

I've never used svg.js or Raphaël, and they both look like pretty robust libraries. There are some key differences that might suit different use cases:

1. svg.js and Raphaël both appear to be intended to be used inside an HTML document. This would probably be better for a live coding experience or if you wanted to integrate the library with a web page or app. In contrast, SalamiVG does not have a concept of a DOM or an HTML page, it just writes basic SVG strings to a file. (Yes, I recognize there is a "Pure SVG" example right on the front page of the svg.js Getting Started guide. Writing your entire script inside a CDATA tag seems horrible to me, but obviously this is a personal opinion.)
2. svg.js and Raphaël have support for a bunch of things that SalamiVG doesn't know or care about, like animations and event listeners.
3. svg.js and Raphaël appear to have a more robust standard lib, meaning they can almost certainly do more than SalamiVG. For most people, svg.js or Raphaël will probably be a better option.

SalamiVG might be a better option for people who:

1. Do not care about running the examples live in a browser
2. Do not care about any multimedia or animation
3. Do not care about sharing live examples, just want to write SVGs to disk
4. Strongly value a local-first development environment with strong types included in the library
5. Value simplicity and fewer dependencies

What are some key differences between SalamiVG and other creative coding libraries?

• Processing
  • Processing is a library written in Java and includes it's own development environment (IDE); sketches can also be compiled from the command line with some work. SalamiVG is written in JavaScript and is intended to work in basically any development environment.
  • Processing is extremely mature, over 2 decades old! SalamiVG is extremely young, less than a month old at time of writing!
  • Processing is fairly opinionated; it is almost a domain-specific language that is very similar to Java. Including external libraries or even your own helper classes is slightly less straightforward in my opinion because it isn't just a library, it's an entire environment. In contrast, SalamiVG is just a library, and will ever only be just a library. It's import/export semantics are completely standard for JavaScript runtimes and using it should feel no different from using any other JavaScript library.
• OPENRNDR
  • OPENRNDR is written in Kotlin and runs on the JVM. SalamiVG is written in JavaScript and runs in (primarily) Node.js
  • OPENRNDR is an extremely mature library that can render to raster images or SVG. SalamiVG is a very young library that can only render to SVG.
  • OPENRNDR is a complete batteries-included library. SalamiVG has a lot of rough edges and is probably missing some important features (though you may be able to supplement with npm packages).
• PixiJS
  • PixiJS targets WebGL, whereas SalamiVG targets SVG. These two media types share very little in common and therefore the libraries share very little in common. If you're having trouble choosing between them, you may need to first ask more fundamental questions about what you're trying to accomplish.
• Other JS libs
  • There are detailed comparisons to p5.js, svg.js, and Raphaël higher up in this document.

What are some shining features of SalamiVG?

• Extremely small and fast
• Zero dependencies
• Laser-focused on simplicity
• Ships with complete TypeScript type declaration files to improve developer experience

What are some dirty stains of SalamiVG?

• Can only render to SVG; can't even render to HTML Canvas
• Can't even create real DOM elements, just writes a string and delegates rendering to a browser
• Limited feature set

Do you support Deno or Bun?

Note

While Deno and Bun should mostly "just work", they are not officially supported. Please open an issue if this is blocking you from enjoying SalamiVG.

The core library works with Deno or Bun, as it does not use any Node internals or npm dependencies. However, the renderSvg() function, which is used extensively in the documentation and examples, will not work with Deno or Bun. If you want to use this library with either runtime, you will need to write your own functions to write the SVG string to a file.

Deno example

// sketch.js
import { svg } from 'https://github.com/ericyd/salamivg/raw/main/lib/index.js'

const drawing = svg({ width: 100, height: 100 }, it => {
  it.circle({ x: 50, y: 50, radius: 50, fill: '#c55' })
}).render()

await Deno.writeTextFile("my.svg", drawing);

Then run

deno run --allow-write sketch.js
open my.svg

Bun example

// sketch.js
import { svg } from '@salamivg/core'

const drawing = svg({ width: 100, height: 100 }, it => {
  it.circle({ x: 50, y: 50, radius: 50, fill: '#c55' })
}).render()

await Bun.write('my.svg', drawing);

Then run

bun install @salamivg/core
bun sketch.js
open my.svg

Please open an issue if you'd like better Deno/Bun support.

Why is this written in JavaScript if TypeScript is a priority?

TypeScript is used for typechecking the library, and generating type declaration files for all classes and functions. This improves the developer experience by providing type hints as documentation. However, the actual code is written in JavaScript with JSDocs. This was inspired by the SvelteKit team (source 1, source 2) and it provides a lot of benefits such as reducing build tooling and speeding up test execution. In addition, shipping human-readable JS files means that it's much easier for a library user to modify the files locally, which can be a great way to lead to experimentation and PRs!

I'd love to contribute to SalamiVG! How can I do that?

Hahahahahahahaha!!! Good one! 🤣 Remember, this is page is for frequently asked questions.

...oh you were serious? Ok, please open an issue first so we can discuss how the feature fits into the vision of SalamiVG. If it feels like a good fit, we can discuss moving on to a PR.