Live data from Hacker News

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

mobiforge.com

301–310 of 467 posts

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

#301
post #269

Earlier quoted context omitted.

No need for a plugin if you are running Linux or OSX: # Bandwidth trottling, enabling 150kB/s on port 80 sudo ipfw pipe 1 config bw 15KByte/s sudo ipfw add 1 pipe 1 src-port 80 # Bandwidth trottling, disable sudo ipfw delete 1 More useful stuff here as well, please star the repo :) https://github.com/logotype/useful-unix-stuff/blob/master/us...

It's not a plugin, it's built into chrome. His joke was about a plugin that enables it permanently for certain people.

Not to mention my account managers and BDM's don't even know what a linux is.

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

#303
post #245
post #161

Earlier quoted context omitted.

I think a plugin that enables the chrome "regular 2G" throttling (developer tools / network tab), permanently, for anyone that works in marketing or web development might help :) Edit: Joking aside, that throttling feature is a nice easy way to let a dev team, or business counterpart, see what their site is like for say, a customer with a low-end DSL connection: https://developers.google.com/web/tools/chrome-devtools…

I have to think that the devs want to make the page lighter, but their managers keep pushing more tracking and ad networks at them that they're forced to integrate.

This. I have my own site slim and lean even with javascript (analytics) in there and it loads in 300-500ms. I developed a site for a client that was slim and lean and then it started. Sliders, full page background images, photos of random people, 3x analytics, this and that. It became a mammoth of 2-3mb and loading times of 1.5-3s.

When we tracked conversion the best converting page on the site was one made specifically for that and it is 100kb and loaded instantly. Two images and lots of text. They still insist on slow, beautiful pages elsewhere instead of making them convert as well.

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

#304

I'm skeptical that developers talking to each other about how bad web bloat is will change anything. They will still face the same incentives in terms of ad revenue, costs of optimization, etc. Here's a random idea that might have more potential: create an adblocker browser plugin that also colors URLs based on how slow they are expected to load, e.g., smoothly from blue to red. The scores could be centrally calculat…

I think a more radical departure is needed. It's about time to acknowledge that the web is increasingly being used to access full-blown applications more often than "webpages."

Web browsers have more or less become mini operating systems, running elaborate virtual machines. There's way too much complexity for everyone involved — from web devs and browser devs to the users and the people who maintain the standards, then there's the devs who have to make native clients for the web apps — just to deliver products that don't have half the power of OS-native software. Everyone has to keep reinventing the wheel, like with WebAssembly, to fix problems that don't have to be there in the first place, not anymore:

Thanks to smartphones, people are already familiar with the modern concept of the standalone app; why not just make downloading an OS-native binary as easy as typing in a web address, on every OS?

Say if I press Cmd+Space on a Mac and type "Facebook" in Spotlight, it immediately begins downloading the native OS X Facebook app. The UI would be described in a format that can be incrementally downloaded, so the experience remains identical to browsing the web, except with full access to the OS's features, like an icon in the Dock and notifications and everything.

TL;DR: Instead of investing resources in browser development, Android/iOS/OSX/Windows should just work on a better standard mechanism to deliver native apps instead.

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

#305

Earlier quoted context omitted.

There are approximately 5 million different CDNs hosting different versions of jQuery. Cache hits are actually quite low.

Three popular ones is not "approximately 5 million": Google, cdnjs, MaxCDN.

even the sites using one of these 3 CDNs probably specify aa specific minor version of jQuery from this list http://code.jquery.com/jquery/

(OK, so I doubt many sites are specifying the beta or uncompressed versions, but there's still a pretty good chance that somebody hasn't downloaded the relevant version from the relevant CDN recently enough for it to be in their cache, especially if they're browsing on their phone)

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

#306

Earlier quoted context omitted.

var obj = {...} // native JavaScript Object.keys(obj).forEach(function(key){ console.log('obj.', key, ' = ', obj[key]) }) // Lodash _.forEach(obj, function(value, key) { console.log('obj.', key, ' = ', value) }) Object.keys(obj) creates an array that contains the keys of the object, which makes it pretty trivial to call filter, map, reduce, etc. And getting the value from an object's key is also pretty straightforwar…

Ruby: obj.each{|k,v| ...} Sure you can do it in JS, but calling Object.keys then forEach (in whose closure you'll still have to reference obj[key] by the way) still doesn't feel optimal.

I would argue that automatically adding methods to a user-created object isn't optimal either.

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

#307

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…

This seems a little redundant - why not just

    
? If you wanted to explicitly fetch from google if the client doesn't have a cached copy, then instead do

    
The first would seem preferable though, as loading from an external source would expose the user to cross-site tracking.

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

#308

I'm skeptical that developers talking to each other about how bad web bloat is will change anything. They will still face the same incentives in terms of ad revenue, costs of optimization, etc. Here's a random idea that might have more potential: create an adblocker browser plugin that also colors URLs based on how slow they are expected to load, e.g., smoothly from blue to red. The scores could be centrally calculat…

I think a more radical departure is needed. It's about time to acknowledge that the web is increasingly being used to access full-blown applications more often than "webpages." Web browsers have more or less become mini operating systems, running elaborate virtual machines. There's way too much complexity for everyone involved — from web devs and browser devs to the users and the people who maintain the standards, th…

What constitutes "way too much complexity" ? What if browsers are evolving with whatever resources are available to them at just the right pace. Why would you want the browser to be hindered by an arbitrary speed/resource limit. Let it soar to the sound of fans going full speed!

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

#309

I'm skeptical that developers talking to each other about how bad web bloat is will change anything. They will still face the same incentives in terms of ad revenue, costs of optimization, etc. Here's a random idea that might have more potential: create an adblocker browser plugin that also colors URLs based on how slow they are expected to load, e.g., smoothly from blue to red. The scores could be centrally calculat…

I think a more radical departure is needed. It's about time to acknowledge that the web is increasingly being used to access full-blown applications more often than "webpages." Web browsers have more or less become mini operating systems, running elaborate virtual machines. There's way too much complexity for everyone involved — from web devs and browser devs to the users and the people who maintain the standards, th…

That sounds ambitious, interesting, and like a lot more work than keeping a webpage running. My first thought is "cross-platform nightmare". My second thought is that they'd have to rethink their expectations of continuous deployment/release and a/b testing.

We're either looking at making individual pages maintain binaries for the platforms they support (implying support of only those platforms that make sense to the site) or some kind of compilation framework running on the local machine.

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

#310

Oh, you just want to add a class to the element? \ adds whole jQuery\ That's what's wrong with the web. Oh, and you need a loop? \ adds underscore.js\

It would help if the basic javascript api's were even vaguely useful I recently tried to force myself not to use any libraries for a simple site. After a while I realised I had so much re-invention of stuff (AJAX in particular is madness without a library) that I ended up adding Zepto With all the crap they're adding in ES6 you would have hoped they would add an ajax function at least

Neither XMLHttpRequest, nor the Fetch API mentioned in a sibling comment are part of the JavaScript language. They are both web platform specs maintained by the WHATWG. The JavaScript committee (TC39) does not control these platform APIs.
Post reply on HN