As a web developer, I see js as a quality improvement. No page reloads, nice smooth ui. Luckily, PHP times has ended, but even in the PHP era disabling jQuery could cause problems.
We could generate static html pages It just adds complexity.
Personally I use only client-side rendering, and I think, that’s the best from dev perspective. Easy setup, no magic, nice ui. And that results in blank page when you disable js.
If your motivation is to stop tracking.
replace all foreign domain sources to file uris. e.g.: load google fonts from local cache.
disable all foreign script files unless it’s valid like js packages from public CDNs, which case load them from local cache.
If your motivation is to see old html pages, with minimal style, well it’s impossible to do them reliably.
If you are worried about closed-source js. You shouldn’t be. It’s an isolated environment. if something is possible for js and you want to limit its capability, contribute to browsers. That’s the clear path.
If your motivation is to see old html pages, with minimal style, well it’s impossible to do them reliably.
Not only should your site be legible without JS, it should be legible without CSS, and infact without rendering the effects of the HTML tags (plain text after striping the tags).
At one point in time this was the standard, that each layer was an enhancement on top of the one below it. Its seems that web devs now cannot even imagine writing a news article or a blog post like, something that has the entirety of its content contained within its text. A plain .txt file renders “reliably” on anything. You are the one adding extra complexity in there and then complaining that you’re forced to add even more to deal with the consequences of your actions.
What I meant is that you cannot turn any existing webpages to a basic page with some simple tricks like disabling js. That would be a never-ending fight.
You are the one adding extra complexity
I’m not the one defining the business requirement. I could build a site with true progressive enhancement. It’s just extra work, because the requirement is a modern page with actions, modals, notifications, etc.
There are two ways I can fulfill this. SSR with scripts that feel like hacks. Or CSR. I choose CSR, but then progressive enhancement is now an extra work.
I guess I earn my living with nothing then. What an absurd take. PHP powers WordPress, Shopware, Typo3 and many other CMS systems and is still very strong. Especially in Europe.
(Apart from that, a lot of people shitting on PHP base it on outdated knowledge or have never used it at all. With modern OOP practices, you can write really clean code.)
I was developing with Laravel until 2019. I agree that you can write clean code with it. Still, there are many better options nowadays, I switched to nodejs because I can use typescript for both backend and frontend, and I’m happier with it. Although js is not a great language, typescript is almost perfect. But it’s not only me who switched, people ditching php because there are better options.
It suggests using minimal js, I use react the same way, whatever I can do with css, I do it with css. But I am not going to footgun myself. I start the app with react because at some point I will need react.
You mean people replying to you? I wouldn’t call those heated, rather derisive. Just like your own original comment. You come across as presumptuous and pretending to be more knowledgeable than you really are. People react.
If your motivation is to see old html pages, with minimal style
Huh? i just want to see a web page. Usually a news article, i.e. text with few styling elements. In other words, HTML.
For most use cases JS is not required.
well it’s impossible to do them reliably
Huh again? Why?
If you are worried about closed-source js.
Isn’t it always open, i.e. one can read the script the browser loads if one is so inclined? No, that’s not the point at all. JS increases the likelihood of data mining, by ordes of magnitude. And most addons that block js also block 3rd party requests generally.
Use as much js as you like (most third party stuff is not really up to the web dev anyhow), but the page must always fail gracefully for those who do not like it, or browse the web in some non-standard way. An empty page is not an option.
Please also read some of the other (top level) comments here.
I can’t take it seriously because of the noise in your text like “Huh?”. If you like to have a conversation, please be more open next time.
Source code is the code before some kind of transpilation. Obfuscated code is not source code.
I get it, you just need the content. But why would you reload the page when you’re just about to get the next news in the page. Isn’t it better to just update that part?
Why is it “impossible to do them reliably” - without js presumably?
What I meant is that you cannot turn any existing webpages to a basic page with some simple tricks like disabling js. That would be a never-ending fight.
even in the PHP era disabling jQuery could cause problems.
WTF. Do you think jQuery is what JavaScript used to be called or something? Pretty much everything you wrote is insane, and I specifically think that because I’ve been building webpages for 25 years. You sure never heard of progressive enhancement.
There were horrible tricks and hacks that were addig not only ux improvements but useful content. We used jquery for many of those things. That’s why I wrote it, and for the legacy vibe.
Disabling js would have broken that site as well, reinforcing my point that it was never a reliable solution to disable js.
As a web dev, and primarily user, I like my phone having some juice left in it.
The largest battery hog on my phone is the browser. I can’t help wonder why.
I’d much rather wait a second or two rather than have my phone initialize some js framework 50 times per day.
Dynamic HTML can be done - and is - server-side. Of course, not using a framework is harder, and all the current ones are client-side.
Saying making unbloated pages is impossible to do right just makes it seem like you’re ill informed.
On that note - “Closed-source” JS doesn’t really exist (at least client-side) - all JS is source-availiable in-browser - some may obfuscate, but it isn’t a privacy concern.
The problem is that my phone does something it doesn’t have to.
Having my phone fetch potentially 50 MB (usually 5-15) for each new website is a battery hog. And on a slow connection - to quote your words, “great UX”.
The alternative is a few KB for the HTML, CSS and a small amount of tailor-made JS.
A few KB’s which load a hundered times faster, don’t waste exorbitant amounts of computing power - while in essence losing nothing over your alternative.
“Old pages with minima style” is a non-sequitur. Need I remind you, CSS is a thing. In fact, it may be more reliable than JS, since it isn’t turing-complete, it’s much simpler for browser interpreters to not fuck it up. Also, not nearly the vulnerability vector JS is.
And your message for me and people like me, wanting websites not to outsource their power-hogging frameworks to my poor phone?
Who said making unbloated pages impossible? Your comment would be more serious without your emotions.
Source code is the source code which gets transformed to some target code. An obfuscated code is not source code.
A reminder, in the past, large pages downloaded all stuff at once. In contrast, with dynamic imports the first load is much much faster. And that matters most. And any changes in dynamic content would just require the dynamic data to be downloaded. My phone lasts at least 2 days with one charge (avg usage), but I charge it every night, that’s not an issue.
For compiled languages like C, only the compiled machine code is made available to the user.
JS is interpreted, meaning it doesn’t get compiled, but an interpreter interprets source code directly during runtime.
Obfuscsted code, while not technically unaltered source code is still source code. Key word being unaltered. It isn’t source code due to the virtue of not being straight from the source (i.e. because it’s altered).
However, obfuscated code is basically source code. The only things to obfuscate are variable and function names, and perhaps some pre-compile order of operations optimizations. The core syntax and structure of the program has to remain “visible”, because otherwise the interpreter couldn’t run the code.
Analyzing obfuscated code is much closer to analyzing source code than reverse-engineering compiled binaries.
It may not be human-readable. But other programs systems can analyze (as they can even compiled code), but more importantly - they can alter it in a trivial manner. Because it’s source code with basically names censored out. Which makes evaluating the code only a bit harder than if it were truly “closed-source”.
That’s why website source code is basically almostsource-available.
A reminder, in the past, large pages downloaded all stuff at once. In contrast, with dynamic imports the first load is much much faster. And that matters most. And any changes in dynamic content would just require the dynamic data to be downloaded.
Unfortunately, you’re very mistaken.
In the past, pages needed to download any stuff they want to display to the user. Now, here’s the kicker: that hasn’t changed!
Pages today are loaded more dinamically and sensibly. First basic stuff (text), then styles, then scripts, then media.
However, it’s not Angular, React Bootstrap or any other framework doing the fetching. It’s the browser. Frameworks don’t change that. What they do, instead, is add additional megabytes of (mostly) bloat to download every day or week (depending on the timeout).
Any web page gets HTML loaded first, since the dawn of the Web. That’s the page itself. Even IE did that. At first, browsers loaded sequentially, but then they figured out it’s better UX to load CSS first, then the rest. Media probably takes precedence to frameworks as well (because thet’s what the user actually sees).
Browsers are smart enough to cache images themselves. No framework can do it even if it wanted to because of sandboxing. It’s the browser’s job.
What frameworks do is make devs’ lives easier. At the cost of performance for the user.
That cost is multiple-fold: first the framework has to load. In order to do that, it takes bandwidth, which may or may not be a steeply-priced commodity depending on your ISO contract. Loading also takes time, i.e. waiting, i.e. bad UX.
Other than that, the framework beeds to run. That uses CPU cycles, which wastes power and lowers battery life. It’s also less efficient than the browser doing it because it’s a higher level of abstraction than letting the browser do it on its own.
With phones being as trigger-happy about killing “unused” apps, all the frameworks in use by various websites need to spin up from being killed as often as every few minutes. A less extreme amount of “rebooting” the framework happens when low-powered PCs run oit of RAM and a frameworked site is chosen by the browser to be “frozen”.
What a framework does is, basically, fill a hole in HTML and CSS - it adds functionality needed for a website which is otherwise unattainable. Stuff like cart, checkout, some complex display styles, etc.
All of this stuff is fully doable server-side. Mind you, login is so doable it didn’t even slip onto my little list. It’s just simpler to do it all client-side for the programmer (as opposed to making forms and HTML requests that much more often, together with the tiny UX addition of not needing to wait for the bac(-and-forth to finish.
Which itself isn’t really a problem. In fact, the “white flashes” are more common on framework sites than not.
When a browser loads any site, it loads HTML first. That’s “the site”. The rest is just icing on the cake. First is CSS, then media and JS (these two are havily browser dependent as far as load priority goes).
Now comes the difference between “classic”, “js-enhanced” and “fully js-based” sites.
A classic site loads fast. First HTML. The browser fetches the CSS soon enough, not even bothering to show the “raw HTML” for a few hundered miliseconds if the CSS loads fast enough. So the user doesn’t even see the “white flash” most of the time, since networks today are fast enough.
As the user moves through different pages of the site, the CSS was cached - any HTML page wishing to use the same CSS won’t even need to wait for it to load again!
Then there’s the js-enhanced site. It’s like the classic site, but with some fancy code to make it potentially infinitely more powerful. Stuff like responsive UI’s and the ability to do fancy math one would exoect of a traditional desktop/native app. Having JS saves having to run every little thing needing some consideration to the server when the browser can do it. It’s actually a privacy benefit, since a lot less things need to leave the user’s device. It can even mend its HTML, its internal structure and its backbone to suit its needs. That’s how powerful JS is.
But, as they say, with great power comes great responsibility. The frameworked-to-hell site. Initially, its HTML is pretty much empty. It’s less of like ordering a car and more of building a house. When you “buy the car” (visit the site), it has to get made right in front of your eyes. Fun the first few times, but otherwise very impractical.
A frameworked site also loads slower by default - the browser gets HTML first, then CSS. Since there’s no media there yet, it goes for the JS. Hell, some leave even CSS out of the empty shell of the page when you first enter so you really get blasted by the browser’s default (usually white, although today theme-based) CSS stylesheet. Only once the JS loads the framework can the foundation of the site (HTML) start being built.
Once that’s been built, it has CSS, and you no longer see the white sea of nothing.
As you move through pages of the site, each is being built in-browser, on-demand. Imagine the car turning into a funhouse where whenever you enter a new room, the bell rings. An employee has to hear it and react quickly! They have to bring the Buld-A-Room kit quickly and deploy it, lest you leave before that happens!
Not only is that slow and asinine, it’s just plain inefficient. There’s no need for it in 99% of cases. It slows stuff down, creates needless bandwidth, wastes needless data and wastes energy.
There’s another aspect to frameworked sites’ inefficiency I’d like to touch.
It’s the fact that they’re less “dynamic” and more “quicksand”.
They change. A lot. Frameworks get updates, and using multiple isn’t even unheard of. Devs push updates left and right, which are expected to be visible and deployed faster than the D-Day landings.
Which in practice means that max resource age is set very low. Days, maybe even hours. Which means, instead of having the huge little 15 MB on-average framework fetched once a week or month, it’s more like 4 to dozens of times per week. Multiply by each site’s preferred framework and version, and add to that their own, custom code which also takes up some (albeit usually less-than-frameork) space.
That can easily cross into gigabytes a month. Gigabytes wasted.
Sure, in today’s 4K HDR multimedia days that’s a few minutes of video, but it isn’t 0 minutes of nothing.
My phone also reliably lasts a day without charge. It’s not about my battery being bad, but about power being wasted. Do you think it normal that checking battery use, Chrome used 64% according to the abdroid settings?
You bet I tried out Firefox the very same day. Googling for some optimizations led me down a privacy rabbit-hole. Today I use Firefox, and battery use fell from 64% to 24%. A 40% decrease! I still can’t believe it myself!
I admit, I tend to use my phone less and less so my current 24% may not be the best metric, but even before when I did, the average was somewhere between 25% and 30%.
There’s a middle-ground in all of this.
Where the Web is today is anything but.
The old days, while not as golden they might seem to me are also not as brown as you paint them out to be.
As a web developer, I see js as a quality improvement. No page reloads, nice smooth ui. Luckily, PHP times has ended, but even in the PHP era disabling jQuery could cause problems.
We could generate static html pages It just adds complexity.
Personally I use only client-side rendering, and I think, that’s the best from dev perspective. Easy setup, no magic, nice ui. And that results in blank page when you disable js.
If your motivation is to stop tracking.
If your motivation is to see old html pages, with minimal style, well it’s impossible to do them reliably. If you are worried about closed-source js. You shouldn’t be. It’s an isolated environment. if something is possible for js and you want to limit its capability, contribute to browsers. That’s the clear path.
I can be convinced. What’s your motivation?
Not only should your site be legible without JS, it should be legible without CSS, and infact without rendering the effects of the HTML tags (plain text after striping the tags).
At one point in time this was the standard, that each layer was an enhancement on top of the one below it. Its seems that web devs now cannot even imagine writing a news article or a blog post like, something that has the entirety of its content contained within its text. A plain .txt file renders “reliably” on anything. You are the one adding extra complexity in there and then complaining that you’re forced to add even more to deal with the consequences of your actions.
What I meant is that you cannot turn any existing webpages to a basic page with some simple tricks like disabling js. That would be a never-ending fight.
I’m not the one defining the business requirement. I could build a site with true progressive enhancement. It’s just extra work, because the requirement is a modern page with actions, modals, notifications, etc.
There are two ways I can fulfill this. SSR with scripts that feel like hacks. Or CSR. I choose CSR, but then progressive enhancement is now an extra work.
I guess I earn my living with nothing then. What an absurd take. PHP powers WordPress, Shopware, Typo3 and many other CMS systems and is still very strong. Especially in Europe.
(Apart from that, a lot of people shitting on PHP base it on outdated knowledge or have never used it at all. With modern OOP practices, you can write really clean code.)
I was developing with Laravel until 2019. I agree that you can write clean code with it. Still, there are many better options nowadays, I switched to nodejs because I can use typescript for both backend and frontend, and I’m happier with it. Although js is not a great language, typescript is almost perfect. But it’s not only me who switched, people ditching php because there are better options.
This community is full of older people who have never done modern development
https://lyra.horse/blog/2025/08/you-dont-need-js/
It suggests using minimal js, I use react the same way, whatever I can do with css, I do it with css. But I am not going to footgun myself. I start the app with react because at some point I will need react.
Fuck yeah!
Bookmarked for future use. CSS has developed a lot since I started getting aquainted with it.
I didn’t read it completely, is browser coverage addressed in the article?
The only non-heated comment. I appreciate it. I will read it.
You mean people replying to you? I wouldn’t call those heated, rather derisive. Just like your own original comment. You come across as presumptuous and pretending to be more knowledgeable than you really are. People react.
Huh? i just want to see a web page. Usually a news article, i.e. text with few styling elements. In other words, HTML.
For most use cases JS is not required.
Huh again? Why?
Isn’t it always open, i.e. one can read the script the browser loads if one is so inclined? No, that’s not the point at all. JS increases the likelihood of data mining, by ordes of magnitude. And most addons that block js also block 3rd party requests generally.
Use as much js as you like (most third party stuff is not really up to the web dev anyhow), but the page must always fail gracefully for those who do not like it, or browse the web in some non-standard way. An empty page is not an option.
Please also read some of the other (top level) comments here.
You were completely fine with slow page reloads blinding you when the theme was dark. I’m speaking to those who appreciate modern tech.
But anyways, unfortunately javascript obfuscation is a common thing.
Obfuscation, OK.
Look, I’m willing to have a conversation with you, but you need to address my points first, that is if you want one too.
I can’t take it seriously because of the noise in your text like “Huh?”. If you like to have a conversation, please be more open next time.
Source code is the code before some kind of transpilation. Obfuscated code is not source code.
I get it, you just need the content. But why would you reload the page when you’re just about to get the next news in the page. Isn’t it better to just update that part?
Why is it “impossible to do them reliably” - without js presumably?
Sounds like you’re thinking about web apps, when most people here think about web pages.
What I meant is that you cannot turn any existing webpages to a basic page with some simple tricks like disabling js. That would be a never-ending fight.
In your words I hear that as a web dev, you rely 100% on javascript.
WTF. Do you think jQuery is what JavaScript used to be called or something? Pretty much everything you wrote is insane, and I specifically think that because I’ve been building webpages for 25 years. You sure never heard of progressive enhancement.
It seems you misunderstood me.
There were horrible tricks and hacks that were addig not only ux improvements but useful content. We used jquery for many of those things. That’s why I wrote it, and for the legacy vibe.
Disabling js would have broken that site as well, reinforcing my point that it was never a reliable solution to disable js.
As a web dev, and primarily user, I like my phone having some juice left in it.
The largest battery hog on my phone is the browser. I can’t help wonder why.
I’d much rather wait a second or two rather than have my phone initialize some js framework 50 times per day.
Dynamic HTML can be done - and is - server-side. Of course, not using a framework is harder, and all the current ones are client-side.
Saying making unbloated pages is impossible to do right just makes it seem like you’re ill informed.
On that note - “Closed-source” JS doesn’t really exist (at least client-side) - all JS is source-availiable in-browser - some may obfuscate, but it isn’t a privacy concern.
The problem is that my phone does something it doesn’t have to.
Having my phone fetch potentially 50 MB (usually 5-15) for each new website is a battery hog. And on a slow connection - to quote your words, “great UX”.
The alternative is a few KB for the HTML, CSS and a small amount of tailor-made JS.
A few KB’s which load a hundered times faster, don’t waste exorbitant amounts of computing power - while in essence losing nothing over your alternative.
“Old pages with minima style” is a non-sequitur. Need I remind you, CSS is a thing. In fact, it may be more reliable than JS, since it isn’t turing-complete, it’s much simpler for browser interpreters to not fuck it up. Also, not nearly the vulnerability vector JS is.
And your message for me and people like me, wanting websites not to outsource their power-hogging frameworks to my poor phone?
Go build your own browser.
What a joke.
You can build some very light pages with JavaScript. JavaScript isn’t the issue, it is the large assets.
Who said making unbloated pages impossible? Your comment would be more serious without your emotions.
Source code is the source code which gets transformed to some target code. An obfuscated code is not source code.
A reminder, in the past, large pages downloaded all stuff at once. In contrast, with dynamic imports the first load is much much faster. And that matters most. And any changes in dynamic content would just require the dynamic data to be downloaded. My phone lasts at least 2 days with one charge (avg usage), but I charge it every night, that’s not an issue.
Source code is the code devs write.
For compiled languages like C, only the compiled machine code is made available to the user.
JS is interpreted, meaning it doesn’t get compiled, but an interpreter interprets source code directly during runtime.
Obfuscsted code, while not technically unaltered source code is still source code. Key word being unaltered. It isn’t source code due to the virtue of not being straight from the source (i.e. because it’s altered).
However, obfuscated code is basically source code. The only things to obfuscate are variable and function names, and perhaps some pre-compile order of operations optimizations. The core syntax and structure of the program has to remain “visible”, because otherwise the interpreter couldn’t run the code.
Analyzing obfuscated code is much closer to analyzing source code than reverse-engineering compiled binaries.
It may not be human-readable. But other programs systems can analyze (as they can even compiled code), but more importantly - they can alter it in a trivial manner. Because it’s source code with basically names censored out. Which makes evaluating the code only a bit harder than if it were truly “closed-source”.
That’s why website source code is basically almostsource-available.
Unfortunately, you’re very mistaken.
In the past, pages needed to download any stuff they want to display to the user. Now, here’s the kicker: that hasn’t changed!
Pages today are loaded more dinamically and sensibly. First basic stuff (text), then styles, then scripts, then media.
However, it’s not Angular, React Bootstrap or any other framework doing the fetching. It’s the browser. Frameworks don’t change that. What they do, instead, is add additional megabytes of (mostly) bloat to download every day or week (depending on the timeout).
Any web page gets HTML loaded first, since the dawn of the Web. That’s the page itself. Even IE did that. At first, browsers loaded sequentially, but then they figured out it’s better UX to load CSS first, then the rest. Media probably takes precedence to frameworks as well (because thet’s what the user actually sees).
Browsers are smart enough to cache images themselves. No framework can do it even if it wanted to because of sandboxing. It’s the browser’s job.
What frameworks do is make devs’ lives easier. At the cost of performance for the user.
That cost is multiple-fold: first the framework has to load. In order to do that, it takes bandwidth, which may or may not be a steeply-priced commodity depending on your ISO contract. Loading also takes time, i.e. waiting, i.e. bad UX.
Other than that, the framework beeds to run. That uses CPU cycles, which wastes power and lowers battery life. It’s also less efficient than the browser doing it because it’s a higher level of abstraction than letting the browser do it on its own.
With phones being as trigger-happy about killing “unused” apps, all the frameworks in use by various websites need to spin up from being killed as often as every few minutes. A less extreme amount of “rebooting” the framework happens when low-powered PCs run oit of RAM and a frameworked site is chosen by the browser to be “frozen”.
What a framework does is, basically, fill a hole in HTML and CSS - it adds functionality needed for a website which is otherwise unattainable. Stuff like cart, checkout, some complex display styles, etc.
All of this stuff is fully doable server-side. Mind you, login is so doable it didn’t even slip onto my little list. It’s just simpler to do it all client-side for the programmer (as opposed to making forms and HTML requests that much more often, together with the tiny UX addition of not needing to wait for the bac(-and-forth to finish.
Which itself isn’t really a problem. In fact, the “white flashes” are more common on framework sites than not.
When a browser loads any site, it loads HTML first. That’s “the site”. The rest is just icing on the cake. First is CSS, then media and JS (these two are havily browser dependent as far as load priority goes).
Now comes the difference between “classic”, “js-enhanced” and “fully js-based” sites.
A classic site loads fast. First HTML. The browser fetches the CSS soon enough, not even bothering to show the “raw HTML” for a few hundered miliseconds if the CSS loads fast enough. So the user doesn’t even see the “white flash” most of the time, since networks today are fast enough.
As the user moves through different pages of the site, the CSS was cached - any HTML page wishing to use the same CSS won’t even need to wait for it to load again!
Then there’s the js-enhanced site. It’s like the classic site, but with some fancy code to make it potentially infinitely more powerful. Stuff like responsive UI’s and the ability to do fancy math one would exoect of a traditional desktop/native app. Having JS saves having to run every little thing needing some consideration to the server when the browser can do it. It’s actually a privacy benefit, since a lot less things need to leave the user’s device. It can even mend its HTML, its internal structure and its backbone to suit its needs. That’s how powerful JS is.
But, as they say, with great power comes great responsibility. The frameworked-to-hell site. Initially, its HTML is pretty much empty. It’s less of like ordering a car and more of building a house. When you “buy the car” (visit the site), it has to get made right in front of your eyes. Fun the first few times, but otherwise very impractical.
A frameworked site also loads slower by default - the browser gets HTML first, then CSS. Since there’s no media there yet, it goes for the JS. Hell, some leave even CSS out of the empty shell of the page when you first enter so you really get blasted by the browser’s default (usually white, although today theme-based) CSS stylesheet. Only once the JS loads the framework can the foundation of the site (HTML) start being built.
Once that’s been built, it has CSS, and you no longer see the white sea of nothing.
As you move through pages of the site, each is being built in-browser, on-demand. Imagine the car turning into a funhouse where whenever you enter a new room, the bell rings. An employee has to hear it and react quickly! They have to bring the Buld-A-Room kit quickly and deploy it, lest you leave before that happens!
Not only is that slow and asinine, it’s just plain inefficient. There’s no need for it in 99% of cases. It slows stuff down, creates needless bandwidth, wastes needless data and wastes energy.
There’s another aspect to frameworked sites’ inefficiency I’d like to touch.
It’s the fact that they’re less “dynamic” and more “quicksand”.
They change. A lot. Frameworks get updates, and using multiple isn’t even unheard of. Devs push updates left and right, which are expected to be visible and deployed faster than the D-Day landings.
Which in practice means that max resource age is set very low. Days, maybe even hours. Which means, instead of having the huge little 15 MB on-average framework fetched once a week or month, it’s more like 4 to dozens of times per week. Multiply by each site’s preferred framework and version, and add to that their own, custom code which also takes up some (albeit usually less-than-frameork) space.
That can easily cross into gigabytes a month. Gigabytes wasted.
Sure, in today’s 4K HDR multimedia days that’s a few minutes of video, but it isn’t 0 minutes of nothing.
My phone also reliably lasts a day without charge. It’s not about my battery being bad, but about power being wasted. Do you think it normal that checking battery use, Chrome used 64% according to the abdroid settings?
You bet I tried out Firefox the very same day. Googling for some optimizations led me down a privacy rabbit-hole. Today I use Firefox, and battery use fell from 64% to 24%. A 40% decrease! I still can’t believe it myself!
I admit, I tend to use my phone less and less so my current 24% may not be the best metric, but even before when I did, the average was somewhere between 25% and 30%.
There’s a middle-ground in all of this.
Where the Web is today is anything but.
The old days, while not as golden they might seem to me are also not as brown as you paint them out to be.