Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CDNs #1

Open
Balearica opened this issue Aug 15, 2024 · 0 comments
Open

Support CDNs #1

Balearica opened this issue Aug 15, 2024 · 0 comments

Comments

@Balearica
Copy link
Contributor

Creating this issue to track interest and progress (if any) for getting Scribe.js working with CDNs, so it can be imported from JSDelivr, unpkg, etc. At present, all code must be loaded from the same domain. Thumbs up this issue if this is something that matters to you, and leave a comment if there is a significant use-case that not supporting CDNs inhibits. My current understanding is that this is a nuisance that makes it more difficult to try out the package or share a snippet, but does not stop anybody from deploying the package in production.

For context, getting Scribe.js running on a CDN is probably possible, however has already proven a headache, and the CDN version would likely need to vary significantly from the main codebase (e.g. by hard-coding a lot of URLs and/or deleting dynamic imports).

  1. Loading code from a CDN requires the ability to load code from a different origin.
  2. Browsers do not allow for directly loading workers from different origins
    • Scribe.js makes extensive use of workers--nearly everything that is computationally expensive is offloaded to a worker.
  3. A common workaround is to create the worker from a blob, and have that blob contain code that imports the "real" worker code from the CDN.
    • This is what Tesseract.js does, and despite seeming hacky, a search online indicates this is the standard method of accomplishing this.
    • However, this approach breaks relative imports because the blob worker is not "relative" to any other files on the server.
      • Tesseract.js solves this by building all worker code to a single file.
      • This would be significantly harder in this codebase, as (1) we have many conditional imports and (2) workers can spawn additional workers.
  4. A less common workaround is to create the worker from a blob, and inline all of the blob code in the main file.
    • This is not viable for us, as it would massively inflate the bundle due to including every optional component.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant