Hacker News Reader

Comment by tomxor | Hacker News Reader

Nice work!

My only suggestion is to optimise it, which we have :) (Lifting this from lower down in the thread). The following SVG fragment is a drop in replacement for the <img> tag and produces the same result, albeit completely symmetrical as a side effect of quantising the coordinates:

    <svg width="18" height="18" viewBox="-32 -32 64 64"
     style="background: #f60; border: 1px white solid;">
     <path fill="#fff" d="m0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/>
    </svg>

This reduces the total payload from 1448 bytes to 172 bytes including whitespace (I ungolfed it slightly to make it less hacky). By comparing both the inline <img> tag, and the svg file and it's HTTP header (which disappears when you inline).

View on HN

Choosing a viewBox of size 64 as you have, is a much better choice than 100, because 64 is a power of 2. Symmetry is hard to achieve by hand with a path, and even harder if the origin is at the top left (0,0) instead of in the center (as you also have), because it's obvious that -3 is symmetrical to 3, and less immediately obvious that 47 is the opposite of 53 for example.

That said, if working entirely by hand, using elementary shapes can be easier to write and understand (I think); here's an attempt with using one rectangle three times for the Y (and another rectangle to mask the edges at the top):

    <svg width="18" height="18" viewBox="-32 -32 64 64" 
        style="background: #f60; border: 1px white solid;">
        <rect x="-3" y="-2"  width="6" height="24" fill="white" id="rc1"/>
        <use href="#rc1" y="-22" transform="rotate(-34) scale(1, 1.2)" id="rc2"/>
        <use href="#rc2" transform="scale(-1,1)"/>
        <rect x="-30" y="-30" width="60" height="12" fill="#f60"/>
        </svg>

Cool! Here is a little smaller version of yours. Spaces and color abbreviation. That word “background” sure is big here.

Stop it! If you bastards optimize this any more, you'll hit the fractal limit, and drop into negative optimized space, renting local spacetime, killing us all!

Is it really worth it? Is it?!?!

Ok, but my point was to be readable and easy to understand by using elementary shapes (rectangles), not to be as small as possible. (My version is much bigger than the comment it was replying to.)

But is it an optimisation to send the SVG contents in every request, instead of just letter the browser cache the image?

Yes, retrieval from disk caching is not as fast as one would expect. Detailed article: https://simonhearne.com/2020/network-faster-than-cache/

Speed is not the only criterion. Using network is a waste of energy and materials when the local cache was enough (even more when nobody sees the perf difference)

Since the svg is not inline but rather loaded externally it is being cached aswell. (source https://stackoverflow.com/questions/37832422/how-can-we-cach...)

That's a valid point, for subsequent loads in this case the inline svg is so small that when compared to the image tag it's replacing the difference is pretty small.

But the other side of this is cache latency, this depends on the caching policy defined in the http header, for example some modes require validating caches with the server which incurs a round trip even if it doesn't require always reloading the resource. If it's fully offline caching then as a sibling comment pointed out, disk caching is not free either, under some threshold (which definitely applies here) inline is going to be the fastest way to get an svg rendering.

When optimizing for lighthouse pagespeed metrics, yes.

This one is based on yours, which is quite elegant, and the total payload is only 115B:

  <svg viewBox="-32-32 64 64">
   <path fill="#f60" d="m-31-31H31V31H-31z M0-5l-8-12h-7L-3 1v16h6V1l12-18H8z"/>
  </svg>

It assumes a white canvas, otherwise a background must be added at line 2

  <path fill="white" d="M-32-32 h64 v64 h-64 z"/>

Spaces can be deleted of course.

What does “ungolfed” mean?

It's a reference to "code golf", where you try to make your code as compact and the least number of bytes possible.

"Ungolfed" in this context means that it was cleaned up to make it more readable, at the expense of adding a few more bytes to the size.

And "code golf" got its name because better scores are a lower number of (key)strokes.

For completion: https://en.wikipedia.org/wiki/Kolmogorov_complexity

Oh I use 'unminified' for that. Even though someone deliberately wrote minified code rather than automatically, so sometimes people disagree. Maybe 'ungolfed' is better.

there's a difference. unminified refers to a program doing that, using single letter function names and such, but the underlying logic is unchanged. code golf is different from that because the human can make changes to the underlying logic if it saves some lines of code, so long as the output is the same.

more advanced minifiers do that as well, but the point remains, as a historical artifact because until we have AGI, there's still a difference between if a person did it vs a human

> unminified refers to a program doing that

I personally also use 'unminified' to refer to a horrible person that doesn't care about anyone else maintaining their code doing the same thing, like they're manually minifying their code to obscure it from their colleagues and future selves.

I wanted to make that definition more popular as there is no reason to write unsearchable code that requires someone else to maintain a mental map of meaningless names to their actual meanings while reading code.

A lot of people (you're one, nothing personal, but I explained this already in a parent comment) don't realize I'm deliberately calling attention to bad behavior and just think I'm confused though. I'll swap to ungolfed.

Reply on news.ycombinator.com