How (and How Not) to Curb Abusive Javabloat

One of many reasons why abuse of JavaScript has become as planted as pernicious is an oddly common inability to properly appraise and endorse solutions to this godforsaken trend. In an article he contributed to Brainleaf, Ben Shepardson reveals that his heart is nearly in the right place, but he’s stymied by his lockstep conformity to the hateful conventions established and perpetrated by horrible industries.

“In a world where UX is king, it’s curious to note that slow-loading websites are still a growing problem. Sadly, our benchmarks for what’s acceptable increase every year as we inch ever upwards towards larger and heavier sites.”

This is incontestable, and though the “our” and “we” never apply to me, websites of governments, small businesses and individuals are often as bloated and ugly as those of corporations.

“Yesterday’s bloated monster of a slow-loading behemoth at 1 megabyte becomes today’s sleek and light example of what to aim for. Back in the day, 100 KB was considered too big.

When I accessed sites at 56K in the mid-’90s, I didn’t adjudge 100K as excessive. Does “back in the day” denote the mid- to late-’80s, when images and audio uploaded to FTP servers and BBSs occasionally exceeded this length?

Today’s Tweets are heavier than yesteryear’s web pages.”

Microblogging is an inherently inferior concept worsened by the coded obesity characterizing nearly every site that provides such a service. At a fraction of their size, most message boards provide their users with far more flexibility and freedom than Twitter, Gab, Tencent Weibo, Plurk, Parler, Facebook, etc. Mastodon is a notable exception to this trend, but it was founded and it’s almost entirely administered by psychotically hypersensitive baizuo who practice ideological censorship as a lifestyle (and probably hate women).

“Of course, we have Moore’s Law to thank for ever-increasing web capabilities. Modern hardware and internet infrastructure can handle an entire galaxy’s worth of extra data transfer. But, like ever-expanding suburbs and the highways that connect them, extra capacity soon gets filled up as we expand in every direction.”

Avarice, stupidity and mundane incompetence is as responsible for this trend as expanded and advancing usage…

“Needless to say, any developer caught ignoring the principles of UX and unleashing megaton websites on the browsing public should take a serious look inwards. It’s simply bad form.”

Obviously, this is because no such principles or protocol thereof have ever been widely or formally acknowledged, much less observed by the vast majority of web designers.

“There are now layman’s tools for helping solve bloat on your own website, even when your web developer has sold you a heavy behemoth. Anyone can lighten up their own load by using code minifiers and image-handling techniques.”

Alternatively, they can actually solve rather than merely mitigate problems by demanding more HTML, CSS, PHP, et cetera, and less JavaScript.

“But this isn’t about tidying up your white space or decreasing pixels in your image carousel. This is about unwanted (read: unnecessary) javascript functionalities that are crashing websites, left and right.”

More trouble’s suffered from crashed and frozen browsers than sites.

“JavaScript is not to blame: unnecessary and therefore unwanted functionalities are the real culprit here.”

Those functionalities are but symptoms of this matter’s actual problem: excessive use of JavaScript to perform functions that are more efficiently executed via HTML, CSS, and other languages.

“No matter who you are – user or developer – you probably love JavaScript. It makes the Web what we need it to be today: fulfilling and dynamic, personalized and fun.”

No, it doesn’t. It can conduce to such qualities in moderate application, but notwithstanding its ubiquity, it’s obviously as demonstrably unnecessary for frolic as for utility.

“Nobody wants to go back to the days when all we had to work with was HTML.”

When was that?! It certainly wasn’t when Internet became popular. PHP and JavaScript were introduced contemporaneously in 1995; the W3C published CSS 1 a year later.

“Without dynamicity, that world would appear sad and flat to today’s users.”

One can intuit so much about a person by cursory observation of their diction and lexicon, and especially neologisms so encompassed in the latter. Dynamism can be a circumstantial virtue; “dynamicity” smacks of moronic corporate attempts to further befoul our living language.

“And marketers? They’d be completely lost without being able to serve up those highly-targeted ads we’ve all come to expect when we browse the web.”

Imagine that you’re in attendance at some soiree or other, and some drone burdened with a retreating hairline, micropenis and IQ of 95 opines from across the dinner table, “To be fair, industries really need to consider the needs of marketing departments when we design and test products and services, because that benefits consumers.” You’d be morally, if not legally justified to rise from your seat in a fit of pique, circumambulate that table and break his stupid face.

