It's a good effort, but a lot of this stuff reads more like the usual bureaucratic virtue-signaling that's popular these days. All that's needed to drastically decrease energy use is to just take late-90s/early 2000s web technology and push it to its limits. Zero JS unless absolutely necessary.
Two days ago I was watching the election results on various sites, along with many others. Some sites just didn't work in a slightly older browser, and those which did were still consuming a lot more resources than they really needed. It shouldn't require the latest in web technologies and computing hardware to show a simple dynamically updating outline map.
Just to play devils advocate for a minute: I live in Montréal Québec Canada, and the power entering my home is almost certainly generated at a hydroelectric dam. [0] There is an ecological impact from damming rivers, but in terms of GHG emissions, it's drastically better environmentally compared to coal or natural gas electricity generation systems.
If the service I'm using is hosted on us-east-1, it's using power from virginia, which uses a mix of natural gas and nuclear. [1]
Based on that... is running more logic on my computer or on an edge server within Québec, actually using less GHG-emitting energy than running it on the origin server?
Not sure why JS is the problem though. You can use JS in small doses to drastically improve the user experience on websites. The fact that heavy frameworks are sometimes used in contexts where they are overkill is not strictly JS' fault.
By that logic you would also need to go down the rabbit hole of what compilers produce efficient programs on the server side and ban everything else.
I think the tools we have nowadays are perfectly fine. It's a matter of how they are used. And I am pretty sure efficiency is not what companies think of when they launch a product.
Languages, language tools, language communities and language reputations are kinda inseparable.
You can write Java without using incredibly huge class, function, and variable names. You don't have to apply complex design patterns everywhere, or use a complicated framework you barely understand. You don't have to write code that produces 50-line stack traces. I don't have to import a dozen dependencies each with a dozen dependencies of their own, creating an endless security update treadmill. You don't have to write code that needs a gigabyte of RAM for the smallest microservice. Problems like long garbage collection pauses can be solved.
But if I take a job writing Java software? Probably I'm going to be handed a codebase written the way most Java developers write Java code. And I'd better make peace with that, or find a different job.
I agree. Sometimes the best you can do to cope with the sprawling ecosystems around programming languages and having to deal with convoluted codebases and inefficient programs, is sit down at home and building something simple (if you can spare the time and energy). That is what I do every now and then and it is incredibly satisfying to be able to explore how therapeutic programming can be when you are not boxed in.
I think this is not how companies work though, because they do not operate based on your views alone. And getting all people to agree on some of the topics you mentioned (e.g. importing dependencies vs. rolling your own implementations) is an incredibly complex task.
> All that's needed to drastically decrease energy use is to just take late-90s/early 2000s web technology and push it to its limits.
Yes, it doesn't have to be that time frame, but it would be a good reference point. Early 2000s allowed us to do most of what we can now, there are certainly exceptions, but the average website would be no worse. The savings in processing and memory consumption can then either be used to run other things, or extend the usable lifetime of a device. There's no reason why we could not use the same device for 10 or more years, again with some specialised exceptions.
Give that this is specifically a w3.org SIG, I'd suggest doing a LTS web standard, something like 10 - 15 years. Make it have a reduced feature set in terms of Javascript and CSS. For some businesses it would be attractive to know that a solution developed to a specific standard which would mean compatibility across devices and software for 10 years (ideally more, 10 years isn't that long). Newer devices would consume less power and older devices would require less frequent replacement.
The problem is that this would need to find it's way into a browser, which would also need a long term supported and stable operating system, to gain all the benefits.
The fact that you entirely ignore the biggest plague of the web, i.e. ads and analytics and all taboola garbage and autoplaying videos and audios, taking more energy than that once a year election pie chart makes me think that you are missing the forest for the tree. Also, even if I were to try picking up React today and make a most garbage pie chart on a page visited by whole population of America, it would still be dwarfed by the amount of energy wasted by watching a tiktok video on same number of devices.
One should not confuse energy-efficiency with sustainability. Yes, pushing simpler frameworks to its limits is good, but it is not the main issue, nor it is enough given the exponential growth in demand that we have been witnessing.
I tend to disagree, in the same way that it is better to use higher efficiency class dishwasher or washing machines it is better to use code that achieves the same with less computing power.
Saying that the increase in energy demand through reason x does not mean that efficiency efforts are in vain.
HE washers have been known to fail more quickly, are more complex and expensive to repair, and not do as good of a job as the machines they replaced, so I don't think that's a good analogy.
Is there a reason why there seemingly aren't any frameworks to do all the fancy web flourish in a normal language and then have it compile down to plain HTML5 + CSS + SVG?
You can compile almost any language to JS or WASM.
As to HTML + CSS: it goes other way around: HTML and CSS (or rather its subsets) are being integrated into "normal languages", like Qt, Java. I'm not sure I ever saw any technology that could serve as a replacement for HTML + CSS. May be Eclipse RAP or Blazor? But they are so heavy that React will look like a butterfly and they're not aiming to replace HTML/CSS but rather just use it as output medium for their UI.
Yeah that kind of stuff is closer but most of those types of frameworks seem to lean heavily on mapping to JS because they try to be turing complete rather than just being easy to work with DSLs.
- You can't do "fancy web flourish" without manipulating DOM. If you target Canvas/WebGL/WebGPU, you'd have to first create your entire graphics lib + flourish + font handling and rendering + accessibility + ... from scratch. And load all that on every page load
- Any language compiling into WASM would still need JS-integration for any of the above. Including Canvas/WebGL/WebGPU
- Any language without JS and DOM semantics will need to account for that (e.g. GC on DOM nodes)
- Any language compiling to WASM would need to load its runtime to actually run (including any libs). See network tab for any such project. e.g. Blazor
> - Browsers don't "talk" any other language but JS
I'm not looking for browsers to talk with any language. I'm looking for some DSL that directly maps to the 3 layout languages that browsers understand (i.e. HTML + CSS + SVG). Not anything turing complete at runtime but rather a sane way of describing a webpage layout with fancy styling, UI elements, transitions, and animations but without dealing with the pain that comes with actually writing in the native browser layout languages.
> You can't do "fancy web flourish" without manipulating DOM.
There is a lot of web flourish you can do without manipulating the DOM. It's not actually terribly unperformant to do but writing that code (mostly HTML + CSS, occasionally SVG) feels like peeling your eyelids with an unwashed lemon zester.
> ...
And for the rest of that, again I'm not looking for anything that actually executes in the browser. Just a sane, modern layout language that compiles down to static HTML and CSS with no JS or WASM (unless you explicitly ask for it).
The web spec is so complex because it serves different masters. You either making a web page, a web app, or some hybrid of the two. And there’s different constraints for each. And you will have to choose which subset to target if you were the one building that modern language.
Yep. Again, I'm not looking for a perfect global solution.
Just some domain specific language for writing sane low-to-no-js web pages or parts of web pages without having to manually fiddle with HTML or CSS in any real amount.
Static site generators honestly get me a lot of the way there but those are unfortunately template based which means any significant customisation requires dealing with the HTML and CSS rather than being able to just describe the layout and behavior I want.
Honestly I'd just write the compiler/lang myself if I didn't hate frontend so much.
Sounds like you might be looking for a Static Site Generator. Astro was already mentioned. There's plenty of others, mostly geared towards blogs. I also had success with docfx and MkDocs, both for project documentation.
Yep. I'm well versed with static site generators but every one I've ever worked with has been heavily template based rather than being an actual layout engine that map onto HTML+CSS+SVG. i.e. They all require you to still write in HTML+CSS+SVG rather than being a generalised way of writing HTML+CSS+SVG without dealing with the warts of those languages.
I don't entirely get what you mean by "layout engine". A WYSIWYG editor perhaps? Or maybe a canvas like Microsoft OneNote, where you can draw and put text boxes? Or a word processor? Why isn't the usual Markdown (or the like) approach enough?
My gut feeling is that you cannot (fully) abstract away HTML/CSS if you want the result to feel like an actual website.
With Astro, MkDocs or docfx, I do not have to touch HTML, except maybe for creating the master layout and/or transformation rules, if needed.
> Why isn't the usual Markdown (or the like) approach enough?
Because you can't use markdown to design CSS or SVG animations. I want to be able to design an animation with code that describes how the elements move/interact and then compile that down into CSS or SVG keyframes so that I don't have to manually declare however many arbitrarily complex keyframes.
I understand the purpose of a static site generator and I'm not looking for anything to replace that. Rather I want to be able to write the templates for my static sites without 1. writing exceptionally tedious HTML & CSS and without 2. relying on client side JS to do those tedious things.
I think HTML+CSS is already a pretty good layout engine, so people don't really bother. In fact I think it's so good it's used even when it really shouldn't be, like with Electron applications.
> Two days ago I was watching the election results on various sites, along with many others. Some sites just didn't work in a slightly older browser, and those which did were still consuming a lot more resources than they really needed
JS crypto miners working overtime. Will allow CNN/MSNBC/Fox/etc. to stay in business for another 4 years.
(Along with Ozempic ads, which are basically completely unnecessary now.)
How do you define absolutely necessary? Shitty JS frameworks written by incompetent people are absolutely necessary to the revenue of advertising media.
Two days ago I was watching the election results on various sites, along with many others. Some sites just didn't work in a slightly older browser, and those which did were still consuming a lot more resources than they really needed. It shouldn't require the latest in web technologies and computing hardware to show a simple dynamically updating outline map.