
Digital pollution - galfarragem
https://sivers.org/polut
======
egypturnash
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.

~~~
jacobolus
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.

~~~
egypturnash
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.

13 points, 122 bytes: <svg viewBox="0 0 54 54"
xmlns="[http://www.w3.org/2000/svg"><path](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](http://www.w3.org/2000/svg"><path)
d="m27 23-27-27v58h4v-27h46v27h4c0-12 0-46.1 0-58z"/></svg>

~~~
jacobolus
You can shorten

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.

------
alanbernstein
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.

~~~
lazyjeff
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.

~~~
marcus_holmes
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.

------
gexla
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.

------
arpa
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.

This is what matters, in my humble opinion.

~~~
zahreeley
Google ads are digital pollution.

------
Ayesh
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](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.

------
open-source-ux
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.

~~~
cosmojg
> 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?

------
perspective1
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.

------
jayd16
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.

------
Crazyontap
Same has happened for HTML since 2000 ever since Microsoft created Frontpage
and Adobe created dreamweaver. Just bloat over bloat of html.

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.

~~~
83457
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.

------
mojuba
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.

------
thomas
> Today I spent the day creating the EPUB’s XML and XHTML by hand, instead of
> using a generator.

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.

------
PavlovsCat
Or use something like Inkscape, but then remove all the extra stuff manually.

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/](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](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](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.

~~~
sokoloff
> 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.

------
ferros
I applaud your efforts and the idea behind your action.

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.

~~~
m463
You're both right.

In any case, I think doing something from first principles is important to
understanding a faster tools-based approach.

------
mindhunter
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](https://github.com/RazrFalcon/svgcleaner-gui) to clean up the svg file
after export.

------
carapace
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)

------
louismerlin
Very cool !

I had the same thoughts in mind when writing
[https://concrete.style](https://concrete.style) and
[https://louismerl.in](https://louismerl.in).

------
CoolGuySteve
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.

~~~
shantly
OTOH, most of the Web is slow and crappy thanks to layer after layer of piled
up “saving 95% of a small number isn’t worth my time” attitudes.

~~~
sgn
And yet they invented another technology (amp) to solve the crappy situation.
Thus, people added more layers over existing layers.

------
jungletime
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!!!!!

------
werber
[https://jakearchibald.github.io/svgomg/](https://jakearchibald.github.io/svgomg/)
This is a great tool to really shrink your svg bloat

------
countryqt30
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.

~~~
netsharc
I wonder if he can draw some tiny text hidden behind one of the opaque parts
that says "This logo was created by...".

~~~
schoen
Yes, or an element with display="none", or an SVG comment, or SVG author
metadata. :-)

