321–330 of 392 posts
This makes me feel pretty guilty when I realize that my blog is loading 118.18 kB of minified (!!) css, and almost 200 kB of web fonts, even though the front page of my blog still doesn't exceed 1MB overall.
(And I actually don't like the current theme of my blog that much anyway. I have a hard time picking a clean, "brutalist" theme.)
My blog is pretty lightweight, but I use Japanese in the about page, and that font on that page blows everything else out on download size. I could subset it just for that line, but consider sites containing entirely CJK content...
Earlier quoted context omitted.
The problem is that sites that really had no business being "web apps" have turned into these monstrosities. The new Reddit and Youtube are great examples of this. The old versions worked just fine, but for some reason they were replaced with all Javascript versions that perform much worse.
It seems pretty clear what the motives for reddit are. They want as much tracking/ads as possible as well as actively discouraging use over the app. At every step the website tells you to use the app instead or that this content is only available for app users. JS is not the issue and reddit could have easily made a snappy react version of the site. Monetization, ad tech and engagement growth are the issues.
I could also build a CNN clone in pure React (no SSG or SSR) without the ads and the millions of autoplaying videos that would demolish its current performance.
As for Reddit, perhaps SSR would be a better fit indeed. But most of its problems come from the fact that the SPA implementation is dogshit, and not from the architecture itself... Some things plainly don’t work, for example a feature as basic as the comment tree is broken as hell. This mess would be equally possible with SSR though - I would personally screw up more easily a comment tree implementation with AJAX data fetching in SSR templating and vanilla JS than in React.
I agree that many sites, especially news sites, are disgusting bloated messes. And yes, JavaScript is often involved but it’s not the cause - it is merely an accessory to the fact. The causes are ads, tracking, data mining, even crypto mining (!), and piss-poor implementations (and no, JS frameworks are not conducive to the latter any more than vanilla JS). Each of these causes is in turn motivated by its own root cause, most often economic in nature.
Earlier quoted context omitted.
The reader who gets to read the page for free in exchange for that marketing cruft being there.
Per definition the reader gets less value than the marketing monkeys.
Also, what’s with calling people monkeys? I’m sure many coders here produce stuff that is as questionable in value as what ad executives do.
People need to put food on the table and it’s abhorrent to think of yourself better than an another person because you build data pipelines in Scala that the universe doesn’t give a shit about.
Earlier quoted context omitted.
Nice page. I only miss Firefox reader mode on these simple pages (for my preffered font size, and dark mode). I wonder if it's possible to hint to the browser that it should be available, even if the mark-up is simple? Ah, the late 90s and early 00s when we still had user.css (in a meaningful sense).
There's a way to force reader mode. Add "about:reader?url=" before your URL.
Ahh let the bikeshedding continue. In these situations all I want to say is "Who cares". Optimization matters when it actually solves a problem, before that it's just wasted effort. I don't hear the general public yelling from the rooftops "The web is too slow! Developers are building too fast! I wish we could go backwards!"
I always think, the one feature everybody wants is speed. The same page but faster is always better.
Makes them feel like the site actually does some calculations, even if everything is cached in the background.
See travel agencies, airline comparators, train booking services, insurance benchmarks or credit simulations.
Earlier quoted context omitted.
Check out this app: https://webide.se/?disable=fonts,discoveryBar It's over one hundred thousand lines of JavaScript code minified and Gziped into a 300KB bundle which should fully load in about 300ms on a decent computer.
That took 4000ms on a phone.
Here's a common example, from a FAANG company: 72mb and 367 requests to display around 2,000 characters of text. Maybe double that if you count the "hyperlinks." Single page applications are horrible, and oh-so-common. https://imgur.com/a/v2rud7T
72 millibits doesn't sound feasible for even the most minimalist of websites. ;) Seriously though, this isn't just a "grammar" thing. If you don't know the difference between millibits and megabytes, you probably shouldn't post on the subject of page size (or anything else relating to bandwidth consumption / network performance).
I still hate it when people flag comments like yours because maybe it sounds "offensive" or something, but you can improve your tone too.
[0] - https://en.wikipedia.org/wiki/International_System_of_Units
Shameless plug: My page, a fully-featured message board with tagging and stats, private key based accounts, and optional JavaScript features, the homepage is much smaller :)