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?
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.
- Browsers don't "talk" any other language but JS
- All browser APIs are exposed through JS only
- You can't manipulate DOM except through JS
- 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
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).
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.
Depends on what you mean by sane modern layout :)
Many modern layouts are still impossible without a lot of JS intervention. Many web flourishes also require Javascript :)
That's why there are no DSLs for this: HTML and CSS already are the DSLs you're looking for.
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.
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.