Hi folks,
I'm have been reading by server-side DOM trees, to solve an issue from another discussion. And last night @Steve-Mcl posted - in the discussion about coco ssd models - the following quote:
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 to achieve this, but it seems that 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 where they use the d3.js 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 shows that you can also convert an SVG drawing to a PNG image. Or we could use the 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?
- A general DOM node could offer non-SVG DOM related functionality. But I cannot think of any use cases at the moment? Perhaps others can find one?
- An SVG specific node on the other hand could offer D3 functionality out-of-the box.
Of course it could be a general dom node, which a.o. offers specific drawing functionality...
-
Other ideas?
Thanks for thinking out loud !!
Bart