Hey, asshole: nearly everyone possessing an IQ above room temperature dreads rather than expects embedded advertisements, highly-targeted and otherwise. You can’t credibly shill JavaScript by promoting solutions when you support the problems that it enables.

“We couldn’t even eradicate JavaScript from the Web if we wanted to.”

We probably could, though that’s hardly desirable. After all, some other language will eventually supersede it.

“It is now a fundamental building block of the web. Almost every browser supports it, and almost every website uses it. Increasingly, mobile and app development are forever entwined with JavaScript as well.”

It’s no such thing, and the notion that JavaScript is fundamental, much less indispensable for its omnipresence is at best specious.

“Plus, we have derivatives like the jQuery library and Node.js (which takes JavaScript to the server side). Both are further evidence that JavaScript is here to stay.”

This is naive; present popularity is no reliable indicator of future preponderance. Incidentally, I freely concede that the development and adoption of jQuery is largely a tremendous boon.

These consecutive, contradictory statements are essentially a caveat for proofreading:

“JavaScript is, however, responsible for some of the weight gain of today’s websites.

“It’s not JavaScript itself to blame for the extra weight, but rather the way it’s being used.”

That latter declaration is true, but…

“In short, many of the functionalities of JavaScript can be handled in different ways, thereby lightening the load across the board for all kinds of websites.”

If “handled in different ways” connoted a decrement of implemented JavaScript, I might agree.

“So, what’s a developer to do? Here are some ideas of how JavaScript can be used in better ways to trim the fat so to speak. These don’t cover all of the creative ways you might tackle this issue, but they will point you in the right direction.”

Wrong! Our trouble isn’t merely that JavaScript’s abused, but that it’s overapplied.

“1. Wean ourselves from jQuery addiction

“jQuery is a wonderful, time-saving convenience, but it’s overused. Using it for simple tasks is often not necessary with today’s browsers. These kinds of tasks have surprisingly robust native implementations that perform jQuery-style functionalities all by themselves. Stick to native JavaScript whenever possible.”

This won’t happen for awhile, for jQuery’s appeal inheres in not merely its convenience and usefulness, but also its novelty. Developers disposed to use jQuery won’t dispense with it until something just as commodious succeeds it.

“2. Limit surveillance scripts

“Third-party tracking code is responsible for much of the weight gain of the internet. We all know it to be true, yet web developers are still held hostage to clients who insist on loading up their seemingly wonderfully optimized and fast-loading newly designed site with cookies, tracking code. Online marketing companies don’t always realize the weight that elaborate advertising code can cause. If you’re not using it, let it go.”

If “limit” read as “eliminate,” I might agree.

“The moral of the story is that JavaScript is great when used properly. What’s more, it’s here to stay, so we may as well learn to get along with it.”

“BLAH BLAH JavaScript is our lord and savior now and forever; accept its love and providence, heathen BLAH BLAH BLAH BLAH.” Whatever!

Here are four tips by which everyone can actually lighten their load:

  1. Don’t use JavaScript as a succedaneum for any of HTML’s elements or attributes thereof, or any function that may be executed more efficiently with CSS or PHP. Nota bene: HTML and CSS are intended and optimized for their respective purposes. If you’re writing JavaScript to replace HTML’s a, img, video or any other block- or text-level elements, you especially deserve the pillory, shitbag.
  2. Never write scripts that enable a server to surveil, track or cryptojack public visitors. If this seems revolutionary, good. Usury and marital infidelity aren’t moral for their legality either.
  3. Stop animating with JavaScript; use embedded videos, GIFs, APNGs, or even MNGs instead.
  4. Don’t be a dunce who renders the title in a user agent’s window caption as a marquee with JavaScript, or anything else.

Per se, JavaScript is a great tool, and in certain ways comparable to firearms, abortion and automobiles: respectively unsurpassed means of self-defense, eugenics and personal transport which have been misused horribly by senseless and sordid people, and consequently prohibited or restricted by governments who’d better serve their societies by stamping out the people who abuse these technologies, and curbing the causes of their pathologies. JavaScript is no different: web bloat won’t cease to exist until societies coerce those who perpetuate it to surcease. Bullycide a web developer today.