Hacker News Reader

Comment by maxloh | Hacker News Reader

What is the use case of this library given that vanilla JS is 10x faster?

Maybe it's ease of development, and resulting readability?

I did enjoy the example code, compared to the native javascript (both shown in the article):

  var draw = SVG().addTo('#drawing')
    , rect = draw.rect(100, 100).fill('#f06')

why would the native JavaScript not be something like (probably errors here, so like, not necessarily this precisely)

const div = document.getElementById('drawing');

div.innerHTML = `<svg width="100%" height="100%"><rect width="100" height="100" fill="#f06"/></svg>`;

obviously if the what is going in can have user input in some way then open to attack using innerHTML but otherwise it seems like the structure of the example native JavaScript is made in such a way as to make the SVG.js version seem super cool in comparison.

> Obviously not as fast as vanilla js

I had a similar question- why is it obviously not as fast as vanilla js?

Because it’s written in vanilla JS.

Perhaps non-browser usage?

Reply on news.ycombinator.com