You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+22-21Lines changed: 22 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -71,38 +71,39 @@ From the perspective of the importer this is ergonomically more or less equivale
71
71
72
72
And the above depends on the standardization and broad adoption of top-level await. Until that happens, devs are stuck exporting a Promise that the importer needs to deal with.
73
73
74
-
## Demo 2
75
-
### [CSS modules vs `<link>` elements in shadow roots](https://dandclark.github.io/json-css-module-notes/demo2/index.html)
### [CSS/JSON modules have a lower memory footprint than inlining the CSS/JSON as a JavaScript string](https://dandclark.github.io/json-css-module-notes/demo1/index.html)
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested using a custom Chromium build).
79
-
80
-
This demo compares two similar custom elements written as a JavaScript module, each of which loads its styles from a separate `styles.css` file. The first custom element applies its styles by adding the styles via a `<link rel="stylesheet">` in the custom element shadow root. The second loads its styles via a CSS module.
78
+
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested a custom Chromium build).
81
79
82
-
With the `<link>` element approach, the `<link>` isn't processed until an instance of the custom element is inserted into the document. In [demo2/NoModule.html](demo2/noModule.html), there is a delay before an instance of the custom element is created and inserted (to simulate, for example, a custom element that is only added based on some user action) and thus a corresponding delay before styles.css is fetched.
80
+
An alternative non-module approach for packaging CSS/JSON in a custom element is to inline the content as a JavaScript string rather than `fetch()`ing it dynamically. This string can be fed into a [Constructed Stylesheet](https://developers.google.com/web/updates/2019/02/constructable-stylesheets) or a `<style>` element.
81
+
This eliminates any concerns about a a delay in the `fetch()` as outlined above. However, in addition to the clunky developer ergonimics
82
+
of a bunch of inlined JavaScript string content in one's custom element JS logic, this approach has a quantifiable memory cost. This is due to the fact that the original JS string lives on alongside the CSSStyleSheet or JSON object that it is eventually parsed into. Whereas with CSS/JSON modules, nothing persists but the CSSStylesheet or JSON object.
83
83
84
-
#### With `<link rel="stylesheet">` in shadowRoot:
85
-
84
+
[Demo1](https://dandclark.github.io/json-css-module-notes/demo1/index.html) linked above illustrates this difference. Both the no-module and the module case load a custom element that pulls in ~30MB of CSS. The no-module case imports inlines it in the JS file defining the custom element, in the style of some of the [existing Chromium layered API elements](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/script/resources/layered_api/elements/). The module case imports the same CSS as a CSS module. After reaching steady-state, the memory difference is around the same ~30MB as the raw CSS text:
86
85
87
-
Using CSS modules, styles.css is fetched as part of processing the module graph, before any JavaScript is executed.
86
+
88
87
89
-
#### With CSS module:
90
-
88
+
This steady state is reached after leaving both tabs in the background for ~60 seconds. Before this final garbage collection, the difference is even more stark; in my observations the inline CSS case hovers around ~95MB for the first 60 seconds, whereas the CSS modules tab goes down to ~38MB within the first few seconds.
91
89
92
-
If `styles.css` was slow to arrive over the network, or was large enough to take a nontrivial amount of time to parse, front-loading the work could result in a user-percievable difference in how early the styles are applied to the page.
93
90
94
91
## Demo 3
95
-
### [CSS/JSON modules have a lower memory footprint than inlining the CSS/JSON as a JavaScript string](https://dandclark.github.io/json-css-module-notes/demo3/index.html)
92
+
### [CSS modules vs `<link>` elements in shadow roots](https://dandclark.github.io/json-css-module-notes/demo3/index.html)
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested a custom Chromium build).
95
+
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested using a custom Chromium build).
99
96
100
-
An alternative non-module approach for packaging CSS/JSON in a custom element is to inline the content as a JavaScript string rather than `fetch()`ing it dynamically. This string can be fed into a [Constructed Stylesheet](https://developers.google.com/web/updates/2019/02/constructable-stylesheets) or a `<style>` element.
101
-
This eliminates any concerns about a a delay in the `fetch()` as outlined above. However, in addition to the clunky developer ergonimics
102
-
of a bunch of inlined JavaScript string content in one's custom element JS logic, this approach has a quantifiable memory cost. This is due to the fact that the original JS string lives on alongside the CSSStyleSheet or JSON object that it is eventually parsed into. Whereas with CSS/JSON modules, nothing persists but the CSSStylesheet or JSON object.
97
+
This demo compares two similar custom elements written as a JavaScript module, each of which loads its styles from a separate `styles.css` file. The first custom element applies its styles by adding the styles via a `<link rel="stylesheet">` in the custom element shadow root. The second loads its styles via a CSS module.
103
98
104
-
[Demo3](https://dandclark.github.io/json-css-module-notes/demo3/index.html) linked above illustrates this difference. Both the no-module and the module case load a custom element that pulls in ~30MB of CSS. The no-module case imports inlines it in the JS file defining the custom element, in the style of some of the [existing Chromium layered API elements](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/script/resources/layered_api/elements/). The module case imports the same CSS as a CSS module. After reaching steady-state, the memory difference is around the same ~30MB as the raw CSS text:
99
+
With the `<link>` element approach, the `<link>` isn't processed until an instance of the custom element is inserted into the document. In [demo3/NoModule.html](demo3/noModule.html), there is a delay before an instance of the custom element is created and inserted (to simulate, for example, a custom element that is only added based on some user action) and thus a corresponding delay before styles.css is fetched.
105
100
106
-
101
+
#### With `<link rel="stylesheet">` in shadowRoot:
102
+
107
103
108
-
This steady state is reached after leaving both tabs in the background for ~60 seconds. Before this final garbage collection, the difference is even more stark; in my observations the inline CSS case hovers around ~95MB for the first 60 seconds, whereas the CSS modules tab goes down to ~38MB within the first few seconds.
104
+
Using CSS modules, styles.css is fetched as part of processing the module graph, before any JavaScript is executed.
105
+
106
+
#### With CSS module:
107
+
108
+
109
+
If `styles.css` was slow to arrive over the network, or was large enough to take a nontrivial amount of time to parse, front-loading the work could result in a user-percievable difference in how early the styles are applied to the page.
0 commit comments