4 ms·

> 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

> 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. 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.

bildung 6y ago
I think the main problem is that most computation happens at the user's browser - the different types of hosting will barely play a role in the overall footprint of a website. Edit: For an example, look at the app store for the oculus quest: https://www.oculus.com/experiences/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.
- dr-detroit 6y ago
  Your opinions are flat out wrong. Unless your market is in Japan you don't market your product with html1.0
jagged-chisel 6y ago
> The issue is how many computations you do at runtime. That is completely unrelated to third party libraries. 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?
- charrondev 6y ago
  In a “modern” JS project, the vast majority of dependencies are normally development dependencies. When you see so many generally 90% of it comes from dev/build time dependencies like webpack, typescript, linters, etc. 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?
  - ogre_codes 6y ago
    > 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.
throwaway894345 6y ago
> 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. 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.
toast0 6y ago
> 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. 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.
- adwn 6y ago
  > My personal sites? If they run on their own bare metal, it's a waste because they're idle to nine nines. Your site is only busy for 31 milliseconds per year?
  - toast0 6y ago
    pretty much yeah. it's a static html <html><body><h1>It works!</h1></body></html> (I stole this from Debian)

bildung 6y ago

I think the main problem is that most computation happens at the user's browser - the different types of hosting will barely play a role in the overall footprint of a website. Edit: For an example, look at the app store for the oculus quest: https://www.oculus.com/experiences/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.

dr-detroit 6y ago
Your opinions are flat out wrong. Unless your market is in Japan you don't market your product with html1.0

jagged-chisel 6y ago

> The issue is how many computations you do at runtime. That is completely unrelated to third party libraries. 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?

charrondev 6y ago
In a “modern” JS project, the vast majority of dependencies are normally development dependencies. When you see so many generally 90% of it comes from dev/build time dependencies like webpack, typescript, linters, etc. 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?
- ogre_codes 6y ago
  > 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.

throwaway894345 6y ago

> 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. 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.

toast0 6y ago

> 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. 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.

adwn 6y ago
> My personal sites? If they run on their own bare metal, it's a waste because they're idle to nine nines. Your site is only busy for 31 milliseconds per year?
- toast0 6y ago
  pretty much yeah. it's a static html <html><body><h1>It works!</h1></body></html> (I stole this from Debian)