2022/10/29

From Woozle Writes Code
Revision as of 16:54, 29 October 2022 by Woozle (talk | contribs) (Created page with "{{page/date}} ==A Reaction== * '''2021-02-23''' [https://seirdy.one/posts/2021/02/23/keeping-platforms-open/ Keeping platforms open] ([https://pleroma.envs.net/notice/AP2dg3MA...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Saturday, October 29, 2022 (#302)
Friday Saturday Sunday

A Reaction

This made me think about Ferreteria vs. the dominant paradigm of JS-loading.

Keeping Ferreteria to plain HTML makes it very fast (while other webapps seem to get slower and bloatier every year) -- so why (one is forced to wonder) does everyone else seem to be focusing on JS-loading? Is it really just that they haven't figured out how to effectively provide the same level of interactivity without using a JS-based framework?

I have a theory that Ferreteria's speed is in part due to removing 99% of the load from the client (and bandwidth) and exchanging that for (possibly?) a bit more load per-user on the server. It's fast right now because there's only ever really been one user (me). It would probably continue to be pretty fast with users in the dozens, since user-initiated operations take a fraction of a second and are typically separated by many seconds or even minutes... but at some point, when we get up in to the thousands, that extra processor-load might start to show up.

With JS-loading, most of the processing gets loaded onto the user's client; from the server's perspective, it's static content which can be cached and punted off to CDNs. Ferreteria's processing, however, is all on the server, and usually requires DB access -- so it can't easily be distributed.

The sluggishness of JS-loading may serve another purpose as well: it domesticates users (see) into expecting sluggish response -- so when the server actually is a little overwhelmed, it's not as noticeable a change.

So... I'm thinking that Ferreteria-like frameworks are basically scaling-hostile (or at least scaling-passive-aggressive) -- and that this is actually kinda what we want, in order to minimize the power-enablement of any given app, the degree to which hosting that app enables dominance by a single org gaining a massive usership.

We want apps that are easy to deploy, but that don't (necessarily) scale well. We want to replace "scalability" with "federation" (and ultimately serverless P2P apps, for which we will also need dev frameworks).

(nb I'm not actually convinced that Ferreteria's extra back-end load is significant; that will require actually having a usership (or devising some kind of scalability-stress-test), which requires actually having a working app. But if it is, then here's where that points.)