Introducing Nitro
I've been prototyping a new way to rapidly make web apps using pure #Python: H2O Nitro. It lets you program interactive GUIs using simple top-down code (no events, handlers, callbacks). Here’s a 7-page app in just 7 Python statements.
No HTML/CSS/Javascript know-how required. Plus, it's a library, not a full-blown web framework, so plugs into Flask, Tornado and Starlette. Think of it like a tiny edition of H2O Wave. Also, it's pre-alpha, so don't use it in production yet!
We develop lots of apps at H2O. Ideas get prototyped, demo'd, forked, cloned, modified all the time. There's 200-250 Wave apps now - I've lost count. And we're always looking for better, faster ways to go from prototype to production, while not losing on performance.
So what's the motivation behind Nitro? App development is complicated (ahem). Leaving aside UX/UI design, most apps, at the implementation level, deal with at least two tiers: client and server. Each has its own programming language and framework.
This implies at least two different kinds of developers, usually more if you include databases. Then there's the added (accidental) complexity of having to define and maintain an API or protocol for the UI and server to communicate correctly, even in the simplest of apps.
In contrast, authoring command-line apps is fairly simple. With Python, for example, input() waits for some input, and print() shows some output. String together a sequence of input() and print() statements, and you've got yourself an interactive app.
What if we could bring that level of simplicity to GUIs and client-server programming?
Granted, CLIs are not the unwieldy all-singing, all-dancing, event-driven state machines that GUIs are. But then again, a client server app with a GUI is not just any state machine, it's a distributed state machine.
Nobody will argue that managing state in a distributed state machine is way more complex to reason about and implement correctly compared to a non-distributed one.
So, if we have to develop interactive, graphical, distributed systems without having to deal with clients and servers and all the plumbing and ceremony in between, what would the simplest possible API look like?
What would UI composition and layout code look like? What would form and input handling look like? What would UI flow and navigation control look like? How would we make all that code as minimal as possible?
This is not just minimalism for minimalism's sake. Code rots. More code has more bugs. More code means more to read and understand and debate and reason about. It's also expensive to maintain: more code needs more programmers, and programmers have N^2 communication costs.
The best code, therefore, is no code at all. So then what's a good balance between code brevity, clarity and expressiveness without losing too much in the way of performance?
Further, can we stick with just one programming language for building the entire app? Can we target web, mobile and desktop apps from the same codebase? How quickly can we ship prototypes, get feedback, and iterate towards a finished product?
More important, how can such a thing stay laser-focused on UIs, and not reinvent the wheel on networking, security, persistence, deployment and hosting? Can it plug into a framework of your choice, or even existing applications, yet provide a simpler way to ship front-ends?
H2O Nitro is a very, very early stage prototype that tries to address the above requirements. It’s currently Python-only and only targets web apps, but we want to tackle R, Julia, Go at a minimum, and ship iOS/Android/Linux/OSX/Windows support by end 2022. Fingers crossed.
So far the API and ergonomics feel right, and initial feedback has been really good, so it seems to be on the right track.
Big caveat 1: Nitro is currently experimental. The API is mostly stable, but has critical missing features like cross-platform data visualization, back-button support in browsers, internationalization/localization, and live (real-time) sync. That said, we’ve started using it internally at H2O, with planned production usage, so expect rapid improvements and stability.
Big caveat 2: The UI and look/feel are strongly opinionated. Nitro is for you if you know Python basics, want to ship apps quickly, care about performance, don't want to futz around with obtuse front-end tooling, and don't care about a highly custom/branded UI.
That's it for now. Follow the project on Github at https://github.com/h2oai/nitro or https://twitter.com/h2o_nitro for updates. I’m really excited about it, and would love to know what you think, what you’d like to see, and where you’d like to see it go.
Happy hacking!