Don't build websites on top of a million libraries which you don't need and put it in some container and host it in the cloud while using as much of the cloud service providers tools.
Build as much as possible from scratch and host it close to metal as possible.
> Build as much as possible from scratch and host it close to metal as possible.
Citation needed. Running your site in a container on a shared host will be significantly more energy efficient then running hardware. It's silly to claim otherwise.
And the idea that the quantity of js libraries before compile affects energy consumption is a stretch as well.
The issue is how many computations you do at runtime. That is completely unrelated to third party libraries.
Edit: For an example, look at the app store for the oculus quest: https://www.oculus.com/experiences/quest/ - That site is ridiculously slow for what it actually does: Static text + images. And the current state already is way better than before! Almost all content is either static (the apps) or cachable (the ratings). There are barely 100 apps in the store, so this isn't exactly a case where there have to be hot updates every few seconds. This should be rendered server-side, cached, and then sent to the users as static html. The world could save literally tons of CO2 with proper design here.
Citation needed. Do you have some linkable metrics on how all those JS libs are reorganized and optimized (similar to how a compiler might do it on native code) such that the call to overlay or animate on a web page doesn't call through a sizable portion of those libs on every call?
If you write hello world in rust, you wouldn’t act as if the generated binary has all of the runtime dependencies of of the compiler, unit test framework, formatted, etc. So why does JavaScript get the same treatment?
Because very frequently sites with minimal functionality have large piles of javascript. Web sites which should take milliseconds to launch take seconds instead. Some of this is ad-tech, but a lot of sites are overloaded with junk before the ad-tech gets stacked on top of it.
Look at moment.js, the most used date library on the web. It is exceptionally common for people to add a library like that to a site to add a few basic bits of date parsing. (And yes I know moment is being sunsetted).
Even if you assume these big piles of code do nothing once they are loaded, passing around and parsing big chunks of Javascript every time you launch a web page is a waste.
Though as someone else pointed out above, web pages are not a big contributor to Global warming. It's just a frustrating, time consuming waste in most cases.
Probably not. Running your own hardware implies more total hardware because you're not going to be able to saturate your hardware as efficiently as Amazon/Google/MS/etc. Moreover, you'll need to hire more people to work on that hardware (doing the work that Amazon/MS/Google do for you--and let's not pretend that cloud provider work is trivial).
That said, I don't exactly understand the calculus here because it's not like you're creating people who wouldn't otherwise exist for the sole purpose of operating your hardware.
> The issue is how many computations you do at runtime. That is completely unrelated to third party libraries.
Presumably the logic is that third-party libraries cause bloat, and bloat that needs to be sent to the client every time they reload your page (modulo cache hits). And it's certainly far more energy intensive to send a megabyte across a continent than to load it from memory into CPU cache or whatever.
It certainly depends on the scope of the site. My personal sites? If they run on their own bare metal, it's a waste because they're idle to nine nines. My previous work sites? www filled up four machines, so bare metal was more efficient.
What would be most efficient for my current sites is an old school shared host --- no containers, one httpd, etc. VPS is more fun, but you can't fit as many mostly idle customers into a single box with that.
Your site is only busy for 31 milliseconds per year?
<html><body><h1>It works!</h1></body></html>
For the "client side":
The web is responsive by default, making it not friendly to screen readers/phones takes extra work.
Semantic forms are great. You're writing a machine readable description of an API that auto generates a GUI. Theme it with some CSS and leave it alone.
No one likes downloading piles of javascript to load text documents.
Oh, the irony of the iPhone. When it was launched, its unique proposition was that it was the only phone which could render normal webpages, while previously specially tuned XHTML code and handheld stylesheets were required. And what did we do with this? We started the era of specially crafted mobile sites and mobile first.
Still, both then and now mobile requires reducing options to avoid lots of zooming and panning. And less JS is better.
Regarding "not just a simplistic reflow", if you take this notion seriously, this applies not only to the presentation of content, but also to the content itself. Notably, shorter, less "baroque" copy text for handheld devices, but richer text and more related or in-depth information on the desktop. However, I've never seen purposefully redacted content like this, targeting multiple platforms. Instead, it's mobile first also for content on the desktop, where often a mere couple of paragraphs are meant to be a full article or blog post.
When your user base consist of different personas, doing distinctly different job to be done, one option is to tailor the application for each scenario.
Depending on the consequence of the app and the business need, ideal UX needs for each persona may no longer seem superficial to ignore. A normalized experience may be a show stopper. In that case it's worth it to invest in building/maintaining different view / functionalities, specific for the user agent type. If you go even further in this direction, then you invest in building a mobile app, to suite the use case of mobile and desktop.
Not discounting the necessity of mastering the language to be a strong engineer. However the framework being used is just as relevant, if not more so, than the underlying language
A web framework is often a one-size-fits-all solution designed to handle a variety of use cases, some of which conflict with each other. Like a swiss army knife, it does everything but none of them particularly well.
One of course wonders what else my computer is doing to render a piece of text/graphics I want to read/view and if all that is necessary and why I have 1Gbit Internet and still feel like I was on modem (sans blinking lights, linkup sounds and phone bills).
Unfortunately, the person or people that will try more energy efficient client side will loose to ones that will use the newly gained performance to waste it on another cool effect.
This would be great but it won't happen without monetary or regulatory intervention. The industry is hell bent on driving the cost of software to zero. Security, performance and accessibility are always the last to see any investment. The baseline seems to be as long as your website doesn't piss people off completely then it's enough.
Wouldn't it be less efficient to host something myself than to use some cloud provider?
The one major improvement over renting a VPS is that I've now got a large RAID array with many terrabytes of storage, where I previously only had a few hundred gig to play with.
While a server in a typical DC would use way more power than a home system, it's also theoretically possible that they are running at near 100% load, meaning all that energy is used doing SOMETHING, whereas your home PC is burning watts at idle.
I'm often interested in older/cheaper/less-popular articles/products/bits of information, but I'm often forced to scroll eternally or perform several clueless searches to find what I want to find. I can only imagine the extra, useless database queries infinite scrolling requires... not to mention how much and how thoroughly I hate it as a user.
More realistically, maybe don't cherrypick ideas to make up correlations that don't really make sense, and instead do actual environmentally net positive things like buying less stuff or donating
This was my first thought too. It's frustrating to see these questions when the answer is blindingly obvious to someone who takes even a small amount of time to do research. It makes them read as if they're all asked in bad faith, of which I am not convinced they are not.
With all the processing power and bandwidth I still feel the Web is much poorer than it was 20 years ago.
I believe if per the article, "the entire network already consumes 10% of global electricity production, with data traffic doubling roughly every two years" the article/share seems like a valid question/concern for the community.
Do designers contribute to the problem? Surely yes. Should "all designers should learn to code"? I don't think so. Besides seeming impractical, it sounds like a security nightmare. Perhaps only coders should be allowed to design? /s
Seriously though, designers should know that an incredible UI that loads slow is still a bad UX. They should care about this- even if they're not trying to save the world.
I'm curious what this means in context: "who the industry is run by" (i.e. Google?) and also the referenced "toxic subset" (i.e. Advertisers, Bitcoin miners?)
I know where I'm posting this (please don't hit me!) but I kind of wish this didn't provoke such a "developers vs everyone else" reaction. As right as the accusations of clownery and bad acting may be, honestly it just feels like a blaming the user.
One thing I haven't seen brought up in other comments (if it has I'm sorry if I missed it) is javascript timer throttling. I think this kind of solution is really positive because it has minimal negative impact on user, doesn't require a million websites to change, and saves a ton of energy. https://docs.google.com/document/d/1sd9EVERCtRWKvnJXnP3iZ83f...
Can we engineer more solutions like that?
When I think of toxic devs I think of being dismissed when I talk about attention span and optimised page load speeds. And perhaps devs who feel that what is currently normal in javascript land (not knowing your stack, many dependencies, perhaps feeling like electron is an okay solution for a very simple problem) is acceptable because that's just how it's done right now. Both of those schools of thought have reasons for why they are so wide-spread, but they're wasteful and in my eyes an example of lazy engineering. That's acceptable as a conscious choice, but not as a default solution.
I actually feel as if most of the designers understand efficiency better than the really problematic devs (especially as it relates to page load speed), but maybe I've met mostly really nice designers :)
There's a lot of patching that could be done at the browser level and I think what you've proposed is a reasonable choice. The nice thing about timer throttling is that it's relatively easy to implement and nothing of value will be lost.
The problem is that web devs got so involved with their toys, that the toys themselves became alpha and omega. Use case, users, accessibility: who cares! All I know is React (mind you, not even JavaScript, but React), so I will build everything with React. And maybe throw MobX in, because I just happen to learn it.
Watching what's going on is part-amusing and part-horrifying. Alas, the latter part grows faster.
come on guys this is obviously sarcasm