Modern coders are also efficient along different axes to the ones we used to care about. Games programmers of all eras are like mainframe programmers in the '60s: they have to optimise for speed, so at least some parts of the code base are to-the-metal. That results in clunky, awful, unmaintainable code. The rest of us put more effort into writing code that's robust against errors and maintainable in the long term, which includes "I can add all the features in v2 without it collapsing into a complete mess." This code is less efficient in speed and space, but CPUs and SSDs are usually cheap compared to engineer-hours (unless you operate at unusual scale.)

Not using Firefox is a good first step to resolving most issues.

I dunno - libraries and frameworks add a massive amount of weight to online projects, and people include them out of habit. And even worse, the lazy-ass "just do it with WordPress" approach that is become more and more common is even worse.

Consider that you can have a dozen people open a Google doc, all editing it, with the changes synced in real time to the windows on everyone else's screen -- all happening within the web browser with sub-second latency. When I was a kid, that was science fiction even to happen on a full native app running across a LAN. Now we can do it within the browser with the backend in the cloud. Why? Because Chrome gives each tab 4Gb of RAM to play with!

Ah. Thank you. I can appreciate now why it took GazChap 6+ years to not get a functioning calendar here.

I dunno - libraries and frameworks add a massive amount of weight to online projects, and people include them out of habit. And even worse, the lazy-ass "just do it with WordPress" approach that is become more and more common is even worse.

;)

You're right, I should have added time to market to the list, too. Probably also price.

Wordpress is absolutely fine unless you let it get out of hand with massive plugins and stuff and then take no extra steps at all to try and make sure the pages load quickly.

I think sometimes people lose sight of what modern web browsers and web sites are. It's not about rendering a simple markup language any more. They're loading multi-threaded applications that need to have memory allocations, process management, interrupts, I/O, and hundreds of other things. In other words, a modern web browser is most of the way to being an entire OS (literally true for ChromeOS, of course.)

Consider that you can have a dozen people open a Google doc, all editing it, with the changes synced in real time to the windows on everyone else's screen -- all happening within the web browser with sub-second latency. When I was a kid, that was science fiction even to happen on a full native app running across a LAN. Now we can do it within the browser with the backend in the cloud. Why? Because web browser are really sophisticated now, is why. And as they grew to subsume more and more desktop apps, so they've become the most complex and heavyweight app you run.

Meh, I feel that's just giving a free pass to shite web development.

And for a lot of people using the Internet, "big" = "slow"

Also that ignores any browser caching, in reality, after the first page most subsequent pages are a few tens of kb.

I'm just saying that frameworks aren't efficient for the end user, and their popularity is a big reason as to why an average webpage is so big.

Kinda. But at the same time you're giving a free pass to shite browser development. It's like driving a car with square wheels and complaining about the state of the roads.

On the other hand, suppose you are going to use 25% of the goodness of one of the big frameworks. Not a crappy bedroom project, but something solidly engineered. You have a choice: use 100% of the framework, or write the 25% yourself. Do you reckon you can write the 25% sufficiently well, on your own, that it's faster than loading 100% of the framework? In the process, will you avoid all the tricky security problems the framework folks have thought about that you've never heard of? Will you be as fast to write patches when new security problems are discovered? When you come to write v2 which needs something in the framework, taking you from 25% to 40%, will it take you months to build out the home-grown version rather than days to integrate some framework call that does the heavy lifting?

There's more factors at play than you're admitting here.

On the other hand, suppose you are going to use 25% of the goodness of one of the big frameworks. Not a crappy bedroom project, but something solidly engineered. You have a choice: use 100% of the framework, or write the 25% yourself. Do you reckon you can write the 25% sufficiently well, on your own, that it's faster than loading 100% of the framework? In the process, will you avoid all the tricky security problems the framework folks have thought about that you've never heard of? Will you be as fast to write patches when new security problems are discovered? When you come to write v2 which needs something in the framework, taking you from 25% to 40%, will it take you months to build out the home-grown version rather than days to integrate some framework call that does the heavy lifting?

There's more factors at play than you're admitting here.

Not really. What he said is exactly right. Frameworks aren't efficient for the end user, and they contribute to the size of a webpage. Your objection is from the perspective of the site author - which is fine, but not really particularly relevant.

End users care just as much about how long it takes to write features and security, albeit indirectly.

What's your take on a modular framework then, where you can strip out guff you don't need before downloading?

What's your take on a modular framework then, where you can strip out guff you don't need before downloading?

I don't think they do. Remember that the end users aren't people like us

They might care about those things, but they don't give a fuck how you do them.

("Why can't I do X" and "what the fuck you lost my credit card details?")

I added more in an edit.

End users care just as much about how long it takes to write features and security, albeit indirectly. ("Why can't I do X" and "what the fuck you lost my credit card details?")

I think Grim...'s argument is against shit frameworks, rather than frameworks in general. Maybe all JavaScript frameworks are shit. Certainly, hardly any of them appear to be old enough to credibly claim to have matured out of the half-baked-stuff-thrown-on-github stage.

Also relatedly Grim..., what did you use to detect the unused css styles?

A mess of JavaScript that I bunged into the console.

There's almost certainly plugins that can do the same thing, though.

Turns out the Chrome Audit tab does it, too (this page has 87).

If you're interested in performance, I highly recommend getting to grips with Chrome's Timeline and Profiling capabilities, which are complicated but astoundingly powerful.

I've seen the Chrome audit tab, but it only does the current page, which means you have to cross reference every page on the site to find that rule that's only used in one popup three screens deep or something.

Ah yes, you would indeed. Take a look at this: https://addyosmani.com/blog/removing-unused-css/

Obviously having the one argument isn't enough, so I'm also going to say that Bootstrap is the fucking Devil, for pretty much the exact same reasons.

They all look to be ones where you have access to the code that controls the site of course. I'm happy with my solution for that*, I just didn't know if you had something whizzy for doing other people's sites.

Of course it is, it's written in JavaScript. If you lie down with dogs, you get up with fleas.

Very soon (if not already) the average size of a single web page will be bigger than the install image for Doom.

Turns out "very soon" is roughly now.

http://www.theregister.co.uk/2016/04/22 ... g_as_doom/