JupyterLite – WASM-powered Jupyter running in the browser
51–60 of 68 posts
Re: JupyterLite – WASM-powered Jupyter running in the browser
#52Re: JupyterLite – WASM-powered Jupyter running in the browser
#53How far are we away from having _collaborative_ Jupyter in the browser? Would love a Google Docs experience of sharing a no-sign up required link to help remotely teach basic python.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#54How far are we away from having _collaborative_ Jupyter in the browser? Would love a Google Docs experience of sharing a no-sign up required link to help remotely teach basic python.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#55How far are we away from having _collaborative_ Jupyter in the browser? Would love a Google Docs experience of sharing a no-sign up required link to help remotely teach basic python.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#56Earlier quoted context omitted.
You misunderstood. The guy above correctly said that Jupyter is nice for ad-hoc analysis kind of work. The problem is that when you've reached terabytes of data and tens of cores you're not "ad-hoc" anymore. Too often the math guys try to avoid responsibility by claiming they're doing "ad-hoc" work when they're clearly not anymore. It's convenient, yes, but leads to a bad place eventually.
I understood fine. The problem is trying to formalize "ad hoc" versus "production development" practices as if they're meaningful. There isn't some golden truth of software development that analysts are too lazy to learn and implement. There's the problem and then there's solutions. Complaining that Jupyter-based development doesn't adequately accomdate version control or some other whistle commonly used in software…
At which point you'll dump the hot mess in somebody else's lap, and the whole thing will be rewritten from scratch.
If that's your thing, then go for it.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#57Earlier quoted context omitted.
> I said this already 10 years ago: We don't need more cloud computing but need to empower users end devices again. Jupyter is typically operated on powerful notebooks and not on mobile devices. If you’re working with data of any significant size at all it then it doesn’t matter how fast your user device is—it’s so much cheaper (time and network egress costs) to send the computations from a user device to the cloud t…
Most users don't have 'tens-thousands' of GB of data as part of their use case. You're describing a business case, not an end user consumer case.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#58Earlier quoted context omitted.
I understood fine. The problem is trying to formalize "ad hoc" versus "production development" practices as if they're meaningful. There isn't some golden truth of software development that analysts are too lazy to learn and implement. There's the problem and then there's solutions. Complaining that Jupyter-based development doesn't adequately accomdate version control or some other whistle commonly used in software…
Your boss will eventually ask to make your "ad-hoc" stuff "production". At which point you'll dump the hot mess in somebody else's lap, and the whole thing will be rewritten from scratch. If that's your thing, then go for it.
Re: JupyterLite – WASM-powered Jupyter running in the browser
#59Earlier quoted context omitted.
Any substance on why we shouldn’t be doing it or why it’s stupid? What’s the alternative? Should researchers all learn Kubernetes and AWS and deploy their own environments?
The problem with Jupyter is that it impedes common-sense practices like version control, reproducibility, and automation. If you're spending the time and effort to rent these big servers, why not spend the 5 percent of the effort and do it right? Jupyter exists mostly because analytics/math guys are too lazy to spend a day learning software development practices. Must be some sort of us-vs-them point of misplaced pri…
Version controlled Jupyter notebooks running in an automated environment (eg Kubernetes), with repeatable test data loading into a processing environment (eg. MinIO or Spark), is quite commonplace. Making it even easier with WASM makes sense.
What about Jupyter impedes good practices? That it empowers ad hoc exploration at all? It is merely an IDE tailored to sharing interactive text and code. To me it is one of the most exciting ecosystems for modern software development (and I’ve been developing software for 30 years).
Re: JupyterLite – WASM-powered Jupyter running in the browser
#60How far are we away from having _collaborative_ Jupyter in the browser? Would love a Google Docs experience of sharing a no-sign up required link to help remotely teach basic python.
Not that far, someone just needs to make a JupyterLab plugin that uses Automerge or a similar OT/CRDT structure for collaborative editing documents in a workspace (perhaps using WebRTC data channels for P2P sync between clients, or stick with the tried and true server model like Google docs). The trouble is turning that into something as polished and secure as Google Docs collaborative editing experience--there's a _…
This reuses almost all the RTC work done upstream in JupyterLab itself.
And since this is implemented as a regular JupyterLab plugin, folks will then be able to swap it for something else and implement their own if they want to, as a federated extension.