Comments (6)
Thanks for starting this. Some additional wrinkles on this:
- might block MVP
- when this gets tackled, we gotta get cache-busting in there
- the top-level can be handled by
index.js?v=<date>
- but subsequent requests below it need to "just work" on redeployment update, or there's gonna be a lot of really confused users
- the top-level can be handled by
- when this gets tackled, we gotta get cache-busting in there
- should not block MVP:
- re #41, it would be ideal if there was a solid way to extract which
static
are needed for which app, such thatjupyter lite build --app @jupyterlite/retro-lite ./my-site
only ships the assets needed, while adding another--app
would only increase the size by the delta of missing packages, without having to knowindex-this
fromindex-that
- have a path (if "fork it and..." in the docs, initially, so be it) to shipping (only) that novel third application (e.g.
CustomLabLite
). This is a case where, unless we unbundle everything into federated modules, someone will still need all the nodejs machinery, no real way around it at present
- re #41, it would be ideal if there was a solid way to extract which
from jupyterlite.
So i got a bit hung up on how we would refactor the various scripts to not make use of data
... and the interplay between bootstrap.js
and the sharing piece, as they will both actually be on the page at the same time, while multiple apps will not be on the page at the same time... but might share worker code, etc. So I'll probably take a look at some other stuff before re-engaging on this, in case someone else has a more concrete plan forward 🙏 !
As we think about #104, I guess there's a latent refactor in the baseline of @jupyterlab/builder
(though maybe we land it here first)... when it gets to the good stuff, might we have a pattern that supported
serverliteExtensions -> package.json#/jupyterlite/???
or, more generally
whateverExtensions => package.json#/???/???
from jupyterlite.
Thinking about this more: what if we just made everything into federated extensions?
Pro:
- site owners
- improve debuggability
- allow swapping out specific packages
- maintainers
- allow more parallel builds, and rebuild less on each incremental change
- even if not parallel, webpack time/memory/open files increase faster-than-linearly
Con:
- end users
- more initial downloads (but not that many more)... hard to assess vs HTTP/2 etc.
- maintainers
- might need to get more clever with our understanding of inter-package dependencies for the CLI
- most of these core features haven't been tested as federated extensions, and may reveal extra gotchas
from jupyterlite.
what if we just made everything into federated extensions?
That sounds very tempting 👍
Probably up until now there was some assumptions on what the base apps like JupyterLab would offer. But in the end they too are also just a set of extensions and probably should not have better treatment than the others.
from jupyterlite.
Also somehow related: it would be nice if we could improve the way the apps are built so we don't duplicate efforts. For example when we make a change to RetroLab we wouldn't need to update lite too if the change is compatible (for instance when adding a new plugin).
Example PRs for reference: #287 and jupyterlab/retrolab#187
Ideally, we would mostly work at the plugin level, with disabledExtensions
and a list of extra plugins. And hopefully most of the boilerplate could be hidden somewhere. Although this might require quite a bit of refactoring.
from jupyterlite.
With #274, we are now using pyodide 0.18, which also ships an officially-maintaiend npm package.
Semi-luckily, this ~100kb package is not a full distribution of all the WASM packages, which still needs to be handled out-of-band and match the package exactly, but does provide full typescript typings... and further includes typings from emscripten
.
However, as this package is not exactly small, it will exacerbate our on-going OoM/too-many-files issues, but is probably pretty important to move forward.
Since we'll have better metadata about what version of pyodide we're using, it's would probably be time to take the first step towards #45... i'm imagining we'll start a pyolite
section in jupyter_lite_config.json
and offer something like use_local_pydodide: True
(or a path to an equivalent tarball) and deploy it someplace predictable during the build. It will, however, be entirely impractical to load it n times for multiple apps.
from jupyterlite.
Related Issues (20)
- Improve the handling of invalid config files
- infinite scrolling loop HOT 4
- No content appears, `all.json` never generated despite content copied to `.../files/` HOT 2
- Collapsable cells HOT 2
- string saved to file has last part repeated (sometimes) HOT 2
- rendering cell output different from rendering same in file (unwrapped, directly in browser) HOT 3
- Widgets don't work with `display(...)`, and instead only appear as `repr(...)` text unless `jupyterlab_server` is installed before `lite build`, but there's no indication it's a requirement HOT 4
- Some extensions cannot be disabled using `disabledExtensions` HOT 3
- Pyodide crashes when starting two pyodide kernels at the same time in Chrome HOT 7
- Allow to pre-populate the REPL prompt without executing the code
- Deploying in environments with credentials HOT 1
- Pressing "Restart and run all cells" randomly causes silent pyodide kernel crash HOT 2
- Pyodide becomes irresponsive after a few ipywidgets interactions HOT 5
- Explicit index.html dropped from path in notebook ToC links
- Delete current notebook option from notebook File menu HOT 1
- ipywidgets Installation issue HOT 1
- DriveFS cannot overwrite-truncate existing file HOT 1
- Add a noscript tag to the page with "js must be enabled" ?
- Fix workflow to update the playwright snapshots HOT 1
- Unable to create a New Notebook HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jupyterlite.