Be Excellent To Each Other

Hah! I just *knew* you'd bite.

(To be fair I was the absolute opposite; awfully anal,purist and stuffy about it all. Despite the devices I was programming then largely using BASIC (or in the case of the Psion Organiser, OPL - a sort of quasi PASCAL/BASIC hybrid if memory serves, though it's been an awfully long time), I'd have rather died than use so much as a single unstructured procedure call/direction, line numbers or any of that shit. If the core code took more than a single screen (with upteen horizontal procedures, themselves often nested 3, 4, 5 deep), it was wrong)

Ah, them's were the days - 64KB was considered an absolute luxury, and writing to EEPROMs was the way forward.

That's a fair description. I've written some OPL in the distant past, although not much.


The project I'm working on now has required us to write a service broker server to sit between our team's product and another team's product; as of right now the shim layer is 5,255 functional lines of code (ie. every line that isn't blank), plus 4,287 lines of tests. The source directories alone are 449 Kb and 229 Kb!

That's just amazing Doc, boggles the mind. Fair play to you.

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

Beex, perhaps not so surprisingly, is incredibly small in the grand scheme of things - < 200KB for most pages.

Why does this happen? Are coders just less efficient?

No*, websites do more stuff, and no-one cares about dial-up users any more.

* Although you could argue it's a factor. I'm looking at you, Bootstrap.

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.)

And you can totally feel it, in my experience. Somewhere between 30-50% of the time I open a link in a new tab my entire browser freezes up for anything up to five seconds while (what I'm guessing is) shittons of fucking JavaScript in the new tab loads up. To give a couple of recent examples, Imgur does it pretty often and something like Google Play is fucking terrible for it. This is on Firefox at home and in the office so presumably it's not down to my specific setup as we're talking two difference versions of Windows and of Firefox itself. My suspicion is that people don't think they need to be efficient with code any more and just pile pages up with fucktons of terribly written crap coming from loads of difference sources all over the place.

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

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

Imgur is actually pretty small (< 300KB, and that includes the images). Maybe the JS behind it is hard for a browser to parse, though.

Web browsing has become massively resource-hungry over the past few years, though.

That's really interesting. Thank you. So, old code is more efficient for the job it does but has to be rewritten each time you want to add something to it, and modern code has to be considerably more complex due to the fast rate of change in its environment?

It's not old versus new - it's what's more important to you out of speed, reliability, or extensibility.

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.

Meh, I feel that's just giving a free pass to shite web development. I prefer the look and feel of FF vs Chrome, though admit I couldn't give you any concrete reasons to prefer one over the other. Well, except the fact that bookmark syncing works on FF here in the office but is somehow blocked on Chrome. Evil Inc doesn't really trust Chrome so the build we've got is hobbled in a few ways.

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.

Also, they have to be FASTEST! No-one cares about reliability, not many people care about usability, and fewer still care about things that don't involve dispalying web pages.

FASTEST! MAKE MY INTERNET GO!

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. Having redesigned our site in it the page load times are well in line with the previous hand-coded version. It was also far quicker to do and easier to manage day to day. The lazy approach there would have been to just stick with what I knew.

FeEx.

It really winds me up sometimes when clients come back to us and say that they've had someone do an "audit" of their website and it's too slow and has too much unnecessary JavaScript and CSS.

Yeah, sometimes we're not as optimal as we could be (more out of clients wanting things super-quick more than anything else) but often their old website was done badly using something like WordPress or (*shudder*) Joomla, with a smorgasbord of plugins shoved in with little thought, which basically means that the content of the page is about 5 lines near the bottom of the HTML, and the other 300 lines are a mess of inline JavaScript, CSS and a million different <script> elements loading external .js files.

Hnngngngngh.

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

There's a reason my Chromebook has 16 GB of RAM.

Now that I think about it, it also has a 64 GB SSD, which is probably the lowest ratio of mass-storage-to-RAM on any device I've ever owned.

Time to market is huge for startups, who drive a disproportionate about of the conversation about tooling because they are more vocal and public about what they use.

It really isn't.

I totally agree that it's easier and faster to build something using it, but it throws in a load of stuff you're never going to need, and it certainly throws in stuff the end user doesn't care about.

Looking at the website you made (and I should stress that I'm not criticizing the site itself, I think it looks good) the front page comes in at 2MB. That's huge for a static website which (and I confess I've not looked that hard) isn't doing anything besides displaying stuff on the screen. Case in point - it has 4,509 unused CSS styles.

Again, I'm not saying that's not the best way to do things - budget, ease of use and time available made it the best choice. But it's certainly contributes to websites being so big.

Yeah but on the front page there's a Twitter feed, YouTube videos and loads of press release pictures, an average page comes in at 7-800kb and pages have an average load time of 1-2s.

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

I genuinely wouldn't complain if I only got performance issues in websites such as you describe. When a site that only exists to serve up a single medium res image can't do so without my browser choking then I think we've got a problem. And bearing in mind this is still happening on lots of sites despite the fact I've loads of custom Adblock filters setup to do stuff like fuck off all the bullshit social media widgets and whatnot that festoon most pages these days. I shudder to think what my experience would be look if it was also loading up all that utter, utter, utter shite.

I'm not saying it's slow (or bad*), I'm saying it's big.

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

* You'd have to pay me to tell you why that is

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.

You can't cache script processing, though. I turned my cache on and hit up a random subpage, and it spent more than half a second on Scripting. Again, there was nothing on the page (beside the menu) that I could see that needed anything doing.

I'm going to stop now, because it looks like I'm having a go about your website, and I'm really not. 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.

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.

Heh. I was bitching like a sailor about the state of Bradford's road surfaces and then I found out the car had 2 snapped front coil springs.

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.

Oh, absolutely, but that's still all stuff that the end user couldn't care less about. I'm just saying all that shit be big.

(Also - yes Also also - frameworks can cause as many problems as they solve, as I'm sure you've found out - mainly when you ask them to do something and they can't, so you have to add it yourself, then maintain it, etc, etc. Don't think I don't use them all the time, though. Libraries, too - I'm trying to wean myself off jQuery because it's fucking awful but I can't help myself)

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.

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.

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

The same, I guess, but not as bad.

Mind you, who doesn't just tick everything?

Definitely better. But how many devs do strip out the guff? How many know to, especially when they're using a third party component that utilises that framework?

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

I added more in an edit.

They still don't care how those things are done, though.

I don't think it's about shit frameworks. It's about making the right choices.

Take the earlier example of Wordpress (like Grim..., I'm not dissing Wordpress or Wordpress sites - but it's an example of a tool that without competent oversight, is a bloat monster). You can use Wordpress to throw together a highly functional, good looking site in not much time. But if the dev is only looking to do that, and doesn't have the skills/experience/time/budget to get strong performance out of it, chances are it will be loaded with a load of unnecessary guff that hits performance. And there's a lot of devs out there whose prime driver is time to market, and nothing else.

A mess of JavaScript that I bunged into the console.

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

Here's one:
https://chrome.google.com/webstore/deta ... ikfgnngeik

[edit] Oh, 2 stars out of 5. Maybe not that one, then.

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.

Oh ok, fair enough. I use the browser link and web essentials if I'm doing it in Visual Studio for a site, but didn't know of anything that could do it for a published site.

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.