Elektrine lite

← Feed

@aredridel@kolektiva.social

Post #3965685

2026-07-19 15:34 UTC

@b0rk@social.jvns.ca Yeah we've managed to make it exhausting, and I've kinda got a trace of technical patterns and decisions that drove us here. It goes back surprisingly far.

Replies (1)

  • @aredridel@kolektiva.social 2026-07-19 16:36

    @b0rk@social.jvns.ca The first friction is https://www.w3.org/Provider/Style/URI "Cool URIs don't change" MIME types to identify what kind of thing you're sending on the web have to come from somewhere. What we decided on first was to map filename extensions to them. This means that the filename, usually, became embedded in the URL. And because good URLs shouldn't change, the specific technologies are imprinted with a trace there. At the same time, we moved from frames as a navigational paradigm to includes, because frames are actually kind of a state-keeping nightmare. URLs should also only refer to one thing, and be specific. Framing broke that. Then we moved to dynamic generation and hid filenames because it was mostly includes anyway, and we lost the 1:1 mapping of file to URL entirely, and hosting got an order of magnitude more complicated. In there is the threshold we crossed that influenced design decisions ongoing in ways that keep this hard. That's when we stopped having web pages be _data_ and started having _applications_, running code. Frames, iframes and SSI includes still expressed relationships between information. But online, dynamic generation as the norm crossed into something we can no longer inspect and manipulate as information, only as representations of abstract things hidden inside a machine. That's the second friction: no longer is a "web server" a single pretty comprehensible construct, where they're all pretty similar — a few features here or there for things like content negotiation or include engines, but still roughly the job was "serve data from disk to network" Apache gave way to apache+mod_php gave way to nginx+php-fpm. Now it's TWO services. CGI scripts stopped being dynamic parts of sites, and instead became entire sites. Then the third friction: the abstraction of "the cloud". Excellent for simplifying large applications and scalable resource needs, because now sites exceeded the capacity of single servers regularly, instead of only at the peak scales. The cost though, is that now you have to rent infrastructure for even something simple. There is no 'throw it on the university file server'. The free options are mostly limited to the era of includes and frames. We now call those static site generators. But that means editing the site still requires something, or expertise in code and build systems. We no longer just edit the information. There's always code that comes with it. There's always been things pulling against these currents: CSS yanks us back in a good direction every time it becomes capable of expressing something without needing Turing-complete language. S3 having a way to set the mime type for an arbitrary URL is great. We lost Accept-Language along the way. We lost browser-managed authentication too, since HTTP Basic and HTTP Digest are old and janky now, hard to manage and integrate and secure well, and still lacking a way to "log out" in all current browsers. Inside the new web the old web is still struggling to get out, but it's buried deep. I keep intending to excavate. Haven't managed to yet. But in the end, what we want is to throw a site up and have it stay working. All our choices to this point have made that harder not easier.

    Open ##3965684