Enable browser / cross-platform support #18

NullVoxPopuli · 2023-07-29T01:32:25Z

Resolves: #11
Unblocks: NullVoxPopuli/limber#1162

Dist Branch: https://github.com/NullVoxPopuli/content-tag/tree/browser-support-dist

Demo of this working: https://4f4afaa6.limber-glimdown.pages.dev/
PR: NullVoxPopuli/limber#1162

(this screenshot reveals I have a concurrency issue because the wasm is loaded twice (this is a me problem, not a content-tag problem) 😅 )

pnpm:

"content-tag": "github:NullVoxPopuli/content-tag#browser-support-dist"

I used the term standalone similar to how @babel/standalone uses it -- in that the existing build of content-tag works in ESM, but is still meant for node usage. the standalone build is built using the browser option, which happens to then be compatible everywhere.

I'm new to Rust, so here are the learning materials I found / used

automated browser tests?

testem + qunit
- way too much manual work to set up with ESM-based tests.
playwright
- can't import anything to test / render / assert against (in ember, this is what ember-qunit is for)
- playwright is a browser driver w/ assertions
- also playwright downloads copies of browsers instead of using what's installed an the system.
vitest's browser mode
- no documentation
- "webdriverIO and playwright support", which means the same limitations as playwright native, probably (at least until they document more of how it's supposed to be used)
mocha (https://mochajs.org/#running-mocha-in-the-browser)
- doesn't explain how to report from browser to node, which is what we need for CI

We do have a npm run web that we can manually run to verify :-\

If anyone knows of a decent web-testing setup with ESM / TS ... that'd be great.

NullVoxPopuli · 2023-07-30T00:58:24Z

Cargo.toml

@@ -9,6 +9,10 @@ edition = "2021"
 [lib]
 crate-type = ["cdylib", "rlib"]

+[profile.release]
+lto = true
+opt-level = 'z'


the browser wasm module:

with only lto = true: 1MB

with only opt-level = 'z': 741K

with neither: 1MB

with both: 741K

with wee_alloc: 741K

with lol_alloc's LockedAllocator<FreeListAllocator>: 741K

with lol_alloc's AssumeSingleThreaded<FreeListAllocator>: 741K

with lol_alloc's FailAllocator: 374K (but also doesn't work 🙈 )

On a separate machine now, it seems I'm getting different results.
I had thought that the current version of the optimization settings would give 741K, but on this machine:

❯ du -r ./pkg/ 2.6M └─┬ pkg │██████████████████████████ │ 100% 1.3M ├─┬ node │ █████████████ │ 50% 1.3M │ ├── content_tag_bg.wasm │ █████████████ │ 49% 16K │ ├── content_tag.cjs │ ░░░░░░░░░░░░█ │ 1% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░░░█ │ 0% 1.3M ├─┬ browser │ █████████████ │ 50% 1.2M │ ├── content_tag_bg.wasm │ █████████████ │ 48% 16K │ ├── content_tag.js │ ░░░░░░░░░░░░█ │ 1% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░░░█ │ 0% 4.0K ├── package.json │ █ │ 0% 4.0K ├── README.md │ █ │ 0% 4.0K └── LICENSE │ █ │ 0%

the browser wasm is 1.2MB...

This ended up being about 1.35MB today:

Hopefully it can shrink in the future (or I can ditch more and more babel stuff / not use @babel/standalone, perhaps)

GH says less:

🤷 could be MiB vs MB or something.

but, 487kB isn't terrible since accuracy is what we're doing here. I can finally divide numbers before <template>, which is good.

note that I opted out of all the different allocators -- seemed too risky, the more I read about them

Today, tho:

❯ du -r ./pkg/ 2.7M └─┬ pkg │█████████████████████ │ 100% 1.3M ├─┬ standalone │ ███████████ │ 50% 1.3M │ ├── content_tag_bg.wasm │ ███████████ │ 48% 20K │ ├── content_tag.js │ ░░░░░░░░░░█ │ 1% 4.0K │ ├── standalone.js │ ░░░░░░░░░░█ │ 0% 4.0K │ ├── standalone.d.ts │ ░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░█ │ 0% 1.3M ├─┬ node │ ███████████ │ 50% 1.3M │ ├── content_tag_bg.wasm │ ███████████ │ 48% 16K │ ├── content_tag.cjs │ ░░░░░░░░░░█ │ 1% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░█ │ 0% 4.0K ├── package.json │ █ │ 0% 4.0K ├── README.md │ █ │ 0% 4.0K └── LICENSE │ █ │ 0%

with:
codegen-units = 1

❯ du -r ./pkg/ 2.6M └─┬ pkg │████████████████████████████████ │ 100% 1.3M ├─┬ standalone │ ████████████████ │ 50% 1.2M │ ├── content_tag_bg.wasm │ ████████████████ │ 48% 20K │ ├── content_tag.js │ ░░░░░░░░░░░░░░░█ │ 1% 4.0K │ ├── standalone.js │ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ ├── standalone.d.ts │ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░░░░░░█ │ 0% 1.3M ├─┬ node │ ████████████████ │ 49% 1.2M │ ├── content_tag_bg.wasm │ ████████████████ │ 48% 16K │ ├── content_tag.cjs │ ░░░░░░░░░░░░░░░█ │ 1% 4.0K │ ├── content_tag_bg.wasm.d.ts│ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ ├── content_tag.d.ts │ ░░░░░░░░░░░░░░░█ │ 0% 4.0K │ └── .gitignore │ ░░░░░░░░░░░░░░░█ │ 0% 4.0K ├── package.json │ █ │ 0% 4.0K ├── README.md │ █ │ 0% 4.0K └── LICENSE │ █ │ 0%

NullVoxPopuli · 2023-08-06T15:59:30Z

Most recently, I tried this using the new Git/dist branch (added to the PR description),
and the webpack config:

module: {
  rules: [
    {
      test: /\.wasm$/,
      type: "asset",
    },
  ]
},

(which seemed the least disruptive to wasm-pack's output, and still respected the native platform features of async wasm loading (a lot of folks seem to prefer asset/inline for wasm... which is a lot))

But I have an error about import names:

I think because webpack is renaming all the exports for some reason.
So I may hold off on this until I get limber/glimdown using Vite -- I don't really want to deal with webpack configs for too much longer.

…case Shrink generate WASM by 25% Save 9KB Set up web test Add more scripts Restore node testing Without wee_alloc, we grow ~ 450KB With no allocator, we get down to 540KB, but the thing doesn't run Back up to 1.2MB, but working in the browser With no changes to the allocator, we are at 1.2MB Give up on custom allocators since they all have problems Switch to dual build Update the README and document how to use Browser (ESM), Node (ESM) and Node (CJS) Update ci.yml Determine that it's simpler to not use a custom allocator -- there must be other ways to get the wasm size down tho Remove browser test experiments

NullVoxPopuli · 2023-11-03T23:49:50Z

build/src/standalone.js

+
+import init, { Preprocessor } from "./content_tag.js";
+
+export async function createPreprocessor() {


just a tiny wrapper function since the default way rust wants us to build a wasm thing is ... goofy. Like, I get it, two things need to happen, load the wasm file and then instantiate the stuff.
maybe I should PR to them.

NullVoxPopuli · 2023-11-03T23:50:19Z

index.html

+  <script type="module">
+    import {createPreprocessor} from './pkg/standalone/standalone.js';
+
+    async function run() {


this is how I'll be using it in my REPL, tho it'll be import { createPreprocessor } from 'content-tag/standalone'

NullVoxPopuli · 2023-11-03T23:50:56Z

test/node-api-esm.mjs

these are still using the non-standalone build.

README.md

…/leptos/appendix_binary_size.html

ef4 · 2023-11-30T20:49:39Z

I don't think we should really need a different import path and public API for the browser.

With conditional exports you could still have your standalone.js file but it would be invisible to consumers. It would be under the conditional export condition "browser".

And that file can use top-level await to await init(), so callers just see the same API as in node ESM.

NullVoxPopuli · 2023-12-01T15:33:59Z

I don't think we should really need a different import path and public API for the browser.

I can have a go at this, but (at least temporarily) it would make the project not consumable in ember at runtime 😅
See: embroider-build/embroider#1678

Standby! new PR incoming!

NullVoxPopuli · 2023-12-12T16:53:20Z

Closing, because we went with a non-monorepo approach

NullVoxPopuli commented Jul 30, 2023

View reviewed changes

NullVoxPopuli requested review from ef4 and mansona July 30, 2023 02:19

NullVoxPopuli marked this pull request as ready for review July 30, 2023 02:19

NullVoxPopuli mentioned this pull request Jul 30, 2023

Use content-tag so that we can work on Safari / iOS NullVoxPopuli/limber#1162

Merged

NullVoxPopuli mentioned this pull request Aug 19, 2023

Vite NullVoxPopuli/limber#1261

Closed

NullVoxPopuli mentioned this pull request Oct 3, 2023

Use content tag typed-ember/glint#615

Closed

NullVoxPopuli added 2 commits November 3, 2023 12:00

update lockfiles

597bdac

NullVoxPopuli force-pushed the browser-support branch from d9c0839 to 597bdac Compare November 3, 2023 16:02

NullVoxPopuli added 2 commits November 3, 2023 15:37

wip

3239bc8

fixes

1f4719b

NullVoxPopuli commented Nov 3, 2023

View reviewed changes

test/node-api-esm.mjs Outdated

Copy link

Contributor Author

NullVoxPopuli Nov 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are still using the non-standalone build.

NullVoxPopuli added 2 commits November 3, 2023 19:51

No need to createRequire

113ed72

Update standalone.d.ts

a997b4a

mansona reviewed Nov 7, 2023

View reviewed changes

README.md Outdated Show resolved Hide resolved

NullVoxPopuli added 4 commits November 6, 2023 19:09

Update README.md

f008c33

Update docs, release workflow, include npm install in build.sh

d691bab

Update ci.yml, since build.sh includes npm install

641448b

Specify codegen-units = 1, from hint from https://leptos-rs.github.io…

c15f7e4

…/leptos/appendix_binary_size.html

NullVoxPopuli mentioned this pull request Nov 23, 2023

content tag ember-tooling/prettier-plugin-ember-template-tag#162

Merged

NullVoxPopuli mentioned this pull request Dec 1, 2023

Add browser support via conditional exports #41

Closed

NullVoxPopuli closed this Dec 12, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable browser / cross-platform support #18

Enable browser / cross-platform support #18

NullVoxPopuli commented Jul 29, 2023 •

edited

Loading

NullVoxPopuli Jul 30, 2023 •

edited

Loading

NullVoxPopuli Jul 30, 2023 •

edited

Loading

NullVoxPopuli Nov 7, 2023

NullVoxPopuli Nov 7, 2023

NullVoxPopuli Nov 7, 2023

NullVoxPopuli Nov 8, 2023

NullVoxPopuli commented Aug 6, 2023

NullVoxPopuli Nov 3, 2023

NullVoxPopuli Nov 3, 2023

NullVoxPopuli Nov 3, 2023

ef4 commented Nov 30, 2023

NullVoxPopuli commented Dec 1, 2023 •

edited

Loading

NullVoxPopuli commented Dec 12, 2023


		import init, { Preprocessor } from "./content_tag.js";

		export async function createPreprocessor() {

Enable browser / cross-platform support #18

Enable browser / cross-platform support #18

Conversation

NullVoxPopuli commented Jul 29, 2023 • edited Loading

NullVoxPopuli Jul 30, 2023 • edited Loading

Choose a reason for hiding this comment

NullVoxPopuli Jul 30, 2023 • edited Loading

Choose a reason for hiding this comment

NullVoxPopuli Nov 7, 2023

Choose a reason for hiding this comment

NullVoxPopuli Nov 7, 2023

Choose a reason for hiding this comment

NullVoxPopuli Nov 7, 2023

Choose a reason for hiding this comment

NullVoxPopuli Nov 8, 2023

Choose a reason for hiding this comment

NullVoxPopuli commented Aug 6, 2023

NullVoxPopuli Nov 3, 2023

Choose a reason for hiding this comment

NullVoxPopuli Nov 3, 2023

Choose a reason for hiding this comment

NullVoxPopuli Nov 3, 2023

Choose a reason for hiding this comment

ef4 commented Nov 30, 2023

NullVoxPopuli commented Dec 1, 2023 • edited Loading

NullVoxPopuli commented Dec 12, 2023

NullVoxPopuli commented Jul 29, 2023 •

edited

Loading

NullVoxPopuli Jul 30, 2023 •

edited

Loading

NullVoxPopuli Jul 30, 2023 •

edited

Loading

NullVoxPopuli commented Dec 1, 2023 •

edited

Loading