# Server side drawing - node proposal
**URL:** https://discourse.nodered.org/t/server-side-drawing-node-proposal/24728
**Category:** Developing Nodes
**Created:** [13 April 2020 06:48 UTC](https://discourse.nodered.org/t/server-side-drawing-node-proposal/24728 "2020-04-13T06:48:40Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)
#### Post date: [13 April 2020 06:48 UTC](https://discourse.nodered.org/t/server-side-drawing-node-proposal/24728/1 "2020-04-13T06:48:40Z")
Hi folks,
I'm have been reading by server-side DOM trees, to solve an issue from another [discussion](https://discourse.nodered.org/t/svg-node-store-the-current-state/24671). And last night @Steve-Mcl posted - in the discussion about coco ssd models - the following quote:
> [@Object Detection using node-red-contrib-tfjs-coco-ssd](https://discourse.nodered.org/t/object-detection-using-node-red-contrib-tfjs-coco-ssd/22931/110):
>
> It uses node-canvas for the drawing. So it inherits the canvas capabilities - good workaround for the limited drawing capabilities of jimp.
The combination of both discussions triggered my brain somehow ...
I'm far from a canvas specialist, but I experienced in the past that it is not straightforward to draw on a canvas in server-side NodeJs. Most canvas related modules in npm have low level node.js libs written in c/c++ or are dependent on native modules (ImageMagick, Cairo, ...). The advantage is that those work very fast, but can be a real nightmare to install (as I already experienced myself).
So - although performance is very important when dealing with images - I still prefer to have a _ **full Javascript** _ solution. Indeed when my users are - for whatever reason - not able to install my nodes, then they won't be of much use anyway ...
_ **I'm now considering to build a new node, that offers a server side DOM tree** _. In the other discussion I always have talked about [svg.js](https://svgjs.com/docs/3.0/) to achieve this, but it seems that [jsdom](https://www.npmjs.com/package/jsdom) also supports SVG! The advantage of jsdom is that it offers a pure-JavaScript implementation of many web standards. Although I don't know whether the complete SVG specification is implemented (but things like animations might perhaps not be really required here)?
When we would have a DOM tree on the server, you can e.g. compose an SVG drawing on the server. Or it becomes even cooler like in this [gist](https://gist.github.com/tomgp/c99a699587b5c5465228) where they use the [d3.js](https://d3js.org/) library (in combination with jsdom) to draw a pie chart in the server side DOM tree:
_ **It is also create images in headless systems** _, where no client (like dashboard) is available. Indeed this [gist](https://gist.github.com/mattbaker/1509145) shows that you can also _ **convert an SVG drawing to a PNG image** _. Or we could use the [html-to-image](https://www.npmjs.com/package/html-to-image) npm library to do this, which also full javascript.
But I have a bunch of questions:
- I don't see any _ **disadvantages** _? Perhaps anybody else sees a major issue...
**[EDIT]** Although I have no clue at all about the performance!
- First thought that this should be added to our current SVG ui node (since I want to introduce there also a server side DOM tree), however it is also useful for people that don't use the dashboard. So I propose to create a _ **new node** _.
- Should the node be _ **focussed** _ on SVG drawings, or should it be a general DOM node?
- _ **Other ideas** _?
Thanks for thinking out loud !!
Bart
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [12 June 2020 06:48 UTC](https://discourse.nodered.org/t/server-side-drawing-node-proposal/24728/2 "2020-06-12T06:48:49Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.