Live data from Hacker News

JupyterLite – WASM-powered Jupyter running in the browser

github.com

61–68 of 68 posts

Re: JupyterLite – WASM-powered Jupyter running in the browser

#61

Earlier quoted context omitted.

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.

Most of the users will not run Jupyter Notebooks locally, they expect a remote kernel in the cloud with GPU/multicore machines, only the web app will be running in browser (think of big query). Of course small users with you datasets will run locally.

This depends greatly what you want to do. After all, this has incredible latency (compared to the cloud), limited throughput. Zero configuration. Free.

You want to train the next imagenet model? Analyse 100Gig database? Probably not the correct tradeoff.

You want 20 students to have a perfectly consistent instant-start-up python environment? Definitely the correct tradeoff.

You want to try some python methods, write tests, ... Very short latency is going to help you more than throughput is.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#62
post #51

How 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.

Doesn’t fufill your wish for no-sign up link yet, but https://hex.tech supports live collaboration for python notebooks.

I think as time goes on, live collaboration is becoming “table stakes” for a lot of tools.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#63

Earlier quoted context omitted.

> Jupyter exists mostly because analytics/math guys are too lazy to spend a day learning software development practices Bahahahaha, yup those dang lazy mathematicians just shooting themselves in the foot and forcing us to deal with it! /s Your preferences for software development are irrelevant. The value is in delivering the math to the end user. Using GCP, kubernetes or JavaScript to do that is an implementation de…

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.

>The problem is that when you've reached terabytes of data and tens of cores you're not "ad-hoc" anymore.

Oh, yes you are. "Ad-hoc" doesn't imply small. It implies one-off exploration and creation. You have no less of a need to do that with terabytes of data than you do with megabytes.

Re: JupyterLite – WASM-powered Jupyter running in the browser

#64
post #48

Earlier quoted context omitted.

Good. People who are bad at administering computers will stop doing it, and will focus on what they're good at. Then, we can use the on-demand nature of cloud services to reduce their power consumption. Simultaneously we can move that consumption into renewable-powered datacenters. This is literally better for everyone.

Meanwhile we create tremendous concentration risk and the world pays rent to Amazon, Google and Microsoft? I wouldn't call that 'good'.

[deleted]

Re: JupyterLite – WASM-powered Jupyter running in the browser

#65
post #48

Earlier quoted context omitted.

Good. People who are bad at administering computers will stop doing it, and will focus on what they're good at. Then, we can use the on-demand nature of cloud services to reduce their power consumption. Simultaneously we can move that consumption into renewable-powered datacenters. This is literally better for everyone.

Meanwhile we create tremendous concentration risk and the world pays rent to Amazon, Google and Microsoft? I wouldn't call that 'good'.

I don't understand your argument, people should do things they're bad at to keep some other company from getting too big? And oh by the way they'll now probably be using more and less sustainable power, but at least they'll be less secure. That sounds like a very high price to pay for ideological purity...

Re: JupyterLite – WASM-powered Jupyter running in the browser

#66
Just to throw in my 2c. I'm a big fan of jupyter notebooks for data visualisation and prototyping pipelines. Being able to run all of your data analysis code then run your visualisation code without having to repipe your data is great.

For other projects such as bots, webapps or regular programming I'll use vscode or neovim.

Which brings me to a neat feature in vscode that has me starting to do my data vis there. The `# %%` in python files lets me run code blocks in the same way as a notebook, but then i can run the file top to bottom aswell. It is starting to change the way i prototype. Not to mention it can open and edit .ipynb files

Re: JupyterLite – WASM-powered Jupyter running in the browser

#67
post #9

Earlier quoted context omitted.

It's convenient to directly open a notebook from a browser download or a slack message without having to fire up jupyter in a terminal and navigate it to that temp file.

I use vscode to open and run notebooks using the jupyter plugin. Works great. Don’t need to fire up the browser

Yeah, that's exactly the same reasoning. Because it's more convenient you run your notebooks in a dedicated tool. Nteract or Vscode or Pycharm..

Re: JupyterLite – WASM-powered Jupyter running in the browser

#68
post #51

How 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.

We offer a collaborative notebook experience on https://iko.ai.

It's our internal machine learning platform that solves a bunch of our problems. We initially started building iko for internal because our projects took a toll on us.

- No-setup, fresh, notebook environments with the most popular libraries pre-installed.

- Real-time collaborative notebooks to see your teammates' changes live. Pair program, troubleshoot, and prototype together.

- Deploys your Streamlit application (we use this for prototypes to show clients so that a data scientist does not have to spin up a VM on GCP, install dependencies and environment, get the model, build the application, etc).

- Multiple notebook versions

- Leverage GPUs and schedule long-running notebooks that survive closed browsers and network disruptions. Watch your notebook's output as it runs from multiple devices.

- Automatic experiment tracking to detect your models, parameters, and metrics and saves them without you remembering to do so or pollute your notebook with tracking code. Know which parameters produced which model on which data.

- Easily deploy your model and get a "REST endpoint" so data scientists don't tap on anyone's shoulder to deploy their model, and developers can use the models without being dragged into the ML realm. You also can invoke it by entering data or uploading a CSV file.

- Build a Docker image for your model and push it to a registry (DockerHub or GitLab for now) to use it wherever you want

- Monitor your models' performance on a live dashboard and know if your model is losing its predictive power.

- Publish notebooks as AppBooks: automatically parametrize a notebook to enable clients to interact with it without being overwhelmed by code, or exporting as PDF, or building an application, or mutating the notebook.

More on our roadmap. We're only focusing on actual problems we have faced serving our clients, and problems we are facing now. This is not a "startup idea"; we're building what we need but we'd love to hear your thoughts and problems you have faced we may not be familiar with.

Post reply on HN