Blame Facebook and Google for starting this awful trend.
It's sending incredible bloat powered by inefficient frameworks and programming practices, and careless use of the bandwidth.
There are frameworks and programming practices that allow doing the same things without burning people's computers and making people wait. Making people wait and burning their bandwidth and data plan is just disrespectful but nobody cares as long as the app works fine on the customer's new phone or laptop.
I'm saying it as someone who does frontend development so it's not just guessing.
I'm writing a Svelte SMS app whose whole frontend is 3 times less heavy than just React itself, and fast on underpowered hardware. I've also built a networked Scrabble game that's instantaneous on an iPad from 2010. I've not focused on performance. This stuff is not impossible to figure out. It's just that these apps don't need to produce and diff entire virtual doms on every mouse move, do not come with custom web fonts, do not embed an entire icon pack of which 10 icons are used, do not use a 100 kb CSS reset framework, do not use 4K images to draw buttons and do not bundle the whole npm planet to work. The amount of features provided by current browser engines is incredible and it is possible to build amazing things by embracing them without breaking a sweat.
React and this state of the frontend world depress me.
It's okay to do client side computation. Just don't do it by sending megabytes of interpreted code for that.
That being said, if I were a front end developer, I would look at the job openings and see most jobs ask for React experience and be more concerned with resume driven development.
That's part of the problem and it's a vicious circle.
And most people like React and I can understand that. It's easy to use and understand. At least at first (debugging subtle (performance or not) bugs related to React's model is… not always easy but these bugs usually arrive when your app is already big enough. This is probably true of any framework).
What's more, most people are not that sensitive to performance and if they are, they might not be aware of React's problems before learning it and practicing (which is also true of any framework).
And also, nobody is fired for picking React.
Which is why I roll my eyes every time someone recommends using vintage laptops from the days they were user upgradable (ThinkPads, MacBooks, etc) and scream from the top of the hills what a great experience that is and why everyone should join in on that.
Yeah I get it, as a HW engineer and tech enthusiast and big right to repair advocate, I also appreciate how upgradable older machines were and how easy to repair they were and I still keep some old machines kicking around, but the modern web is simply a jarring experience on those old machines compared to the experience on modern machines with the latest processors that I cannot in good conscience recommend it to people, if they can afford something decent.
If you live in Vim and the terminal and just use your laptop to SSH into stuff then yeah, they work just fine, but for consuming content on the modern web or heavy productivity tasks I can never recommend staying on vintage HW if your time has any value and if you can afford the upgrade to newer HW.
It's just not a nice experience and with most web-devs using M1 class machines it doesn't look like things will improve for the users on less powerful hardware which I guess here lies the problem.
In Hollywood/Netflix productions, video mastering is done on super accurate $50K monitors but they use in parallel a $300 Walmart grade TV, set to the shitty "Vivid" setting to make sure the final content also looks good on the average TV average consumers have in their homes.
I think the same thing should be done in web development. Feel free to develop the front-end on your kitted out $6000 M1 MacBook Pros but testing should also be done on your average $500 Walmart laptop to check it runs well.
Let them eat Megabytes.
Don't know who you're referring to but I wasn't arguing against making usable products. I'm not even a web developer. I merely stated the facts grounded in the real world. Most of the web is dogshit slow. What is more likely to happen from the two: 1) Web-devs starting to optimize their code to run well on old hardware or 2) People upgrade to HW that can run the current web a little bit better.
> used in africa, india, china and most of the non developed world. Do you think these devices are in any means powerful?
I find it funny the moments the HN users try to shoe-horn the poverty of the third world into various arguments, as if that's somehow a consideration for most people in rich countries on how they conduct their lives. Spoiler alert, most people only care about what happens in their surrounding, and in their personal bubble, and that's it, and most app-devs and web-devs care about the userbase they can monetize the most, which is why some app devs, especially in the US, never port their apps to Android as well and are fine with only with the more affluent iOS majority userbase. So bringing up the third world poverty and inclusiveness in such contexts feels deeply ironic to me.
Yeah, I'd like that too, that web-devs and app devs would not discriminate between iOS and Android and all websites would run great on older machines, but that's not the truth. The truth is that most websites developed in the west are not optimized property therefore heavily favor those with modern machines and some apps are even Apple exclusive to the detriment of those left out.
I've seen Facebook offer Lite version of their mobile client and messaging apps but that's only due to their huge userbase in the developing world, which like ou said, owns mostly low-end devices.
And if western web-devs cared so much about the experience of the users in poor countries, why haven't they optimized it already to run better on older devices?
When most people go online they go to consume content on the websites of the biggest corporations like Google, YouTube, Netflix, Reddit, Facebook, TicTok and so on.
That's what most of the internet is for most average consumers.
The fact that indie devs exist who care about well optimized websites doesn't change this.
I have nothing against the individuals doing web-development, it's just a job to eat and pay rent.
Why are websites now less and less optimized? Because people use apps and APIs. Ergo, they're just fetching the data set.
CloudFlare Pages and GitHub Pages are bringing in a new era of fast, static websites. It isn't all doom and gloom. Furthermore, plenty of people are now using static site generator plugins with CMS like WordPress so that there's no database access required for each page load, which is really what slows things down.
Static site hosting with a brand name smashed onto it is a new era? GitHub itself btw is broken on palemoon for one thing. Not here to defend palemoon but it does show one thing: GitHub's frontend is over-engineered.
Not a GitHub Pages user, also not a Palemoon user, so couldn't say, but Palemoon is niche. There's not even an official macOS version.
All owned by the same company. I'd agree about it being revolutionary if it was on some distributed p2p network like freenet, torrent, ipfs etc. But to call some company doing things in a slightly different manner a new era? Come on
Oh FWIW my personal site is static files built with Hugo SSG, and a minimum of JS. I don't think I will ever use a server-side technology for my personal site again. I do think a growing number of users are "seeing the light" in this regard.
Is it as fast as my M1 MacBook Air? No, of course not. Is it unusably slow? No.
On a daily basis.
It's a matter of perspective in the end. I upgraded from a notebook with a 6th gen Intel chip which I thought was fine to a notebook with a 5th gen Ryzen and the difference blew me away and made me realize how sluggish things were on my older machine in comparison.
There's nothing wrong per se with my old machine, on it's own it's fine, but the newer on is so much faster in comparison, it's night and day for me.
For my parents the old machine is fine not it's own but they're coming from one with a core 2 quad so there's that perspective.
The only common tasks on the Pi4 that have unacceptably slow performance are web browsing and any IO speeds for the primary SD card.
I'm sure if I upgraded CPU, things would become a bit quicker and I would perceive the older performance as slow, similar to every computer upgrade from 1990-2010. But it's really not as dire as you're making it out to be.
Also the javascript heavy web is for the most part an entertainment medium. I'm loading a link to Twitter (one of the most pointlessly heavy sites) and it takes several seconds, I'm already wasting time and so wasting slightly more isn't a big deal. If I wanted to optimize that path, I'd just not click the link to Twitter in the first place. Or if I needed to use Twitter professionally, I'd install a responsibly-developed third party client.
(Having said that the M1 is interesting for its low power consumption)
I think it actually has a lot more to do with mobile. Back in the day you could just send everyone the same HTML/JS/CSS rendered on your server and it would work for everyone.
Now things are more complicated: people want "native apps" on their Android and iOS and whatnot, and also want a "desktop" version and a "web version".
So you build a "light" server API, and put a lot of logic in the frontend. Not to save money, but because all the frontend logic is different on every platform (and in different languages: JS on web, Java or Kotlin on Android, Obj-C or Swift on iOS).
Mobile complicated these things a lot more than people realize.
Mobile apps are also more bloated than needed. But at least you only have to load them once.
Then again, client side frameworks started taking off in 2012.
HN itself works perfect on mobile or anywhere for that matter and is very lightweight. I don't think it's because they optimized it. They just didn't fuck with it.
>Now things are more complicated: people want "native apps" on their Android and iOS
Do people want those? I believe it's just companies shoving those down people's throats
Edit: Ugh, yes, I know network is part of the equation. Parent specifically called out client-side rendering though and that's what I'm responding to.
Caching on CMS like WordPress via plugins helps, but they still query a database on each page load. Ergo, the rise in popularity of static site generators even on top of WordPress. Not everything needs to read from a database for every page load.
tl;dr, not all websites need to "do" anything other than serve static information, but the way in which websites are commonly created and served is piss-poor. Just because the served content is static files doesn't mean that a CMS can't generate it if users want a graphical editor in their browser, and still want their theme of choice.
Oh wait, they already are cached locally.
As a side note, I would also like to mention that OP in spite of having probably the fastest hand held computer wasn't able to mitigate some of the issues of the web like useless scripts, Ads etc. because Apple doesn't provide that control to the users; Where an android at fraction of the cost with Firefox and UBlock Origin/No Script could have provided a better web experience.
[1] https://twitter.com/amilajack/status/1484970825568505856
Does it? I doubt hiring people to produce dozens of megabytes of compressed (!) javascript costs less than the cpu cycles it takes to produce html, especially if that's succinct html, not said megabytes of diarrhea. And "people" here almost definitely does not mean "that one guy who makes the frontend" - no single human could ever produce such abomination. For one thing he just wouldn't have the time! And then if we're frank there are no traces of humanity in twitter's front end - only the pungent smell or festering corporate development.
I say this with love, but judging from every week threads talking about half-million total comp at FANGs, there is probably no internet forum more responsible for the state and direction of the modern web than HN.