Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

Bravo. Does anybody know of an energy-efficieny criterion or so to drive the 201x's webapp abominations out of existence going forward?

View on HN

I think the web is a great target for apps. The other app platforms are either proprietary or have negligible market share. The web as a platform for distributing applications is a better alternative than desktop platforms that are either fragmented or a monopoly.

The abomination is turning web pages into javascript apps when HTML would be a better choice. The browser already has the capability to render text and images. News articles and blogs are better served as static content than as apps that run in the browser.

The Chrome-only web future we're heading towards is as proprietary as it gets, and absurdly complex and unfit at the same time for demanding desktop apps people actually would want to use (audio, video, CAD, etc.). Google have successfully infiltrated web standard bodies and competitors to the point these are financially dependent on Google, successfully convincing younger devs that the web is a non-proprietary community effort.

As improbable as it sounds, your best bet for a portable desktop app seems X-Windows (1980's tech) or Qtk. Unless you wanted a shitty privacy-invading Web app, or one where the site owner can shut down your app and data at any time.

It sounds like your comment was meant to be snarky, but it is an interesting question. When you push the CPU processing of the UX from the mobile device back down to the server, the energy consumption certainly moves. Does it decrease, though?

Because if all JS were to go away tomorrow, and all CPU processing happened server-side, what would that change in server resource requirements?

I'm not convinced that tightening up web development practices is what's going to solve climate change, but:

> When you push the CPU processing of the UX from the mobile device back down to the server, the energy consumption certainly moves. Does it decrease, though?

One could argue that developers/website owners might be more motivated to optimize their server code for performance, thereby decreasing their hosting bills, vs optimizing front-end code which they don't pay to run.

You're assumption that it'd move server side is incorrect. It would simply disappear. When you use a javascript library the browser has to process and load all the functions in the library, even the functions that aren't used. This wastes memory and processing cycles on the client computer.

> When you use a javascript library the browser has to process and load all the functions in the library.

That simply isn't true. Your device does load a library (usually minified), and parses the JS to be sure it is runnable. But it doesn't run every function just because it is loaded in memory. Even if it did, it happens on app load, once... then runs functions on-demand. And the size of the load can be mitigated with appropriate use of tree-shakable libraries. But without JS, the server regenerates an entire page, every time you do something, which takes some resources. It sends it over the wires, which takes some small amount of resources. The mobile device loads an entire page again.

I do agree there is wasted processing in both scenarios. But that waste doesn't just disappear when you do server-side work.

Some of it moves server-side anyway. Counterpoint servers require expensive cooling, phones do not.

We all can over approximate in our preferred direction.

surely the more the client can do, the better.

Their machine is already on and idle, by pushing processing onto the backend your just creating a provisioning issue where either under or over provisioning is a waste of people's time or resource.

No. If I want to use an old computer I shouldn't have to wait forever for content because someone thought the client should do the work. That's a bigger waste of my time than your server capacity issues.

If the client device is a desktop computer, sure. Typically, the client is a mobile device whose bandwidth and energy are precious commodities. In these cases, better for the server to do the heavy lifting.

Separating form from content (xhr based) allows for better caching and overall respond better to changing demands, therefore limit the need for over-capacity. I think it is a null sum game between the two options.

Lowtech magazine investigated energy efficient web experience a few years ago, and the conclusion was much simpler. If we really want to have an impact on the energy, don't use white background in your design and use the default font, dithered images, reduce dynamic content and don't have the server running 24/7.

Reply on news.ycombinator.com