Live data from Hacker News

The average size of Web pages is now the average size of a Doom install

mobiforge.com

121–130 of 467 posts

Re: The average size of Web pages is now the average size of a Doom install

#121

Earlier quoted context omitted.

I hear this argument a lot, and I very much disagree. Now you have browser vendors having to device which libraries are "popular" and shipping them in the initial download of the browser. It turns out that this technology already exists in a much better form. It's called cache. The problem is that almost everyone hosts their own version of jQuery. If everyone simply linked the "canonical" version of jQuery (the CDN l…

What if the checksum was the same and you accepted the cache hit if the checksum agrees and get your own copy if it doesn't? Maybe the application should get to declare a canonical URL for the js file instead of the browser? So something like https://ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.m... sha-256="31be012d5df7152ae6495decff603040b3cfb949f1d5cf0bf5498e9fc117d546"> Would this cause more problems than i…

>How easy is it to create a malicious file that matches the checksum of a known file?

I'd say not easy at all, practically impossible.

https://en.wikipedia.org/wiki/Preimage_attack

Re: The average size of Web pages is now the average size of a Doom install

#122
post #49

Earlier quoted context omitted.

I would say that a possible solution is also to better rank websites that mention the checksums of their external resources and make web browsers keep them in cache much longer... if pretty much every website uses jQuery, perhaps we should ship jQuery with the web browser?

I hear this argument a lot, and I very much disagree. Now you have browser vendors having to device which libraries are "popular" and shipping them in the initial download of the browser. It turns out that this technology already exists in a much better form. It's called cache. The problem is that almost everyone hosts their own version of jQuery. If everyone simply linked the "canonical" version of jQuery (the CDN l…

The problem with hosting JS libraries on CDNs is that the cache has a network effect.

You only gain performance if the browser already has a cached version of this specific version on this specific CDN. If you don't - you end up losing performance, because now an additional DNS lookup needs to be performed, and an additional TCP connection needs to be opened.

Here are a few reasons people choose to avoid CDNized versions of JS libraries. http://www.sitepoint.com/7-reasons-not-to-use-a-cdn/

This is a 6 year old post, but it raises some valid concerns: https://zoompf.com/blog/2010/01/should-you-use-javascript-li...

Re: The average size of Web pages is now the average size of a Doom install

#123
I legitimately do not understand why webdevs insist on learning new, equally complicated API's to do things that raw HTML/ CSS/ javascript are already perfectly capable of doing just as easily. Not only do you have to write your code, but you also have to learn the new API for the framework flavor of the month.

So much about frameworks just flat out doesn't make sense. Are you honestly telling me that it's more efficient to make a second DOM in a language with much more overhead than the native C++ implementation? Best case scenario is that you consume twice the resources. There seems to be a serious case of monkey-see-monkey-do in the web development community.

Re: The average size of Web pages is now the average size of a Doom install

#124

Earlier quoted context omitted.

I hear this argument a lot, and I very much disagree. Now you have browser vendors having to device which libraries are "popular" and shipping them in the initial download of the browser. It turns out that this technology already exists in a much better form. It's called cache. The problem is that almost everyone hosts their own version of jQuery. If everyone simply linked the "canonical" version of jQuery (the CDN l…

> If everyone simply linked the "canonical" version of jQuery (the CDN link is right on their site) then requiring jQuery will be effectively free because it will be in everyone's cache. So create one massive target that needs to be breached to access massive numbers of websites around the world? Imagine if every Windows PC ran code from a single web page on startup every time they started up. Now imagine if anything…

The solution to this is including a checksum with the link to the file, and if the checksum doesn't match, don't load the file.

See https://developer.mozilla.org/en-US/docs/Web/Security/Subres... though it isn't universally supported yet.

Re: The average size of Web pages is now the average size of a Doom install

#125

Earlier quoted context omitted.

I hear this argument a lot, and I very much disagree. Now you have browser vendors having to device which libraries are "popular" and shipping them in the initial download of the browser. It turns out that this technology already exists in a much better form. It's called cache. The problem is that almost everyone hosts their own version of jQuery. If everyone simply linked the "canonical" version of jQuery (the CDN l…

What if the checksum was the same and you accepted the cache hit if the checksum agrees and get your own copy if it doesn't? Maybe the application should get to declare a canonical URL for the js file instead of the browser? So something like https://ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.m... sha-256="31be012d5df7152ae6495decff603040b3cfb949f1d5cf0bf5498e9fc117d546"> Would this cause more problems than i…

> How easy is it to create a malicious file that matches the checksum of a known file?

As others have pointed out, it's quite difficult. But here's another way to think about it: if hash collisions become easy in popular libraries, the whole internet will be broken and nobody will be thinking about this particular exploit.

Servers won't be able to reliably update. Keys won't be able to be checked against fingerprints. Trivial hash collisions will be chaos. Fortunately, we seem to have hit a stride of fairly sound hash methods in terms of collision freedom.

Re: The average size of Web pages is now the average size of a Doom install

#127

The Doom install image was 35x the size of the Apollo guidance computer. Thirty-five times! Apollo software got us to the moon. Doom wasted millions of man-hours on a video game. My point of course is that these comparisons are not actually that illuminating. Are web pages much heavier than they need to be? Yes. This presentation very capably talks about that problem: http://idlewords.com/talks/website_obesity.htm Do…

> Apollo software got us to the moon. Doom wasted millions of man-hours on a video game.

Well, to be honest, Episode 1 and Episode 2 of Doom takes place on Phobos and Deimos, so you could say Apollo software got us to the moon but Doom got us to Mars :)

Re: The average size of Web pages is now the average size of a Doom install

#128

If web bloat is a problem, I don't think that looking at whether can be removed is the answer. I suggest that at the moment, we have basically two camps of website, with rough, fuzzy boundaries. 1. A place where someone sticks up an insight, or posts a wiki page, or whatever, to share some thought to others (if anyone actually cares). The blogs of many users of HN. Hacker News itself. Wikipedia. The Arch Linux Wiki.…

I dig that you tie this domain-specific problem with that much larger social issue.

Re: The average size of Web pages is now the average size of a Doom install

#129

...and my first computer had 128 bytes of RAM. And a 300-baud modem.

That's amazing, what was it? My first computer had 5K of RAM.

Altair 8800, kit from MITS. And I wrote a game on it, using keyboard and screen.
Post reply on HN