Skip to toolbar

Community & Business Groups

WEB Protocols and Energy Utilization

Hej all,

Isn’t anyone more than me concerned about the enormous amount of energy the WEB transforms?

I feel very frustrated. This post is wild, unpolite and unstructured but I hope someone will pick up the message.

Outdated HTML ?

Even though much effort is spent on virtualization WEB-serves the overall load is depending on the fact that we feed the computers with data using OUTDATED protocols.
Protocols Like HTML/CSS/Javascript/HTTP/Cookies etc have become
a mess of construction like using LEGO, MECCANO and bunch of different glues at the same time

I mean that the HTML really is mature enough for architectural refactoring.

90% reloaded

Most of you – I think – are often disturbed by long response time but also quite annoyed on uncertain behavior of a WEB interaction. The very point in this observation is that the basic HTML with its PAGE/BODY metaphor is from old batch -90 IT-system. In a session – constituted by a set of interactions – the whole content on the user screen is (re)produced by the server, transported and rendered.
Even though most of the visual screen is he same! My experiences the last years are that 90% of the visual screen is the same between two steps – just 10% is changed.
But HTML is not able – by design – to just send the changes.

<ReplaceSomething ID=”…>

But the basic HTML has no tag for <ReplaceSomething ID=”…>.

If such a mechanism – REPLACE – was introduced I think we can reduce the energy utilization by 90% – a magnitude – and also make it much more easier for the Dialog Constructor on the server to really make a radically more understandable interactions and express the in basic HTML perhaps using the MVC Pattern.

Of course there exist solutions today which will work like REPLACE PART. Build a mix of javascript, AJAX and JSON/HTML. But this should be standard in basic HTML. No javascript for this.

Compatibility

The WEB-browser must deal with the <REPLACE>
Introduce a <!doctype ResponseCouldBeBodyOrReplace …/> telling that responses from an HREF et al. request might be one of

1. <!doctype as present standard of course …>
2. <!doctype ResponseCouldBeBodyOrReplace …/>
3. <!doctype Replace…/><REPLACEPARTS>…</REPLACEPARTS>

Focus on goals (Energy Utilization)

Forget the obsessed focus on functions and performance!
Forget cache (rethink).
Recfactor CSS into layout (positioning) and style (texture) at least.
Forget javascript, forget crawlers.
Forget for the present.

Hurry up before the goverments detects that there are no relationships between W3C and Energy Utilization.

I’m not the guy to run or orchestra a group on ‘WEB Protocols and Energy Utilization’ but I can contribute with experience and idea and reviews.

Cheers!

2 Responses to WEB Protocols and Energy Utilization

  • Benjamin Beurdouche

    Hello Dear Willy,
    First of all let me thank you for giving your thoughts on that problem! As you have maybe seen, the forum is not very active even regarding interesting topics like yours or the user identity group i just proposed…While I don’t know how long it will remain like that, let’s talk =)

    First, I do agree with you it is necessary that the W3C has to keep in mind that the way the web standards are evolving has, at least, as much importance for energetic (and financial) as the hardware infrastructure of internet.
    I do agree with you about the fact that an enormous quantity of energy is used in order to update the content of webpages. This process is not efficient enough but for now it seems energetic consumption is not a very big concern while i do too consider it should be!
    My point of view regarding this is that the usual frameworks of web languages (HTML, PHP, AJAX …) should be unified, or at least converge at some point ! This would have a few advantages like for instance reducing power consumption by automatically using the most common and efficient way to do each task, and moreover the second point is that it would contribute to the accessibility of the web which is not the case at the moment. In the future the ways to interact with computers will evolve and I’m not sure the coding like we do it now will keep beeing as complex since not everybody has time to learn all this languages, simple webpages or new kinds of web services are not so easy enough to create.

    At least two approaches are possible then: optimise each languages and continue to dissociate them or the second : I personally would have the approch to first unify languages while optimazing operations like refresh process so that the transition between the old and the new ways of writing would be smooth enough…
    What do you think about all that ? =)

    Cheers,
    Benjamin

    Reply

  • Willy Svenningsson

    @Benjamin:
    Fragmented comments
    …forum is not very active.. (and still some bureaucratic. It seems like the internal processes of W3C are exposed and that
    we must stick to that. The public ‘process description’ is some 20k text without any drawings at all)

    ..energetic (and financial).. (follow the money!)

    ..it would contribute to the accessibility of the web.. (not many seems to care about usability)

    I also think that in order to meet all demands – safe and secure and ability to verify etc –

    we must reduce the complexity. It cost energy to learn new languages and their usage.

    I like your writings on …that the transition between the old and the new ways of writing would be smooth enough.

    You mentioned frameworks on the server side.
    My latest thoughts are that the server is a stateless and mindless functional program responsible for transforming my desktop (XHTML) view state to another modified (XHTML) state.
    So just give me the changes back. I’m alsmost blind – or might be – and can’t overlook a full XHTML replacement.

    @all:

    I will suggest a group on the ‘WEB Protocols and Energy Utilization’.

    Support it! You must though join as a member I think.

    If you hesitate joining this community visit my demo at deciweb.se/SuggestionsW3C/

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*