Diggy Newsletter #1
Hi everyone. My name is Kirill (or you may know me by oneearedrabbit on HN), and I’m a founder of Diggy . I want to thank everyone who tried Diggy so far. I cannot be happier to see you and have a chance to talk to you!
I hope to send you short (and hopefully sweet) updates every two weeks to explain what’s been done and what’s the motivation behind Diggy and its design principles. If you’re looking for more/less regular updates, let me know, there’re other options on how to make it happen. You can scroll all the way down to see what’s new.
As a full disclosure, Diggy is not the first (honestly speaking, it’s far from being the first) attempt on bringing Python to the web environment. As far as I know, the very first results of running Python in the browser were published almost a decade ago by Repl.it team, see: https://github.com/replit-archive/empythoned. It was also a demand for an interactive Python environment for a much longer time. For instance, the first IPython version was developed back in 2001.
Jupyter is built on a classic client-server architecture, which is not what I’m looking for. I do believe that recent technologies are pushing boundaries of edge-computing to new levels. Like Bret Victor said, the creative process works best when we have an immediate connection with the object of creation. I can see this happening when the entire Notebook runs in a web browser.
The second part why I’m working on Diggy is my frustration with Jupyter notebooks. I still do not grasp a hidden-state approach. It feels unnatural. Whenever I change a cell in Jupyter, I need to re-run manually all cells that depend on it. It’s a relief that I’m not alone: I don’t like notebooks . Diggy calculates a topology graph that knows which cells and in which order to execute. If you fight reactivity it may break, and it’s going to be a PITA. If you embrace it, you’ll find more peace than you ever imagined.
Ultimately, I’d like to mention several things that I learned after my first Show HN launch. The most challenging part was to find a balance between mobile and desktop/laptop devices support. On a mobile device, there’re lots of moving parts that may break the execution loop: limited CPU/RAM resources, support of WASM across a variety of browsers, unstable mobile networks to download the initial runtime.
What’s changed since last week:
- Diggy is almost three times faster now. When I launched Diggy on Show HN, it was hosted as a set of static files on Netlify. I wasn’t happy about their CDN. It felt very slow. I tried several other options and ended up with S3+Cloudfront, which provides a reasonable balance between infrastructure complexity and speed. On my WiFi, a Diggy runtime loads between 4-6 seconds now (it used to be about 13 seconds).
- I merged Python runtime with the main application. Those changes are hardly visible, but it’s a part of a bigger story to enable authentication & authorization.
- Mobile support is disabled for the time being. I had to prioritize other items. It’s a shame, but I know that it’s fixable.
Check it out: Diggy.