Same experience with SVG. Inkscape is terrible at generating files, Illustrator is only marginally better (haven't tried Sketch yet).
The same thing applies to code too. There's the principle of using frameworks wherever possible that especially novice programmers stick to without realizing how much harm it can do in the long run.
My personal record is reducing the main code base of an app about 20 times (!) by just removing unnecessary frameworks and replacing others with better ones. No, 20 times applies to the main code, excluding the frameworks. This is the same kind of digital pollution.
Digital stuff such as graphics files, source code, etc scale too easily unfortunately for all of us, developers and users. Every time I open someone else's big iOS project I find about 80% of 3rd party code linked for no good reason. Let alone some essential frameworks that themselves create pollution by pulling endless dependencies (Google being one of the top offenders from my experience).
This is not going to change unfortunately. Digital media is cheap, easy to scale, usually a bit too expensive to get right (i.e. to reduce pollution) and at the same time it's not always easy to see the drawbacks of pollution in the long run.
edit: sigh, I don't know if that's for suggesting to use Inkscape and then remove stuff manually, or for linking css-tricks... so I'll answer to both hypothetical criticisms:
But I know CSS has this property because I'm using it, and it's awesome. You obviously don't need it on a site that just has one color scheme, or if using either black or white outlines depending on background is good enough -- but if you want icons that scale and fit any color scheme, and want to avoid digital pollution, this is something you should be aware of.
> You couldn’t just roll down the street leaving huge piles of garbage everywhere you go, making life slower for everyone as they climb over your mountains of junk, just to get on with their life. You’d feel bad about it, right?
It's perhaps not that large an exaggeration to suggest that rush hour commuters, one per car, are doing exactly this to each other.
I doubt about the convenience part. With more moving parts, you sooner or later run into problems you couldn't anticipate. I'd rephrase it as "immediate and deceptive feeling of convenience vs. purity and convenience"
I feel like the blog argument could be made for using garbage collected language (Java?) over assembly.
Anyway, stepping from C to C++ is a lot of overhead.
Please don't lump the two together, at least not near that time period. Frontpage would take clean html and convert it to crap when edited. Dreamweaver was amazing in comparison.
This is how I feel about front end frameworks. I understand the benefits for large projects, although I still wouldn't want to do that work myself. I have some small personal projects in vanilla JS, and they're a few hundred lines in 3-4 files.
They will continue to function for the foreseeable future, with zero build process, no node_modules directory full of tens of thousands of garbage files, no transpiler or bundler version issues, and almost no overhead in understanding the code, even for a bug fix 5 years down the line.
But, I still get funny looks if I tell my front-end friends all this. Sometimes I feel a little crazy.
I'd love to get other peoples' thoughts on this, but I think we're at a tipping point back to vanilla html/css/js.
There used to be a huge need to jquery, bootstrap, polyfills, and other tricks, but many of those features are now available in the built-in languages. If you ignore IE, then you can make elaborate websites just by writing it by hand, doing some plain css grid, svg, html5, etc. How much time is spent resolving npm dependencies and packaging scripts for simple libraries that used to just be adding a .js file to your repo?
Obviously, web applications (that do more than show some content) will need more infrastructure, but I feel like we can safely stick with mostly vanilla languages for web pages that is content-focused. Let's go back to the days where you could learn a lot from View Source, and version control was dead simple.
Dropping IE support is a luxury not everyone can afford. So you either write code like it's 2014, or you use modern js features and have to transpile your code. That may add some overhead, but I'm much happier using async/await and babel.
I tried writing an interactive UI in vanilla, because I'm a huge fan of less is more. But I had to switch to Vue in the end. As the complexities of managing state mounted, it just got too difficult to handle without effectively writing a custom version of Vue/React to manage it.
But I have just imported the Vue code as a script file - no node modules folder ;) Though without Webpack I can't do single-file components properly, which sucks.
Unless the overhead is truly polluting, as in using a significant amount of electricity or physical computers, the thesis contained in this article seems like a good way to worry about bullshit that truly, profoundly, just doesn’t matter.
So be wise before inflicting this staggering bullshit on your colleagues. Pick your battles.
If 100 things are each responsible 1% of the total "pollution", how significant would you rate each of them?
Also don't overlook that just one byte more can double the amount of packets that need to be sent for something, just a little bloat can mean individual items in a list of millions no longer fully fit in the CPU cache, and so on. We also can't really know how many times things (that are put on the web) get handled by how many computers and users, so any byte you save could be multiplied by infinity. If I can do it easily, cutting out bloat is always good IMO. Personally, I find it enjoyable.
I find myself doing the opposite, since I write stuff once (at most, since there is auto-complete and copy & paste), but read it a lot more often. I find reading long variable names takes exactly as long as reading short words, but with less mental overhead. So instead of something like srv_mem_max, I have stuff like "server__max_allocated_memory". It doesn't affect the output or the compiled result, after all.
VS Code is very similar, with the additional support for .EditorConfig files.
I do have a new line at the end of files now so that Git doesn't complain. That and new lines before some curly braces (either JS/TS/C#, can't recall which) is the only thing I've changed over the last decade+. The fact that I don't recall which I do where suggests I might want to reevaluate that, if it's not in a language that's going to compile it out.
The only "staggering bullshit" I see is acting like elegance is a luxury, and waste is irrelevant, and the only value is to ship something, anything, in as little time as possible. (As if the only metrics that matter are the ones that can be evaluated by non-engineers and correlate with short term business outcomes, hm...).
The problem is that this attitude leads not only to waste and inefficiency but also to insecure, unreliable, buggy systems that are incomprehensible even to the people who build them, because they are built on layers of poorly understood, overly complicated trash.
So we have laziness, incompetence, and waste at every level of the stack, and this is celebrated as efficiency.
I share the love for hand-made svg. But it has its limits when graphics need complexity.
In those cases I use https://github.com/RazrFalcon/svgcleaner-gui to clean up the svg file after export.
On the other hand, you should delegate whenever possible. The less decisions you have to make the better. When you're using package X, you're handing off a lot of those decisions for something which most likely will "just work" and you can move on with life. One feature of delegation is that the job may not get done as well as you would like. You then have to weigh the value of doing the job yourself. If your calculation is that the job was done "good enough" then you can move on. One heavy consideration is if the thing is core to your mission. If the thing is going to be part of your crown jewels, then go ahead and do the job yourself.
This also doesn't scale. Where do you start with the garbage? As soon as you start with the OS, you're dealing with a stack of trash. Every layer adds more junk to the pile. Even considering where you should start cleaning is huge decision overhead. Every decision is a potential rabbit hole which can lead to problems. Mo' decisions, mo' problems. Better to keep the decision space clean. I would rather my trash be digital than cognitive.
This is an interesting topic and reflects an obvious double standard among developers.
On the one hand, popular opinion in the profession is to encourage you to launch your product as quickly as possible and then revise rapidly. That naturally leads the developer to reach for time-saving libraries, templates and frameworks. Even, if you're not launching a product, you still reach for a framework because it makes you - to use a favourite term among developers - 'productive'. In other word, everything for the comfort of the developer.
On the other hand, when the developer is on the receiving end of a memory-guzzling app, or a bloated website, they will complain loudly and eagerly point the finger at the designer, the Product Manager, the stakeholders, the boss or whoever - always someone else to blame. What developers won't do is acknowledge that attitudes and practices in the programming profession are the root of many of these problems.
I sometimes wonder if programming is the only profession where so many people aspire to the lowest possible standard, while holding everyone else to a much higher one.
> I sometimes wonder if programming is the only profession where so many people aspire to the lowest possible standard, while holding everyone else to a much higher one.
This is cute but stretches the point too far. Your time is better spent working in Inkscape versus handcrafting a file that is a hundred bytes smaller, more likely to have syntax errors and has to be tested across different browsers. Likewise, frameworks help standardize code and reduce a lot of cognitive overhead once you understand them and their limitations and workarounds. On the other hand, using white-space padding npm packages may be taking things too far.
Crafting an SVG by hand is fun, but it can easily get out of hand, after which a svg minification tool can do wonders.
I'm working on a small side-project (https://visalogy.com) that the entire site is using less than 20KB JS, and 25KB of CSS. Logo is half a KB, ridiculously small over Brotli/GZip. A fully functional site weights less than 150KB with all assets.
Instead of doing everything by hand, this digital pollution can be removed with proper building process. Automate image compression, uncss, svgmin, etc to the CI pipeline and you will have the best of both worlds.
One upside of saving it as hundreds of lines: You can immediately spot if somebody is copying or stealing your logo. I think very well that that might be intentional.
I just redrew his SVG in Illustrator. 593 bytes. Then I ran it through ImageOptim, which is a frontend to a bunch of jpg/png optimizers and svgcleaner, and got back a 279-byte svg. His is 306. Mine includes the XML namespace his drops, and writes out the path definitions in a very different, more succinct format.
It helps that I know to uncheck "save with Illustrator compatibility" so it doesn't cram a whole text-encoded .AI file into the back of the SVG; I also drew one 5-pt polygon instead of a pair of 3-pt triangles.
Which does not invalidate his core point about "holy crap some machine-made files are stupidly huge". But hand-writing SVG is like trying to hand-write assembly for a modern CPU - collectively, the people who wrote the compiler probably know more clever tricks about optimizing code than you ever will.
If all you care about is the appearance, you can also (in Illustrator) convert the strokes to outlines and then merge all the shapes, and then you’ll just get a single filled path.
Hmm, good call, that gets it down to 122 bytes after optimization. I was mostly optimizing for "minimum time and thought spent vs. reading the SVG spec and hand-writing a file".
Oddly enough if I prune out the four seemingly-superfluous points that result where the shapes overlap it goes back up to 125. SVG's path compression is weeeird.
Far inferior in human-friendliness to read and edit. But less bytes, and editing would realistically involve loading up the AI source file I didn't bother saving and generating a new SVG.
I opened this expecting an opinion piece on how microblogs artificially limited to 160 characters contribute to the ever diminishing signal to noise ratio in regards on the information quality on the internet and perhaps some reflection into the eternal september of all things; not to say that i was disappointed, but it briefly touches a single, very technical aspect (a single plastic straw if you like in an ocean of garbage). Digital pollution is so much more than optimising SVGs and not including 20 megs of javascript - it is the global decline of the noosphere, where truth is buried under mountains of trash, antivax propaganda and the echo from your own AI-crafted hypercustom echo chamber.
What an honest to goodness waste of time. It's fun to challenge yourself with micro optimizations but the time spent on this could have been used on a million things a user cares more about.
I'm not saying perf isn't a feature but if you're playing svg golf you're just doing it for the sport and not the user value and not some altruistic digital pollution argument.
Thats why a prescribed burn, is so beneficial to an ecosystem. Getting rid of tangles of weeds, old, decaying and diseased wood.
Wars and revolutions, sometimes server a similar function for societies.
HTML, Javascript, CSS and the entire tangled mess web front end tech it produced needs to burn!!!!!
I once worked at a place that had massive bandwidth usage. I can't recall the exact numbers but you would show them to people (who knew about such things) and watch them blink. We served hella data.
Our pages were written in PHP by an idiot, a true berk. He liked long lines, heavily indented. Lots and lots of indentation. LOTS of indentation.
I noticed this one day and did a quick bit of hacking to see how much of our traffic was just whitespace. Twenty-five. 25%. One out of every four bytes of our (non-image) traffic was 32 (0x20).
(And, yes, I brought it up, and, no, no one else cared. The CEO was eventually replaced by the investors and now the company is a big ol' success. FWIW)
50 comments
[ 2.7 ms ] story [ 107 ms ] threadI had the same thoughts in mind when writing https://concrete.style and https://louismerl.in.
The same thing applies to code too. There's the principle of using frameworks wherever possible that especially novice programmers stick to without realizing how much harm it can do in the long run.
My personal record is reducing the main code base of an app about 20 times (!) by just removing unnecessary frameworks and replacing others with better ones. No, 20 times applies to the main code, excluding the frameworks. This is the same kind of digital pollution.
Digital stuff such as graphics files, source code, etc scale too easily unfortunately for all of us, developers and users. Every time I open someone else's big iOS project I find about 80% of 3rd party code linked for no good reason. Let alone some essential frameworks that themselves create pollution by pulling endless dependencies (Google being one of the top offenders from my experience).
This is not going to change unfortunately. Digital media is cheap, easy to scale, usually a bit too expensive to get right (i.e. to reduce pollution) and at the same time it's not always easy to see the drawbacks of pollution in the long run.
You can even color SVG with CSS, making it easy to integrate single color icons into color schemes:
https://css-tricks.com/almanac/properties/f/fill/
edit: sigh, I don't know if that's for suggesting to use Inkscape and then remove stuff manually, or for linking css-tricks... so I'll answer to both hypothetical criticisms:
1.) You can't make something like this, as simple as it is, purely by entering numbers into a text file: http://b.sandboxx.org/icons/autonomy.svg
2.) I couldn't find a better page on fill, MDN for example flat out pretends there is no such CSS property, redirecting to SVG: https://developer.mozilla.org/en-US/docs/Web/CSS/fill
But I know CSS has this property because I'm using it, and it's awesome. You obviously don't need it on a site that just has one color scheme, or if using either black or white outlines depending on background is good enough -- but if you want icons that scale and fit any color scheme, and want to avoid digital pollution, this is something you should be aware of.
It's perhaps not that large an exaggeration to suggest that rush hour commuters, one per car, are doing exactly this to each other.
Now we have npm and webpack doing this for Js. It's convinience vs purity.
But now I think the same argument can be made for using C++ over assembly language.
I doubt about the convenience part. With more moving parts, you sooner or later run into problems you couldn't anticipate. I'd rephrase it as "immediate and deceptive feeling of convenience vs. purity and convenience"
They will continue to function for the foreseeable future, with zero build process, no node_modules directory full of tens of thousands of garbage files, no transpiler or bundler version issues, and almost no overhead in understanding the code, even for a bug fix 5 years down the line.
But, I still get funny looks if I tell my front-end friends all this. Sometimes I feel a little crazy.
There used to be a huge need to jquery, bootstrap, polyfills, and other tricks, but many of those features are now available in the built-in languages. If you ignore IE, then you can make elaborate websites just by writing it by hand, doing some plain css grid, svg, html5, etc. How much time is spent resolving npm dependencies and packaging scripts for simple libraries that used to just be adding a .js file to your repo?
Obviously, web applications (that do more than show some content) will need more infrastructure, but I feel like we can safely stick with mostly vanilla languages for web pages that is content-focused. Let's go back to the days where you could learn a lot from View Source, and version control was dead simple.
But I have just imported the Vue code as a script file - no node modules folder ;) Though without Webpack I can't do single-file components properly, which sucks.
So be wise before inflicting this staggering bullshit on your colleagues. Pick your battles.
Also don't overlook that just one byte more can double the amount of packets that need to be sent for something, just a little bloat can mean individual items in a list of millions no longer fully fit in the CPU cache, and so on. We also can't really know how many times things (that are put on the web) get handled by how many computers and users, so any byte you save could be multiplied by infinity. If I can do it easily, cutting out bloat is always good IMO. Personally, I find it enjoyable.
I do have a new line at the end of files now so that Git doesn't complain. That and new lines before some curly braces (either JS/TS/C#, can't recall which) is the only thing I've changed over the last decade+. The fact that I don't recall which I do where suggests I might want to reevaluate that, if it's not in a language that's going to compile it out.
The problem is that this attitude leads not only to waste and inefficiency but also to insecure, unreliable, buggy systems that are incomprehensible even to the people who build them, because they are built on layers of poorly understood, overly complicated trash.
So we have laziness, incompetence, and waste at every level of the stack, and this is celebrated as efficiency.
However, I would find it very hard to justify the extra time for these benefits.
There are simply too many more valuable things I could create with this time.
In any case, I think doing something from first principles is important to understanding a faster tools-based approach.
This also doesn't scale. Where do you start with the garbage? As soon as you start with the OS, you're dealing with a stack of trash. Every layer adds more junk to the pile. Even considering where you should start cleaning is huge decision overhead. Every decision is a potential rabbit hole which can lead to problems. Mo' decisions, mo' problems. Better to keep the decision space clean. I would rather my trash be digital than cognitive.
On the one hand, popular opinion in the profession is to encourage you to launch your product as quickly as possible and then revise rapidly. That naturally leads the developer to reach for time-saving libraries, templates and frameworks. Even, if you're not launching a product, you still reach for a framework because it makes you - to use a favourite term among developers - 'productive'. In other word, everything for the comfort of the developer.
On the other hand, when the developer is on the receiving end of a memory-guzzling app, or a bloated website, they will complain loudly and eagerly point the finger at the designer, the Product Manager, the stakeholders, the boss or whoever - always someone else to blame. What developers won't do is acknowledge that attitudes and practices in the programming profession are the root of many of these problems.
I sometimes wonder if programming is the only profession where so many people aspire to the lowest possible standard, while holding everyone else to a much higher one.
Isn't that just life?
I'm working on a small side-project (https://visalogy.com) that the entire site is using less than 20KB JS, and 25KB of CSS. Logo is half a KB, ridiculously small over Brotli/GZip. A fully functional site weights less than 150KB with all assets.
Instead of doing everything by hand, this digital pollution can be removed with proper building process. Automate image compression, uncss, svgmin, etc to the CI pipeline and you will have the best of both worlds.
It helps that I know to uncheck "save with Illustrator compatibility" so it doesn't cram a whole text-encoded .AI file into the back of the SVG; I also drew one 5-pt polygon instead of a pair of 3-pt triangles.
Which does not invalidate his core point about "holy crap some machine-made files are stupidly huge". But hand-writing SVG is like trying to hand-write assembly for a modern CPU - collectively, the people who wrote the compiler probably know more clever tricks about optimizing code than you ever will.
Oddly enough if I prune out the four seemingly-superfluous points that result where the shapes overlap it goes back up to 125. SVG's path compression is weeeird.
13 points, 122 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z"/></svg>
9 points, 125 bytes: <svg viewBox="0 0 54 54" xmlns="http://www.w3.org/2000/svg"><path d="m27 23-27-27v58h4v-27h46v27h4c0-12 0-46.1 0-58z"/></svg>
d="m27 23-27-27v4 27 27h4v-27h46v27h4v-27-27-4z"
to
d="m27 23-27-27v58h4v-27h46v27h4v-58z"
The cubic bezier curve in your second version seems like some kind of strange artifact.
Far inferior in human-friendliness to read and edit. But less bytes, and editing would realistically involve loading up the AI source file I didn't bother saving and generating a new SVG.
ugh.
Numbers like 10 30 became 10.0000023 29.9999948 and basically everything became complicated.
It was like running a one-line program through a compiler and then a disassembler.
This is what matters, in my humble opinion.
Not everyone’s ideal use of a day, especially when the work is already done and the drop in file size helps (almost) no one.
I'm not saying perf isn't a feature but if you're playing svg golf you're just doing it for the sport and not the user value and not some altruistic digital pollution argument.
Our pages were written in PHP by an idiot, a true berk. He liked long lines, heavily indented. Lots and lots of indentation. LOTS of indentation.
I noticed this one day and did a quick bit of hacking to see how much of our traffic was just whitespace. Twenty-five. 25%. One out of every four bytes of our (non-image) traffic was 32 (0x20).
(And, yes, I brought it up, and, no, no one else cared. The CEO was eventually replaced by the investors and now the company is a big ol' success. FWIW)