1
0

document reasons for increased network load in README

This commit is contained in:
Adrian Wannenmacher 2026-03-10 22:14:49 +01:00
parent f530706097
commit 55289557e1
Signed by: tfld
GPG Key ID: 19D986ECB1E492D5

View File

@ -15,19 +15,24 @@ following principles will guide its development.
score keeping tool. Logical expansions, like synching a session between users / devices, will 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 not be implemented, because they would be too complicated for the time I intend to spend on
maintenance. maintenance.
2. **Simple and stable dependencies:** I have learned in past projects that fast moving 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 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. 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. 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, 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 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. 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 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 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", 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. 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 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. that can be tested automatically should be.
6. **Good documentation:** I'll most certainly forget how some things work at some point. Thus it 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. 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. least document the disadvantages.
1. No access to a lot of JavaScripts modern ecosystem. 1. No access to a lot of JavaScripts modern ecosystem.
2. No access to compile time features such as actual typechecking. 2. No access to compile time features such as actual typechecking.
3. More network load that strictly necessary. 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. 4. Less performance than what would be possible.
### Violations ### Violations
@ -50,10 +66,12 @@ following:
1. The `jsconfig.json` file is a build tool configuration file. It shouldn't be needed, as the 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 project doesn't use any build tools. However, it allows the LSP to be more usefull, thus
justifying its existence. justifying its existence.
2. Nested CSS. It is so much more managable than repeating the same selectors over and over. Keep 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 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 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. 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 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 the same time as nested CSS. Might as well use it then, as a non-supporting browser can't be
used either way. used either way.