8 ms·

Digital pollution

108 points by galfarragem 7y ago

louismerlin 7y ago
Very cool ! I had the same thoughts in mind when writing https://concrete.style https://concrete.style and https://louismerl.in https://louismerl.in.
mojuba 7y ago
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.
PavlovsCat 7y ago
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 7y ago
  > 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.
Crazyontap 7y ago
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.
- mojuba 7y ago
  > It's convinience vs purity. 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"
- sgn 7y ago
  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.
- 83457 7y ago
  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.
alanbernstein 7y ago
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.
- deleted 7y ago
  [deleted]
- lazyjeff 7y ago
  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.
  - bleuarff 7y ago
    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.
  - marcus_holmes 7y ago
    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.
CoolGuySteve 7y ago
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 7y ago
  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 7y ago
    And yet they invented another technology (amp) to solve the crappy situation. Thus, people added more layers over existing layers.
- PavlovsCat 7y ago
  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.
  - james-skemp 7y ago
    Removing spaces from the end of lines, changing double spaces in HTML to one, and using tabs for indentation, these are a few of my favorite things.
    - throwaway744678 7y ago
      And most importantly, use only one-letter variables. Mother Earth will thank you.
mindhunter 7y ago
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.
ferros 7y ago
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 7y ago
  You're both right. In any case, I think doing something from first principles is important to understanding a faster tools-based approach.
gexla 7y ago
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.
open-source-ux 7y ago
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 7y ago
  > 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 7y ago
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.
Ayesh 7y ago
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.
countryqt30 7y ago
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 7y ago
  I wonder if he can draw some tiny text hidden behind one of the opaque parts that says "This logo was created by...".
  - schoen 7y ago
    Yes, or an element with display="none", or an SVG comment, or SVG author metadata. :-)
werber 7y ago
https://jakearchibald.github.io/svgomg/ https://jakearchibald.github.io/svgomg/ This is a great tool to really shrink your svg bloat
egypturnash 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
arpa 7y ago
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 7y ago
  Google ads are digital pollution.
thomas 7y ago
> 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.
zahreeley 7y ago
Google ads are digital pollution.
jayd16 7y ago
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.
jungletime 7y ago
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!!!!!
carapace 7y ago
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)

108 points by galfarragem 7y ago

Very cool ! I had the same thoughts in mind when writing https://concrete.style https://concrete.style and https://louismerl.in https://louismerl.in.

mojuba 7y ago

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.

PavlovsCat 7y ago

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 7y ago
> 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.

Crazyontap 7y ago

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.

mojuba 7y ago
> It's convinience vs purity. 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"
sgn 7y ago
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.
83457 7y ago
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.

alanbernstein 7y ago

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.

deleted 7y ago
[deleted]
lazyjeff 7y ago
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.
- bleuarff 7y ago
  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.
- marcus_holmes 7y ago
  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.

CoolGuySteve 7y ago

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 7y ago
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 7y ago
  And yet they invented another technology (amp) to solve the crappy situation. Thus, people added more layers over existing layers.
PavlovsCat 7y ago
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.
- james-skemp 7y ago
  Removing spaces from the end of lines, changing double spaces in HTML to one, and using tabs for indentation, these are a few of my favorite things.
  - throwaway744678 7y ago
    And most importantly, use only one-letter variables. Mother Earth will thank you.

mindhunter 7y ago

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.

ferros 7y ago

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 7y ago
You're both right. In any case, I think doing something from first principles is important to understanding a faster tools-based approach.

gexla 7y ago

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.

open-source-ux 7y ago

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 7y ago
> 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 7y ago

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.

Ayesh 7y ago

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.

countryqt30 7y ago

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 7y ago
I wonder if he can draw some tiny text hidden behind one of the opaque parts that says "This logo was created by...".
- schoen 7y ago
  Yes, or an element with display="none", or an SVG comment, or SVG author metadata. :-)

werber 7y ago

https://jakearchibald.github.io/svgomg/ https://jakearchibald.github.io/svgomg/ This is a great tool to really shrink your svg bloat

egypturnash 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.

arpa 7y ago

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 7y ago
Google ads are digital pollution.

thomas 7y ago

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

zahreeley 7y ago

Google ads are digital pollution.

jayd16 7y ago

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.

jungletime 7y ago

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

carapace 7y ago

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)