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.
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.
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.
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.
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.
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.
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.
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.
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.
Readit News
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>
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.
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.
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.
Deleted Comment
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 what matters, in my humble opinion.
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.
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 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.