I've been looking into using a library such as SVGO to be able to clean user submitted SVG code on the front end. SVGO is a node.js based library which typically works on the back end, so I've been trying to wrap my head around how to go about sending SVG code from the front end to the back end and then have the cleaned code regurgitated on the front end.

It's when I was trying to figure this out that I checked their web app example, which—upon inspection, runs code inside linked scripts that I would typically see on the back end on the front end. In particular, many of their functions have the signature (full script):

1: [function(require, module, exports) {
    "use strict";
    var loadScripts = require("./load-scripts"),
    ...
module.exports = exportedFunction;
}]

Pretty confusing, as this is typically JS that I've associated with the backend, particularly the require, module.exports syntaxes to name a few.

Question

1. Is this simply their entire library, SVGO, on the front end? Did they manually rewrite it to be patible with the front end? Or is that what tools like browserfy are for?
2. If so, what are the benefits of running it on the front end vs on the back end? Would one be easier/are there some mon guidelines on which to use where?
3. From initial glance, it seems that it would be easier to just run the SVGO library in browser and do my conversion there (as I wouldn't have to make a call to the back end). What is the general practice there?

Thanks for any insight. I'm trying to make sure I build my project in the way that makes most sense/up to web standards.

I've been looking into using a library such as SVGO to be able to clean user submitted SVG code on the front end. SVGO is a node.js based library which typically works on the back end, so I've been trying to wrap my head around how to go about sending SVG code from the front end to the back end and then have the cleaned code regurgitated on the front end.

It's when I was trying to figure this out that I checked their web app example, which—upon inspection, runs code inside linked scripts that I would typically see on the back end on the front end. In particular, many of their functions have the signature (full script):

1: [function(require, module, exports) {
    "use strict";
    var loadScripts = require("./load-scripts"),
    ...
module.exports = exportedFunction;
}]

Pretty confusing, as this is typically JS that I've associated with the backend, particularly the require, module.exports syntaxes to name a few.

Question

1. Is this simply their entire library, SVGO, on the front end? Did they manually rewrite it to be patible with the front end? Or is that what tools like browserfy are for?
2. If so, what are the benefits of running it on the front end vs on the back end? Would one be easier/are there some mon guidelines on which to use where?
3. From initial glance, it seems that it would be easier to just run the SVGO library in browser and do my conversion there (as I wouldn't have to make a call to the back end). What is the general practice there?

Thanks for any insight. I'm trying to make sure I build my project in the way that makes most sense/up to web standards.

• javascript
• node.js
• svg
• browserify

• 1 please take a look at browserify or requirejs. They both are module loaders for front-end. – n00dl3 Commented Jun 17, 2015 at 8:44
• @dandavis however, regarding the way the question is asked it doesn't mean he knows the library but "how would i browserify my backend code ?" ... – n00dl3 Commented Jun 17, 2015 at 8:46
• 2 1. browserify turns node.js packages into browser-runnable code, even if the output is ugly. 2. the client is free and safe, node.js can be expensive and risky. 3. the more cleanup you can do up-front, the more stuff your backend has time/ram to do. – dandavis Commented Jun 17, 2015 at 8:46
• @JuniusRendel: touchè – dandavis Commented Jun 17, 2015 at 8:48

1 Answer 1

Answers:

1. They are using module loaders like browserify or requirejs to allow the use of monjs modules in the browser. It doesn't mean all the library would work on the client side, using node io modules would not work for example.

2. It can be useful to make some cleanup on the browser side before sending (saving a few kBytes). Browser has the advantage to be free, you don't pay for hosting the code that run on the client side, some optionnal sanitization can be run on the browser. But: see 3.

3. Even if it is easy to make client-side sanitization, you should always check and sanitize user's inputs on the backend, especially .svg files as they can contain <script> tags that might allow XSS .