tuxmain/website
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

surveillance fixes, index update, asm draft

Browse source
This commit is contained in:
Pascal Engélibert 2024-11-29 17:34:50 +01:00
commit 54b35e7aaf
6 changed files with 69 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

11
content/blog/js.md
View file

@ -25,7 +25,7 @@ JavaScript is obviously not made for being used in webpages.
* no native HTML escaping function
* no native basic templating system (need `String.replaceAll("{{foo}}", foo)`)
* no easy-to-use bytes array (like `Bytes` in Python or `Vec<u8>` in Rust), but many different bytes arrays with weird interfaces
* no native cryptographic tools if you aren't using HTTPS and satisfying other strange "security" requirements (you often end up inefficiently implementing SHA2 or AES in JS, while the browser natively uses OpenSSL)
* no native cryptographic primitives if you aren't using HTTPS and satisfying other strange "security" requirements (you often end up inefficiently implementing SHA2 or AES in JS, while the browser natively uses OpenSSL)
* no native date/time string formatting
* When defining an anonymous function (such as a callback) you can't reliably move variables to it.
@ -46,7 +46,8 @@ JavaScript doesn't respect anything.
```
* Hence `==`, `===` and `if` have three distinct strictness levels.
* `&&` is not commutative: `(true && "2") === "2" && ("2" && true) === true` is true
* It is even inconsistent: `"0" == false && "1" == true` is true... but so is `"0" && "1"`.
* It is even inconsistent: `"0" == false && "1" == true` is true...
but so is `"0" && "1"`.
* Operators are inconsistent: we have both `"1"+1 === "11"` and `"1"*2 === 2`
* ```js
var n = "1";
@ -67,10 +68,10 @@ JavaScript doesn't respect anything.
```
* `document.getElementsByClassName` does not return an array: its return type supports indexing but not for/in loops.
## Conclusion
Let's deprecate JavaScript and replace it with better languages compiled into WASM.
However, plain HTML/CSS should *always* be prefered, for performance, compatibility and accessibility. Form inputs crafted with tons of CSS and JS are often unresponsive, not accessible to screen readers, incompatible with native features, inefficient. It is even worse for pages rendered in a canvas. Please use the wonderful possibilities offered by HTML5 and CSS3, and follow the accessibility recommendations by the [W3C](https://www.w3.org/WAI/) and [Mozilla](https://developer.mozilla.org/en-US/docs/Web).
However, plain HTML/CSS should *always* be prefered, for performance, compatibility and accessibility. Form inputs crafted with tons of CSS and JS are often unresponsive, not accessible to screen readers, incompatible with native features, inefficient. It is even worse for pages rendered in a canvas.
Please use the wonderful possibilities offered by HTML5 and CSS3, and follow the accessibility recommendations by the [W3C](https://www.w3.org/WAI/) and [Mozilla](https://developer.mozilla.org/en-US/docs/Web).