document reasons for increased network load in README
This commit is contained in:
parent
f530706097
commit
55289557e1
18
README.md
18
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
|
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.
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user