From 55289557e1eda70fcb17d44a9025ab821e025888 Mon Sep 17 00:00:00 2001 From: Adrian Wannenmacher Date: Tue, 10 Mar 2026 22:14:49 +0100 Subject: [PATCH] document reasons for increased network load in README --- README.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/README.md b/README.md index 95bdb21..c3b2113 100644 --- a/README.md +++ b/README.md @@ -15,19 +15,24 @@ following principles will guide its development. score keeping tool. Logical expansions, like synching a session between users / devices, will not be implemented, because they would be too complicated for the time I intend to spend on maintenance. + 2. **Simple and stable dependencies:** I have learned in past projects that fast moving environments, like many modern JS frameworks, are very tedious to keep up with. Therefore all libraries must be stable and consistent. Also, I don't want to spend much time wrangling npm. Therefore all dependencies must be vendorable as a couple of files. + 3. **Browser based development:** I don't want to spend a lot of time on build tools, transpilers, and similar things. All code has to be able to run in the browser in the form it is written. All dev tools (like the testing framework) have to be able to run in the browser. + 4. **Targetting Baseline:** The limited time for maintenance means I won't be able to do testing for all browser/version/os tripples. Instead, I'll target "baseline widely available" and rely on it's correctness for portability. I'll also use features that are "baseline newly available", but only with feature checking, which I'll only do for them. + 5. **Extensive tests:** I don't want to spend a lot of time on bug hunting, therefore everything that can be tested automatically should be. + 6. **Good documentation:** I'll most certainly forget how some things work at some point. Thus it is paramount to keep a good documentation, so I won't have to read through everything again. @@ -38,8 +43,19 @@ have a cost. While I have deemed it to be worthwhile in this case, I consider it least document the disadvantages. 1. No access to a lot of JavaScripts modern ecosystem. + 2. No access to compile time features such as actual typechecking. + 3. More network load that strictly necessary. + + Build tools can provide minification, bundling and tree shaking. All of these are not available + to this project, but likely would decrease the total amount of data needed to be transfered. + However, likely it wouldn't actually be all that much, because it's a rather small application, + and it does its own caching with the service worker. + + Also, most of the icons font could propably be cut away with some build tool. While I could do + that manually, it'd be too much hassle if I ever needed an additional icon. + 4. Less performance than what would be possible. ### Violations @@ -50,10 +66,12 @@ following: 1. The `jsconfig.json` file is a build tool configuration file. It shouldn't be needed, as the project doesn't use any build tools. However, it allows the LSP to be more usefull, thus justifying its existence. + 2. Nested CSS. It is so much more managable than repeating the same selectors over and over. Keep in mind that the principles are to make the maintenence of this side project viable for me in the long term. In ~4 months from this writing (2026-03-04) they become baseline widely available and I would want to rewrite all the styles then. I deem this to be a worthwhile trade-off. + 3. The `:has()` CSS pseudo-class. While it's not as useful, it becomes baseline widely available at the same time as nested CSS. Might as well use it then, as a non-supporting browser can't be used either way.