Notebook Interfaces Are the Future
Notebook interfaces get a bad rap. It’s not that we dislike them, we just neglect them as tools for any serious software development. ML? Data visualization? Great! Building apps and websites using notebook interfaces? That’s a no-no.
The notebook coding interface is not a new idea. We can trace its origins from Donald Knuth’s idea of “Literate Programming”, an approach that advocates writing code, macros, documentation, and anything relevant, all in the same place.
Knuth’s vision was to move away from writing code in the manner imposed by the computer and instead enable programmers to write programs in the order demanded by the logic and flow of their thoughts. Today we have an assortment of such tools available for a variety of (niche) purposes, such as Wolfram Notebooks, Jupyter Notebook, and Observable.
But so far nobody has picked up the glove to make a notebook tool for coding run-of-the-mill apps and websites.
A Case for Notebook Interfaces
For those who tried, coding in a notebook interface can be a downright magical experience, and here’s why:
- Most tools that utilize this paradigm render the result of every line of code as they are written. This approach gives developers instant feedback, allowing them to iterate faster than ever before, and that means faster turnaround and better “flow state” for the developers themselves, which equals more enjoyment and better code.
- Notebooks take care of all DevOps and tooling considerations by providing a ready-made dev environment. This means that developers can focus on writing code and not on setting up and maintaining the infrastructure of the project. While some people love setting up their infrastructure (and are rewarded handsomely for it), I wager most of us would call it a nuisance. Wouldn’t it be great if we could just get straight to the code whenever we want to create something?
- The UI is clean, friendly, and minimalistic. IDEs like VSCode often appear intimidating to beginners. There’s none of that with notebook interfaces. Instead, they tend to resemble a Google Doc more than a regular code editor.
But there are also a few good reasons why we’re still not using notebook IDEs for most of our projects:
- The UI may be too simple for some users, with many features missing. There are no fancy debuggers or even terminals in your regular notebook editor and that limits the scale and depth of projects that can be built with it.
- Having a ready-made dev environment sacrifices the flexibility that comes with setting up your own custom infrastructure. DevOps may be a nuisance but it’s also an unavoidable part of most serious projects. While developers would be happy to avoid it on smaller-scale projects, any serious undertaking requires some form of a custom solution.
- Managing large projects with many files can be a nightmare in a notebook-type IDE. There’s probably a way to solve this, but nobody has cracked it yet.
What if we could enjoy all of the upsides of notebook interfaces while also mitigating the downsides? Wouldn’t that be a worthy undertaking? We believe so, which is why we started Djitsu.
Making a Better Notebook Interface
Djitsu began as a curiosity, but over a couple of iterations, it became clear to us that this development experience is fast, smooth, and addicting. In fact, once we got used to it, everything else started feeling slow, cumbersome, and outdated.
That’s when we asked ourselves: What if we create a notebook that’s simple, yet robust enough to use for production code? Flexible where needed, yet able to execute almost any kind of task? Such a code editor can be both easy to use and also truly multi-purpose, not confined to a single niche.
We believe that all of the drawbacks listed above can be solved by making the right compromises, and we know that if we do that, a notebook-type IDE can win big in the market today.
Come check out how well we’re doing so far.
Thoughts? Ideas? Bugs? Want to join the revolution? Feel free to ping us at contact (at) djit.su
