Blizzard:

> If this had been the opposing viewpoint delivered in the same divisive and deliberate way, we would have felt and acted the same.

Also Blizzard:

> We will defend the pride of our nation (that nation being China)

So when will they be terminating the people in their company that posted that announcement on behalf of the company? Oh wait, they won't be, because this company is completely and utterly full of shit. This is a company that will ban players for using naughty words, but won't ban a country from the market place for actual real life atrocities. People like this make me ashamed to be American. Honesty and integrity mean nothing in this country. All people care about is whether you use nice words.

The word “nation” as you quoted above isn’t present in the post by Blizzard linked here. Is your quote from another Blizzard statement somewhere?

It was posted by Blizzard's partner in China, NetEase, on an official Blizzard account on weibo.

It was made by a company that works for blizzard under blizzard's name as an official blizzard response to the event. Your failure to include this information makes it look like you are attempting to mislead people.

the programming community never ceases to amaze me

There's too much filler in this article for me to understand what's being conveyed.

The article is geared towards front end engineers, clarifying how and when to compress images and which formats to choose. It stresses the importance of the image context more than the technicalities of the image. This context can also lead to the decision to choose other types of image, such as choosing a simplified drawing instead of a photo when the image context is icon-like.

Use svgs*

* when you can

I just went through a project where we deliberately converted all SVGs to PNGs (using an image CDN where we could request different transformed resolutions) and it resulted in MUCH better performance, both in tools like PageSpeed and in perceived performance, for 2 major reasons:

1. The PNGs tended to be MUCH smaller than the SVGs, and I think you'll find this likely whenever you have even a very minorly complicated graphic (the article points this out).

2. There is an issue on Android devices where scrolling was absolutely awful when there were lots of large SVGs on the page. This completely went away when we switched to PNGs.

I think the best recommendation is to store the initial image either as an SVG or very high resolution raster image, but then use an on-the-fly transforming CDN so you can experiment and easily get the right image (size and format) where necessary.

SVG is an incredibly inefficient way to represent a line drawing,with all the coordinates written out as text, and not as deltas from the previous one. Flash's internal representation is much tighter, but not cool any more.

SVG can do relative coordinates fine: "m 10 10" (m dx dy) rather than "M 10 10" (M x y). But yes, they're text until you compress them.

Yes, but unless you round the floating point digits, you're going to use about as much bytes.

The parent is correct. At some point we gained a fear of binary formats, but binary formats are still the only way to transfer data efficiently.

Yes, flash had other problems. No, this doesn't make their point false.

Is that really true with gzipping?

Browsers still need to unzip and parse the SVG, and store the DOM representation of it.

Any examples you mind sharing?

One case where you probably can't is for image uploads. You might think it would be nice to allow a user to upload a svg for their avatar or something.

But SVG can embed javascript which can lead to XSS: https://hackerone.com/reports/148853

That's certainly something to be considered with user uploaded svg images. However it's reasonably straightforward to parse an svg and remove any script elements.

You can safely use XSLT to subset SVG, and (for example) limit complexity. Scripts in SVGs do not load in img tags either.

No wonder scrolling is bad for us! Without line-tracking, scrolling kinda culls our attention span, patience and retention—all in one stroke. ;-)

I found the article very nicely written and do not think there was filler in there.

they didn't limit ads. they banned them altogether. it's a charitable thought, but doesn't hold up.

That was the correct thing to do. Considering how many npm packages the average project consumes, having even a single line of advertising for each would make npm a pain in the ass to use, and people would be looking for ways to block the ads.

Clearly, you didn't read the article from the original author. Ads were deduplicated, so only a single ad was shown, even if 500 deps used the funding dependency.

That’s a big _if_. Until now, each package with ads have rolled their own, and since there’s probably more money to be had that way, there’s no reason that would not continue.