Fossil SCM
It turns out we already have javascript.md, with similar aims, so now it's a matter of integrating this doc into that one.
Commit
2e131efc87c5948600f9e6aca940f500a38d087426dcb050c7834f4364e45ebc
Parent
571bf459be99b10…
1 file changed
+10
-10
+10
-10
| --- www/js-policy.md | ||
| +++ www/js-policy.md | ||
| @@ -25,11 +25,11 @@ | ||
| 25 | 25 | |
| 26 | 26 | - To provide asynchronous communication between the client and the |
| 27 | 27 | server, commonly known as "ajax" or "XHR" communication. This allows |
| 28 | 28 | certain pages to operate more quickly and fluidly by avoiding |
| 29 | 29 | complete round-trips to and from the server. Perhaps |
| 30 | - counter-intuitively, the increase JS load such pages typically | |
| 30 | + counter-intuitively, the increased JS load such pages typically | |
| 31 | 31 | require costs less bandwidth than is saved via using ajax traffic |
| 32 | 32 | instead of conventional HTML forms. |
| 33 | 33 | |
| 34 | 34 | - To implement, or reimplement, certain editing-centric features with |
| 35 | 35 | a degree of interactivity which is impossible to duplicate in purely |
| @@ -48,17 +48,17 @@ | ||
| 48 | 48 | 1. "It's increases the size of the page download." |
| 49 | 49 | - For the fossil pages which make heavy use of JS, the initial page |
| 50 | 50 | transfer size may increase: 6-8kb (compressed) is typical, and it |
| 51 | 51 | may even go up to a whopping 15kb (as of this writing, it's 8kb |
| 52 | 52 | compressed on our most JS-intensive page (`/fileedit`), and only |
| 53 | - 25kb uncompressed and unobfuscated). With fossil's newer (summer 2020) | |
| 53 | + 25kb uncompressed). With fossil's newer (summer 2020) | |
| 54 | 54 | JS delivery mechanism and etags-related caching |
| 55 | 55 | improvements, such JS can be served with a single HTTP request and |
| 56 | 56 | cached by browsers for up to a year. Additionally, most pages |
| 57 | 57 | which use that much JS also use comparitively lightweight ajax |
| 58 | 58 | communication to eliminate page reloads and enable data-loss-free |
| 59 | - recovery in certain error cases which would lose client-side edits | |
| 59 | + recovery in certain error cases which could lose client-side edits | |
| 60 | 60 | in a non-JS-powered page. The end result is that the aggregate |
| 61 | 61 | cost of such pages is actually *lower* than their static |
| 62 | 62 | counterparts, and the total bytes of JS "overhead" is equal to |
| 63 | 63 | only 1-2 full round-trip requests of the equivalent static pages. |
| 64 | 64 | |
| @@ -78,11 +78,11 @@ | ||
| 78 | 78 | [default CSP](defcsp.md) prohibits execution of JS code which is |
| 79 | 79 | delivered from anywhere but the fossil server which delivers the |
| 80 | 80 | page. |
| 81 | 81 | |
| 82 | 82 | 3. "It's slow." |
| 83 | - - It *was*, before September 2008. Google's introduction [of their | |
| 83 | + - It *was*, before September 2008. Google's introduction of [their | |
| 84 | 84 | V8 JS engine][v8] taught the world that JS need not be slow, and |
| 85 | 85 | the JS engines used by every modern browser have been improved |
| 86 | 86 | upon by leaps and bounds to keep them competitive with Google's |
| 87 | 87 | engine. Nowadays JS is, as a rule, astoundingly fast. As the world |
| 88 | 88 | continues to move more and more to web-based applications |
| @@ -90,16 +90,16 @@ | ||
| 90 | 90 | their engines fast and competitive. |
| 91 | 91 | |
| 92 | 92 | [v8]: https://en.wikipedia.org/wiki/V8_(JavaScript_engine) |
| 93 | 93 | |
| 94 | 94 | 4. "Cross-browser compatibility is poor." |
| 95 | - - It *most certainly was*. Starting around 2006/2007, when jQuery | |
| 96 | - literally revolutionized how people worked with and thought about | |
| 97 | - JS, there has been a massive industry-level push behind it and | |
| 98 | - compatibility has become the norm rather than the exception. | |
| 99 | - Cross-browser JS compatibility issues which affect web developers | |
| 100 | - are, by and large, a thing of the past. | |
| 95 | + - It *most certainly was*. Since 2006/2007, when jQuery literally | |
| 96 | + revolutionized how people worked with and thought about JS, there | |
| 97 | + has been a massive industry-level push behind it and compatibility | |
| 98 | + has become the norm rather than the exception. Cross-browser JS | |
| 99 | + compatibility issues which affect web developers are, by and | |
| 100 | + large, a thing of the past. | |
| 101 | 101 | |
| 102 | 102 | 5. "The UI works fine without it." |
| 103 | 103 | - True, for *some* definition of "works." Modern times and modern |
| 104 | 104 | tools call for modern solutions. While we don't claim to be |
| 105 | 105 | cutting-edge technologists, the days of when static HTML |
| 106 | 106 |
| --- www/js-policy.md | |
| +++ www/js-policy.md | |
| @@ -25,11 +25,11 @@ | |
| 25 | |
| 26 | - To provide asynchronous communication between the client and the |
| 27 | server, commonly known as "ajax" or "XHR" communication. This allows |
| 28 | certain pages to operate more quickly and fluidly by avoiding |
| 29 | complete round-trips to and from the server. Perhaps |
| 30 | counter-intuitively, the increase JS load such pages typically |
| 31 | require costs less bandwidth than is saved via using ajax traffic |
| 32 | instead of conventional HTML forms. |
| 33 | |
| 34 | - To implement, or reimplement, certain editing-centric features with |
| 35 | a degree of interactivity which is impossible to duplicate in purely |
| @@ -48,17 +48,17 @@ | |
| 48 | 1. "It's increases the size of the page download." |
| 49 | - For the fossil pages which make heavy use of JS, the initial page |
| 50 | transfer size may increase: 6-8kb (compressed) is typical, and it |
| 51 | may even go up to a whopping 15kb (as of this writing, it's 8kb |
| 52 | compressed on our most JS-intensive page (`/fileedit`), and only |
| 53 | 25kb uncompressed and unobfuscated). With fossil's newer (summer 2020) |
| 54 | JS delivery mechanism and etags-related caching |
| 55 | improvements, such JS can be served with a single HTTP request and |
| 56 | cached by browsers for up to a year. Additionally, most pages |
| 57 | which use that much JS also use comparitively lightweight ajax |
| 58 | communication to eliminate page reloads and enable data-loss-free |
| 59 | recovery in certain error cases which would lose client-side edits |
| 60 | in a non-JS-powered page. The end result is that the aggregate |
| 61 | cost of such pages is actually *lower* than their static |
| 62 | counterparts, and the total bytes of JS "overhead" is equal to |
| 63 | only 1-2 full round-trip requests of the equivalent static pages. |
| 64 | |
| @@ -78,11 +78,11 @@ | |
| 78 | [default CSP](defcsp.md) prohibits execution of JS code which is |
| 79 | delivered from anywhere but the fossil server which delivers the |
| 80 | page. |
| 81 | |
| 82 | 3. "It's slow." |
| 83 | - It *was*, before September 2008. Google's introduction [of their |
| 84 | V8 JS engine][v8] taught the world that JS need not be slow, and |
| 85 | the JS engines used by every modern browser have been improved |
| 86 | upon by leaps and bounds to keep them competitive with Google's |
| 87 | engine. Nowadays JS is, as a rule, astoundingly fast. As the world |
| 88 | continues to move more and more to web-based applications |
| @@ -90,16 +90,16 @@ | |
| 90 | their engines fast and competitive. |
| 91 | |
| 92 | [v8]: https://en.wikipedia.org/wiki/V8_(JavaScript_engine) |
| 93 | |
| 94 | 4. "Cross-browser compatibility is poor." |
| 95 | - It *most certainly was*. Starting around 2006/2007, when jQuery |
| 96 | literally revolutionized how people worked with and thought about |
| 97 | JS, there has been a massive industry-level push behind it and |
| 98 | compatibility has become the norm rather than the exception. |
| 99 | Cross-browser JS compatibility issues which affect web developers |
| 100 | are, by and large, a thing of the past. |
| 101 | |
| 102 | 5. "The UI works fine without it." |
| 103 | - True, for *some* definition of "works." Modern times and modern |
| 104 | tools call for modern solutions. While we don't claim to be |
| 105 | cutting-edge technologists, the days of when static HTML |
| 106 |
| --- www/js-policy.md | |
| +++ www/js-policy.md | |
| @@ -25,11 +25,11 @@ | |
| 25 | |
| 26 | - To provide asynchronous communication between the client and the |
| 27 | server, commonly known as "ajax" or "XHR" communication. This allows |
| 28 | certain pages to operate more quickly and fluidly by avoiding |
| 29 | complete round-trips to and from the server. Perhaps |
| 30 | counter-intuitively, the increased JS load such pages typically |
| 31 | require costs less bandwidth than is saved via using ajax traffic |
| 32 | instead of conventional HTML forms. |
| 33 | |
| 34 | - To implement, or reimplement, certain editing-centric features with |
| 35 | a degree of interactivity which is impossible to duplicate in purely |
| @@ -48,17 +48,17 @@ | |
| 48 | 1. "It's increases the size of the page download." |
| 49 | - For the fossil pages which make heavy use of JS, the initial page |
| 50 | transfer size may increase: 6-8kb (compressed) is typical, and it |
| 51 | may even go up to a whopping 15kb (as of this writing, it's 8kb |
| 52 | compressed on our most JS-intensive page (`/fileedit`), and only |
| 53 | 25kb uncompressed). With fossil's newer (summer 2020) |
| 54 | JS delivery mechanism and etags-related caching |
| 55 | improvements, such JS can be served with a single HTTP request and |
| 56 | cached by browsers for up to a year. Additionally, most pages |
| 57 | which use that much JS also use comparitively lightweight ajax |
| 58 | communication to eliminate page reloads and enable data-loss-free |
| 59 | recovery in certain error cases which could lose client-side edits |
| 60 | in a non-JS-powered page. The end result is that the aggregate |
| 61 | cost of such pages is actually *lower* than their static |
| 62 | counterparts, and the total bytes of JS "overhead" is equal to |
| 63 | only 1-2 full round-trip requests of the equivalent static pages. |
| 64 | |
| @@ -78,11 +78,11 @@ | |
| 78 | [default CSP](defcsp.md) prohibits execution of JS code which is |
| 79 | delivered from anywhere but the fossil server which delivers the |
| 80 | page. |
| 81 | |
| 82 | 3. "It's slow." |
| 83 | - It *was*, before September 2008. Google's introduction of [their |
| 84 | V8 JS engine][v8] taught the world that JS need not be slow, and |
| 85 | the JS engines used by every modern browser have been improved |
| 86 | upon by leaps and bounds to keep them competitive with Google's |
| 87 | engine. Nowadays JS is, as a rule, astoundingly fast. As the world |
| 88 | continues to move more and more to web-based applications |
| @@ -90,16 +90,16 @@ | |
| 90 | their engines fast and competitive. |
| 91 | |
| 92 | [v8]: https://en.wikipedia.org/wiki/V8_(JavaScript_engine) |
| 93 | |
| 94 | 4. "Cross-browser compatibility is poor." |
| 95 | - It *most certainly was*. Since 2006/2007, when jQuery literally |
| 96 | revolutionized how people worked with and thought about JS, there |
| 97 | has been a massive industry-level push behind it and compatibility |
| 98 | has become the norm rather than the exception. Cross-browser JS |
| 99 | compatibility issues which affect web developers are, by and |
| 100 | large, a thing of the past. |
| 101 | |
| 102 | 5. "The UI works fine without it." |
| 103 | - True, for *some* definition of "works." Modern times and modern |
| 104 | tools call for modern solutions. While we don't claim to be |
| 105 | cutting-edge technologists, the days of when static HTML |
| 106 |